W artykule autor jest niewidoczny, data zmienia się co tydzień, a JSON-LD opisuje inną osobę i starszy obraz. Test składni przechodzi, więc zespół uznaje temat za zamknięty. Dane strukturalne są formalnie poprawne i faktycznie nieprawdziwe. To gorszy stan niż brak znaczników, bo daje pewność bez zgodności.
Dane Article powinny opisywać rzeczywistą stronę. Google nie wskazuje wymaganych właściwości dla tego typu; zaleca dodawać te, które pasują do treści, na przykład autora, daty, tytuł lub obraz. Nie jest to osobny kanał na dodatkowe słowa kluczowe. Przy treściach AI nie ma specjalnego schema wymaganego przez funkcje AI Google. Podstawy nadal działają.
Zacznij od widocznej treści
Sprawdź, co użytkownik widzi: tytuł, autora, datę, obraz, wydawcę i treść. JSON-LD powinien odzwierciedlać te same informacje. Nie dodawaj w kodzie osób, których nie ma na stronie.
Jeżeli autorem jest zespół lub organizacja, opisz to zgodnie z rzeczywistą rolą. Nie twórz fikcyjnej osoby dla lepszego wyglądu bio. Redakcja może być wskazana jako organizacja, jeżeli odpowiada procesowi publikacji.
Przy bio stosuj zasady z artykułu o autorze i doświadczeniu w treściach AI. Autorstwo powinno być związane z odpowiedzialnością, a nie tylko polem w CMS.
Autor z właściwym typem i adresem
Google opisuje author jako Person lub Organization oraz zaleca poprawne rozróżnianie ról. Nie wpisuj kilku osób w jedno pole tekstowe. Każdy autor powinien mieć właściwą strukturę i zgodny profil.
Adres autora powinien prowadzić do strony identyfikującej go i opisującej doświadczenie. Nie musi to być profil społecznościowy, jeżeli istnieje dobra strona redakcyjna. Link musi działać i dotyczyć tej samej osoby.
Nie dodawaj stanowiska i tytułów do author.name, jeżeli pole ma zawierać nazwę. Używaj właściwych pól i zgodnych informacji. Kod nie jest miejscem na całe CV.
Data publikacji i modyfikacji
datePublished opisuje pierwszą publikację, dateModified rzeczywistą zmianę. Nie aktualizuj modyfikacji przy samym otwarciu edytora lub zmianie jednego znaku bez znaczenia. Proces powinien definiować istotną zmianę.
Zachowaj datę i strefę zgodnie z formatem ISO 8601. Widoczna data powinna być zgodna z kodem. Nie pokazuj użytkownikowi jednej daty, a wyszukiwarce drugiej.
Przy aktualizacji źródeł lub faktów zaktualizuj treść przed datą. Nowa data przy starym cenniku nie jest aktualizacją. Artykuł o aktualizacji treści SEO opisuje proces bez kosmetyki.
Tytuł bez nadmiarowego pakowania
headline powinien odpowiadać rzeczywistemu tytułowi. Możesz mieć krótszy seoTitle dla wyniku, ale nie twórz kilku sprzecznych obietnic. Czytelnik po kliknięciu powinien rozpoznać ten sam temat.
Nie dodawaj listy modeli i fraz tylko w JSON-LD. Nie poprawia to treści i tworzy sprzeczność. Naturalny tytuł z zadaniem jest wystarczający.
Przy długim tytule zastanów się nad czytelnością na urządzeniach. Google zaleca zwięzłość, bo tytuły mogą być skracane. Nie ucinaj jednak warunku zmieniającego sens.
Obraz zgodny z artykułem
Jeżeli dodajesz obraz w danych Article, wybierz plik reprezentujący treść i dostępny do zeskanowania. Google zaleca tę właściwość, ale nie wymaga jej dla Article. Nie używaj samego logo jako zamiennika każdej ilustracji. Obraz powinien mieć prawa, wersję i opis.
Google opisuje zalecenia dotyczące obrazów Article, w tym format i rozdzielczość. Sprawdź aktualne wytyczne przed wdrożeniem. Nie generuj sztucznych wariantów obrazu tylko dla znaczników bez wartości dla czytelnika.
Przy bibliotece stosuj zasady z artykułu o prawach do obrazów CMS. SEO nie zdejmuje obowiązku odbioru licencji i wariantu.
JSON-LD jako jedno źródło danych
Generuj znaczniki z tych samych pól co strona. Nie utrzymuj osobnego obiektu ręcznie, jeżeli może się rozjechać z CMS. Autor, data, obraz i tytuł powinny mieć jedno źródło prawdy.
Sprawdź typy i pola wymagane przez własny CMS oraz zalecane właściwości w dokumentacji Google. Dla znacznika Article Google podaje właściwości zalecane, a nie listę wymaganych. Nie wpisuj pustych lub zgadywanych wartości tylko po to, żeby obiekt wyglądał na pełny.
Przy aktualizacji artykułu zaktualizuj renderowaną stronę i kod w tym samym procesie. Test powinien porównywać HTML z JSON-LD, nie tylko składnię.
Brak specjalnego schema dla AI Overviews
Google wskazuje, że funkcje AI wyszukiwarki nie wymagają osobnych plików, znaczników ani specjalnego schema. Strona musi być indeksowana i kwalifikować się do wyświetlenia z fragmentem. Standardowe zasady SEO pozostają podstawą.
Sprawdź również ustawienie funkcji generatywnej AI w Search Console. Według Google domyślnie witryny są uwzględniane, ale właściwość może dziedziczyć ustawienie nadrzędne lub zostać wykluczona. Samo spełnienie warunków nie gwarantuje wyświetlenia strony.
Nie dodawaj wymyślonych typów „AIAnswer” lub „LLMContent” w nadziei na specjalną widoczność. Nie istnieje taki wymóg w oficjalnych zasadach. Skup się na pomocnej treści i technicznym dostępie.
Dane strukturalne powinny odpowiadać widocznej treści. To szczególnie ważne przy AI, gdzie model może wspomagać pisanie, ale odpowiedzialność za fakt pozostaje przy redakcji.
Dane strukturalne nie gwarantują wyniku
Poprawny Article pomaga zrozumieć stronę, ale nie gwarantuje rozszerzonego wyniku, indeksacji ani konkretnej pozycji. Google jasno zastrzega, że wyświetlenie zależy od wielu elementów.
Nie raportuj wdrożenia jako gwarancji ruchu. Mierz stan techniczny, indeksację i zachowanie użytkowników. Nie przypisuj każdej zmiany ruchu samemu JSON-LD.
Testy Rich Results i inspekcja URL pomagają znaleźć problemy, ale nie zastępują oceny treści. Brak błędu składni nie dowodzi prawdziwości danych.
Article, Organization i Breadcrumb zgodnie z rolą
Nie mieszaj typów bez potrzeby. Article opisuje artykuł, Organization wydawcę lub organizację, BreadcrumbList ścieżkę. Każdy element powinien odpowiadać widocznej strukturze.
Nie twórz fałszywej nawigacji tylko w danych. Jeżeli użytkownik nie widzi kategorii, kod nie powinien przedstawiać innej hierarchii. Zachowaj spójność adresów i nazw.
Przy stronie usługi stosuj zasady z artykułu o SEO B2B i dowodach. Schema jest częścią opisu, a nie dodatkową warstwą reklamy.
Przykład: dwóch autorów i redakcja
Artykuł ma dwóch autorów oraz redaktora odpowiedzialnego za odbiór. W widocznej treści pokazujesz ich role zgodnie z procesem. W JSON-LD rozdzielasz autorów zamiast wpisywać jedno nazwisko po przecinku.
Jeżeli redaktor nie jest autorem, nie przypisuj mu autorstwa dla kompletu. Może pełnić inną rolę zgodną z danymi i procesem. Nie każda osoba przy tekście musi znaleźć się w author.
Profile prowadzą do rzeczywistych bio. Data zmiany odpowiada ostatniemu przeglądowi merytorycznemu. Obraz ma prawa i opis. Dopiero po tym sprawdzasz składnię.
Przykład: artykuł po aktualizacji modelu
Stary tekst opisuje funkcję, która zmieniła limit. Aktualizujesz źródło, przykład i widoczną datę. JSON-LD pobiera nową datę oraz obraz z tej samej wersji.
Nie przepisuj datePublished. Zachowujesz pierwotną publikację i dodajesz rzeczywistą modyfikację. Linki z artykułu prowadzą do aktualnej dokumentacji.
Przy wersjach pomocny jest artykuł o monitoringu starych źródeł AI. Schema nie zastępuje procesu świeżości.
Test na kilku typach stron
Wybierz artykuł, stronę kategorii i usługę. Sprawdź, czy typy odpowiadają roli, autorzy są zgodni, daty poprawne, a obrazy dostępne. Nie oczekuj Article na każdej stronie.
Otwórz źródło HTML i porównaj z widocznym tekstem. Sprawdź renderowanie po publikacji, nie tylko dane w CMS. Proces może tworzyć różnice między środowiskami.
Przy technicznym odbiorze stosuj zasady z artykułu o testach linków i canonical. Dane strukturalne należą do pełnego testu SEO.
Automatyzacja bez zgadywania pól
AI może pomóc wykryć braki i sprzeczności, ale nie powinno uzupełniać autora, daty ani obrazu na podstawie podobnych artykułów. Reguły powinny zatrzymywać publikację przy krytycznym konflikcie.
Dodaj testy jednostkowe dla mapowania pól i testy strony po renderze. Nie przepisuj wyniku modelu do JSON-LD bez walidacji. Kod wymaga wersji i właściciela.
Przy zmianie CMS powtórz zależne typy stron i jeden kontrolny. Nie generuj całej historii od nowa bez potrzeby. Zachowaj daty i identyfikatory.
Odbiór przez redakcję i technika
Redakcja potwierdza autora, rolę, datę i widoczną treść. Technik sprawdza typy, adresy, składnię i renderowanie. Właściciel praw ocenia obrazy i bio.
Przy wyniku testu nie kończ na zielonym statusie. Otwórz stronę i porównaj informacje. Jeżeli dane są sprzeczne, popraw źródło, a nie jeden wariant ręcznie.
Raz na jakiś czas sprawdź aktualne wytyczne Google. Zasady i obsługiwane funkcje mogą się zmieniać. Nie przenoś starych porad bez odczytu dokumentacji.
Minimalny odbiór przed publikacją
Sprawdź typ, autora, datę, tytuł, obraz, wydawcę, canonical i dostępność. Uruchom właściwe testy Google oraz własne porównanie HTML z danymi. Zapisz wersję szablonu.
Nie dodawaj pól, których nie rozumiesz i nie potrafisz utrzymać. Mniej zgodnych danych jest lepsze niż pełny obiekt zgadywany przez model.
Migracja CMS bez utraty zgodności
Przy zmianie systemu zmapuj pola autora, dat, obrazów i typów przed eksportem. Nie zakładaj, że pole o nazwie modified oznacza to samo w obu platformach. Zachowaj strefę czasu i historię rzeczywistych zmian.
Po imporcie porównaj kilka stron z różnymi rolami: jeden autor, kilku autorów, organizacja i starsza aktualizacja. Sprawdź HTML oraz JSON-LD. Jeżeli widoczna data jest poprawna, a kod pokazuje inną strefę lub dzień, popraw mapę przed kolejnym etapem.
Nie generuj brakujących autorów z kont użytkowników automatycznie. Konto administratora nie zawsze jest autorem treści. Przy migracji może być potrzebny osobny profil redakcyjny i decyzja właściciela.
Najczęstsze błędy do testu regresji
Dodaj przypadki: autor usunięty, data bez strefy, obraz niedostępny, tytuł różny od H1, puste pole i niespójne relacje między typami na jednej stronie. Dwa właściwe typy mogą opisywać różne elementy bez błędu. Każdy powinien mieć oczekiwany komunikat lub blokadę. Nie testuj tylko idealnego artykułu.
Sprawdź wersję językową. Autor i data mogą być wspólne, ale tytuł, obraz i canonical muszą odpowiadać właściwej stronie. Nie kopiuj JSON-LD z polskiej wersji na angielską bez mapy pól.
Po zmianie szablonu uruchom zależne testy i jeden poprawny kontrolny. Zielony wynik jednego artykułu nie potwierdza całego serwisu. Regresja lubi pojawiać się na stronie z mniej typową rolą autora.
Dokument dla redakcji bez żargonu
Opisz, które pola są wymagane, co oznacza modyfikacja i kiedy wybrać organizację zamiast osoby. Nie każ redaktorowi edytować JSON-LD ręcznie. System powinien prowadzić przez pola i pokazywać błąd zrozumiale.
Dodaj przykład poprawny i jeden konflikt do rozwiązania. Instrukcja powinna być krótsza niż sama strona Article. Redakcja ma odpowiadać za prawdę treści, a techniczny szablon za przeniesienie jej do kodu bez dodatkowych interpretacji.
Aeneia Design pomaga połączyć treść, autora i doświadczenie. Aeneia Audit pomaga uporządkować proces publikacji i odbiór.
Po zmianie autora, obrazu lub daty porównaj widoczną stronę z jej danymi strukturalnymi. Weryfikator składni pomoże wykryć błąd techniczny, ale zgodność znaczenia trzeba ocenić na podstawie treści. Wynik testu zachowaj przy wersji publikacji i powtórz go po zmianie szablonu lub integracji CMS.
Sprawdź nas. To zdrowe.
Temat zmienia się szybko. Linki prowadzą do źródeł pierwotnych i stron, na których możesz zweryfikować kontekst.
