Schema validator: jak sprawdzić JSON-LD i wyniki rozszerzone

Mieliście kiedyś tak, że Rich Results Test świecił na zielono, a opublikowana strona pokazała „Nie wykryto elementów”? Albo cena w JSON-LD była bezbłędna, tylko dotyczyła wczorajszej promocji?

Mnie zielony wynik okłamał we własnym narzędziu, bo inspektor JSON-LD z tego poradnika jeszcze niedawno mylił się w 9 z 12 przypadków testowych. Zielony wynik znaczy tyle, ile narzędzie sprawdziło, więc poniżej pokażę pięć warstw kontroli danych strukturalnych, od składni JSON po to, co z opublikowanej strony odczytał Google, i test z retestem w 6 krokach.

Schema validator i schema checker: nazwy od dostawców, zakres z dokumentacji

Schema validator to narzędzie, które sprawdza składnię i strukturę danych JSON-LD albo Schema.org: wykrywa między innymi niepoprawny JSON, błędne typy i niezgodne wartości, a „schema checker” to druga nazwa tej samej kategorii. Obie nazwy nadają dostawcy, bez osobnych etapów zdefiniowanych przez W3C czy Google, więc „checker” jednego dostawcy potrafi sprawdzać więcej niż „validator” innego. Zakres czytam w dokumentacji, jak u Schema.org Markup Validator czy w poradniku Google o testowaniu danych strukturalnych, i pytam o cztery rzeczy.

1. Czy narzędzie tylko parsuje JSON?
2. Czy zna słownik Schema.org?
3. Czy odczyta stronę, która buduje dane JavaScriptem?
4. Czy stosuje reguły konkretnego wyniku rozszerzonego?

Łatwo też pomylić ze sobą trzy pojęcia, które poniżej rozdzielam.

• JSON-LD to zapis danych połączonych ze specyfikacji W3C JSON-LD 1.1.
• Schema.org dostarcza nazwy obiektów (encji) i właściwości, np. Article, Product, headline czy offers (model danych Schema.org).
• JSON Schema to osobny język ograniczeń dla danych JSON, np. pól wymaganych w odpowiedzi API (json-schema.org), więc sprawdzi kontrakt aplikacji, ale zasady Google są mu obce.

Google obsługuje JSON-LD, Microdata i RDFa, a według wprowadzenia Google do danych strukturalnych zwykle zaleca JSON-LD, bo opis danych leży osobno od HTML-a i łatwiej go utrzymać. Poprawnych mikrodanych nie przenoszę jednak tylko dla lepszej oceny narzędzia, a samą definicję znajdziesz w haśle dane strukturalne.

Pięć warstw walidacji danych strukturalnych i narzędzie do każdej

Każda warstwa ma własne narzędzie i odpowiada na własne pytanie.

Podział opieram na pomocy Search Console o Rich Results Test i pomocy o sprawdzaniu adresów URL, która odróżnia wersję w indeksie od bieżącej. Schema Markup Validator bierze adres albo wklejony kod, czyta trzy formaty, łączy znalezione oznaczenia i potrafi wydobyć dane dodane przez JavaScript. Zewnętrzne adresy @context wymagają pełnego procesora JSON-LD, a funkcję Google ocenisz dopiero w Google Rich Results Test. Każdy wynik zapisuję z adresem i datą oraz trybem testu (kod albo URL).

Region testu w Polsce i EOG: zapisz go obok daty i URL-a

Poprawne oznaczenie działa różnie w różnych krajach, najbardziej u użytkowników z Europejskiego Obszaru Gospodarczego (UE plus Islandia, Liechtenstein i Norwegia). 8 września 2026 Google opublikowało dokumentację różnic regionalnych w wyszukiwarce, odnotowaną też w dzienniku zmian dokumentacji. Dla EOG opisuje m.in. regionalne moduły agregatorów i dostawców oraz wybrane karuzele danych strukturalnych.

