Techniczne SEO i Schema.org w praktyce – wdrożenie PortalMuzyczny.pl
Techniczne SEO to znacznie więcej niż tytuł, opis i kilka fraz kluczowych. Na przykładzie rzeczywistego wdrożenia PortalMuzyczny.pl pokazuję, jak łączyć WordPress, Schema.org, JSON-LD, canonical, Open Graph, obrazy, strukturę kategorii, API, OpenAPI, MCP i AI w jeden spójny system publikacyjny. To praktyczny materiał o tym, jak budować stronę czytelną jednocześnie dla użytkownika, wyszukiwarki i systemów maszynowych.
AutorKamil Mystek
Nowoczesne SEO działa jak architektura informacji. Treść odpowiada na potrzebę odbiorcy, HTML porządkuje dokument, Schema.org definiuje encje i relacje, linki budują hierarchię, obrazy obsługują wyszukiwarkę oraz kanały społecznościowe, a API i MCP udostępniają tę samą wiedzę aplikacjom i agentom AI.
@id łączą artykuł, autora, wydawcę, sekcję i obraz.Co znajduje się w tym HTML, a co generują wtyczki
Ten rozdział wyznacza techniczną granicę odpowiedzialności poszczególnych warstw serwisu. Treść publikacji obejmuje tekst, nagłówki, tabele, listy, ilustracje, podpisy i linki. Szablon strony odpowiada za jej publiczny układ, natomiast program „Pozycjonowanie strony” pobiera parametry zapisane przy wpisie i emituje metadane oraz Schema w odpowiedniej części dokumentu. Dzięki temu zmiana ustawienia w panelu aktualizuje warstwę techniczną bez ręcznego edytowania artykułu.
| Element końcowej strony | Właściciel | Czy znajduje się w tym pliku? | Kontrola |
|---|---|---|---|
| H1 publikacji | Szablon strony / tytuł wpisu | Nie — treść zaczyna się od H2 | Jeden H1 w finalnym DOM |
| Główny spis treści | Szablon publikacji | Nie — sekcje mają stabilne identyfikatory | Jedna lista kotwic i poprawne przewijanie |
| Autor, data, czas czytania | Szablon publikacji i dane WordPressa | Nie jako drugi komponent | Zgodność z profilem i datami wpisu |
| Tekst, objaśnienia i ilustracje | Ten fragment HTML | Tak | Widok desktop/mobile, dostępność i linki |
| Title, description, canonical i robots | „Pozycjonowanie strony” | Nie | Jedna wartość każdego rodzaju w <head> |
| Open Graph i karta X | „Pozycjonowanie strony” | Nie; artykuł jedynie wyjaśnia mechanizm | Źródło strony i podgląd platformy |
| Wykonywany JSON-LD | „Pozycjonowanie strony” oraz wyznaczone moduły domenowe | Nie | Jeden właściciel dla każdej klasy URL |
| Przykłady terminów i wartości | Treść edukacyjna | Tak, jako zwykły tekst lub kod widoczny | Brak znacznika uruchamiającego dane strukturalne |
Przepływ po zapisaniu artykułu
Redaktor tworzy wpis i wkleja treść. Następnie ustawia w panelu tytuł SEO, opis, canonical, robots, rodzaj publikacji, kategorię główną, daty, obrazy, autorów, źródła i encje. WordPress zapisuje treść oraz metadane jako oddzielne wartości. Podczas obsługi żądania szablon buduje widoczny układ publikacji, a program SEO podłącza wynik do sekcji <head> oraz właściwych hooków WordPressa. Przeglądarka dostaje jeden złożony dokument, mimo że jego części mają różnych właścicieli w kodzie.
Cache strony może przechowywać gotowy HTML. Po zmianie pola SEO, obrazu social albo ustawień organizacji trzeba wyczyścić odpowiednią warstwę cache: wtyczkę, serwer, CDN i ewentualny cache obiektowy. Generator obrazu społecznościowego używa wersjonowanej nazwy pliku, co ułatwia odświeżenie zasobu w zewnętrznych crawlerach. Test końcowy wykonuje się bez zalogowania i po opróżnieniu cache, ponieważ panel administracyjny pokazuje dane źródłowe, a robot otrzymuje wersję publiczną.
Kontrola duplikacji po wdrożeniu
Źródło strony warto przeszukać pod kątem liczby canonicali, meta description, zestawów Open Graph, H1 i bloków danych strukturalnych. Sama obecność kilku węzłów w jednym grafie jest prawidłowa; problemem są dwa niezależne systemy opisujące tę samą encję sprzecznymi wartościami. Na profilu artysty moduł „Artyści” może być właścicielem danych encji, a program SEO właścicielem canonical i Open Graph. Na zwykłym artykule pełny graf tworzy program SEO. Macierz właścicieli powinna być częścią dokumentacji technicznej projektu.
Aktualizacja motywu albo instalacja nowej wtyczki wymaga ponownego testu próbki. Szczególnie istotne są dodatki SEO, social sharing, breadcrumbs, AMP, cache, generatory stron i moduły niestandardowych typów. Każdy z nich może zacząć emitować własne metatagi lub Schema. Test regresji wykrywa zmianę, zanim powielony kod obejmie cały indeks witryny.
SEO jako system publikacyjny
Punkt wyjścia stanowi model serwisu: czym jest wydawca, jakie encje opisuje, jak wyglądają główne działy, gdzie znajduje się źródło prawdy i które adresy tworzą publiczny indeks wiedzy. Fraza kluczowa pojawia się później — jako język łączący pytanie odbiorcy z konkretnym dokumentem.
Portal muzyczny może zawierać newsy, analizy, recenzje, profile artystów, producentów sprzętu, koncerty, kalendarium, rankingi Spotify i rozbudowane działy historyczne. Każdy typ ma własny cykl życia oraz własny kontrakt danych. Artykuł ma autora i daty. Koncert ma termin oraz miejsce. Profil artysty opisuje osobę albo zespół. Kategoria agreguje dokumenty. Producent łączy markę, rodzaje sprzętu i powiązane publikacje.
@id, author, publisher, about, mentions, isPartOf.Źródło prawdy i reprezentacje
Najstabilniejszy model opiera się na jednym rekordzie treści oraz kilku deterministycznie tworzonych reprezentacjach. Aktualizacja nazwiska autora, obrazu głównego lub kategorii głównej powinna przejść do HTML, danych strukturalnych, API i mechanizmów odkrywania. Taki układ ogranicza rozjazdy między tym, co widzi człowiek, a tym, co odczytuje maszyna.
WordPress / baza danych
├── dokument HTML dla czytelnika i robota
├── meta title, description, canonical i robots
├── Open Graph oraz Twitter Card
├── graf JSON-LD / Schema.org
├── sitemap.xml oraz news-sitemap.xml
├── publiczne REST API opisane przez OpenAPI
└── serwer MCP i zasoby discovery dla agentów AIWartość tej architektury ujawnia się przy skali. Tysiąc artykułów, setki autorów i wiele kategorii można utrzymywać przez reguły, walidatory i precyzyjne pola redakcyjne. Człowiek odpowiada za znaczenie, źródła i decyzję publikacyjną. Program utrzymuje zgodność techniczną.
Jak przełożyć ten model na własną stronę i własny biznes
PortalMuzyczny.pl jest przykładem serwisu redakcyjnego, lecz sama metoda ma szersze zastosowanie. Najpierw powstaje model biznesu i jego publicznych obiektów, następnie typy stron, relacje, pola redakcyjne i reguły generowania. Sklep opisuje produkty, marki, kategorie, poradniki oraz punkty sprzedaży. Kancelaria opisuje usługi, specjalizacje, ekspertów, publikacje i lokalizacje. Producent łączy firmę z rodzinami urządzeń, dokumentacją, dystrybutorami i materiałami eksperckimi. Organizator wydarzeń wiąże wydarzenie, miejsce, wykonawców, bilety, daty i status. W każdej branży punktem startowym jest rzeczywista struktura działalności.
Etap projektowy: inwentaryzacja adresów i encji
Audyt warto rozpocząć od listy wszystkich klas publicznych adresów. Sam wykaz pojedynczych podstron szybko traci aktualność; klasa URL opisuje regułę działającą dla całej grupy. Dla WordPressa typowy katalog obejmuje stronę główną, strony statyczne, wpisy, kategorie, tagi, profile autorów, wyniki wyszukiwania, paginację, załączniki, niestandardowe typy treści oraz ich archiwa. Dodatkowe wtyczki wprowadzają kolejne klasy: produkty, wydarzenia, artyści, producenci, rankingi, kursy, lokalizacje lub oferty.
| Pytanie projektowe | Przykład portalu muzycznego | Przykład innej firmy | Decyzja techniczna |
|---|---|---|---|
| Co jest organizacją? | Wydawca PortalMuzyczny.pl | Spółka prowadząca sklep lub kancelarię | Jeden trwały rekord, logo, dane kontaktowe i publiczne zasady |
| Co jest główną treścią? | News, analiza, recenzja | Poradnik, oferta, dokumentacja produktu | Osobny typ wpisu i zestaw wymaganych pól |
| Co jest osobą? | Autor, artysta, redaktor | Ekspert, lekarz, prawnik, instruktor | Publiczny profil z trwałym adresem i zakresem kompetencji |
| Co jest kolekcją? | Gatunek, dekada, dział newsów | Kategoria produktów, usługa, region | Opisowa strona archiwum i uporządkowane linkowanie |
| Co ma własny czas? | Koncert, premiera, pozycja rankingu | Szkolenie, targi, promocja, nabór | Właściwy moment, strefa czasowa, status i archiwum |
| Co ma wiele wariantów? | Obraz artykułu dla treści, Discover i social | Zdjęcie produktu, miniatura, karta kampanii | Jedno źródło plus kontrolowane kadry i kanały dystrybucji |
Dla każdej klasy URL powstaje krótka karta architektoniczna. Zawiera cel użytkownika, właściciela danych, źródło tytułu, zasady canonical, robots, główny typ treści, wymagane obrazy, autora, daty, relację nadrzędną, status w sitemapie oraz oczekiwane zachowanie wyszukiwarki wewnętrznej. Taka karta upraszcza rozmowę między właścicielem firmy, redakcją, SEO, programistą i projektantem.
Macierz źródeł prawdy
Każde pole powinno mieć jednego właściciela. Tytuł dokumentu może pochodzić z pola SEO, H1 z tytułu wpisu, nazwa osoby z profilu użytkownika, a nazwa wydawcy z ustawień globalnych. Generator może stosować bezpieczne wartości domyślne, lecz kolejność dziedziczenia musi być jawna. Przykładowa reguła obrazu społecznościowego wygląda tak: obraz wskazany dla konkretnej sieci → wspólny obraz social → preferowany obraz Google → obraz wyróżniający → globalny obraz marki. Panel powinien pokazać finalnie wybrany zasób, dzięki czemu redaktor widzi wynik przed publikacją.
Ustawienia globalne
Nazwa organizacji, logo, język, mapa witryny, domyślny obraz, profile zewnętrzne, adres dokumentacji, strony zasad, polityka indeksacji oraz przełączniki modułów. Dane globalne powinny zmieniać się rzadko i przechodzić osobny przegląd.
Ustawienia typu treści
Wymagane pola, dopuszczalne typy, domyślne robots, obecność w sitemapie, schemat adresów, role użytkowników i sposób prezentacji. Reguła dla artykułu różni się od reguły wydarzenia lub profilu eksperta.
Ustawienia pojedynczego rekordu
Unikalny tytuł, opis, canonical, obraz, kategoria główna, encje, źródła, autorzy, sponsor, data i ewentualne wyjątki. To warstwa, w której redaktor opisuje konkretny dokument.
Dane obliczane
URL, identyfikatory, liczba słów, czas czytania, daty w formacie maszynowym, wymiary obrazu, breadcrumbs, powiązania oraz wynik analiz. Program liczy je deterministycznie z danych źródłowych.
Minimalna specyfikacja dla wykonawcy
Firma zamawiająca wdrożenie może przygotować specyfikację w postaci kilkunastu konkretnych odpowiedzi. Wystarczą: domena, rodzaj działalności, typy publikowanych treści, lista ról użytkowników, obecne wtyczki SEO, mapa kluczowych podstron, języki, kanały społecznościowe, wymagania Google News lub Discover, systemy zewnętrzne, których dane mają być pobierane, oraz proces akceptacji publikacji. Do tego dochodzą przypadki wyjątkowe: treści płatne, sponsorowane, czasowe, wielolokalizacyjne, pochodzące od społeczności lub tworzone przez wiele redakcji.
- Zdefiniuj cel biznesowy.Przykład: zwiększenie widoczności eksperckich poradników, uporządkowanie katalogu marek albo udostępnienie danych aplikacji mobilnej.
- Wybierz reprezentatywną próbkę.Po jednym adresie strony głównej, artykułu, kategorii, autora, oferty, wydarzenia i niestandardowego typu treści.
- Zapisz stan wyjściowy.Źródło HTML, widoczne elementy, aktualne metatagi, błędy walidacji, stan map i dane Search Console.
- Ustal właścicieli warstw.Jedna wtyczka generuje canonical i główny graf, moduły domenowe odpowiadają za swoje encje, a szablon za widoczną strukturę.
- Zaprojektuj pola redakcyjne.Każde pole otrzymuje nazwę zrozumiałą dla użytkownika, pomoc kontekstową, walidację i bezpieczny fallback.
- Wdróż na środowisku testowym.Porównaj wynik z próbką i sprawdź konflikty z motywem, cache, CDN, builderem oraz innymi rozszerzeniami.
- Uruchom kontrolowaną migrację.Najpierw raport i tryb testowy, później zapis, ponowna walidacja i monitoring indeksacji.
- Ustal utrzymanie.Wersjonowanie, kopie, log zmian, procedura aktualizacji i pomiar efektów zamykają cykl wdrożenia.
Przykłady rozszerzeń branżowych
Mechanizm może zostać dopasowany do struktury firmy zamiast narzucać jeden uniwersalny formularz. Dla sklepu audio warto połączyć producenta, kategorię urządzenia, serię, model, recenzję i punkt sprzedaży. Dla kliniki potrzebne bywają profile specjalistów, procedury, placówki, terminy, języki obsługi i medyczny proces zatwierdzania. Dla dewelopera nieruchomości dochodzą inwestycje, budynki, lokale, etapy, lokalizacje i dostępność. Dla organizatora koncertów kluczowe są wydarzenia, wykonawcy, miejsca, partnerzy biletowi, zmiany terminów i archiwum. Dla portalu finansowego pierwszeństwo mają autor, weryfikator, źródła danych, czas aktualizacji i widoczna metodologia.
Najlepszy rezultat daje wdrożenie przygotowane pod model danych, uprawnienia i drogę klienta konkretnej organizacji. Wtedy panel redakcyjny przypomina język biznesu, automatyzacja pilnuje technicznych szczegółów, a kod wynikowy zachowuje spójność w całym serwisie.
Cztery architektury referencyjne dla innych użytkowników programu
Ogólny rdzeń SEO może pozostać wspólny, a warstwa domenowa zmienia się wraz z biznesem. Poniższe warianty pokazują, jak dobrać typy treści, pola, relacje i testy. Są to punkty wyjścia do specyfikacji, a finalny model powinien powstać po audycie rzeczywistych danych i procesu obsługi klienta.
Wydawca, portal branżowy i newsroom
Portal publikuje wiele dokumentów, dlatego główną jednostką operacyjną jest artykuł. Rekord powinien mieć autora, datę pierwszej publikacji, kontrolowaną datę aktualizacji, kategorię główną, typ redakcyjny, źródła, obrazy i status. Warstwa globalna opisuje wydawcę, redakcję, zasady, kontakt i finansowanie. Profile autorów łączą biogram z archiwum materiałów. Kategorie stają się kolekcjami, a strony działów prowadzą do kilku kolekcji i zasobów specjalnych.
Dedykowane funkcje mogą obejmować kolejkę akceptacji, współautorów, fact-checkera, rejestr korekt, embargo, datę wygaśnięcia, syndykację, osobną mapę newsową i pulpit jakości. Integracja z agencją prasową potrzebuje identyfikatora źródłowego, stanu licencji oraz zabezpieczenia przed powtórnym importem. Materiał automatycznie pobrany powinien trafić do szkicu lub kolejki, a publikacja wymagać uprawnienia redakcyjnego.
| Obszar newsroomu | Pole źródłowe | Automatyzacja | Test odbioru |
|---|---|---|---|
| Autorstwo | Autor główny, współautor, redaktor, weryfikator | Profile, podpisy i role | Każda emitowana rola jest widoczna |
| Czas | Publikacja, modyfikacja, embargo | ISO 8601, kolejność i publikacja zaplanowana | Widok, kod i mapa mają zgodne wartości |
| Źródła | URL, organizacja, cytowanie, backstory | Walidacja adresów i potwierdzenie | Twierdzenia prowadzą do właściwych źródeł |
| Promocja | Sponsor, partner, rodzaj relacji | Widoczny disclosure i metadane | Oznaczenie pojawia się przed właściwą treścią |
| Korekta | Opis, data, URL polityki | Historia zmiany i kontrolowana modyfikacja | Odbiorca rozumie zakres poprawki |
| Obrazy | Źródło, trzy kadry, social, prawa | Generatory, dziedziczenie i podglądy | Każdy kanał pokazuje właściwy kadr |
Test reprezentatywny obejmuje świeży news, starszy evergreen, analizę, materiał sponsorowany, korektę, wpis wielu autorów i artykuł bez własnego obrazu. Każdy przypadek sprawdza front, źródło, mapę, podgląd społecznościowy oraz odpowiedź API. Search Console dostarcza później informacji o indeksowaniu, wynikach rozszerzonych, Discover i Google News.
Producent, sklep i katalog sprzętu
W katalogu główną osią może być produkt, producent albo rozwiązanie. Producent wytwarza wiele kategorii urządzeń, a jedna kategoria zawiera produkty wielu producentów. Artykuł może dotyczyć pojedynczego modelu, porównania, technologii albo całej rodziny. Relacja powinna być dwukierunkowa w zapytaniach: profil Monitor Audio pokazuje kategorie i publikacje tej marki, a strona zestawów głośnikowych pokazuje producentów oraz artykuły powiązane z urządzeniami tego typu.
Sam fakt zaznaczenia producenta przy artykule może wystarczyć do pokazania publikacji na profilu marki. Strona kategorii sprzętu wymaga dodatkowej reguły: artykuł kwalifikuje się przez bezpośrednią kategorię sprzętu albo przez przypisanego producenta, który ma tę kategorię. Najlepszy model zapisuje obie relacje jawnie, ponieważ producent może działać w wielu segmentach. Artykuł o słuchawkach JBL powinien trafiać do słuchawek, a tekst o wzmacniaczu tej samej marki do wzmacniaczy, zamiast automatycznie pojawiać się we wszystkich kategoriach JBL.
Panel Gutenberga może oferować wyszukiwalny wybór istniejącego producenta, kategorii sprzętu, serii i modelu. Dodawanie nowej marki powinno pozostać w kokpicie z pełnym formularzem bio, witryny, logo, tła, ustawień SEO i danych branżowych. Dzięki temu redaktor artykułu wybiera encję, a administrator encji odpowiada za jej jakość. Identyczna zasada działa dla artystów, lekarzy, autorów, hoteli i innych profilów o rozbudowanych danych.
| Encja katalogu | Przykładowe pola | Relacje | Widok publiczny |
|---|---|---|---|
| Producent | Nazwa, bio, strona, logo, tło, kraj | Kategorie, produkty, artykuły | Hero, opis, kategorie i publikacje |
| Kategoria sprzętu | Nazwa, opis, obraz, hierarchia | Producenci, produkty, artykuły | Hero kategorii i filtrowana kolekcja |
| Seria | Nazwa, producent, okres, opis | Modele i publikacje | Chronologia i lista modeli |
| Produkt | Model, wariant, parametry, zdjęcia | Producent, kategoria, seria, recenzje | Karta produktu lub encyklopedii |
| Artykuł | Temat, producent, kategoria, modele | Linki do encji katalogu | Publikacja i moduły powiązane |
Obrazy mają kilka niezależnych źródeł. Profil producenta używa własnego tła i logo. Karta producenta może używać zdjęcia przypisanego do marki. Karta kategorii powinna zawsze używać obrazu kategorii, dzięki czemu „Zestawy głośnikowe” przedstawiają kolumny, nawet jeśli pierwszy producent ma fotografię salonu lub słuchawek. CSS z object-fit: cover utrzymuje wypełnienie, a overflow: hidden chroni ramę karty. Nazwy wielu kategorii mogą układać się w zawijany pasek bez wychodzenia poza szary prostokąt.
Firma usługowa i eksperci lokalni
Firma usługowa łączy organizację, usługi, ekspertów, lokalizacje, obszary obsługi, poradniki, realizacje i kontakt. Strona główna opisuje markę. Każda usługa ma własną intencję oraz zakres. Lokalizacja przedstawia realną placówkę lub obsługiwany region. Profil eksperta pokazuje kompetencje, kwalifikacje i publikacje. Artykuły wspierają usługę, lecz zachowują własny cel informacyjny.
Rozbudowa programu może dodać cenniki, formularze kwalifikacyjne, terminy, języki obsługi, certyfikaty, numery uprawnień, zespoły i oddziały. Dla branż regulowanych potrzebna jest dodatkowa kontrola treści i odpowiedzialności. Pole kwalifikacji powinno mieć źródło i datę ważności, a rola weryfikatora pozostawać widoczna. Lokalizacja musi odpowiadać realnemu miejscu lub jasno opisanemu obszarowi, zamiast tworzyć dziesiątki identycznych stron z nazwą miasta.
Wyszukiwarka wewnętrzna może rozdzielać materiały, usługi i osoby. Pasek w głównym menu szuka wyłącznie artykułów i prowadzi do strony wyników otwartej według przyjętej polityki interfejsu. W katalogu ekspertów użytkownik filtruje specjalizację, język i placówkę. Każdy formularz ma własny endpoint, zakres danych i komunikat dostępności.
Wydarzenia, kalendarium i dane okresowe
Serwis wydarzeń ma dwa rodzaje dokumentów: opis wydarzenia oraz kolekcję kalendarza. Pojedynczy koncert otrzymuje trwały URL, wykonawcę, miejsce, termin, status i bilety. Kalendarz agreguje rekordy według dnia, miasta albo artysty. Po upływie terminu wydarzenie przechodzi do archiwum, lecz zachowuje adres i faktyczną datę. Dzisiejsza kartka kalendarium może zawierać fakty sprzed dekad, a każdy z nich zachowuje własny rok.
Integracja partnerska wymaga deduplikacji. Klucz może łączyć identyfikator partnera, wykonawcę, miejsce i początek. Aktualizacja biletu albo ceny zmienia rekord, a nowy termin przełożonego koncertu aktualizuje status i poprzednią datę. Import zapisuje ostatni udany czas synchronizacji, odpowiedź źródłową lub jej skrót oraz błąd ostatniej próby. Panel administracyjny powinien rozróżniać brak rekordów, błąd partnera i filtr, który niczego nie znalazł.
Ranking okresowy działa podobnie. Rekord pozycji należy do określonego zestawienia, a zestawienie do okresu i zakresu. Archiwum przechowuje kolejne tygodnie, dzięki czemu zapytanie z datą daje deterministyczną odpowiedź. Asystent AI powinien wywołać endpoint rankingu z parametrami zamiast tworzyć odpowiedź z przypadkowych artykułów zawierających nazwę Spotify.
Najpierw powstaje model realnych obiektów biznesu, następnie relacje, formularze, reguły generowania i testy. Rdzeń SEO pozostaje wspólny, a funkcje domenowe otrzymują osobne moduły. Właściciel treści pracuje na pojęciach swojej branży, zaś program automatycznie składa wynikową warstwę techniczną.
Graf encji PortalMuzyczny.pl
Schema.org opisuje znaczenie danych. JSON-LD jest formatem, w którym te znaczenia można opublikować bez mieszania ich z warstwą prezentacji. Największą wartość daje wspólny graf z identyfikatorami @id, ponieważ kolejne węzły odwołują się do tej samej organizacji, witryny, osoby i publikacji.
SearchAction.sameAs i worksFor.isPartOf i hasPart.MusicGroup, Person, Event, Organization, produkt lub miejsce wskazane przez about i mentions.Co potwierdza kod działającego artykułu
W dostarczonym kodzie artykułu o HammerFall znajduje się jeden blok JSON-LD z @graph. Zawiera cztery główne węzły: NewsMediaOrganization, WebSite, publikację o typach NewsArticle i AnalysisNewsArticle oraz BreadcrumbList. Węzeł publikacji ma adres zakończony #main i łączy m.in. datePublished, dateModified, image, thumbnailUrl, keywords, about, mentions, wordCount, timeRequired, articleSection, author, publisher, publishingPrinciples oraz isPartOf.
Każda realna encja otrzymuje stabilny identyfikator, a wszystkie strony odwołują się do niego konsekwentnie. Organizacja może mieć https://portalmuzyczny.pl/#organization, witryna https://portalmuzyczny.pl/#website, a główna encja konkretnego dokumentu jego kanoniczny URL zakończony #main.
| Relacja | Znaczenie w modelu | Źródło danych | Kontrola redakcyjna |
|---|---|---|---|
mainEntityOfPage | Wskazuje dokument, którego główną encją jest publikacja. | Kanoniczny URL wpisu | URL zgodny z canonical |
author | Łączy publikację z trwałą encją osoby. | Profil użytkownika/autora | Widoczny podpis i publiczny profil |
publisher | Łączy materiał z organizacją odpowiedzialną za publikację. | Ustawienia wydawcy | Jedno wspólne @id |
about | Określa główne tematy i encje materiału. | Pola artykułu i encje portalu | Zgodność z osią tekstu |
mentions | Wskazuje osoby, marki, miejsca i utwory istotnie wspomniane w materiale. | Pola artykułu | Obecność w widocznej treści |
isPartOf | Odwzorowuje przynależność wpisu do kategorii, działu i witryny. | Kategoria główna i jej powiązana podstrona | Ta sama ścieżka w linkach i breadcrumbs |
sameAs | Łączy encję z jej wiarygodnymi profilami lub identyfikatorami zewnętrznymi. | Profil autora, artysty lub organizacji | Wyłącznie adresy tej samej encji |
Kontrakt techniczny pojedynczego artykułu
Dobry artykuł posiada dwie zgodne warstwy: redakcyjną i maszynową. Warstwa redakcyjna obejmuje tytuł, lead, logiczne nagłówki, źródła, autora, daty, zdjęcia oraz powiązane publikacje. Warstwa maszynowa zapisuje ten sam sens w metadanych, grafie Schema i interfejsach portalu.
Warstwa widoczna
- Jeden H1 generowany przez szablon lub wtyczkę. Tekst artykułu zaczyna się od H2, dzięki czemu hierarchia dokumentu pozostaje jednoznaczna.
- Lead odpowiadający na intencję. Czytelnik od pierwszego ekranu rozumie zakres, wartość i charakter materiału.
- H2 jako główne problemy, H3 jako ich rozwinięcia. Nagłówki działają jak spis modelu informacji.
- Podpis autora połączony z publicznym profilem. Profil przedstawia kompetencje, obszary tematyczne i inne publikacje.
- Widoczna data publikacji oraz aktualizacji. Istotna aktualizacja otrzymuje krótką informację o zakresie zmian.
- Źródła osadzone przy twierdzeniach oraz uporządkowane na końcu. Cytowania prowadzą do dokumentów, danych i materiałów pierwszego wyboru.
- Transparentność komercyjna. Sponsor, partner, produkt lub własna usługa są opisane językiem zrozumiałym dla odbiorcy.
Warstwa dokumentu HTML
<title>
Zwięzły tytuł wyniku, zawierający istotę materiału i nazwę serwisu wtedy, gdy pomaga odbiorcy. Jego brzmienie może być krótsze od H1.
Meta description
Konkretny opis korzyści i zakresu. Najlepiej działa jak miniaturowy lead, bez listy powtarzanych słów kluczowych.
Canonical
Jeden preferowany URL dokumentu, zgodny z adresem w Schema, sitemapie, linkowaniu wewnętrznym i Open Graph.
Robots
Dla publicznej publikacji: index,follow,max-image-preview:large. Pozostałe limity podglądu wynikają z polityki serwisu.
Dobór typu publikacji
| Materiał | Typ bazowy | Podtyp redakcyjny | Przykładowe zastosowanie |
|---|---|---|---|
| Wiadomość | NewsArticle | NewsArticle | Premiera, komunikat, aktualne wydarzenie |
| Analiza | NewsArticle | AnalysisNewsArticle | Interpretacja danych, zjawiska lub utworu |
| Reportaż / relacja własna | NewsArticle | ReportageNewsArticle | Relacja z koncertu, festiwalu lub wydarzenia |
| Opinia / komentarz | NewsArticle | OpinionNewsArticle | Autorski punkt widzenia podpisanej osoby |
| Recenzja redakcyjna | NewsArticle | ReviewNewsArticle | Recenzja albumu, koncertu lub sprzętu |
| Poradnik evergreen | Article lub TechArticle | Według charakteru dokumentu | Materiał edukacyjny o trwałej wartości |
| Profil autora | ProfilePage | Główna encja Person | Biogram i archiwum publikacji |
| Kategoria | CollectionPage | Lista publikacji | Dział tematyczny i jego opis |
Dane przekazywane generatorowi Schema
Redaktor uzupełnia znaczenie materiału w polach programu, a generator tworzy wynikowy graf poza treścią artykułu. Do rekordu publikacji trafiają: właściwy rodzaj materiału, kanoniczny URL, tytuł, moment publikacji, moment istotnej modyfikacji, autor, wydawca, obrazy, kategoria główna, encje główne i encje wspomniane. Wartości powstają w jednym miejscu, przechodzą walidację i są emitowane jeden raz przez wtyczkę.
Treść artykułu opisuje architekturę i sposób pracy redakcji. Wtyczka odpowiada za składnię JSON-LD, kontekst Schema.org, identyfikatory, połączenia węzłów oraz publikację kodu w dokumencie. Takie rozdzielenie chroni stronę przed dwoma konkurującymi grafami.
Google zaleca przy typach Article, NewsArticle i BlogPosting m.in. precyzyjnego autora, daty z właściwą strefą czasową, zwięzły nagłówek oraz reprezentatywne, indeksowalne obrazy. Szczegóły publikuje dokumentacja Article structured data.
Daty publikacji, aktualizacji, wydarzeń i archiwów: jeden zapis, kilka znaczeń
Data jest elementem semantycznym, a nie ozdobą wpisu. Artykuł ma moment pierwszej publikacji i moment istotnej modyfikacji. Koncert ma początek, czasem koniec oraz status. Rocznica historyczna odnosi się do dnia sprzed wielu lat, choć opisujący ją materiał mógł powstać dzisiaj. Ranking Spotify ma okres zestawienia oraz czas pobrania danych. Połączenie tych wartości w jedno pole prowadzi do błędów: wydarzenie sprzed trzydziestu lat zaczyna wyglądać jak dzisiejsze, a dzisiejszy artykuł otrzymuje historyczną datę publikacji.
Cztery osie czasu, które trzeba rozdzielić
| Oś czasu | Znaczenie | Przykład | Źródło prawdy |
|---|---|---|---|
| Publikacja dokumentu | Moment pierwszego publicznego udostępnienia artykułu | 5 września 2026, godz. 10:00 | Data publikacji rekordu WordPress |
| Modyfikacja dokumentu | Moment znaczącej zmiany informacji widocznej dla czytelnika | 5 września 2026, godz. 12:30 | Data modyfikacji lub kontrolowana data redakcyjna |
| Czas opisywanego zdarzenia | Faktyczny moment koncertu, premiery, założenia firmy lub wydarzenia historycznego | 5 września 1996 | Rekord zdarzenia, źródło historyczne albo baza koncertów |
| Okres danych | Zakres, którego dotyczy ranking, raport lub zestawienie | Tydzień 31.08–6.09.2026 | Źródłowy okres raportowy i identyfikator zestawienia |
| Czas pobrania | Moment synchronizacji danych z zewnętrznego API | 5 września 2026, godz. 06:15 UTC | Log importu lub znacznik odpowiedzi API |
| Data wygaśnięcia | Moment zakończenia ważności czasowej informacji | Sprzedaż biletów do 10 października 2026 | Reguła biznesowa konkretnej oferty lub publikacji |
Na stronie „Dziś w historii muzyki” nagłówek może mówić o bieżącym dniu, a każda pozycja opisuje zdarzenie z konkretnego roku. Materiał opublikowany 5 września 2026 r. zachowuje własną datę publikacji z 2026 r. Wpis o zdarzeniu z 5 września 1996 r. przechowuje rok 1996 przy encji historycznej. Interfejs może obliczyć tekst „30 lat temu”, lecz wartością źródłową pozostaje pełna data zdarzenia. Dzięki temu za rok interfejs pokaże „31 lat temu” bez ręcznej zmiany rekordu, a maszyna nadal odczyta prawidłowy rok.
Format ISO 8601 w polach maszynowych
Wartości dat i godzin generowane przez program stosują ISO 8601. Dla daty z dokładną godziną zapis obejmuje rok, miesiąc, dzień, literę T, czas i przesunięcie strefy. Przykład czasu lokalnego w Polsce latem to 2026-09-05T14:30:00+02:00. Ten sam moment w UTC można zapisać jako 2026-09-05T12:30:00Z. Wydarzenie całodniowe albo historyczny dzień o nieznanej godzinie otrzymuje samą datę: 1996-09-05.
| Sytuacja | Prawidłowa wartość maszynowa | Tekst widoczny dla polskiego czytelnika | Powód |
|---|---|---|---|
| Publikacja z godziną w Warszawie | 2026-09-05T10:00:00+02:00 | 5 września 2026, 10:00 | Przesunięcie określa jednoznaczny moment |
| Ten sam moment w UTC | 2026-09-05T08:00:00Z | 5 września 2026, 10:00 czasu polskiego | Z wskazuje UTC |
| Wydarzenie całodniowe | 2026-09-05 | 5 września 2026 | Brak sztucznej godziny północy |
| Historyczne zdarzenie | 1996-09-05 | 5 września 1996 — 30 lat temu | Rok wydarzenia pozostaje częścią faktu |
| Koncert z podaną godziną | 2026-10-14T19:30:00+02:00 | 14 października 2026, 19:30 | Użytkownik zna faktyczny początek i strefę |
| Znany dzień, godzina czeka na ogłoszenie | 2026-10-14 | 14 października 2026, godzina zostanie podana | Dokładność wartości odpowiada dokładności źródła |
Zapis 05.09.2026 jest czytelny lokalnie, lecz nadaje się do warstwy widocznej, a nie do pola maszynowego. Wartość 2026-09-05T00:00:00 stwierdza faktyczny początek o północy. Gdy godzina jest nieznana, lepszą informacją jest sama data. Google w dokumentacji wydarzeń zaleca pełny czas z przesunięciem UTC dla znanej godziny oraz sam dzień dla wydarzeń całodniowych lub czasu jeszcze nieogłoszonego.
Data publikacji i data modyfikacji
Pierwsza publikacja zachowuje stały moment. Korekta literówki, zmiana przecinka albo techniczne ponowne zapisanie wpisu nie powinny sztucznie odświeżać wiadomości. Znacząca aktualizacja może otrzymać nowy moment modyfikacji, o ile czytelnik widzi zakres zmiany. Przykłady znaczącej aktualizacji to dodanie wyniku wydarzenia, potwierdzonej listy wykonawców, nowej wypowiedzi źródła, sprostowania lub obszernego rozdziału wynikającego z nowych danych.
Program „Pozycjonowanie strony” pobiera daty bez filtra prezentacyjnego WordPressa i formatuje je przez standard DATE_W3C. Mechanizm korzysta z właściwej strefy witryny. Gdy WordPress przy zaplanowanym wpisie przechowuje przejściowo modyfikację wcześniejszą od publikacji, program wyrównuje ją do momentu publikacji. Moduł zaawansowany pozwala ustawić kontrolowaną redakcyjną datę modyfikacji dopiero po aktywacji i potwierdzeniu danych konkretnego materiału.
Moment modyfikacji powinien być równy momentowi publikacji albo późniejszy. Widoczna data, metadane artykułu, mapa Google News i dane zwracane przez API powinny opisywać ten sam stan. Google zaleca wyraźną datę i godzinę przy artykule oraz przestrzega przed sztucznym odświeżaniem materiału bez istotnego uzupełnienia.
Koncert przełożony, odwołany albo wielodniowy
Zmiana terminu koncertu wymaga zachowania tożsamości wydarzenia. Rekord utrzymuje stały URL i pierwotne dane identyfikacyjne. Nowy termin staje się bieżącym początkiem, poprzedni termin trafia do pola poprzedniej daty, a status wskazuje przełożenie. Dla odwołania zachowuje się znany termin i miejsce, po czym zmienia status na odwołany. Użytkownik oraz system wyszukujący mogą wtedy rozpoznać tę samą imprezę i jej aktualny stan.
Wydarzenie trwające kilka dni otrzymuje początek i koniec. Kilka oddzielnie biletowanych występów warto modelować jako osobne wydarzenia, ponieważ każdy ma własny termin, dostępność i URL docelowy. Integracja z Eventim lub innym systemem biletowym powinna przechowywać zewnętrzny identyfikator, oryginalny URL, czas ostatniej synchronizacji oraz mapowanie strefy. Dzięki temu ponowny import aktualizuje istniejący rekord zamiast tworzyć kopię.
| Zmiana | Co pozostaje stałe | Co aktualizujemy | Co pokazujemy odbiorcy |
|---|---|---|---|
| Przełożenie | URL, identyfikator, nazwa, wykonawca | Nowy start, poprzedni start, status | Nowy termin i wyraźna informacja o przełożeniu |
| Odwołanie | URL, termin identyfikujący, miejsce | Status wydarzenia | Komunikat o odwołaniu oraz źródło informacji |
| Zmiana miejsca | URL i identyfikator | Lokalizacja, ewentualnie instrukcje wejścia | Aktualne miejsce i data zmiany |
| Wydarzenie wielodniowe | Jedna encja wydarzenia | Początek oraz koniec | Pełny zakres dat |
| Oddzielne występy | Nazwa cyklu lub trasy | Osobny rekord każdej daty | Oddzielne strony i bilety |
Archiwa rankingów i danych cyklicznych
Ranking Spotify wymaga co najmniej czterech wymiarów: zakresu geograficznego, okresu, pozycji i utworu. Bieżąca tabela może przedstawiać najnowszy dostępny okres, a archiwum powinno zachować każdą historyczną serię pod stabilnym identyfikatorem. Zapytanie „pierwsze miejsce w Polsce 12 tygodnia 2025” różni się od zapytania „obecny numer jeden”. API oraz asystent AI potrzebują jawnych parametrów scope, okresu i paginacji, aby zwrócić właściwy rekord.
Czas pobrania służy do kontroli synchronizacji. Okres rankingu opisuje znaczenie danych. Data publikacji strony mówi, kiedy portal udostępnił dany dokument. Te trzy wartości mogą się różnić i każda odpowiada na inne pytanie. Ten sam model pasuje do kursów walut, cenników, rozkładów, wyników sportowych i raportów sprzedażowych.
Lista kontrolna dat dla własnej strony
- Ustaw strefę WordPressa na nazwany region, np. Europe/Warsaw, a nie na ręcznie stałe przesunięcie.
- Przechowuj źródłową datę i godzinę bez lokalnego formatowania wyświetlania.
- Generuj zapis ISO 8601 z rzeczywistym przesunięciem obowiązującym w danym dniu.
- Dla nieznanej godziny przechowuj samą datę zamiast północy.
- Rozdziel publikację dokumentu od czasu opisywanego zdarzenia.
- Rozdziel okres raportu od momentu importu.
- Aktualizuj moment modyfikacji po istotnej zmianie treści i pokaż zakres aktualizacji.
- Zachowuj poprzednią datę wydarzenia przy przełożeniu oraz publikuj status.
- Porównuj datę widoczną, kod generowany przez wtyczkę, mapę i odpowiedź API.
- Testuj zmianę czasu letniego, wpis zaplanowany, import UTC, wydarzenie całodniowe i rekord historyczny.
Szczegółowe reguły dla publikacji opisuje dokumentacja Google Article, a zasady czasu wydarzeń, stref i przełożeń — Google Event. W treści artykułu wystarczają objaśnienia i przykłady wartości. Finalną strukturę maszynową generuje program.
WebP, ALT, podpisy i osobne obrazy dla każdego kanału
Obraz jest samodzielnym zasobem informacyjnym. Ma treść, kontekst, warianty rozmiaru, właściciela praw, podpis oraz kilka miejsc dystrybucji. Plik wyświetlany w artykule, kadr Discover, obraz w danych Article i plansza udostępniana w komunikatorze mogą pochodzić z jednej fotografii, lecz pełnią różne role.
WebP w treści artykułu
Google Search obsługuje WebP, a nowoczesne przeglądarki potrafią pobrać wariant dobrany do szerokości ekranu. WebP sprawdza się jako format zdjęć umieszczonych w treści i obrazów wyróżniających: pozwala zachować dobrą jakość przy niższej masie pliku. Ostateczną jakość wyznaczają parametry kompresji, rozdzielczość źródła i sposób skalowania. Sama zmiana rozszerzenia pliku daje jedynie nowy kontener; realna optymalizacja wymaga pomiaru wagi i kontroli ostrości.
Google odkrywa obrazy z atrybutu src elementu <img>. Warianty responsywne można przekazać przez srcset i sizes, a <picture> pozwala wybrać format. Fallback w src zapewnia stabilne odkrywanie oraz obsługę klientów o węższych możliwościach.
<picture>
<source
type="image/avif"
srcset="monitor-audio-768.avif 768w, monitor-audio-1600.avif 1600w">
<source
type="image/webp"
srcset="monitor-audio-768.webp 768w, monitor-audio-1600.webp 1600w">
<img
src="monitor-audio-1600.jpg"
srcset="monitor-audio-768.jpg 768w, monitor-audio-1600.jpg 1600w"
sizes="(max-width: 768px) 100vw, 1180px"
width="1600"
height="900"
alt="Kolumny Monitor Audio ustawione w salonie odsłuchowym"
loading="lazy"
decoding="async">
</picture>Obraz LCP widoczny na pierwszym ekranie warto pobierać priorytetowo, z pełnymi wymiarami width i height. Obrazy położone niżej mogą korzystać z loading="lazy". Każdy wariant powinien zachować właściwy kadr, czytelny temat i rozsądną wagę.
ALT, podpis, opis i nazwa pliku mają różne zadania
| Element | Odpowiada na pytanie | Przykład | Reguła |
|---|---|---|---|
| Nazwa pliku | Jak technicznie rozpoznać zasób? | monitor-audio-salon-odsluchowy.webp | Krótka, opisowa, stabilna i zgodna z rzeczywistym formatem. |
| ALT | Co przedstawia obraz w kontekście tego miejsca? | „Kolumny Monitor Audio ustawione w salonie odsłuchowym” | Konkretny opis funkcji albo treści obrazu. Dekoracja otrzymuje pusty alt="". |
| Podpis | Co czytelnik powinien wiedzieć, oglądając zdjęcie? | „Seria Creator łączy konstrukcje instalacyjne z domowym systemem hi-fi.” | Informacja uzupełniająca, kontekst, autor albo źródło. |
| Opis w bibliotece | Jak redakcja identyfikuje źródło, prawa i użycie? | Autor, data, miejsce, licencja, ograniczenia publikacji. | Metadane operacyjne; część z nich może zasilić ImageObject. |
title obrazu | Czy interfejs potrzebuje dodatkowej etykiety? | Opcjonalny tytuł redakcyjny | ALT pozostaje podstawowym odpowiednikiem tekstowym; title pełni rolę pomocniczą. |
Tekst alternatywny opisuje obraz i jego funkcję w danym artykule. Zdjęcie koncertowe może otrzymać ALT: „James Hetfield podczas koncertu Metalliki na Stadionie Narodowym w Warszawie”. Opis oparty na przypadkowej serii fraz zaciera sens i utrudnia korzystanie z czytników ekranu. Google łączy ALT z treścią otaczającą obraz i analizą wizualną, dlatego naturalny kontekst daje maszynie najwięcej informacji. Aktualne wskazówki zawiera oficjalny przewodnik Google Image SEO best practices.
Pięć obrazów, pięć kontraktów
| Rola | Rekomendowany format i kadr | Gdzie trafia | Co kontrolujemy |
|---|---|---|---|
| Obraz w treści / wyróżniający | WebP lub AVIF z fallbackiem; warianty responsywne | HTML, Google Images, karta artykułu | Ostrość, waga, ALT, wymiary, kontekst |
| Discover | Poziomy 16:9, co najmniej 1200 px szerokości i ponad 300 000 pikseli | Google Discover i inne powierzchnie Search | Reprezentatywność, bezpieczny kadr, max-image-preview:large |
| Article / NewsArticle | Wysokiej jakości kadry 16:9, 4:3 i 1:1; Google rekomenduje minimum 50 000 pikseli dla każdego | Właściwość image w JSON-LD | Indeksowalne URL-e, zgodność z materiałem, komplet wariantów |
| Open Graph | W tym wdrożeniu osobny JPEG 1200×630 | Facebook, Messenger, WhatsApp, LinkedIn i inne klienty odczytujące OG | Osobny tytuł, opis, URL, typ, wymiary i og:image:alt |
| Twitter/X Card | summary_large_image, samodzielny URL grafiki | X i klienty zgodne z kartami Twitter | twitter:title, opis, obraz i twitter:image:alt |
| Logo wydawcy | Czysty znak o prawidłowych proporcjach | NewsMediaOrganization.logo | Stały URL, czytelność i odrębność od zdjęcia artykułu |
Dlaczego Open Graph ma osobny plik
Kadr 1200×630 odpowiada proporcjom kart społecznościowych. Komunikator pobiera go bez potrzeby odgadywania, czy logo, kod QR, pionowy plakat albo miniatura z galerii lepiej reprezentuje publikację. W badanym artykule PortalMuzyczny.pl widoczne są kompletne znaczniki og:image, og:image:url, og:image:secure_url, typ MIME, szerokość 1200, wysokość 630 i opis alternatywny. Ten sam zasób zasila kartę summary_large_image dla Twitter/X.
<meta property="og:type" content="article">
<meta property="og:title" content="Tytuł przygotowany do udostępnienia">
<meta property="og:description" content="Opis karty społecznościowej">
<meta property="og:url" content="KANONICZNY-URL/">
<meta property="og:image" content="URL-GRAFIKI-1200x630.jpg">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
<meta property="og:image:alt" content="Opis rzeczywistej grafiki">
<meta name="twitter:card" content="summary_large_image">
<meta name="twitter:title" content="Tytuł karty">
<meta name="twitter:description" content="Opis karty">
<meta name="twitter:image" content="URL-GRAFIKI-1200x630.jpg">
<meta name="twitter:image:alt" content="Opis rzeczywistej grafiki">Oddzielny kadr Discover 16:9 i plansza OG 1200×630 rozwiązują dwa różne problemy. Pierwszy odpowiada wymaganiom dużego obrazu w spersonalizowanym feedzie Google. Drugi stabilizuje podgląd w kanałach społecznościowych. Program „Pozycjonowanie strony” pozwala wskazać osobne zasoby dla Discover/News, social, Facebooka, Twittera oraz trzech proporcji Schema.
Co dokładnie robi generator JPEG 1200×630
Wersja 5.4.0 tworzy dla zewnętrznych crawlerów stabilny plik JPEG o wymiarach 1200×630. Źródłem może być WebP, JPEG, PNG albo inny format obsługiwany przez bibliotekę obrazów serwera. Oryginalny załącznik oraz obraz wyróżniający pozostają bez zmian. Wynik trafia do katalogu csiis-og-cache, a nazwa zawiera identyfikator załącznika, czas modyfikacji źródła i wersję algorytmu. Zmiana źródła prowadzi do nowego URL-a, co pomaga platformom pobrać zaktualizowaną kartę zamiast korzystać z długo przechowywanego podglądu.
Duży obraz poziomy o bezpiecznych proporcjach jest kadrowany do 1200×630. Pionowe, kwadratowe oraz zbyt małe źródła trafiają pojedynczo na neutralne poziome płótno. Obraz zachowuje proporcje i pojawia się jeden raz, więc algorytm unika rozciągania, powielonych kopii oraz przypadkowego odcięcia ważnego fragmentu. Jakość JPEG wynosi 88, a zapis ma typ MIME image/jpeg. Po przygotowaniu program ponownie odczytuje wymiary wyniku i używa pliku wyłącznie wtedy, gdy ma dokładnie 1200×630.
Obsługa błędu jest częścią kontraktu. Problem dekodera WebP, brak pamięci w bibliotece graficznej albo uszkodzone metadane załącznika nie powinny wyłączyć całego artykułu błędem serwera. Generator wraca wtedy do bezpiecznego źródła, a pozostałe metadane strony nadal mogą zostać opublikowane. To ważna różnica między demonstracyjnym skryptem kadrującym a funkcją pracującą w produkcyjnym WordPressie.
| Element | Wymóg standardu lub platformy | Profil zastosowany w programie | Cel praktyczny |
|---|---|---|---|
| Format pliku OG | Open Graph opisuje URL i metadane obrazu; sam protokół nie narzuca wyłącznie JPEG | JPEG | Szeroka zgodność crawlerów i przewidywalny typ MIME |
| Proporcja | Platformy mogą przycinać podgląd według własnego interfejsu | 1200×630, około 1,91:1 | Stabilna duża karta społecznościowa |
| Adres | Bezwzględny publiczny URL dostępny przez HTTPS | Wersjonowany URL w osobnym cache | Odświeżenie po zmianie źródła i łatwy audyt |
| Typ i wymiary | Właściwości strukturalne Open Graph są zalecane przy wielu obrazach i szybszym odczycie | Jawne MIME, szerokość i wysokość | Crawler zna parametry przed pobraniem całości |
| Tekst alternatywny | Open Graph przewiduje og:image:alt; X ma twitter:image:alt | Opis wybranego zasobu | Dostępność i jednoznaczny kontekst karty |
| Bezpieczne kadrowanie | Decyzja implementacyjna wydawcy | Kadr dla dużego poziomego źródła, płótno dla pozostałych | Brak deformacji i czytelny motyw na telefonie |
Stwierdzenie „JPEG 1200×630” w tym materiale opisuje profil zgodności wdrożony w programie, a nie jedyny format dopuszczony przez Open Graph. Protokół definiuje między innymi adres obrazu, jego bezpieczny URL, typ, szerokość, wysokość i opis alternatywny. Facebook, komunikatory, LinkedIn i X stosują własne zasady pobierania, cache i kadrowania. Dlatego finalny test obejmuje źródło HTML, odpowiedź obrazu, nagłówek Content-Type, certyfikat HTTPS, przekierowania, wagę pliku oraz realny podgląd w narzędziu danej platformy.
WebP w treści, JPEG w karcie i pełna spójność znaczenia
Ten sam materiał może korzystać z WebP w widocznej treści oraz JPEG w metadanych społecznościowych. Format pliku zmienia sposób dostarczenia, a nie temat obrazu. ALT w artykule opisuje funkcję zdjęcia w sąsiedztwie tekstu. Opis karty społecznościowej opisuje obraz używany przy udostępnieniu. Podpis może zawierać autora, źródło, sytuację i kontekst. Program dziedziczy informacje, gdy wariant pochodzi z tego samego załącznika, a redaktor może ustawić osobny tekst wtedy, gdy kadr przedstawia inny fragment.
Dla własnej strony warto wyznaczyć politykę formatów. Przykładowo: AVIF/WebP dla obrazów w treści, JPEG 1200×630 dla kart społecznościowych, JPEG 1200×675 dla głównego kadru Discover, a 1200×900 i 1200×1200 dla pozostałych proporcji artykułu. Serwer powinien zwracać właściwy MIME, CDN zachowywać rozszerzenie lub typ odpowiedzi, a robots i zabezpieczenia hotlinków przepuszczać crawlerów platform. Każdy obraz powinien mieć publiczny, stabilny i bezpośredni URL.
Prawa i pochodzenie obrazu
Zaawansowany rekord obrazu może zawierać twórcę, podpis kredytowy, informację o prawach, adres licencji i stronę opisującą sposób uzyskania praw. Pola programu powinny odzwierciedlać faktyczną sytuację oraz informację dostępną czytelnikowi. Sam adres znaleziony w wyszukiwarce obrazów stanowi punkt odkrycia, a źródło praw wynika z licencji, umowy, informacji autora albo własnego wykonania.
| Pole redakcyjne | Dane do wpisania | Miejsce potwierdzenia |
|---|---|---|
| Autor zdjęcia | Imię i nazwisko osoby albo nazwa organizacji | Widoczny podpis lub informacja o prawach |
| Credit | Brzmienie wymagane przez autora, agencję lub licencję | Podpis bezpośrednio przy obrazie |
| Prawa autorskie | Rok i właściciel praw | Podpis, nota prawna lub strona licencji |
| Licencja | Publiczny URL warunków wykorzystania | Dokument źródłowy licencji |
| Uzyskanie praw | URL strony kontaktowej albo instrukcji licencyjnej | Publiczny proces dla zainteresowanego użytkownika |
Google News: kwalifikacja, mapa i transparentność
Google automatycznie odkrywa treści informacyjne w zwykłym crawlu. Kwalifikacja do powierzchni newsowych opiera się na jakości publikacji, zgodności z zasadami Google Search i Google News, dostępności technicznej oraz przejrzystości wydawcy. Strona artykułu powinna mieć unikalny i trwały URL, łatwo rozpoznawalny nagłówek, widoczne daty, podpis autora i pełną treść w HTML.
Kontrakt strony newsowej
- Stały, unikalny URL. Ten sam artykuł zachowuje adres po aktualizacji.
- Crawlable HTML. Sekcje prowadzą do artykułów zwykłymi linkami tekstowymi, a główna treść jest dostępna w dokumencie.
- Jednoznaczna data i byline. Czytelnik widzi moment publikacji, aktualizację i autora.
- UTF-8 i spójny język dokumentu. Portal publikuje polskojęzyczną wersję strony.
- Transparentny wydawca. Strony o redakcji, właścicielu, finansowaniu, korektach, standardach, kontakcie i odpowiedzialności są publicznie dostępne.
- Jasne oznaczenie promocji. Charakter komercyjny, sponsor lub relacja biznesowa pojawiają się w widocznym komunikacie.
- Reprezentatywny obraz. Fotografia i metadane dotyczą dokładnie oznaczonego materiału.
- Typ publikacji zgodny z treścią. Wiadomość, analiza, reportaż, opinia i recenzja otrzymują właściwe podtypy redakcyjne.
Oficjalne wymagania techniczne opisuje dokument Google News technical guidelines, a zasady transparentności i materiałów sponsorowanych znajdują się w Google News policies.
Osobna mapa Google News
Mapa newsowa przyspiesza odkrywanie świeżych materiałów i ułatwia ich osobne monitorowanie w Search Console. Google dopuszcza dodanie rozszerzeń newsowych do głównej mapy albo utworzenie osobnego pliku. PortalMuzyczny.pl publikuje osobny adres /news-sitemap.xml.
Mapa obejmuje artykuły z ostatnich dwóch dni. Starszy URL znika z części newsowej, a sam artykuł pozostaje dostępny w głównej mapie i zwykłym indeksie. Limit pojedynczej mapy wynosi 1000 wpisów <news:news>. Nazwa publikacji w <news:name> powinna odpowiadać nazwie prezentowanej przy artykułach, a <news:language> zawiera kod języka.
<url>
<loc>KANONICZNY-URL-ARTYKUŁU/</loc>
<news:news>
<news:publication>
<news:name>PortalMuzyczny.pl</news:name>
<news:language>pl</news:language>
</news:publication>
<news:publication_date>2026-09-05T10:00:00+02:00</news:publication_date>
<news:title>Tytuł artykułu</news:title>
</news:news>
</url>Publiczny test wykonany 5 września 2026 r. zwrócił dla mapy kod HTTP 200 i dokument XML z przestrzenią nazw Google News. W tym momencie mapa miała pustą listę URL-i, co odpowiada sytuacji bez kwalifikujących się publikacji w ruchomym oknie dwóch dni. Pełną składnię i reguły publikuje dokumentacja News sitemaps.
NewsArticle i podtyp redakcyjny
Wybór zaawansowanego podtypu w programie ustawia bazowy NewsArticle i dodaje dokładniejszy typ, np. AnalysisNewsArticle. Generator mapy może dzięki temu stosować przewidywalną regułę kwalifikacji świeżej publikacji. Typ Schema dokumentuje charakter materiału; decyzję o obecności w mapie określają również status publikacji, data i konfiguracja generatora.
Próbka produkcyjna posiada wyraźny H1, datę publikacji i aktualizacji, autora jako encję Person, wydawcę NewsMediaOrganization, reprezentatywny obraz, canonical, breadcrumbs, sekcję artykułu oraz publiczne odnośniki do polityk redakcyjnych. To tworzy kompletny techniczny kontekst wiadomości. Rzeczywistą obecność i ruch w Google News ocenia raport Google News w Search Console.
Google Discover: czym jest i jak przygotować publikację
Discover jest spersonalizowanym strumieniem treści w ekosystemie Google. Dobiera materiały do zainteresowań odbiorcy na podstawie aktywności i kontekstu. W strumieniu mogą pojawiać się zarówno świeże publikacje, jak i starsze materiały nadal wartościowe dla konkretnej osoby.
Publiczna strona staje się automatycznie kwalifikowalna po indeksacji i spełnieniu zasad Discover. Kwalifikacja odbywa się bez osobnego znacznika i bez dedykowanego typu Schema. Największy wpływ redakcyjny mają atrakcyjna, uczciwa zapowiedź, oryginalna wartość materiału, dobra strona docelowa oraz wysokiej jakości obraz.
Specyfikacja dużego obrazu
- co najmniej 1200 pikseli szerokości,
- ponad 300 000 pikseli łącznie,
- rekomendowany kadr 16:9,
- ważny temat zachowany w poziomym kadrowaniu,
- wybór przez Schema.org lub
og:image, - zgoda na duży podgląd przez
max-image-preview:largealbo AMP.
<meta name="robots" content="index,follow,max-image-preview:large">Grafika 1280×720 ma 921 600 pikseli i spełnia oba progi wymiarów. Najważniejsza twarz, produkt lub obiekt powinny pozostać czytelne także po automatycznym kadrowaniu. Oficjalny opis powierzchni i wymiarów znajduje się w przewodniku Discover and your website.
cover, tryb zachowania całego zdjęcia contain, przesuwany punkt kadru oraz odziedziczone dane SEO obrazu. Oryginał pozostaje w bibliotece, a program tworzy nowy JPEG o wybranym wymiarze.Cover, contain i punkt kadru
Tryb cover wypełnia cały docelowy prostokąt. Program oblicza proporcję źródła, wyznacza fragment możliwy do przycięcia i przesuwa go wokół punktu wskazanego przez redaktora. W szerokim obrazie zmienia się pozycja pozioma, w obrazie zbyt wysokim — pionowa. Współrzędne są ograniczane do granic pliku, więc kadr zachowuje dokładny rozmiar i nie tworzy pustych obszarów.
Tryb contain zachowuje całe źródło. Obraz jest proporcjonalnie pomniejszany i umieszczany na płótnie o wybranym kolorze. Punkt kadru steruje położeniem wolnego miejsca. Ten wariant jest użyteczny dla okładek albumów, logotypów, plakatów, zrzutów panelu i pionowych fotografii, których fragmentów redakcja chce zachować w całości. Program powstrzymuje powiększanie małego źródła, dzięki czemu piksele nie są sztucznie rozciągane.
Wybór proporcji odpowiada roli obrazu. Kadr 16:9 o rozmiarze 1200×675 jest naturalnym pierwszym wariantem dla dużych powierzchni. Kadr 4:3 ma 1200×900, a kwadrat 1:1 ma 1200×1200. Trzy prawdziwe pliki zapewniają lepszą kontrolę niż jeden URL deklarowany jako trzy proporcje. Redaktor powinien obejrzeć każdy wynik osobno, ponieważ twarz albo produkt pośrodku szerokiego kadru może znaleźć się zbyt blisko brzegu kwadratu.
max-image-preview:large oraz jakość zapowiedzi. Wynik 100/100 potwierdza kompletność reguł technicznych w analizowanym rekordzie; o faktycznym wyświetleniu decydują systemy Google i zainteresowania odbiorcy.Discover a Google News
| Obszar | Discover | Google News |
|---|---|---|
| Mechanizm | Spersonalizowany feed zainteresowań | Powierzchnie wiadomości i wyniki newsowe |
| Wiek treści | Materiały świeże i evergreen | Silny nacisk na aktualność; mapa newsowa obejmuje dwa dni |
| Schema | Brak osobnego wymaganego typu | Article/NewsArticle ułatwia jednoznaczny opis |
| Obraz | Duży, co najmniej 1200 px, ponad 300 000 pikseli, najlepiej 16:9 | Reprezentatywny, dostępny dla robota; w Article warto podać 16:9, 4:3 i 1:1 |
| Pomiar | Raport Discover w Search Console, gdy serwis osiągnie wymagany poziom danych | Raport Google News w Search Console |
Zakładka „Discover i Google News” we wtyczce analizuje cel publikacji, obraz, robots, tytuł, autora, daty, typ Schema, transparentność wydawcy i adres mapy. Pole celu kieruje podpowiedziami redakcyjnymi. Metadane wynikowe pozostają oparte na prawdziwym typie i zawartości artykułu.
Strona główna jako mapa całego serwisu
Strona główna pełni rolę węzła orientacyjnego. Przedstawia nazwę i specjalizację wydawcy, otwiera najważniejsze działy, prowadzi do aktualnych publikacji oraz pokazuje, jakimi encjami serwis zajmuje się stale. Jej celem jest przekazanie użytkownikowi i robotowi spójnej odpowiedzi na trzy pytania: kto publikuje, jaki obszar obejmuje i gdzie znajdują się główne zasoby.
WebSite + Organization/NewsMediaOrganization, główny opis, logo, wyszukiwanie i najważniejsze linki./developers, REST, OpenAPI, MCP i discovery.Elementy techniczne strony głównej
Jednoznaczny H1
Nagłówek opisuje portal i jego główną wartość. Sekcje strony korzystają z H2 i H3, dzięki czemu wynikowy outline ma przewidywalną hierarchię.
Własny title i description
Opis strony głównej obejmuje cały portal. Opisy kategorii i artykułów zachowują własną, węższą intencję.
WebSite i wydawca
Wspólne @id organizacji oraz witryny są później używane przez artykuły, profile i kolekcje.
SearchAction
Opisuje wewnętrzne wyszukiwanie serwisu. Interfejs wyszukiwania powinien prowadzić do publicznego URL-a wyników i szukać w określonym zbiorze treści.
Linki do klastrów
Najważniejsze działy otrzymują opisowe anchory. Kolejność i eksponowanie wynikają z priorytetów redakcji.
Własny obraz social
Karta strony głównej reprezentuje markę. Artykuły używają własnych fotografii i osobnych kart.
Jak pisać treść strony głównej
Pierwszy ekran powinien nazwać serwis i jego zakres naturalnym językiem. Kolejne sekcje rozwijają główne obszary: wiadomości muzyczne, historię, koncerty, artystów, sprzęt audio, streaming i rankingi. Każdy blok dostaje krótki opis oraz link do kanonicznej strony działu. Strona główna staje się w ten sposób indeksem pojęć o znacznie większej wartości niż chronologiczna ściana kart.
Redakcja może zmieniać kolejność modułów zgodnie z aktualnym programem wydawniczym. Stałe linki do działów powinny zachować stabilne adresy oraz nazewnictwo. Ważne publikacje otrzymują ekspozycję w kontekście właściwego klastra, co wzmacnia drogę: strona główna → dział → kategoria → artykuł.
Kategorie, podstrony, profile i archiwa w WordPressie
Każdy typ URL-a opisuje inną encję. Kategoria jest zbiorem wpisów. Podstrona działu przedstawia temat i prowadzi do jego kolekcji. Profil autora jest stroną osoby. Profil artysty opisuje wykonawcę albo zespół. Artykuł pozostaje konkretną publikacją. Rozdzielenie tych ról usuwa konkurencję między identycznymi stronami i porządkuje graf.
Hierarchia podstrona działu → kategoria → wpis
PortalMuzyczny.pl
└── Dekady WebPage / CollectionPage
└── lata 90. CollectionPage
└── artykuł o HammerFall NewsArticle + AnalysisNewsArticlePowiązana podstrona sekcji pełni funkcję nadrzędnego działu. Kategoria publikuje isPartOf prowadzące do tej strony, a strona może publikować hasPart z listą kolekcji. Wpis wskazuje kategorię główną przez isPartOf i jej nazwę przez articleSection. Breadcrumbs odtwarzają tę samą kolejność.
Dwa poprawne tryby powiązania
Nadrzędny dział
Podstrona i archiwum mają odrębne intencje. Podstrona wyjaśnia temat, pokazuje wejścia do podkategorii lub dodatkowe moduły. Archiwum przedstawia listę przypisanych wpisów. Oba adresy pozostają indeksowalne i wzajemnie połączone.
Podstrona zastępuje archiwum
Oba URL-e realizują tę samą funkcję. Archiwum otrzymuje przekierowanie 301 do strony docelowej, a generator sitemap pomija adres przekierowany. Linki WordPressa prowadzą od razu do celu.
Matryca typów URL
| URL | Główna rola | Schema | Najważniejsza relacja |
|---|---|---|---|
| Strona główna | Wejście do całej witryny | WebSite + wydawca | Wspólne @id dla całego grafu |
| Podstrona działu | Hub tematyczny | WebPage albo CollectionPage | hasPart do kategorii |
| Kategoria wpisów | Zbiór dokumentów | CollectionPage | isPartOf do działu |
| Artykuł | Publikacja redakcyjna | Article, NewsArticle lub właściwy podtyp | isPartOf, author, publisher |
| Profil autora | Informacja o twórcy i archiwum jego tekstów | ProfilePage z mainEntity: Person | worksFor, sameAs |
| Profil artysty | Encja muzyczna | Person lub MusicGroup | Powiązania z artykułami i gatunkami |
| Producent sprzętu | Marka i jej kategorie produktów | Organization / typ zgodny z modelem | Artykuły oraz kategorie sprzętu |
| Koncert | Zdarzenie w czasie i miejscu | Event lub podtyp | startDate, location, performer |
Jedna wtyczka jako właściciel Schema encji
Profil artysty może być wzbogacany przez SEO ogólne, wtyczkę artystów, szablon i dodatkowy moduł. Najbezpieczniejszy kontrakt przypisuje jednego właściciela JSON-LD każdej encji. W PortalMuzyczny.pl wtyczka „Artyści” publikuje Schema profili pm_artist, archiwum i gatunków. Program „Pozycjonowanie strony” nadal dostarcza meta title, description, robots, canonical oraz Open Graph, a własny JSON-LD na tych widokach pozostawia modułowi domenowemu. Ten sam wzorzec warto stosować wobec producentów, koncertów i innych typów specjalnych.
Ustal nazwę, slug, opis widoczny, tytuł SEO, opis SEO, robots, nadrzędną podstronę sekcji i sposób powiązania. Następnie wybierz kategorię główną w artykule. Ten wybór buduje articleSection, isPartOf oraz breadcrumbs; typ artykułu jest osobną decyzją.
Program „Pozycjonowanie strony” jako warstwa spójności
Wdrożona wersja 5.4.0 łączy klasyczne metadane SEO, model encji, obsługę wydawcy newsowego, obrazy wielokanałowe i kontrolę redakcyjną. Jej głównym zadaniem jest przełożenie decyzji człowieka na powtarzalny kod. Pola zaawansowane działają per artykuł i publikują wyłącznie dane uzupełnione oraz potwierdzone przez redakcję.
Zakładka SEO: od tematu do adresu kanonicznego
Pierwsza zakładka zbiera informacje odpowiedzialne za temat dokumentu i jego prezentację w wynikach wyszukiwania. Główna fraza kluczowa jest etykietą roboczą analizy, a nie komendą do mechanicznego powtarzania słów. Pomaga sprawdzić, czy tytuł, opis, początek, nagłówki i URL wspólnie opisują to samo zagadnienie. Pole fraz pokrewnych obejmuje synonimy, warianty językowe, nazwy encji oraz pytania uzupełniające. Analizator może wtedy ocenić szerszy kontekst bez wymuszania jednej identycznej formy w każdym akapicie.
Tytuł SEO opisuje wynik wyszukiwania. H1 opisuje dokument widoczny na stronie. Oba teksty mogą być zbliżone, a tytuł SEO może zawierać bardziej zwięzłą obietnicę albo nazwę marki. Opis SEO streszcza zakres i wartość publikacji. Liczniki znaków pełnią funkcję orientacyjną, ponieważ wyszukiwarka mierzy także szerokość znaków i może zbudować własny tytuł lub snippet. Dobry panel pokazuje rekomendowany zakres, lecz zachowuje decyzyjność redaktora.
Fraza główna
Fraza powinna odpowiadać dominującej intencji użytkownika. Dla analizy utworu może łączyć wykonawcę, tytuł i rodzaj odpowiedzi, np. znaczenie albo interpretację. Dla usługi powinna odzwierciedlać problem klienta oraz zakres geograficzny wtedy, gdy lokalizacja ma znaczenie. Dla produktu naturalnym rdzeniem jest pełna nazwa modelu wraz z cechą odróżniającą. Fraza ogólna typu „muzyka” lub „usługi” daje analizatorowi zbyt mało informacji.
Frazy pokrewne
Lista pokrewna opisuje pole semantyczne. Mogą się w niej znaleźć odmiany nazwiska, polska i oryginalna nazwa, album, wykonawcy, konkretne pytania oraz terminy specjalistyczne. Własna firma może wykorzystać tu słownictwo klientów z Search Console, rozmów sprzedażowych, wyszukiwarki wewnętrznej i działu wsparcia. Celem jest kompletna odpowiedź, a nie gęstość słów.
Slug i canonical
Slug powinien być czytelny, stabilny i wystarczająco opisowy. Zmiana opublikowanego adresu wymaga przekierowania, aktualizacji linków i kontroli canonical. Pole canonical służy do wskazania preferowanego dokumentu. Dla samodzielnie opublikowanego artykułu zwykle jest to jego własny URL. W przypadku legalnej syndykacji albo bardzo zbliżonych wariantów decyzję podejmuje właściciel treści na podstawie modelu publikacji.
Robots i duży podgląd obrazu
Publiczny, kanoniczny materiał przeznaczony do wyszukiwania zwykle korzysta z index,follow. Dyrektywa max-image-preview:large zezwala Google na duży podgląd obrazu, co ma znaczenie dla powierzchni takich jak Discover. max-snippet:-1 pozostawia systemowi możliwość użycia dowolnej długości fragmentu. Reguły powinny wynikać z polityki typu treści. Wyniki wyszukiwania wewnętrznego, prywatne profile, koszyk albo duplikaty filtrów mogą otrzymać inną politykę.
Robots i canonical rozwiązują inne zadania. Robots określa dopuszczalne wykorzystanie strony w indeksie i podglądach. Canonical wskazuje preferowaną reprezentację w grupie zbliżonych adresów. Adres z noindex nie staje się dobrym kandydatem na canonical dla indeksowalnych kopii. Program powinien wychwycić sprzeczne kombinacje oraz pozostawić jasny opis konsekwencji.
Podgląd Google
Podgląd jest narzędziem redakcyjnym. Pokazuje oczekiwany tytuł, URL i opis, lecz finalny wynik buduje Google na podstawie zapytania, zawartości i własnych systemów. Warto oceniać jasność komunikatu: czy użytkownik rozumie temat, dostaje konkretną obietnicę oraz widzi markę tam, gdzie pomaga ona w decyzji. Podgląd powinien też sygnalizować ucięcie na różnych szerokościach.
Analiza treści: sygnały do przeglądu, a nie automat piszący
Analiza SEO sprawdza zestaw obserwowalnych cech. Dla frazy są to obecność w tytule SEO, H1, opisie, pierwszej części tekstu, wybranych nagłówkach i adresie. Dla techniki — długość tytułu i opisu, obraz wyróżniający, ALT-y, powiązania tematyczne oraz metadane. Dla struktury — długość treści, liczba H2, podział sekcji, kotwice i linkowanie wewnętrzne. Każdy test powinien wyjaśniać stan, próg i sens poprawki.
Ostrzeżenie przy frazie w H1 trzeba czytać w kontekście końcowego frontu. Nagłówek H1 może powstawać w szablonie poza treścią zapisaną w edytorze. Analizator badający wyłącznie bloki wpisu chwilowo go wtedy nie widzi. Test produkcyjny powinien otworzyć publiczną stronę i policzyć finalne H1. Podobnie działają autor, data, spis treści i link „Dla AI”: mogą być niewidoczne w surowej treści, lecz pojawiają się w wynikowym dokumencie.
Jak pracować z wynikiem
- Najpierw popraw błędy techniczne: pusty tytuł, błędny canonical, brak publicznego obrazu, konflikt robots lub niepoprawną hierarchię.
- Następnie sprawdź zgodność znaczenia: temat, tytuł, lead, kategoria, encje i linki.
- Ostrzeżenia stylistyczne oceniaj po lekturze całego akapitu; nazwa własna albo termin branżowy może wymagać częstszego użycia.
- Porównaj wynik edytora z finalnym HTML, ponieważ motyw i inne moduły dodają część elementów dopiero na froncie.
- Po publikacji użyj danych Search Console, aby zweryfikować rzeczywiste zapytania, CTR i wybór canonical.
Zakładka Czytelność: pomiar rytmu i obciążenia tekstu
Czytelność opisuje sposób odbioru tekstu, a nie poziom wiedzy autora. Materiał techniczny może zawierać specjalistyczne terminy, wzory i długie nazwy, a nadal prowadzić czytelnika logicznie. Program analizuje czas czytania, liczbę słów, częste wyrazy, długość zdań, liczbę konstrukcji mocno złożonych, długość akapitów, podział na akapity, słowa łączące, stronę bierną i powtarzające się początki zdań.
Średnia długość zdania jest sygnałem diagnostycznym. Dwa teksty ze średnią dziesięciu słów mogą różnić się klarownością: pierwszy prowadzi logiczny wywód, drugi składa serię urwanych komunikatów. Program powinien wskazać fragmenty skrajne, a autor ocenia składnię, kolejność informacji i znaczenie. Analogicznie limit akapitu pomaga znaleźć ścianę tekstu, lecz rozdzielenie argumentu w przypadkowym miejscu może pogorszyć zrozumienie.
Lista popularnych słów pomaga wykryć przypadkową dominację terminu i wspiera redakcję nazw własnych. W artykule o utworze naturalnie często pojawią się tytuł, zespół i bohater interpretacji. W tekście usługowym lista może ujawnić, że autor częściej opisuje własną firmę niż problem klienta. To narzędzie do obserwacji, nie automatyczny ranking tematów.
Dlaczego moduły domenowe powinny być osobne
Adres utworu w Spotify ma sens dla materiału muzycznego, a numer katalogowy, składniki produktu albo termin konsultacji należą do innych branż. Rdzeń programu może obsługiwać metadane, obrazy, autorów, daty, źródła i relacje. Rozszerzenia domenowe dodają własne pola oraz walidatory. Dzięki temu panel sklepu medycznego nie pokazuje integracji TIDAL, a portal muzyczny nie otrzymuje pól receptury lub dostawy.
Zakładka Schemat: redaktor ustawia znaczenie, program generuje kod
Zakładka „Schemat” służy do wyboru znaczenia dokumentu. „Rodzaj treści” opisuje klasę redakcyjną używaną przez analizę i podpowiedzi. „Typ Schema” wskazuje techniczny typ publikacji. „Kategoria główna” ustala jej miejsce w hierarchii. „Tytuł okruszków” pozwala skrócić nazwę w breadcrumbs. Słowa kluczowe Schema, about i mentions opisują temat oraz powiązane encje.
About i mentions
about obejmuje encje stanowiące właściwy temat dokumentu. mentions obejmuje podmioty istotnie wspomniane, które pomagają zrozumieć treść, lecz nie są osią publikacji. W analizie „The Fallen One” głównym tematem może być utwór, album i zespół, a wzmiankami — członkowie grupy, wytwórnia oraz źródła kulturowe interpretacji. Dla artykułu produktowego głównym tematem może być testowany wzmacniacz, a wzmiankami kolumny referencyjne, producent i zastosowane technologie.
Własny program może rozbudować te pola o wybór istniejącej encji zamiast wpisywania dowolnego tekstu. Autouzupełnianie po nazwie i typie, podgląd kanonicznego URL-a oraz kontrola duplikatów zmniejszają ryzyko połączenia dwóch osób o tym samym nazwisku lub marki z produktem o podobnej nazwie. Portal może korzystać z profili artystów, producentów i autorów jako wewnętrznego słownika encji.
Zakres automatyzacji
| Moduł | Dane wejściowe | Wynik techniczny | Odpowiedzialność człowieka |
|---|---|---|---|
| Podstawowe SEO | Tytuł, opis, canonical, robots | Metatagi i adres kanoniczny | Unikalność i zgodność z intencją |
| Social | Tytuły, opisy i osobne obrazy | Open Graph i Twitter Card | Właściwy kadr, opis i prawa |
| Schema artykułu | Typ, autor, daty, sekcja, obrazy | Spójny graf JSON-LD | Prawdziwy charakter publikacji |
| Encje | about, mentions, URL/@id, sameAs | Semantyczne relacje do osób, zespołów, organizacji i pojęć | Potwierdzenie obecności w tekście |
| Newsroom | Podtyp, źródła, cytowania, korekty, sponsor, dateline, dostęp | Rozszerzone Schema i kontrola kompletności | Jawność oraz poprawność danych |
| Role redakcyjne | Współautor, redaktor, recenzent | Powiązane encje Person | Widoczność roli dla czytelnika |
| Obrazy redakcyjne | 16:9, 4:3, 1:1, twórca, prawa, licencja | ImageObject i tablica image | Źródło oraz stan prawny |
| Wydawca | Publiczne adresy polityk | NewsMediaOrganization | Utrzymanie prawdziwych dokumentów |
| Import/eksport | CSV dla kategorii, wpisów i stron | Masowa, walidowana konfiguracja | Tryb testowy i przegląd raportu |
| IndexNow | Opublikowany, zmieniony lub usunięty URL | Asynchroniczne powiadomienie zgodnych wyszukiwarek | Włączenie modułu i ochrona klucza |
| Dla AI | Adres dokumentacji | Widoczny link pod H1 i rel="help" w <head> | Aktualna, publiczna dokumentacja integracji |
Zaawansowany moduł newsroomowy
Moduł globalny uruchamia zakładkę „Zaawansowane” w edycji artykułu. Aktywacja dla konkretnego materiału otwiera pola pochodzenia, źródeł, cytowań, korekt, ról redakcyjnych, dostępu, paywalla, lokalizacji, trzech kadrów obrazu, praw oraz encji. Pole końcowego potwierdzenia wiąże dane maszynowe z tym, co rzeczywiście znajduje się na stronie.
Podtypy obejmują NewsArticle, ReportageNewsArticle, AnalysisNewsArticle, OpinionNewsArticle i ReviewNewsArticle. Dobór najwęższego prawdziwego typu zwiększa precyzję opisu. Publiczny tekst powinien jednocześnie sygnalizować formę — np. „analiza”, „opinia”, „recenzja” albo „relacja”.
Zaawansowane encje przyjmują jeden rekord w każdym wierszu. Wersja 5.4.0 obsługuje typy Person, MusicGroup, MusicAlbum, MusicRecording, MusicEvent, Organization, Place i Thing.
Typ | Nazwa | URL kanoniczny / @id | sameAs1, sameAs2
MusicGroup | Metallica | https://portalmuzyczny.pl/artysci/metallica/ | https://www.wikidata.org/wiki/Q15920
Organization | PortalMuzyczny.pl | https://portalmuzyczny.pl/ |
Thing | Model Context Protocol | https://modelcontextprotocol.io/ |
Dokładny rodzaj materiału
Typ redakcyjny opisuje metodę powstania tekstu. Wiadomość przekazuje nowe fakty. Analiza łączy fakty z interpretacją lub metodą. Reportaż bazuje na bezpośredniej obserwacji i pracy reporterskiej. Opinia przedstawia wyraźnie podpisane stanowisko. Recenzja ocenia dzieło, wydarzenie, usługę albo produkt według przyjętych kryteriów. Wybór wpływa na podpowiedzi panelu oraz dane generowane przez program, dlatego powinien odpowiadać formatowi widocznemu w tytule i treści.
Pochodzenie materiału, isBasedOn i citation
Pochodzenie odpowiada na pytanie, skąd redakcja pozyskała materiał: z pracy własnej, źródeł zewnętrznych, komunikatu, wywiadu, danych, transmisji albo połączenia kilku metod. Lista materiałów bazowych wskazuje dokumenty, na których opiera się konstrukcja publikacji. Cytowania wskazują źródła wykorzystane przy konkretnych twierdzeniach. W praktyce część adresów może wystąpić w obu rolach, lecz opis procesu powinien zachować sens: dokument bazowy buduje materiał, a cytowanie wspiera oznaczoną informację.
Backstory przedstawia metodę w języku czytelnika. Może opisywać odsłuch, pomiary, rozmowy, analizę archiwów, porównanie specyfikacji lub sposób weryfikacji informacji. Dla testu wzmacniacza warto podać tor odsłuchowy, pomieszczenie, wersję urządzenia, czas testu i kryteria. Dla artykułu historycznego — archiwa, wydania źródłowe, wywiady i rozbieżności między relacjami. Dla rankingu — źródło danych, zakres geograficzny, okres i zasady agregacji.
Sponsor i materiał promocyjny
Pole sponsora łączy nazwę z publicznym adresem organizacji, a widoczny komunikat wyjaśnia charakter relacji. Sam zapis w danych maszynowych nie zastępuje oznaczenia dla czytelnika. Google News wymaga jasnego ujawnienia wsparcia, płatności, interesu właścicielskiego lub afiliacji. W artykule prezentującym własny program warto napisać w pierwszej części, kto jest autorem rozwiązania, na czym oparto test oraz że materiał ma charakter promocyjny. Taka transparentność wzmacnia dokumentację, bo odbiorca zna perspektywę autora.
Autor, współautor, redaktor i weryfikator
Każda rola ma inne znaczenie. Autor odpowiada za tekst i główną pracę twórczą. Współautor wnosi istotną część materiału. Redaktor prowadzący odpowiada za proces i finalną formę. Weryfikator lub fact-checker sprawdza fakty, obliczenia albo zgodność branżową. Jedna osoba może pełnić kilka funkcji, lecz panel powinien publikować tylko role faktycznie wykonane i publicznie wskazane.
Profile osób potrzebują imienia i nazwiska, biogramu, zakresu specjalizacji, zdjęcia, publicznego URL-a i powiązanych materiałów. Adres profilu powinien chronić prywatność: nazwa użytkownika lub slug nie może ujawniać adresu e-mail. Przy dwóch osobach o tym samym imieniu i nazwisku system może dodać neutralny identyfikator albo uzgodniony wyróżnik, zachowując czytelny publiczny tytuł.
Korekta a istotna aktualizacja
Korekta usuwa błąd. Pole powinno zapisać, co poprawiono, dlaczego, kiedy i gdzie znajduje się publiczny opis zmiany. Istotna aktualizacja dodaje nowy stan wiedzy: wyniki, potwierdzenie, nowy rozdział, zmieniony termin lub ważne dane. Program pozwala oddzielić te sytuacje, dzięki czemu historia materiału pozostaje czytelna. Nowa data modyfikacji powinna wynikać z realnej zmiany, a nie z automatycznego zapisania wpisu przez integrację.
Dateline i lokalizacje
Dateline jest widoczną linią miejsca i daty przygotowania, np. „Warszawa, 5 września 2026”. Miejsce tematu wskazuje lokalizację, której dotyczy materiał: salę koncertową, miasto, studio, region albo siedzibę instytucji. Miejsce przygotowania opisuje, gdzie pracowała redakcja. W relacji terenowej wartości mogą być wspólne, a w analizie przygotowanej w Warszawie o wydarzeniu w Göteborgu będą różne.
Gatunek redakcyjny
Gatunek jest etykietą zrozumiałą dla odbiorcy i redakcji, np. „analiza i interpretacja utworu”, „test laboratoryjny”, „rozmowa”, „reportaż koncertowy” albo „poradnik instalacyjny”. Może być bardziej szczegółowy od technicznego typu publikacji. Własna firma może zdefiniować zamknięty słownik gatunków, a następnie powiązać go z checklistą: test laboratoryjny wymaga metodologii i wyników, wywiad wymaga rozmówcy i daty, materiał sponsorowany wymaga disclosure.
Dostęp i paywall
Model dostępu określa, czy cała treść jest bezpłatna, częściowo ograniczona czy dostępna po opłacie. Gdy szablon ma paywall, selektor CSS powinien wskazywać rzeczywisty kontener ograniczonego fragmentu. Warto przetestować stronę bez logowania, po zalogowaniu i po wyłączeniu JavaScriptu. Odbiorca powinien od początku rozumieć, który zakres materiału jest dostępny, na jakich zasadach i co otrzyma po zakupie.
Trzy obrazy artykułu
Panel pozwala wskazać osobne załączniki dla proporcji 16:9, 4:3 i 1:1. Każdy plik może mieć własny kadr, a wspólna warstwa praw opisuje autora, credit, copyright, licencję i stronę pozyskania. Analiza sprawdza obecność trzech wariantów oraz ich rzeczywiste wymiary. Program może też tworzyć nowe pliki za pomocą kreatora Google, co zachowuje oryginał i dziedziczy opisowe metadane źródła.
sameAs. Główne encje trafiają do about, pozostałe istotne podmioty do mentions. Poniższe grupy oceny rozdzielają typ, pochodzenie, autorstwo i obrazy.Walidacja grafu encji
Wiersz powinien reprezentować jedną realną encję. Typ musi odpowiadać obiektowi, nazwa brzmieniu publicznemu, URL prowadzić do kanonicznego profilu, a sameAs do zewnętrznego rekordu tej samej osoby, grupy, albumu lub organizacji. Wikipedia, Wikidata, oficjalna witryna i profil branżowy mogą pomóc w rozróżnieniu nazw, lecz każdy adres wymaga weryfikacji tożsamości.
Potwierdzenie na dole panelu pełni rolę blokady jakości. Redaktor oświadcza, że źródła, sponsor, korekta, backstory, dateline, prawa do obrazów i encje są prawdziwe oraz zgodne z treścią widoczną na stronie. Program zachowuje pola robocze, ale pomija wrażliwe właściwości w wygenerowanym kodzie do czasu potwierdzenia. To ogranicza zjawisko danych przygotowanych wyłącznie dla robota.
Polityki NewsMediaOrganization
Ustawienia globalne przyjmują publiczne adresy zasad publikacji, korekt, etyki, fact-checkingu, anonimowych źródeł, zgłaszania błędów, właściciela i finansowania, składu redakcji, misji, różnorodności i materiałów bez podpisu. Te URL-e są właściwościami wydawcy, więc obowiązują w całym serwisie. Każda podstrona powinna zawierać własny H1, datę obowiązywania, właściciela dokumentu, procedurę oraz dane kontaktowe.
Jeden właściciel metadanych
Najważniejszą decyzją globalną jest wskazanie systemu odpowiedzialnego za title, description, canonical, robots, Open Graph i główny graf. Dwie aktywne wtyczki SEO mogą opublikować dwa canonicale, dwa zestawy kart oraz konkurujące opisy tej samej encji. Panel kontroli powinien wykrywać popularne rozszerzenia i pokazywać źródło aktywne na froncie. Moduły specjalistyczne mogą nadal publikować własne dane domenowe, o ile reguła właściciela jest jawna dla każdej klasy URL.
Kontrola indeksacji
Status WordPressa „proś wyszukiwarki o nieindeksowanie” ma zasięg całej witryny i wymaga szczególnej uwagi przy migracji ze stagingu. Oprócz niego istnieją ustawienia per wpis, per kategoria, nagłówki HTTP, zabezpieczenia serwera i robots.txt. Panel zbiorczy powinien pokazać stan globalny, publiczne typy, liczbę wyjątków oraz adres mapy. Po zmianie warto sprawdzić próbki w Inspekcji URL zamiast opierać się wyłącznie na ustawieniu formularza.
/developers i otrzymuje relację help.Jak przygotować podstrony polityk
Każdy URL w ustawieniach powinien prowadzić do opublikowanego dokumentu. Zasady publikowania opisują proces od zgłoszenia tematu do publikacji. Polityka korekt podaje kanał zgłoszenia, sposób oceny, formę widocznego sprostowania i czas reakcji. Standardy etyczne obejmują konflikty interesów, prezenty, relacje komercyjne i szacunek dla źródeł. Fact-checking opisuje hierarchię źródeł oraz odpowiedzialność. Anonimowe źródła określają przesłanki ochrony tożsamości i poziom autoryzacji.
Strona zgłaszania błędów powinna zawierać formularz lub adres kontaktu i zestaw informacji potrzebnych do weryfikacji. Dokument właściciela i finansowania pokazuje podmiot, źródła przychodów, relacje właścicielskie i zasady reklam. Skład redakcji prezentuje osoby i role. Misja wyjaśnia obszar oraz odbiorców. Polityka różnorodności opisuje praktyki, pomiar i odpowiedzialność. Zasady materiałów bez podpisu określają sytuacje, w których podpis organizacji zastępuje osobę.
Link „Dla AI” jest widoczny dla każdego odbiorcy. Prowadzi do publicznego kontraktu danych i integracji, zamiast ukrytego zestawu instrukcji. Użytkownik, programista, czytnik ekranu oraz agent trafiają do tego samego dokumentu. Własna firma może nazwać go „Dla integratorów”, „API i AI” albo „Dokumentacja danych”, zachowując jasny cel linku.
Import i eksport CSV
Eksport można ograniczyć do kategorii, wpisów albo podstron. Import dopasowuje istniejące obiekty po ID i slugu lub samym slugu, waliduje typy Schema, robots, URL-e, obrazy oraz relacje i generuje raport zmian. Tryb testowy pozwala obejrzeć wynik przed zapisem. Puste komórki zachowują istniejące dane, a osobna opcja może świadomie je wyczyścić.
IndexNow i Google
IndexNow powiadamia Bing oraz inne zgodne systemy o dodaniu, zmianie lub usunięciu publicznego URL-a. Google Search Console, mapy XML i zwykły crawl pozostają właściwymi kanałami kontroli obecności w Google. Wtyczka celowo używa IndexNow w zakresie przewidzianym przez protokół i omija Google Indexing API przeznaczone dla innych, ściśle określonych przypadków.
/developers: publiczny kontrakt integracyjny portalu
Strona portalmuzyczny.pl/developers jest wejściem dla programisty, aplikacji i agenta AI. Łączy opis źródła, model dostępu, przykłady uruchomienia, dokumentację REST, specyfikację OpenAPI, serwer MCP, sandbox, zasady limitów, obsługę błędów, wersjonowanie oraz zestaw adresów discovery.
Publiczny kontrakt ma formę read-only. Dostęp do opublikowanych danych odbywa się bez klucza i bez OAuth. Zakres obejmuje dane publiczne, a operacje administracyjne, zapisy i prywatne rekordy użytkowników pozostają poza tym interfejsem. Taki model upraszcza wdrożenie klienta oraz wyznacza czytelną granicę bezpieczeństwa.
rel="help", /developers, llms.txt, agents.md i pliki .well-known.openapi.json, Swagger, katalog API, opis wersji i format błędów.Quickstart
curl https://portalmuzyczny.pl/wp-json/pm-ai/v1/news
curl "https://portalmuzyczny.pl/wp-json/pm-ai/v1/search?q=metallica"
curl "https://portalmuzyczny.pl/wp-json/pm-ai/v1/spotify-rankings?scope=polska&per_page=10"
curl -X POST https://portalmuzyczny.pl/mcp \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}'Na dzień 5 września 2026 r. /openapi.json publikuje specyfikację OpenAPI 3.0.3 dla „PortalMuzyczny.pl Public AI API” w wersji 1.8.2. Endpoint statusu zwraca {"status":"ok","version":"1.8.2"}. Odpowiedzi REST mają typ application/json, nagłówki limitu oraz Deprecation: false.
Publiczne endpointy REST
| Endpoint | Zakres | Przykładowe użycie |
|---|---|---|
GET /news | Najnowsze publiczne wiadomości muzyczne | Feed newsowy, podsumowanie dnia |
GET /reviews | Recenzje opublikowane w portalu | Wyszukiwanie recenzji albumu lub sprzętu |
GET /events | Koncerty i rekordy kalendarium | Pytania o wydarzenia, daty i wykonawców |
GET /artists | Profile artystów i dane osi czasu | Rozpoznanie encji wykonawcy |
GET /manufacturers | Producenci sprzętu audio | Marki, kategorie sprzętu i materiały powiązane |
GET /spotify-rankings | Bieżące i archiwalne rankingi według zakresu | Ranking Polska, region lub wskazany okres |
GET /authors | Publiczne profile autorów | Źródło informacji o twórcy tekstu |
GET /categories | Kategorie WordPressa | Budowanie filtrów i mapy tematycznej |
GET /tags | Tagi publikacji | Dodatkowe grupowanie zasobów |
GET /search | Wyszukiwanie publicznej treści | Zapytanie encyjne lub pełnotekstowe |
GET/POST /ask | Zapytanie w stylu NLWeb | Interfejs pytań nad zasobami portalu |
GET /feed | Ujednolicony feed | Klient agregujący nowe rekordy |
GET /discovery | Opis dostępnych powierzchni | Automatyczne wykrywanie możliwości |
GET /status | Wersja i stan API | Health check integracji |
GET /webhooks | Katalog informacji o webhookach | Odczyt możliwości kontraktu |
Wyszukiwanie i rankingi Spotify
W czasie testu zapytanie /search?q=metallica&per_page=2 zwróciło kod 200, status ok, liczbę dwóch rekordów na stronie, osiem wyników łącznie, cztery strony oraz kursor do kolejnej porcji. Odpowiedź rankingu dla scope=polska zwróciła źródło spotify-ranking, etykietę „Polska”, okres 2026-09 i znacznik określający, czy wynik pochodzi z zamkniętego archiwum. Dzięki temu klient może odróżnić bieżący okres od wersji historycznej.
Zapytanie encyjne powinno zachować precyzję. Fraza „Metallica” ma prowadzić do zasobów faktycznie związanych z tą encją i odfiltrować przypadkowe rekordy z podobnym ciągiem znaków. Stabilny identyfikator artysty, filtry typu treści i relacje zapisane w bazie dają lepszy wynik niż sam operator LIKE na tytule.
Sandbox, batch i zadania asynchroniczne
Dokumentacja udostępnia bezpieczne ścieżki do sprawdzenia kontraktu:
curl https://portalmuzyczny.pl/wp-json/pm-ai/v1/sandbox/status
curl "https://portalmuzyczny.pl/wp-json/pm-ai/v1/sandbox/search?q=metallica"
curl -X POST https://portalmuzyczny.pl/wp-json/pm-ai/v1/batch \
-H "Content-Type: application/json" \
-d '{"requests":[
{"path":"/search","params":{"q":"metallica"}},
{"path":"/status"}
]}'
curl -X POST https://portalmuzyczny.pl/wp-json/pm-ai/v1/jobs \
-H "Content-Type: application/json" \
-d '{"query":"metallica"}'Batch grupuje kilka publicznych zapytań w jednym żądaniu. Jobs tworzy zadanie wyszukiwania i pozwala później odczytać jego stan. Sandbox zapewnia przewidywalne miejsce na smoke test klienta oraz demonstrację odpowiedzi.
Generowanie SDK z OpenAPI
Specyfikacja OpenAPI jest kontraktem czytelnym dla człowieka i narzędzia. Można z niej wygenerować klienta, typy, dokumentację albo testy kontraktowe.
openapi-generator-cli generate \
-i https://portalmuzyczny.pl/openapi.json \
-g typescript-fetch \
-o portalmuzyczny-sdk-js
openapi-generator-cli generate \
-i https://portalmuzyczny.pl/openapi.json \
-g python \
-o portalmuzyczny-sdk-pythonWygenerowany kod jest punktem startowym dla własnej paczki. Publikacja oficjalnego SDK w npm, PyPI lub innym rejestrze wymaga osobnego procesu wersjonowania, testów i utrzymania.
Limity, błędy i wersjonowanie
REST publikuje nagłówki RateLimit-Limit, RateLimit-Remaining i RateLimit-Reset. Test produkcyjny wskazał limit 120;w=60. Klient powinien buforować stabilne odpowiedzi, ograniczać równoległość i respektować czas resetu po HTTP 429. Chwilowy błąd 5xx obsługuje się ponowieniem z exponential backoff oraz limitem prób.
Odpowiedzi błędów w przestrzeni /wp-json/pm-ai/v1/* mają ujednolicony model {status,error{code,message,status}}. Wersja główna jest częścią ścieżki /v1, a nagłówek Deprecation sygnalizuje stan endpointu. Zmiana łamiąca kontrakt powinna otrzymać okres migracyjny i dokumentację przejścia.
Warstwa discovery
Portal publikuje kilka klas punktów odkrywania, ponieważ klienci używają różnych konwencji:
- Dokumentacja dla człowieka:
/developers,/api,/api-reference,/getting-started,/integrations,/pricingi/compare. - Specyfikacje maszynowe:
/openapi.json,/swagger.json,/.well-known/openapi.jsoni/.well-known/api-catalog. - Pliki tekstowe dla agentów:
/llms.txt,/llms-full.txt,/agents.md,/AGENTS.mdi/index.md. - Karty i manifesty:
/.well-known/ai-plugin.json,/.well-known/agents.json,/.well-known/agent-card.json, karta serwera MCP, uprawnienia agenta oraz indeks umiejętności. - Protokoły:
/mcp, alternatywne/api/mcp,/webmcporaz interfejsui://portalmuzyczny/search.html. - Mapa semantyczna:
/schemamap.xml, która zestawia główne URL-e z typami Schema.
Program dodaje pod tytułem widoczny odnośnik „Dla AI” prowadzący do /developers oraz umieszcza w sekcji <head> relację <link rel="help" href="https://portalmuzyczny.pl/developers">. Czytelnik, programista i automat trafiają do tego samego opisu kontraktu.
Jak przygotować własne /developers
Dokumentacja integracyjna powinna zacząć się od odpowiedzi biznesowej: jakie publiczne dane udostępnia serwis, kto może ich używać i do jakich celów. Dopiero później pojawia się baza URL, format transportu, wersja i przykłady. Programista powinien uruchomić pierwsze bezpieczne zapytanie w kilka minut, a administrator zrozumieć granice dostępu bez czytania kodu źródłowego.
| Sekcja dokumentacji | Co powinna zawierać | Błąd projektowy, który eliminuje |
|---|---|---|
| Opis produktu | Źródło danych, odbiorcy, zakres i przypadki użycia | Integracja pobiera niewłaściwą klasę treści |
| Quickstart | Jedno działające wywołanie, odpowiedź i następny krok | Użytkownik szuka podstawowego adresu w wielu podstronach |
| Uwierzytelnienie | Tryb publiczny, klucze, OAuth, nagłówki i uprawnienia | Klucze trafiają do frontendu albo prywatne dane stają się publiczne |
| Endpointy | Metoda, ścieżka, parametry, filtry, sortowanie i paginacja | Klient zgaduje nazwy parametrów |
| Modele | Typy pól, wymagane wartości, format dat, identyfikatory i przykłady | Ten sam rekord ma inne znaczenie w dwóch integracjach |
| Błędy | Kod HTTP, kod domenowy, wiadomość, możliwość ponowienia | Klient ponawia trwały błąd albo porzuca błąd chwilowy |
| Limity | Okno, nagłówki, retry, cache i zasady uczciwego użycia | Integracja przeciąża serwis |
| Wersjonowanie | Aktualna wersja, deprecjacja, historia zmian i migracja | Aktualizacja serwera nagle łamie klienta |
| Zaufanie | Właściciel, kontakt, polityka danych, uptime i status | Odbiorca nie potrafi ocenić pochodzenia odpowiedzi |
| AI i MCP | Zasoby, narzędzia, granice, przykładowe zadania i wersja protokołu | Model używa wyszukiwania pełnotekstowego tam, gdzie potrzebny jest filtr encji |
Identyfikatory i stabilność
Publiczny rekord powinien mieć stabilny identyfikator niezależny od tytułu wyświetlanego w interfejsie. Tytuł artykułu może zostać poprawiony, nazwa wydarzenia doprecyzowana, a artysta zmienić pseudonim. ID pozwala klientowi rozpoznać ten sam obiekt. Kanoniczny URL pozostaje publicznym adresem dokumentu, a zewnętrzne ID może łączyć rekord z partnerem biletowym, dostawcą rankingu lub systemem katalogowym.
Slug jest elementem adresu dla człowieka, a nie właściwym zabezpieczeniem unikalności danych. Dwie osoby o tym samym imieniu i nazwisku potrzebują różnych identyfikatorów. Generator może zachować czytelny rdzeń i dodać neutralny numer, np. jan-kowalski-1842. Publiczny tytuł nadal brzmi „Jan Kowalski”. Baza i API pracują na ID, a wyszukiwarka może prezentować dodatkowe rozróżnienie: miasto, rolę, zespół albo specjalizację.
Precyzja wyszukiwania encyjnego
Zapytanie „Metallica” powinno mieć tryb dopasowania encji, który preferuje dokładną nazwę zespołu. Pełnotekstowe wyszukiwanie artykułów może zwrócić publikacje, w których słowo występuje w tytule lub treści. Są to dwa poprawne, lecz różne zadania. API warto wyposażyć w parametr typu, dokładności oraz pola przeszukiwanego, np. type=artist, match=exact i q=Metallica. Wynik może podać powód dopasowania oraz wynik trafności.
Normalizacja obejmuje wielkość liter, znaki diakrytyczne, apostrofy, łączniki i znane aliasy. Alias musi należeć do konkretnej encji. Luźne podobieństwo ortograficzne powinno mieć mniejszą wagę niż pełna zgodność nazwy. W przypadku wyszukiwarki menu można ograniczyć indeks wyłącznie do artykułów i otwierać osobną stronę wyników. Wyszukiwarka bazy artystów pozostaje oddzielnym interfejsem z własnym opisem celu.
Parametry archiwum
Dane cykliczne wymagają parametrów okresu. Endpoint rankingu powinien pozwalać wybrać kraj lub zakres, rok, tydzień albo datę zestawienia, limit, kursor i kolejność. Endpoint koncertów potrzebuje początku i końca zakresu, wykonawcy, miasta, miejsca oraz statusu. Użycie tych samych parametrów przez stronę, API i asystenta ogranicza rozjazdy odpowiedzi.
Odpowiedź archiwalna powinna zawierać nazwę okresu, jego początek i koniec, źródło, czas importu oraz informację o kompletności. Brak danych różni się od pustej listy. Pusta lista oznacza poprawnie obsłużony okres bez rekordów. Brak danych może oznaczać, że archiwum jeszcze go nie obejmuje. Kod błędu lub jawne pole statusu pozwala asystentowi uczciwie wyjaśnić sytuację.
Bezpieczeństwo publicznego API
Interfejs read-only powinien zwracać wyłącznie opublikowane rekordy oraz pola przeznaczone do ujawnienia. E-mail użytkownika, prywatna nazwa konta, notatki redakcyjne, token partnera, adres IP i wersje robocze pozostają poza serializatorem. Uprawnienie trzeba sprawdzić na poziomie zapytania i prezentacji odpowiedzi. Samo ukrycie pola w dokumentacji nie stanowi zabezpieczenia.
Warstwa cache powinna uwzględniać pełny zestaw parametrów, język, wersję i zakres autoryzacji. Odpowiedzi mogą używać ETag albo czasu modyfikacji. Limiter rozróżnia użytkownika, IP lub klucz zgodnie z modelem dostępu. Log techniczny zapisuje endpoint, czas, status i identyfikator korelacji, a dane prywatne podlegają minimalizacji. Mechanizm błędów nie powinien ujawniać ścieżek serwera, zapytań SQL ani sekretów.
Test kontraktowy
Każdy endpoint warto testować na trzech warstwach. Test schematu sprawdza typy i wymagane pola. Test semantyczny porównuje rekord z publiczną stroną: tytuł, URL, data i status powinny opisywać ten sam obiekt. Test zachowania obejmuje puste wyniki, błędny parametr, granice paginacji, znaki narodowe, aliasy, limit, timeout i chwilowy błąd zależności.
Przy zmianie OpenAPI klient testowy może zostać wygenerowany automatycznie. Pipeline uruchamia przykładowe wywołania i porównuje status oraz strukturę odpowiedzi. Zmiana pola wymaganego, formatu daty albo znaczenia parametru jest zmianą kontraktu nawet wtedy, gdy endpoint nadal zwraca HTTP 200. Historia zmian powinna wskazać wersję, datę, powód i działania wymagane po stronie klienta.
REST, OpenAPI, MCP i AI — podział odpowiedzialności
HTML, Schema, REST i MCP opisują tę samą domenę z różnych perspektyw. HTML tworzy publiczny dokument. JSON-LD definiuje znaczenie encji na tym dokumencie. REST zwraca ustrukturyzowane rekordy. OpenAPI opisuje kontrakt HTTP. MCP udostępnia zasoby i narzędzia w formie rozpoznawalnej przez aplikacje oparte na modelach językowych.
| Warstwa | Główny odbiorca | Kontrakt | Przykład |
|---|---|---|---|
| HTML | Czytelnik i crawler | Semantyczny dokument oraz linki | Publiczny artykuł |
| JSON-LD | System rozumiejący Schema.org | Graf encji i relacji | NewsArticle → author → Person |
| REST | Aplikacja i integrator | HTTP + JSON | GET /events |
| OpenAPI | Programista i generator kodu | Maszynowy opis endpointów oraz schematów | /openapi.json |
| MCP | Host, klient i model AI | JSON-RPC, negocjacja możliwości, resources i tools | tools/list, resources/read |
| Discovery | Automat rozpoczynający integrację | Manifesty, karty i katalogi | /.well-known/agent-card.json |
Jak działa MCP PortalMuzyczny.pl
MCP używa architektury host–client–server i komunikatów JSON-RPC. Podczas initialize strony uzgadniają wersję protokołu oraz możliwości. Serwer PortalMuzyczny.pl odpowiada obecnie wersją protokołu 2025-06-18 i wersją serwera 1.8.2. Udostępnia narzędzia oraz zasoby publiczne. Pełną architekturę protokołu opisuje oficjalna specyfikacja MCP.
POST https://portalmuzyczny.pl/mcp
Content-Type: application/json
{
"jsonrpc": "2.0",
"id": 1,
"method": "initialize",
"params": {
"protocolVersion": "2025-06-18",
"capabilities": {},
"clientInfo": {
"name": "example",
"version": "1.0.0"
}
}
}Narzędzia MCP potwierdzone na żywo
get_news— najnowsze wiadomości,get_reviews— recenzje,get_events— koncerty i kalendarium,get_artists— artyści i osie czasu,get_manufacturers— producenci sprzętu,get_spotify_rankings— bieżące oraz archiwalne rankingi,search_content— wyszukiwanie zasobów portalu.
Zasoby MCP potwierdzone na żywo
portalmuzyczny://news,portalmuzyczny://reviews,portalmuzyczny://events,portalmuzyczny://artists,portalmuzyczny://spotify-rankings,portalmuzyczny://discovery,ui://portalmuzyczny/search.htmljako interfejs MCP App.
Lista promptów była pusta w teście z 5 września 2026 r. To przydatna informacja kontraktowa: klient korzysta aktualnie z zasobów i narzędzi, a gotowe szablony promptów mogą zostać dodane jako osobna, wersjonowana funkcja.
AI korzysta z encji do precyzyjnego wyszukiwania
Warstwa AI powinna otrzymywać wyniki wraz z typem, kanonicznym URL-em, datą, źródłem, identyfikatorem encji i relacjami. Wtedy pytanie o Metallikę może łączyć profil zespołu, artykuły, koncerty i kalendarium. Pytanie o archiwalny ranking Spotify może wskazać zakres i okres. Pytanie o Monitor Audio może prowadzić do producenta, kategorii sprzętu i przypisanych publikacji.
MusicGroup: Metallica, stabilny identyfikator i warianty nazwy.get_events, get_artists, search_content.Ora.ai jako audyt gotowości agentowej
Ora.ai służy do badania, jak łatwo agent odkrywa witrynę, dokumentację, interfejsy i możliwości wykonania zadania. To odrębny obszar pomiaru od pozycji w Google. Audyt agentowy może wykryć braki w OpenAPI, MCP, discovery, formatach błędów, dokumentacji, uprawnieniach i ścieżkach użytkownika.
npx ax audit https://portalmuzyczny.pl
npx ax audit https://portalmuzyczny.pl --min-score 70
npx ax audit https://portalmuzyczny.pl --jsonDokumentacja Ora opisuje również skanowanie API/MCP, katalog testów, wynik domeny i agent journeys. Wynik takiego skanu warto traktować jako test użyteczności dla integratora: pokazuje, czy agent potrafi odnaleźć kontrakt i ukończyć zadanie. Widoczność w Search pozostaje mierzona przez Search Console, indeksację, zapytania i ruch organiczny.
Dobre encje poprawiają jakość każdej warstwy. Stabilny autor pomaga w Schema i API. Jednoznaczny artysta poprawia wyszukiwanie oraz MCP. Kanoniczny URL spina HTML, sitemapę i odpowiedź REST. Prawidłowa data rozróżnia publikację, aktualizację, wydarzenie historyczne i koncert przyszły.
Testowanie: osobne narzędzie dla każdego pytania
Walidacja składni, możliwość indeksacji, kwalifikacja do wyników rozszerzonych, obecność w Google News, wyświetlenia w Discover i gotowość agentowa to osobne właściwości systemu. Rzetelny audyt używa kilku narzędzi i przypisuje każdemu jedno precyzyjne pytanie.
| Narzędzie | Pytanie testowe | Co zapisujemy w raporcie |
|---|---|---|
| Google Rich Results Test | Czy Google odczytuje obsługiwany typ danych strukturalnych i jego wymagane pola? | Błędy, ostrzeżenia, wykryte elementy i renderowany kod |
| Schema.org Validator | Czy graf jest poprawny względem słownika Schema.org, także poza funkcjami rozszerzonymi Google? | Typy, właściwości, identyfikatory i połączenia w grafie |
| Google Search Console — Inspekcja URL | Jak Google widzi konkretny URL, jaki canonical wybrało i kiedy strona była crawlowana? | Stan indeksacji, wersja kanoniczna, blokady, zasoby i test aktywnego URL-a |
| Search Console — Skuteczność | Na jakie zapytania dokument uzyskuje wyświetlenia i kliknięcia? | Zapytania, strony, CTR, pozycja, urządzenia i kraje |
| Search Console — Google News / Discover | Czy materiały uzyskują ruch na tych powierzchniach? | Wyświetlenia, kliknięcia, CTR i trendy; raport pojawia się po zebraniu danych |
| Bezpośredni test sitemap | Czy XML zwraca HTTP 200, ma poprawną przestrzeń nazw i właściwe URL-e? | Status, typ treści, liczba rekordów, daty i canonical |
| Walidacja OpenAPI | Czy specyfikacja opisuje działające ścieżki i schematy odpowiedzi? | Wersja, paths, operationId, przykłady i test klienta |
| Smoke test REST | Czy status, wyszukiwanie, zdarzenia i rankingi zwracają prawidłowe dane? | HTTP, JSON, paginacja, limity, czas i model błędu |
| Handshake MCP | Czy działa initialize, tools/list i resources/list? | Wersja protokołu, capabilities, nazwy narzędzi i URI zasobów |
| Ora.ai | Czy agent odkrywa witrynę, kontrakt i potrafi wykonać typowe zadanie? | Wynik audytu, problemy warstwowe i wskazówki naprawcze |
| PageSpeed Insights / Lighthouse | Czy dokument jest szybki, stabilny wizualnie i dostępny? | Core Web Vitals, masa obrazów, kontrast, semantyka i problemy mobilne |
Minimalny test po publikacji
- Otwórz stronę bez zalogowania.Sprawdź tytuł, lead, autora, daty, disclosure, źródła, zdjęcia, podpisy i linki.
- Sprawdź urządzenia.Przejrzyj szerokości około 360, 768, 1280 i 1920 pikseli. Zwróć uwagę na nagłówki, tabele, kod, obrazy i marginesy.
- Policz strukturę dokumentu.Jeden H1 pochodzi z szablonu lub wtyczki. Treść rozpoczyna się od H2 i zachowuje kolejność poziomów.
- Porównaj canonical.Ten sam URL powinien wystąpić w
rel="canonical",og:url,mainEntityOfPage, identyfikatorze publikacji i sitemapie. - Uruchom Rich Results Test.Otwórz wykryty artykuł, autora, wydawcę, breadcrumbs i obrazy.
- Uruchom Schema.org Validator.Przejrzyj cały graf oraz wszystkie odwołania
@id. - Sprawdź podgląd społecznościowy.Skontroluj finalny obraz, tytuł, opis i odświeżenie cache platformy.
- Użyj Inspekcji URL.Test aktywnego adresu pokaże dostępność zasobów i aktualny kod.
- Sprawdź mapy.Artykuł powinien wystąpić w głównej sitemapie; świeży news również w ruchomym oknie mapy Google News.
- Wykonaj smoke test API i MCP.Porównaj odpowiedź maszynową z widoczną publikacją.
Jak czytać wynik
Zielona walidacja potwierdza poprawność rozpoznanego kontraktu. Widoczność i ranking zależą od szerszego systemu: jakości oraz oryginalności treści, trafności dla zapytania, reputacji źródła, linkowania, dostępności, wydajności, świeżości i konkurencji. Dlatego raport techniczny powinien łączyć stan kodu z realnymi danymi Search Console.
Jak przygotować artykuł: procedura od tematu do utrzymania
Dobre materiały inżynierskie prowadzą czytelnika od kontekstu przez model po procedurę i referencję. Tę samą zasadę można zastosować w publikacji SEO. Najpierw wyjaśniamy znaczenie, potem pokazujemy architekturę, następnie dajemy przykład, instrukcję testową i granice odpowiedzialności. GitHub Docs podkreśla logiczną kolejność, znaczące nagłówki, jeden problem na akapit, kontekst przed blokiem kodu i format ułatwiający skanowanie. Takie podejście poprawia jednocześnie czytelność ludzką i maszynową.
Etap 1: brief encji i intencji
- Zapisz jedno zdanie opisujące pytanie czytelnika i wartość odpowiedzi.
- Określ format: wiadomość, analiza, reportaż, opinia, recenzja, poradnik albo dokumentacja.
- Wybierz główną encję: artysta, album, utwór, koncert, producent, technologia, osoba lub zjawisko.
- Zapisz encje drugoplanowe, które rzeczywiście pomagają zrozumieć temat.
- Przypisz nadrzędny dział i kategorię główną.
- Określ, czego czytelnik będzie umiał dokonać albo co zrozumie po lekturze.
Intencja: wyjaśnić, jak działa kompletne techniczne SEO portalu. Format: analiza techniczna i case study. Główna encja: wdrożenie PortalMuzyczny.pl. Encje wspomniane: Schema.org, Google News, Discover, Search Console, OpenAPI, MCP, Ora.ai. Dział: Portal i AI / technologie.
Etap 2: źródła i materiał dowodowy
Źródła warto zebrać przed budowaniem tez. Pierwszy poziom tworzą specyfikacje, dokumentacja dostawcy i dane bezpośrednie. Drugi poziom obejmuje wiarygodne opracowania branżowe. Własne pomiary i kod produkcyjny powinny mieć datę badania, zakres próbki oraz wskazanie środowiska.
- Google Search Central dla Search, Discover, danych strukturalnych, obrazów i sitemap,
- Google News Publisher Center dla zasad i wymagań wydawcy,
- Schema.org dla znaczenia typów oraz właściwości,
- specyfikacja MCP dla protokołu,
- OpenAPI portalu dla kontraktu REST,
- kod HTML realnego artykułu dla stanu produkcyjnego,
- Search Console dla widoczności i stanu indeksacji.
Etap 3: konspekt, który jest mapą odpowiedzi
H1 formułuje główną obietnicę. Lead przedstawia wynik i zakres. H2 odpowiadają kolejnym problemom użytkownika, a H3 rozdzielają komponenty techniczne lub kroki wykonania. Kolejność powinna odzwierciedlać drogę odbiorcy: zrozumienie → decyzja → implementacja → test → utrzymanie.
H1 — główna obietnica artykułu (generowana przez wtyczkę)
├── H2 — model problemu
│ ├── H3 — pojęcia i encje
│ └── H3 — decyzje architektoniczne
├── H2 — implementacja
│ ├── H3 — HTML i metadane
│ ├── H3 — Schema.org
│ └── H3 — API / MCP
├── H2 — testowanie
└── H2 — wnioski i odpowiedzialnośćEtap 4: tekst oparty na konkretach
Każdy ważny akapit powinien zawierać przynajmniej jeden element weryfikowalny: definicję, decyzję, właściwość, przykład, adres, pomiar, kryterium albo konsekwencję. Akapity otwierają się najważniejszą informacją. Termin techniczny jest definiowany przy pierwszym użyciu. Kod otrzymuje krótkie wprowadzenie i opis tego, co należy w nim sprawdzić.
Rytm tekstu budują różne formy informacji: zwarty akapit, lista kontrolna, tabela porównawcza, graf zależności i przykład kodu. Taki układ pozwala ekspertowi szybko odnaleźć szczegół, a mniej technicznemu czytelnikowi zbudować poprawny model pojęciowy.
Etap 5: obrazy i prawa
- Wybierz oryginalny lub legalnie pozyskany obraz związany z tematem.
- Przygotuj wydajny wariant WebP/AVIF i fallback do treści.
- Wpisz naturalny ALT opisujący obraz w kontekście.
- Dodaj podpis, gdy zdjęcie wymaga kontekstu, źródła lub identyfikacji osoby.
- Zapisz autora, credit, prawa, licencję i stronę uzyskania licencji.
- Przygotuj kadr Discover 16:9, kadry Schema 16:9/4:3/1:1 oraz osobny social 1200×630.
- Sprawdź czytelność tematu po kadrowaniu na telefonie.
Etap 6: konfiguracja we wtyczce
- Uzupełnij title, description, canonical i robots.
- Wybierz typ treści i typ Schema.
- Ustaw kategorię główną.
- Wskaż obrazy Discover/News, social, Facebook, Twitter i trzy kadry Schema.
- Dodaj
aboutorazmentionsze stabilnymi URL-ami encji. - Dla materiału newsroomowego włącz moduł zaawansowany i wybierz podtyp.
- Uzupełnij źródła, cytowania, pochodzenie, role redakcyjne, sponsorowanie, korektę, dateline, lokalizację i warunki dostępu w zakresie dotyczącym materiału.
- Potwierdź zgodność zaawansowanych danych z widocznym tekstem.
Etap 7: publikacja i pierwsze 48 godzin
Po publikacji redakcja sprawdza finalny URL, podgląd mobilny, grafikę social, mapę główną i — dla świeżej wiadomości — mapę Google News. Rich Results Test potwierdza odczyt danych strukturalnych. Inspekcja URL pokazuje dostępność dla Google. API i MCP powinny zwrócić ten sam tytuł, daty, URL oraz typ.
Etap 8: aktualizacja i korekta
Istotna zmiana treści aktualizuje dateModified oraz widoczną informację redakcyjną. Korekta błędu otrzymuje opis zakresu, czasu i odpowiedzialnej redakcji zgodnie z publiczną polityką. Zmiana adresu wymaga mapy przekierowania, aktualizacji linków, canonical, sitemap i identyfikatorów. Powtarzalny przegląd kontroluje również prawa do obrazów, linki źródłowe oraz zgodność danych encji.
Jako firma i ekspert mogę zaprojektować oraz wykonać takie wdrożenie dla innego biznesu
Opisany system jest przykładem pracy wykonanej dla PortalMuzyczny.pl. Jako autor programu i wykonawca wdrożenia mogę przeprowadzić analogiczny projekt dla firmy, wydawcy, sklepu, organizacji, eksperta albo platformy posiadającej własne typy danych. Zakres może obejmować sam audyt, naprawę istniejącego SEO, stworzenie dedykowanej wtyczki WordPress, migrację z innego rozszerzenia, budowę grafu encji, konfigurację newsroomu, obrazy wielokanałowe, integracje API oraz przygotowanie serwisu do współpracy z aplikacjami i asystentami AI.
Każde wdrożenie zaczyna się od modelu konkretnego biznesu. Innych pól potrzebuje portal informacyjny, innych sklep z tysiącami produktów, a jeszcze innych firma usługowa działająca w wielu miastach. Program może otrzymać nowe typy treści, słowniki, walidatory, role redakcyjne, integracje i reguły generowania. Panel jest wtedy dopasowany do języka używanego w organizacji, a zespół uzupełnia dane bez ręcznego pisania kodu.
Audyt i architektura
Inwentaryzacja klas URL, właścicieli metadanych, konfliktów wtyczek, typów treści, canonical, robots, sitemap, obrazów, profili autorów, kategorii, encji i danych z Search Console. Wynikiem jest mapa stanu, lista ryzyk i kolejność wdrożenia.
Dedykowany program
Rozbudowa „Pozycjonowania strony” albo osobna wtyczka dopasowana do WordPressa klienta. Zakres może obejmować metaboksy, Gutenberg, role, walidację, import CSV, generatory obrazów, migracje, logi i testy zgodności.
Schema i graf encji
Projekt organizacji, witryny, publikacji, produktów, usług, osób, miejsc, wydarzeń i relacji branżowych. Wtyczka generuje jedną spójną warstwę danych z właściwymi identyfikatorami i bez ręcznego wklejania kodu do artykułów.
News, Discover i obrazy
Proces publikacyjny, daty, autorzy, transparentność, mapy newsowe, kadry 16:9/4:3/1:1, WebP w treści, JPEG dla kart, prawa, ALT-y, podpisy, podglądy i kontrola jakości na urządzeniach.
API, wyszukiwanie i AI
Publiczne lub chronione REST API, OpenAPI, wyszukiwanie encyjne, integracje danych zewnętrznych, MCP, dokumentacja dla programistów i mechanizmy umożliwiające asystentowi odpowiadanie na podstawie bieżących oraz archiwalnych rekordów.
Utrzymanie i rozwój
Aktualizacje zgodności, monitoring błędów, testy regresji, przegląd danych, rozwój funkcji, obsługa nowych typów działalności oraz kontrolowane migracje przy zmianach motywu, WordPressa i zewnętrznych platform.
Funkcje możliwe do dopisania pod konkretny biznes
Zakres techniczny może wykraczać poza pola widoczne w przedstawionej wersji. Dla producenta lub sklepu można dodać relacje marka → kategoria → seria → produkt → artykuł, warianty dostępności, dystrybutorów, dokumentację i porównywarki. Dla wydarzeń można zintegrować Eventim, kalendarze, statusy, wiele terminów, miejsca, bilety i archiwum. Dla serwisu eksperckiego można rozbudować autorów o kwalifikacje, obszary odpowiedzialności, weryfikatorów i proces korekt. Dla portalu danych można stworzyć wersjonowane rankingi, okresy raportowe, API historyczne i filtry.
Możliwe są również dedykowane reguły obrazów, automatyczne tworzenie kadrów dla różnych kanałów, ochrona przed duplikacją nazw i slugów, wyszukiwarka ograniczona do wybranego typu treści, ekrany akceptacji społeczności, anonimizacja danych osobowych, import z systemów partnerów, kolejki synchronizacji, cache, limity, webhooki i raporty administracyjne. Każda funkcja otrzymuje kryteria wejściowe, walidację, uprawnienia, obsługę błędów i test końcowego dokumentu.
Jak wygląda realizacja
- Rozpoznanie.Ustalam cele, typy treści, źródła danych, obecne wtyczki, proces redakcyjny oraz przykładowe strony.
- Audyt próbki.Sprawdzam kod, indeksowanie, metadane, obrazy, wydajność, strukturę i konflikty na reprezentatywnych URL-ach.
- Projekt kontraktu.Powstaje macierz pól, typów, relacji, dziedziczenia, uprawnień, błędów i scenariuszy testowych.
- Implementacja.Tworzę lub rozwijam wtyczkę, integracje i panel, zachowując dane istniejących wpisów.
- Migracja kontrolowana.Import działa najpierw w trybie raportu, a zapis następuje po zatwierdzeniu mapowania.
- Test produkcyjny.Porównuję widok użytkownika, kod, Search Console, podglądy social, mapy, API i urządzenia mobilne.
- Dokumentacja i szkolenie.Zespół otrzymuje instrukcję pól, decyzji redakcyjnych, publikacji, korekt oraz procedur awaryjnych.
- Dalszy rozwój.Nowe funkcje powstają na bazie danych z użycia, zmian standardów i rozwoju działalności.
Co otrzymuje zamawiający
Rezultatem może być raport techniczny, mapa architektury, gotowa wtyczka ZIP, kod źródłowy, instrukcja instalacji, procedura kopii i powrotu, pliki importu, testy, dokumentacja pól, lista kontrolna publikacji i raport walidacyjny. Przy integracji API dochodzą opis endpointów, OpenAPI, przykłady zapytań, model błędów, limity i zasady wersjonowania. Przy procesie redakcyjnym powstają również publiczne polityki oraz matryca odpowiedzialności.
Wdrożenie można zamówić jako pełny projekt albo etapami. Pierwszy etap może ograniczyć się do audytu i usunięcia duplikatów. Drugi obejmuje metadane, obrazy oraz Schema generowane przez jedną wtyczkę. Kolejne mogą dodać newsroom, API, wyszukiwanie, wydarzenia, rankingi i AI. Taki podział pozwala uruchamiać wartość stopniowo, zachowując możliwość rozwoju programu wraz z biznesem.
Co potwierdza audyt PortalMuzyczny.pl
Poniższe zestawienie rozdziela stan znaleziony w dostarczonym kodzie i testach publicznych od funkcji konfigurowalnych oraz metryk dostępnych wyłącznie właścicielowi Search Console. Próbkę HTML stanowi artykuł o HammerFall, a testy endpointów wykonano 5 września 2026 r.
| Obszar | Status | Dowód lub następny krok |
|---|---|---|
| Jeden H1 w badanym artykule | Potwierdzone | W źródle znajduje się jeden główny nagłówek. Ten fragment HTML celowo zaczyna hierarchię od H2. |
| Meta description, canonical i robots | Potwierdzone | Źródło zawiera unikalny opis, canonical oraz max-image-preview:large. |
| Open Graph i Twitter/X | Potwierdzone | Komplet tytułów, opisów, URL-a, obrazu i ALT; social JPEG ma 1200×630. |
| Graf artykułu | Potwierdzone | Jeden @graph z NewsMediaOrganization, WebSite, NewsArticle + AnalysisNewsArticle i BreadcrumbList. |
| Autor, wydawca i polityki | Potwierdzone | Encja autora, organizacja i publiczne odnośniki zasad znajdują się w grafie. |
about, mentions, sekcja i hierarchia | Potwierdzone | Właściwości występują w węźle publikacji, a isPartOf prowadzi przez kolekcję. |
| Trzy kadry 16:9, 4:3 i 1:1 | Obsługiwane | Wersja 5.4.0 ma osobne pola i walidację; redakcja wskazuje je przy konkretnym materiale. |
| WebP w treści i warianty responsywne | Do kontroli per obraz | Sprawdzić format źródłowy, srcset, sizes, fallback, wagę, ALT i wymiary. |
| Główna sitemap | Potwierdzone | /sitemap.xml zwraca HTTP 200 i XML. |
| Mapa Google News | Potwierdzone technicznie | /news-sitemap.xml zwraca HTTP 200 i namespace news. W chwili testu okno dwóch dni było puste. |
| SchemaMap | Potwierdzone | /schemamap.xml zwraca HTTP 200 i mapuje URL-e na typy. |
Strona /developers | Potwierdzone | HTTP 200; quickstart, auth, limity, błędy, wersjonowanie, integracje, trust anchors i discovery. |
| OpenAPI | Potwierdzone | OpenAPI 3.0.3, API 1.8.2 i opisane ścieżki publiczne. |
| REST status, search i Spotify | Potwierdzone | HTTP 200, JSON, paginacja/kursor, zakres i okres rankingu, nagłówki limitów. |
| MCP initialize, tools i resources | Potwierdzone | HTTP 200, protokół 2025-06-18, siedem narzędzi i siedem zasobów. |
| Prompty MCP | Lista pusta | Funkcja może zostać rozwinięta jako wersjonowany zestaw procedur. |
| Obecność i ruch w News/Discover | Search Console | Sprawdzić raporty konta właściciela; publiczny kod potwierdza przygotowanie techniczne. |
| Indeksacja i wybrany canonical | Search Console | Użyć Inspekcji URL dla każdej reprezentatywnej klasy strony. |
Co warto mierzyć cyklicznie
- liczbę indeksowanych i wykluczonych URL-i według typu strony,
- rozbieżności canonical zadeklarowany / wybrany przez Google,
- błędy danych strukturalnych oraz trend po wdrożeniach,
- ruch z Search, Google News, Discover i Google Images,
- CTR kart społecznościowych oraz poprawność generowanych podglądów,
- czas odpowiedzi i odsetek błędów REST/MCP,
- trafność wyszukiwania encyjnego dla artystów, producentów, koncertów i rankingów,
- kompletność ALT, podpisów, praw i kadrów obrazów,
- spójność autora, dat, kategorii głównej i statusu publikacji,
- gotowość agentową oraz powtarzalność kluczowych zadań integracyjnych.
Wniosek: pozycjonowanie jest utrzymywaniem znaczenia
Najmocniejsze wdrożenie powstaje wtedy, gdy treść, kod i model domeny opisują tę samą rzeczywistość. Czytelnik widzi autora, datę, źródła, obraz i kategorię. HTML porządkuje dokument. Schema wiąże encje. Sitemap pomaga je odkryć. Open Graph przedstawia publikację w komunikatorach. REST i OpenAPI dostarczają dane aplikacjom. MCP udostępnia zasoby oraz narzędzia agentom. Search Console pokazuje, jak system działa w Google.
Automatyzacja ma największą wartość jako warstwa spójności. Program może pilnować formatów dat, identyfikatorów, właściwości Schema, kadrów, canonical, map, relacji, limitów i walidacji. Autor nadal wnosi wiedzę, doświadczenie, ocenę źródeł, oryginalną analizę i odpowiedzialność za publikację. To połączenie buduje serwis, który jest jednocześnie użyteczny, wiarygodny, indeksowalny i gotowy do integracji.
PortalMuzyczny.pl pokazuje praktyczny model takiej architektury: redakcyjny graf NewsMediaOrganization, typowane artykuły, profile encji, hierarchia kolekcji, obrazy dla wielu kanałów, publiczne polityki, osobne mapy, dokumentacja developerska, REST, OpenAPI i MCP. Kolejne etapy rozwoju można oceniać tym samym pytaniem: czy nowa funkcja wzmacnia zgodność między tym, co opublikowano, co zapisano w kodzie i co odczytuje odbiorca?
Dokumentacja i narzędzia wykorzystane w opracowaniu
- Google: Creating helpful, reliable, people-first content
- Google: wprowadzenie do danych strukturalnych
- Google: Article, NewsArticle i BlogPosting
- Google: dane wydarzeń, formaty czasu, strefy i zmiany terminów
- Google: Image SEO best practices
- Google: Discover and your website
- Google: robots meta tag i
max-image-preview - Google: News sitemaps
- Google News: wymagania techniczne
- Google News: najlepsze praktyki stron artykułów, dat i aktualizacji
- Google News: zasady treści i transparentności
- Schema.org: Getting Started
- The Open Graph protocol: obraz, typ, wymiary i ALT
- MDN: element obrazu, wymiary, lazy loading i stabilność układu
- Model Context Protocol: architektura
- GitHub Docs: najlepsze praktyki dokumentacji technicznej
- PortalMuzyczny.pl Public API & AI Discovery
- PortalMuzyczny.pl OpenAPI
- Google Rich Results Test
- Google Search Console
- Ora.ai API & MCP documentation