JSON-LD – co to jest i jak działa w SEO?

Standard W3C, nie wynalazek Google

W praktyce SEO chodzi o blok kodu umieszczony w znaczniku script, który opisuje maszynie, czym jest zawartość strony, korzystając ze słownika schema.org: że ten ciąg znaków to nazwa firmy, tamten to cena, a jeszcze inny to pytanie i odpowiedź.

Zalecany, bo łatwiejszy dla Ciebie, nie skuteczniejszy dla Google

Tu leży najczęstsze nieporozumienie wokół tego formatu. Krąży przekonanie, że JSON-LD jest przez wyszukiwarkę „lepiej rozumiany” niż starsze sposoby zapisu. Dokumentacja mówi coś innego, i to w jednym zdaniu: „In general, we recommend using a format that’s easiest for you to implement and maintain (in most cases, that’s JSON-LD); all 3 formats are equally fine for Google, as long as the markup is valid and properly implemented per the feature’s documentation”.2

Trzy dopuszczalne formaty są więc dla Google równoważne. Rekomendacja dotyczy wygody wdrażającego, nie skuteczności w wyszukiwarce. Wybór formatu jest decyzją o koszcie utrzymania, a nie o wynikach. Dobrze to wiedzieć, zanim ktoś zaplanuje migrację starszych znaczników wyłącznie z powodu formatu.

Powód wygody dokumentacja też podaje: znacznik „is not interleaved with the user-visible text, which makes nested data items easier to express”.2 Dane siedzą w osobnym bloku, więc zagnieżdżone struktury zapisuje się prościej niż rozsypane po atrybutach w treści.

Wstrzyknięty skryptem też się liczy

Rzadko cytowane, a praktycznie ważne dla systemów zarządzania treścią: „Also, Google can read JSON-LD data when it is dynamically injected into the page’s contents, such as by JavaScript code or embedded widgets in your content management system”.2

Znaczy to, że znacznik dodawany przez wtyczkę albo skrypt po wczytaniu strony jest widziany tak samo jak wpisany w kod źródłowy. Rozwiewa to popularną obawę, że schemat „musi być w źródle”. Warunek pozostaje jeden i dotyczy czego innego niż moment powstania: znacznik ma opisywać to, co użytkownik faktycznie widzi na stronie.

Nasz audyt: trzy hasła i różnica jednego znaku

Ta zasada zgodności jest łatwa do wypowiedzenia i trudna do sprawdzenia, bo walidator jej nie mierzy. Narzędzia testujące sprawdzają składnię i wymagane pola, natomiast pytanie, czy opisany obiekt istnieje na stronie, zostaje po stronie człowieka. Postanowiliśmy to zmierzyć 2 września 2026 roku na własnym słowniku.

Skrypt porównał pytania zapisane w schemacie z pytaniami widocznymi w sekcji najczęściej zadawanych pytań, hasło po haśle. Na 232 hasła ze schematem tego typu zgodnych jest 229. Rozbieżności są trzy i wszystkie trzy mają tę samą liczbę pytań po obu stronach, więc żaden walidator ich nie zgłosi.

Różnica okazała się jednoznakowa. W jednym z tych haseł treść zawiera pytanie z cudzysłowem drukarskim zamykającym, a schemat ma w tym samym miejscu cudzysłów prosty. Tekst jest identyczny co do słowa, znaki są dwa różne. To ilustruje, czym w praktyce jest zgodność schematu z treścią: nie chodzi o sens, tylko o dosłowność, a rozjazd potrafi mieć rozmiar jednego znaku.

Sam pomiar wymagał przy tym dwóch poprawek i obie warto znać. Pierwsza wersja skryptu wykładała się na wyciąganiu pytań wyrażeniem regularnym po tekście schematu. Poprawne okazało się dopiero czytanie ich ze struktury dokumentu. Druga wersja objęła wszystkie wpisy serwisu i wykazała trzydzieści pięć rozbieżności, co brzmiało alarmująco, dopóki nie sprawdziliśmy jednego przypadku: wpisy blogowe mają sekcję pytań pod innym nagłówkiem niż hasła słownika, więc parser jej nie znajdował i raportował zero pytań w treści. Po zawężeniu do zbioru o jednolitej konwencji zostały trzy realne przypadki.

Co z tego wynika przy wdrażaniu

Pierwszy wniosek dotyczy wyboru formatu. Jeśli serwis ma już poprawne znaczniki w starszym zapisie, sama zmiana na JSON-LD niczego nie poprawi w wynikach. Sensowna jest wtedy, gdy ułatwia utrzymanie, na przykład pozwala generować schemat w jednym miejscu zamiast w kilkunastu szablonach, co ma znaczenie przy wynikach rozszerzonych obsługiwanych na wielu typach stron.

Drugi dotyczy kolejności prac. Schemat aktualizuje się razem z treścią, a nie przy okazji. Znacznik zapisany osobno od tekstu nie zmienia się, gdy tekst zostaje przepisany. Właśnie dlatego rozjazdy powstają po każdej większej redakcji, a nie przy wdrożeniu.

Trzeci dotyczy sprawdzania. Przydaje się własny, prosty test porównujący to, co deklaruje schemat, z tym, co widać na stronie. Poprawność składniową sprawdzi każde narzędzie testujące dane strukturalne, natomiast zgodności z treścią nie sprawdzi żaden. Dlatego to ona rozjeżdża się niezauważona.

Najczęstsze pytania

Czy JSON-LD działa lepiej niż Microdata?
Nie dla wyszukiwarki. Dokumentacja stwierdza, że wszystkie trzy formaty są równie dobre, a JSON-LD zalecany jest jako najłatwiejszy we wdrożeniu i utrzymaniu.2

Czy znacznik musi być w kodzie źródłowym strony?
Nie. Google odczytuje dane JSON-LD również wtedy, gdy są wstrzykiwane dynamicznie przez skrypt lub wtyczkę systemu zarządzania treścią.2

Kto jest autorem tego standardu?
W3C. JSON-LD 1.1 to rekomendacja z 16 lipca 2020 roku, opisana jako serializacja danych powiązanych oparta na JSON.1

Czy walidator wykryje niezgodność schematu z treścią?
Nie. Narzędzia sprawdzają składnię i wymagane pola. Porównanie deklaracji z tym, co widać na stronie, trzeba wykonać osobno. U nas taki test wykrył trzy hasła różniące się jednym znakiem.

Źródła

1. W3C, „JSON-LD 1.1 — A JSON-based Serialization for Linked Data”, rekomendacja z 16 lipca 2020 — status i tytuł specyfikacji. Zobacz specyfikację W3C →

2. Google Search Central, „Intro to how structured data markup works” — równoważność trzech formatów, powód rekomendacji JSON-LD, brak przeplatania z treścią widoczną oraz odczyt znaczników wstrzykiwanych dynamicznie. Zobacz dokumentację Google →