Według ogólnych zasad danych strukturalnych poprawne oznaczenie umożliwia funkcję, ale jej wyświetlenia nie gwarantuje, a decyzja może zależeć m.in. od lokalizacji i urządzenia. Gdy kwalifikacja jest, a widoku w SERP-ie brak, sprawdź kraj i rynek, rodzaj zapytania, urządzenie oraz bieżącą dostępność funkcji z jej dodatkowymi kryteriami. Dlatego region zapisuję obok daty i URL-a, a brak widoku traktuję najpierw jako pytanie o rynek, potem o błąd schema.

Jak sprawdzić dane strukturalne w 6 krokach

Kolejność jest stała: cel, potem to, co wysyła serwer, na końcu to, co odczytał Google.

Krok 1: Wybierz konkretny URL i oczekiwaną funkcję Google

Zapisz URL, typ strony i cel kontroli, np. autora artykułu, cenę produktu albo BreadcrumbList nawigacji. W galerii funkcji Google sprawdź, czy oczekiwana prezentacja istnieje i czego wymaga.

Do próby dobierz przypadki brzegowe pod ryzyko witryny, bo jedna poprawna strona mówi tylko o sobie. Mogą to być np. produkt bez opinii, promocja i niedostępny wariant, artykuł z kilkoma autorami, wersja językowa, brak opcjonalnej wartości albo dane od zewnętrznego dostawcy.

Krok 2: Porównaj odpowiedź serwera z DOM po JavaScripcie

Sprawdź oba widoki, bo „Pokaż źródło strony” pokazuje odpowiedź dokumentu, a panel Elements DOM po wykonaniu skryptów. Według poradnika Google o danych strukturalnych z JavaScriptu Google potrafi odczytać JSON-LD dodany dynamicznie, więc o bloku, którego brak w odpowiedzi, rozstrzyga DOM po renderowaniu. Przy Product ta sama dokumentacja ostrzega, że dynamiczne oznaczenia mogą sprawić, że skanowanie danych zakupowych będzie rzadsze i mniej niezawodne, co przy szybko zmieniających się cenach jest ryzykiem.

Podstawowy opis strony trzymaj poza zakładkami i przyciskami, bo Google Search nie klika jak użytkownik (poradnik o treściach ładowanych leniwie). W teście adresu sprawdź też dostęp do skryptów i odpowiedzi API, z których powstają dane.

Krok 3: Oddziel składnię JSON od znaczenia Schema.org

Do parsera JSON wklej samą zawartość bloku, bez znaczników <script>. Napraw końcowe przecinki i niezamknięte nawiasy, usuń komentarze i popraw cudzysłowy, bo reguły składni z RFC 8259 ich zabraniają. Gdy narzędzie przyjmuje pełny HTML, użyj jego trybu HTML.

Potem sprawdź nazwy: Artilce i hedline to poprawny JSON i dalej literówki. Uważaj też na powtórzone klucze, bo standard JSON opisuje różne zachowania odbiorców takich danych, a JSON-LD wymaga unikalnych kluczy w obrębie obiektu. Samą składnię sprawdzisz lokalnie inspektorem poniżej, a wklejone dane zostają w twojej przeglądarce.

Inspektor sprawdza sześć rzeczy:

1. czy blok jest poprawnym JSON;
2. czy ma kontekst Schema.org;
3. czy każdy obiekt ma niepusty tekstowy @type;
4. czy encja ma adres;
5. czy daty mają format ISO 8601;
6. tylko w rodzinie Article: czy jest autor i data publikacji.

Inspektor nie sprawdza nazw typów i właściwości, bo do tego potrzebny jest słownik Schema.org, którego to narzędzie nie ma. Dostają więc status „nie sprawdzono” w miejscu dawnego zielonego „OK”.

Powtórzonych kluczy inspektor nie zgłasza wcale, bo JSON.parse zostawia z nich ostatni. Sprawdź je parserem z kontrolą duplikatów, jak w eksperymencie niżej.

Brak sprawdzenia i brak problemu to dwie różne rzeczy. Dotyczy to też mojego narzędzia: przy duplikatach wciąż milczy. Wpadka ze wstępu polegała na tym, że inspektor zgłaszał brak autora w Product, który autora nie potrzebuje.

Dziś te przypadki pilnuje test kontraktowy w repozytorium, razem z przypadkami negatywnymi. Jeśli dopiero piszesz znacznik, generator schema markup złoży JSON-LD dla 8 typów Schema.org i oznaczy pola, których Google wymaga albo które zaleca.

Krok 4: Sprawdź wymagania właściwego typu i funkcji Google

Pola wymagane zależą od funkcji Google, a w dokumentacji Google dla 0 żadne pole nie jest bezwzględnie wymagane, są tylko zalecane, więc brak autora to tam inna kategoria niż błąd składni.

Twarde wymagania mają za to product snippets, dla których według dokumentacji fragmentów produktu Google wymaga name oraz co najmniej jednego z review, aggregateRating lub offers, razem z wymaganiami wybranego obiektu. Merchant listings mają własne wymagania i sprawdzasz je osobno.

Dla BreadcrumbList dokumentacja okruszków wymaga co najmniej dwóch ListItem z nazwami i pozycjami, a item ostatniego elementu możesz pominąć. Lista ma oddawać sensowną ścieżkę nawigacji, bez mechanicznego rozbijania każdego segmentu URL-a.

Krok 5: Porównaj dane z treścią strony i stanem oferty

Porównaj z widoczną stroną każde pole opisujące treść: tytuł, autora, daty, cenę z walutą, dostępność, opinie. Opis ma dotyczyć tej strony i być aktualny, ale czy oferta istnieje i czy cena należy do właściwego wariantu, oceniasz sam, bo test widzi tylko zapis.

Tak wygląda cena w obiekcie oferty (to tylko fragment modelu; pełne oznaczenie produktu ma więcej pól):

{
  "@type": "Offer",
  "price": "129.00",
  "priceCurrency": "PLN",
  "availability": "https://schema.org/InStock"
}

Na stronie cena może mieć postać „129,00 zł”, a w danych piszesz kropkę dziesiętną i walutę w osobnym polu. Według definicji 0 w Schema.org właściwy może być i tekst "129.00", i liczba 129.00, więc cudzysłów możesz zostawić.

Zgodność dotyczy danych: użytkownik nie musi widzieć technicznego identyfikatora @id. Treści subskrypcyjne mają osobne zasady oznaczania, więc przy paywallu reguła „wszystko widoczne dla każdego” jest za prosta.

Krok 6: Przetestuj kod, a po publikacji pełny URL

Wklejony kod jest wygodny przy pracy nad szablonem, ale po wdrożeniu testuj pełny URL, bo dopiero on pokazuje, co wysyła serwer. Przy implementacjach w JavaScripcie Google zaleca wejście URL, bo tryb kodu ma dodatkowe ograniczenia, np. związane z CORS.

Potem porównaj w Search Console inspekcję wersji w indeksie z testem na żywo i zapisz datę ostatniego odczytu oraz wynik pobrania strony. Test na żywo mówi o bieżącej wersji, a czy Google przetworzył już poprawkę, pokaże dopiero wersja w indeksie.

Gdy test kodu i test strony się różnią, zapisz, którą warstwę z tabeli oglądasz, bo samo „walidator nie znalazł schema” to niepełna diagnoza.

Przykład JSON-LD artykułu z autorem, @graph i @id

Poniżej jest fikcyjny przykład dydaktyczny: wszystko w nim, od adresów example.org po daty, jest wymyślone. Wstaw prawdziwe dane i sprawdź kwalifikację na swojej stronie.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "WebPage",
      "@id": "https://example.org/poradnik#webpage",
      "url": "https://example.org/poradnik",
      "name": "Jak sprawdzić dane strukturalne",
      "inLanguage": "pl-PL"
    },
    {
      "@type": "BlogPosting",
      "@id": "https://example.org/poradnik#article",
      "headline": "Jak sprawdzić dane strukturalne",
      "mainEntityOfPage": {
        "@id": "https://example.org/poradnik#webpage"
      },
      "author": {
        "@id": "https://example.org/autor#person"
      },
      "datePublished": "2026-09-01T10:00:00+02:00",
      "dateModified": "2026-09-03T12:30:00+02:00",
      "inLanguage": "pl-PL"
    },
    {
      "@type": "Person",
      "@id": "https://example.org/autor#person",
      "name": "Osoba testowa",
      "url": "https://example.org/autor"
    }
  ]
}

@graph grupuje opisy, a @id pozwala odwołać się do obiektu bez powtarzania jego danych. Samo odwołanie, np. {"@id":"https://example.org/autor#person"}, może obyć się bez @type. Kilka bloków JSON-LD na stronie jest w porządku, dopóki opisy tego samego obiektu sobie nie przeczą.

@id i adres kanoniczny to osobne mechanizmy, bo fragment #article identyfikuje artykuł jako obiekt, a rel="canonical" jest sygnałem strony, opisanym w dokumentacji Google o kanonikalizacji. Po migracji sprawdź oba, a do tego przekierowania i adresy użyte w relacjach. Jak zgrać sygnały indeksacji, pokazuję w poradniku o canonicalu, sitemapie i robots.txt.

W prawdziwym artykule dodaj też pasującą grafikę (tu jej brak, bo adres byłby fikcyjny), a kilku autorów zapisz jako tablicę osobnych obiektów. Daty zapisuj w pełnym ISO 8601, z godziną i strefą, jak zaleca Google, i zgodnie z datą na stronie. dateModified przestawiaj przy zmianie publikacji, bo codzienny deploy albo automatyczne odświeżenie szablonu to za mało. Blok osadzasz w elemencie script o typie application/ld+json.

Parser JSON przepuścił 4 z 5 błędnych próbek JSON-LD

JSON.parse przyjął 4 z 5 celowo błędnych próbek, a parser z kontrolą powtórzonych kluczy 3 z 5. Sześć plików (jeden kontrolny, pięć z błędem) przepuściłem przez JSON.parse w Node.js 22.16.0 i parser w Pythonie wykrywający powtórzone klucze. To dobrane przypadki edukacyjne, bez ambicji reprezentatywnego benchmarku i bez Rich Results Testu czy Schema Markup Validatora.

W próbce z powtórzonym tytułem JSON.parse zachował ostatnią wartość, „Drugi”, a wcześniejsza zniknęła z obiektu bez błędu. Metodologia eksperymentu z wynikami i ograniczeniami jest w pakiecie badań.

Błędy i ostrzeżenia w walidatorze schema: co sprawdzić przy każdym

„Error” i „warning” znaczą tyle, ile reguła konkretnego narzędzia. Zasady jakościowe Google sięgają dalej niż krytyczne błędy techniczne: fikcyjne opinie albo opis innej treści mogą wymagać oceny człowieka.

Przy ocenach sprawdź zasady fragmentów opinii. Gdy firma kontroluje opinie o sobie i publikuje je w danych LocalBusiness albo Organization, jej strona nie kwalifikuje się do gwiazdek z review snippet, także przez osadzony zewnętrzny widżet. Prawdziwe opinie o produktach oceniasz według ich własnych zasad.

FAQ, HowTo i pole wyszukiwania: które wyniki rozszerzone Google wycofał

Stary szablon potrafi wysyłać oznaczenia pod funkcje, które Google już wycofał.

Datę dla FAQ odnotowuje dziennik zmian dokumentacji Google, a wycofanie HowTo ogłosił post o zmianach HowTo i FAQ. Datę dla pola wyszukiwania podaje pożegnanie pola wyszukiwania.

0 nadal istnieje w Schema.org, a pytania i odpowiedzi bywają przydatną częścią strony, jak na dole tego poradnika. Za samo oznaczenie nie obiecuj jednak rozwijanych wyników Google. Nieobsługiwanego oznaczenia nie kasuję automatycznie, tylko najpierw sprawdzam, czy korzystają z niego inne systemy i czy nadal opisuje prawdziwe dane.

Schema a cytowania w AI Overviews i AI Mode: co pokazują dane

Według badania Ahrefs z maja 2026 dodanie schema nie zwiększyło cytowań stron, które AI już cytowało.

Ahrefs prześledził 1 885 stron, które między sierpniem 2025 a marcem 2026 dodały JSON-LD, i porównał je z 4 000 dobranymi stronami kontrolnymi. Wszystkie badane strony miały już ponad 100 cytowań w AI Overviews w lutym 2025.

Typy schema policzono łącznie, a spadku w AI Overviews autorzy nie przypisują z pewnością samemu oznaczeniu. Dla stron, których AI jeszcze nie zna, pytanie zostaje otwarte.

W poradniku o optymalizacji pod funkcje generatywnej AI Google pisze, że funkcje generatywne nie wymagają specjalnego oznaczenia Schema.org, a danych strukturalnych dalej warto używać dla wyników rozszerzonych. Wynika z tego, że dane strukturalne zostają częścią zwykłego SEO.

Sam stawiam na jasne definicje ze źródłami i widoczne ograniczenia narzędzia, bo pomagają czytelnikowi ocenić wynik, ale cytowań nikomu nie obiecuję. Wskaźnik „AI-ready 100/100” bez jawnej metody i prawdziwych obserwacji to liczba bez pokrycia w widoczności.

Naprawa danych strukturalnych: jak ją zamknąć i utrzymać po aktualizacji

W zadaniu zapisz adres i wariant strony, błędny obiekt, źródło danych, wynik testu i warunek retestu, np.: „cena wybranego wariantu w HTML i offers.price jest zgodna po zmianie promocji; test obejmuje opublikowany URL”.

W WordPressie albo innym CMS-ie ustal, która warstwa generuje każdy opis, a gdy motyw i wtyczka publikują sprzeczne oferty, napraw wspólne źródło. Reprezentatywne szablony waliduj ponownie po aktualizacji CMS-a albo szablonu, migracji adresów URL, zmianie pól produktowych i zmianie komponentu FAQ.

Blokery publikacji zapisuj osobno od rekomendacji, a stan „nie zbadano” jako trzecią kategorię. Po wdrożeniu wróć do inspekcji URL i raportu indeksowania stron w Search Console. Zmiana kliknięć po publikacji może wynikać z innych zmian strony lub zapytań albo z sezonowości, więc walidacji przypisuj najwyżej część wyniku.

Puste szablony do pracy to karta walidacji i retestu oraz kontrola konfliktów między źródłami. Szersze kontrole crawla i indeksacji zbiera poradnik o tym, co powinien zawierać audyt SEO.

Gdy adresów jest za dużo na ręczne sprawdzanie, moduł SEO w CometWeb Insight ocenia dane strukturalne jako osobny filar, obok meta i czytelności, w skali 0–100. W audycie projektu robi to na wielu stronach z crawla, więc widzisz, który obszar ciągnie wynik w dół. Kwalifikację do wyniku Google i tak potwierdza Rich Results Test. Załóż darmowe konto i uruchom pierwszy audyt.

Trzy wnioski

1. Zielony wynik odpowiada na pytanie swojej warstwy, czyli parser wyłapie składnię w kilka sekund, a prawdziwość danych i odczyt przez Google sprawdzasz sam.
2. Po wdrożeniu testuj opublikowany URL i zapisuj region, bo brak widoku w SERP-ie bywa sprawą rynku.
3. Schema zostaje częścią zwykłego SEO, bo w badaniu Ahrefs nie przysporzyła cytowań stronom, które AI już cytowało.

Jutro rano przepuść URL jednej karty produktu przez oba narzędzia i porównaj cenę w JSON-LD z ceną na stronie.

Najczęstsze pytania

Źródła i zakres

Własna próba obejmuje sześć plików JSON przepuszczonych przez parsery, opisanych w pakiecie danych. Całego Schema.org, usług Google ani produkcyjnego serwisu CometWeb nie testuje. Zasady funkcji Google sprawdź ponownie przed wdrożeniem.

1. W3C: JSON-LD 1.1.
2. Google Search Central: General structured data guidelines.
3. Google Search Central: Generate structured data with JavaScript.
4. Google Search Central: Article structured data.
5. Google Search Central: Product snippet structured data.
6. Google Search Central: Breadcrumb structured data.
7. Google Search Central: Latest documentation updates.
8. Google Search Central: Changes to HowTo and FAQ rich results.
9. Google Search Central: Farewell, Sitelinks Search Box.
10. IETF / RFC Editor: RFC 8259, sekcja 4.
11. Google Search Central: Różnice regionalne w wyszukiwarce.
12. Ahrefs: We Tracked 1,885 Pages Adding Schema. AI Citations Barely Moved. (Louise Linehan, 11 maja 2026).