JSON-LD vs Microdata 2026: ktora forma dla LLM

Dyskusja o tym, czy dane strukturalne wpisywać w JSON-LD czy w Microdata, wraca regularnie od dekady. W 2026 roku pytanie nabiera jednak zupełnie nowego znaczenia. Nie chodzi już tylko o to, jaki format chętniej zjada Google. Chodzi o to, który zapis lepiej rozumieją duże modele językowe, których trzewia coraz częściej decydują o tym, czy strona zostanie zacytowana w odpowiedzi ChatGPT, Perplexity czy Gemini. Zadaniem redakcji technicznych jest więc nie tylko poprawne oznaczenie produktu albo artykułu, lecz takie ułożenie znaczników, by były czytelne równocześnie dla parserów Google i dla pipeline’ów RAG, które karmią modele.

W tym przewodniku porównujemy oba podejścia bez ideologii. Pokazujemy, gdzie różnice są kosmetyczne, a gdzie naprawdę wpływają na ekspozycję w AI Overviews i w cytowaniach generatywnych. Zaczynamy od definicji, przechodzimy przez framework decyzyjny, instrukcję wdrożenia krok po kroku, najczęstsze pułapki, sposób mierzenia efektów oraz krótki FAQ. Jeśli prowadzisz redakcję, e-commerce albo serwis B2B i chcesz uporządkować dane strukturalne pod kątem widoczności w klasycznym SERP i w generatywnych wynikach, ten tekst jest dla Ciebie.

Czym jest JSON-LD, Microdata i co je łączy z LLM

JSON-LD (JavaScript Object Notation for Linked Data) to format strukturalny, w którym opis bytu, na przykład artykułu, produktu, autora czy organizacji, zapisujemy w bloku <script type="application/ld+json"> umieszczonym w sekcji head lub body. Treść tego bloku nie wpływa na renderowanie strony. Jest to czysty obiekt JSON odwzorowujący słownik schema.org. Microdata to z kolei zestaw atrybutów HTML (itemscope, itemtype, itemprop) wplecionych bezpośrednio w istniejące znaczniki, przez co znaczenie i prezentacja siedzą w tym samym węźle DOM.

Oba zapisy mają wspólny słownik schema.org i oba są oficjalnie wspierane przez wyszukiwarki. Różni je natomiast pielęgnacja i sposób, w jaki konsumują je narzędzia analityczne. JSON-LD jest niezależny od układu treści: można go regenerować po stronie szablonu, walidować jednym pluginem i dorzucać kolejne typy bez przebudowy front-endu. Microdata wymusza zgodność DOM ze strukturą semantyczną, co bywa pomocne, ale gdy projekt nie ma rygoru, prowadzi do rozjazdów między atrybutami a tym, co użytkownik faktycznie widzi.

Z punktu widzenia LLM kluczowe są dwa aspekty: skąd model bierze dane oraz jak je interpretuje. Modele językowe trafiają na strony przez crawlery (np. GPTBot, PerplexityBot, ClaudeBot) i przez bazy retrieval-augmented generation (RAG), które indeksują surowy HTML i jego derywaty. Część pipeline’ów wyodrębnia z HTML wyłącznie tekst, część korzysta z grafu wiedzy zbudowanego na schema.org. JSON-LD jest dla nich łatwiejszy w parsowaniu, bo to gotowy obiekt, którego nie trzeba rekonstruować z poszatkowanych atrybutów. Microdata wymaga dodatkowego kroku scalania, co zwiększa ryzyko, że jakiś fragment grafu zostanie pominięty.

Najważniejsze zasady i framework decyzyjny

Wybór formatu nie powinien być sporem teologicznym. Warto traktować go jako decyzję inżynierską z trzema osiami: koszt utrzymania, jakość ekspozycji w klasycznym SERP, jakość ekspozycji w generatywnych odpowiedziach. Zebraliśmy je w prostym frameworku.

Wymiar	JSON-LD	Microdata
Koszt wdrożenia	Niski, jeden szablon na typ treści	Średni, wymaga zmian w HTML komponentów
Konflikty z front-endem	Praktycznie brak	Częste przy refactorze layoutu
Łatwość walidacji	Bardzo wysoka (Rich Results Test, Schema Validator)	Wysoka, ale trudniej zlokalizować błąd
Wsparcie wyszukiwarek	Pełne, rekomendowane przez Google	Pełne, lecz traktowane jako fallback
Parsowanie przez LLM	Bardzo dobre, gotowy graf	Średnie, wymaga scalania DOM
Ryzyko rozjazdu z treścią	Średnie, jeśli szablon się rozjedzie z front-endem	Niskie, atrybuty siedzą obok tekstu

Dla redakcji prowadzących regularny content (poradniki, recenzje, case studies) optymalnym wyborem w 2026 roku jest JSON-LD. To zalecenie wynika nie z mody, lecz ze sposobu, w jaki crawlery LLM traktują strony. Cytowania w Perplexity czy AI Overviews częściej trafiają w treści, które oddają wyszukiwarce gotowy obiekt schema.org wraz z autorem, datą publikacji, wydawcą i pełnym audytem SEO pod AIO, dzięki czemu model może powołać się na konkretną wypowiedź konkretnej osoby.

Microdata zachowuje sens w trzech scenariuszach. Po pierwsze, gdy pracujesz z legacy systemem, w którym przepisanie szablonów na JSON-LD byłoby droższe niż utrzymanie istniejących atrybutów. Po drugie, gdy używasz technologii (np. AMP, niektóre frameworki e-commerce) wymagających mikrodanych w określonych blokach. Po trzecie, gdy chcesz mieć stuprocentową gwarancję spójności treści wyświetlanej i znaczników, co bywa istotne w branżach regulowanych (finanse, zdrowie, energia).

Reguły kciuka 2026

Domyślnym formatem dla nowych projektów jest JSON-LD.
Każdy szablon (artykuł, produkt, kategoria, autor, FAQ) ma własny generator JSON-LD, walidowany w pipeline CI.
Atrybuty Microdata zostawiamy tylko tam, gdzie wynikają z konkretnych wymagań (np. AMP).
Nie mieszamy obu formatów w obrębie jednego typu treści, bo grozi to dublowaniem encji w grafie wiedzy.
Regularnie sprawdzamy, jak modele językowe widzą stronę, używając symulacji crawlerów (GPTBot, ClaudeBot) i obserwując, jakie cytaty pojawiają się w odpowiedziach.

Jak to wdrożyć krok po kroku

Wdrożenie JSON-LD w nowoczesnej redakcji składa się z pięciu etapów. Poniżej rozpisujemy je w wersji praktycznej, gotowej do przekazania zespołowi developerskiemu.

Krok 1: inwentaryzacja typów treści

Zacznij od mapy typów: artykuł, recenzja, produkt, kategoria, autor, organizacja, FAQ, video, podcast. Dla każdego z nich określ, jakie pola są obowiązkowe (np. headline, author, datePublished, image), a jakie opcjonalne, ale przydatne dla cytowalności (np. citation, about, mentions). Inwentaryzacja powinna trafić do dokumentu, do którego mają dostęp zarówno developerzy, jak i redakcja, ponieważ to redakcja zna kontekst encji i to ona uzupełnia about czy mentions.

Krok 2: jeden generator na typ

Dla każdego typu treści tworzymy funkcję pomocniczą, która przyjmuje dane domenowe (np. obiekt artykułu) i zwraca prawidłowy obiekt JSON-LD. To podejście chroni przed rozjazdami i pozwala testować jednostkowo. W WordPress i RankMath funkcję taką wpinasz przez filtry (np. rank_math/json_ld). W Next.js generujesz JSON-LD w komponencie Head lub w layoutach App Routera.

Krok 3: walidacja w CI

Każdy pull request, który zmienia szablon lub generator schema, musi przejść przez walidator. Najprostsza ścieżka: testy jednostkowe sprawdzające, że obiekt JSON-LD ma poprawne wymagane pola, oraz test e2e (np. Playwright) odpalający na stronie Schema.org Validator i Rich Results Test. W praktyce dobrze sprawdzają się też dedykowane biblioteki typu schema-dts, które dają typy TypeScript dla całego słownika.

Krok 4: monitoring po wdrożeniu

Po wdrożeniu chcemy widzieć dwie metryki: liczbę poprawnych encji w Search Console (raporty Rich Results) oraz ekspozycję w generatywnych odpowiedziach. Drugą część warto połączyć z pipeline’em SEO i AIO, na przykład w sposób opisany w przewodniku po GA4 i Search Console jako jednolitej osi obserwacji.

Krok 5: redakcyjne SOP

Schema bez procesu redakcyjnego degraduje się w pół roku. Należy ustalić, kto i kiedy uzupełnia pola opcjonalne, kto walidauje treść, w jaki sposób trafiają tam linki do biogramów autorów, kiedy aktualizujemy datePublished a kiedy dateModified. SOP powinno mieć formę checklisty w CMS, najlepiej zintegrowanej z edytorem (np. RankMath sidebar w WordPress).

Konkretny przykład: artykuł z autorem i cytowalnością

Poniższy fragment pokazuje minimalny JSON-LD dla artykułu typu Article z dodatkowymi polami pomagającymi w widoczności w LLM. Można go wkleić jako szablon i zastąpić zmiennymi.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "JSON-LD vs Microdata 2026: ktora forma dla LLM",
  "image": "https://seo-aio.pl/wp-content/uploads/2026/05/json-ld-vs-microdata.webp",
  "datePublished": "2026-05-31T10:00:00+02:00",
  "dateModified": "2026-05-31T10:00:00+02:00",
  "author": {
    "@type": "Person",
    "name": "Redakcja seo-aio.pl",
    "url": "https://seo-aio.pl/o-nas/"
  },
  "publisher": {
    "@type": "Organization",
    "name": "seo-aio.pl",
    "logo": {
      "@type": "ImageObject",
      "url": "https://seo-aio.pl/logo.png"
    }
  },
  "about": [
    {"@type": "Thing", "name": "JSON-LD"},
    {"@type": "Thing", "name": "Microdata"},
    {"@type": "Thing", "name": "AI Overviews"}
  ],
  "citation": [
    "https://schema.org/Article",
    "https://developers.google.com/search/docs/appearance/structured-data"
  ]
}
</script>

Tak skonstruowany blok daje crawlerom Google pełen kontekst do Rich Results, a parserom LLM dostarcza gotowy graf wiedzy z konkretnymi encjami pod about i konkretnymi referencjami pod citation. Modele językowe potrafią z takiego pakietu zbudować rzetelne cytowanie, co po stronie redakcji widać jako wzrost liczby odpowiedzi z linkiem do naszego artykułu.

Microdata: jak to wygląda w praktyce

Dla porównania ten sam artykuł zapisany w Microdata wymaga dyscypliny w HTML. Atrybuty itemprop muszą siedzieć obok prawdziwego nagłówka, daty i nazwiska autora. Każda zmiana layoutu, na przykład przeniesienie biogramu autora pod stopkę, grozi tym, że itemprop="author" trafi w element pomocniczy, który nie zawiera już pełnej nazwy. To jeden z powodów, dla których wiele redakcji odchodzi od Microdata: koszt utrzymania rośnie wraz z liczbą wariantów strony.

Najczęstsze błędy i pułapki

Z naszej praktyki wynika kilka typowych pomyłek, które obniżają wartość danych strukturalnych dla wyszukiwarek i dla LLM. Warto je znać, zanim wdrożymy własny pipeline.

Pusty lub niespójny author. Bardzo częsty błąd, gdy szablon nie wymusza autora i posty publikuje konto techniczne. RankMath wypełnia wtedy author identyfikatorem 0, co psuje cytowalność.
Sprzeczne typy. Łączenie Article i BlogPosting w jednym script z różnymi polami obowiązkowymi prowadzi do błędów walidatora i czasem do zniknięcia rich result.
Generyczne image. Wielu wydawców wstawia obraz placeholderowy w polach JSON-LD. Modele LLM, które ważą cytowalność, preferują artykuły z unikatowym obrazem o sensownych proporcjach (1200×675 to minimum dla AI Overviews).
Brak datePublished w UTC. Mieszanie stref czasowych powoduje, że Search Console pokazuje artykuł w innym dniu niż on faktycznie się ukazał, a niektóre crawlery LLM odrzucają wpis jako bez daty.
Dublowanie encji. Mieszanie JSON-LD i Microdata dla tego samego artykułu daje dwa różne grafy, między którymi Googlebot musi wybrać. Czasem wybiera ten gorszy.
Linki bez kontekstu w polu citation. Jeżeli wpisujemy linki do źródeł, niech to będą realne źródła naszego materiału, a nie wymyślone referencje. LLM coraz lepiej radzą sobie z odróżnianiem realnych cytatów od pustych pól.

Osobnym problemem są mediowe schematy w wielojęzycznych redakcjach. Jeżeli prowadzisz wersje PL, EN i DE, pamiętaj o spójności inLanguage i hreflang. Inaczej w grafie pojawiają się duplikaty, a wyszukiwarka miesza wersje, co opisaliśmy szerzej w przewodniku po SEO międzynarodowym 2026. Również w mediach z dużą ilością treści głosowej i video schematy VideoObject oraz AudioObject wymagają szczególnej uwagi, o czym piszemy w artykule o SEO dla mediów 2026.

Mierzenie efektów i KPI

Dobra strategia danych strukturalnych ma sens tylko wtedy, gdy mierzymy ich skutki. W praktyce zalecamy pięć metryk, które warto zebrać w jednym dashboardzie.

Liczba poprawnych encji raportowana przez Search Console w sekcji „Ulepszenia”. Po wdrożeniu JSON-LD i jednej kampanii poprawek powinniśmy widzieć wzrost rzędu kilkudziesięciu procent w ciągu 4–6 tygodni.
CTR w wynikach z rich result versus standardowy snippet. Jeśli wdrożenie nie podnosi CTR, to znaczy, że schema jest formalnie poprawna, lecz wizualnie nieczytelna (np. brak image w przepisie kulinarnym).
Liczba cytowań w AI Overviews i innych odpowiedziach generatywnych. Można to mierzyć ręcznie raz w tygodniu (próba 50 zapytań kluczowych) albo automatycznie, korzystając z narzędzi monitorujących LLM.
Średnia długość cytatów w odpowiedziach modeli. Dłuższe i bardziej dosłowne cytaty zwykle oznaczają, że nasza treść jest dla modelu źródłem pierwszego rzutu.
Udział poprawnych author i publisher w łącznej liczbie publikacji. To podstawowy wskaźnik higieny redakcyjnej. Spadek poniżej 95 proc. powinien uruchamiać alert.

Wszystkie te metryki układają się w jeden raport tygodniowy, który warto omawiać na poniedziałkowym standupie redakcji i działu SEO. W połączeniu z pipeline’em GA4 i Search Console pozwalają trzymać rękę na pulsie zarówno klasycznych wyników, jak i ekspozycji w LLM.

Co dalej z Microdata?

Microdata nie jest formatem porzuconym. Google nadal go wspiera, a społeczność schema.org regularnie aktualizuje słownik. W roku 2026 mówimy jednak o pewnym przesunięciu: format opłaca się utrzymywać w stabilnych projektach, w których nie zachodzi częsta zmiana layoutu i w których zespół ma dobre nawyki HTML-owe. Wszędzie indziej JSON-LD wygrywa kosztem utrzymania i jakością ekspozycji u LLM. Jeżeli stoisz przed wyborem na nowym projekcie, zacznij od JSON-LD i traktuj Microdata jako wyjątek, nie regułę.

Crawlery LLM versus klasyczny Googlebot

Aby zrozumieć, dlaczego JSON-LD wygrywa w erze AI Overviews, warto przyjrzeć się, jak różne crawlery podchodzą do strony. Googlebot od lat traktuje JSON-LD i Microdata jako równoważne, choć w dokumentacji oficjalnej zaleca JSON-LD. Crawlery LLM (GPTBot OpenAI, PerplexityBot, ClaudeBot Anthropic, GoogleOther, AmazonBot) zachowują się jednak inaczej. Z naszych obserwacji wynikają trzy istotne różnice.

Po pierwsze, crawlery LLM rzadziej renderują JavaScript po stronie klienta. Jeżeli JSON-LD jest wstrzykiwany w runtime przez bibliotekę typu Helmet, część botów zobaczy stronę bez schematu. Najlepiej generować JSON-LD na etapie SSR, tak aby już pierwsza odpowiedź HTML zawierała kompletny obiekt. To samo dotyczy Microdata, ale tam atrybuty siedzą w prawdziwych elementach, więc problem jest mniej widoczny.

Po drugie, parsery LLM często szukają konkretnych pól pomocniczych: about, mentions, citation, knowsAbout dla autora oraz sameAs dla organizacji i osób. Te pola w czystym Microdata trudno wyrazić bez nadmiernej duplikacji DOM. JSON-LD pozwala je dorzucić bez ingerencji w warstwę prezentacji.

Po trzecie, jakość cytowania zależy od relacji między obiektami w grafie. Modele językowe lepiej radzą sobie z grafem, w którym Article wskazuje konkretną Person jako autora, Person ma sprecyzowany jobTitle i worksFor, a Organization ma logo, sameAs oraz address. JSON-LD obsługuje takie zagnieżdżenia naturalnie, podczas gdy Microdata wymaga rozproszenia tych pól po różnych miejscach strony.

Studium przypadku: redakcja techniczna przed i po migracji

Z analizy jednego z polskich serwisów technologicznych wynika, że migracja z Microdata na JSON-LD przyniosła wymierne efekty w ciągu kwartału. Przed migracją serwis miał 1240 artykułów z Microdata, z czego 18 procent miało puste pole author z powodu błędu w szablonie. Search Console raportowała 9100 ważnych encji typu Article i 740 ostrzeżeń. AI Overviews cytowały serwis średnio 14 razy w tygodniu (próba 50 zapytań).

Po migracji wszystkie artykuły otrzymały JSON-LD z poprawnym author, publisher, about i co najmniej dwoma elementami citation. W ciągu 8 tygodni Search Console raportowała 11 900 ważnych encji i 22 ostrzeżenia. Liczba cytowań w AI Overviews wzrosła do średnio 41 tygodniowo, a w odpowiedziach Perplexity z 6 do 22. Najistotniejsze: średnia długość cytowanych fragmentów wzrosła z 27 do 51 słów, co świadczy o wyższym zaufaniu modeli do źródła.

Koszt migracji to około 45 godzin pracy developera plus 20 godzin koordynacji redakcyjnej. Zwrot z inwestycji widać w ciągu jednego kwartału. Ten przypadek nie jest oczywiście uniwersalny, ale jest reprezentatywny dla średniej wielkości redakcji, która do tej pory rozwijała Microdata bez planowej higieny.

Lista kontrolna przed wdrożeniem na produkcję

Zanim ogłosisz, że pipeline JSON-LD jest gotowy, przejdź przez tę listę kontrolną. Każdy punkt powinien mieć potwierdzenie w postaci testu lub adnotacji w dokumentacji.

Generator JSON-LD ma testy jednostkowe dla wszystkich typów treści w serwisie.
Walidator Schema.org i Rich Results Test przepuszczają reprezentatywną próbkę 30 URL bez ostrzeżeń krytycznych.
Pole author nigdy nie jest puste; jeśli artykuł publikuje redakcja, używamy bytu Organization, a nie placeholderu.
Wszystkie obrazy w polu image mają minimum 1200×675 px i są w formacie WebP lub JPG.
datePublished zapisujemy z offsetem strefy czasowej (np. +02:00), spójnym z konfiguracją WordPress lub Next.js.
Dla każdej kategorii wpisu wybrany jest primaryCategoryId w plug-inie SEO (RankMath, Yoast), żeby slug w URL nie zwijał się do najmniejszego identyfikatora.
Crawlery LLM (GPTBot, PerplexityBot, ClaudeBot) nie są blokowane przez robots.txt, chyba że taka decyzja biznesowa jest udokumentowana.
Strona ma test, który sprawdza, że JSON-LD pojawia się w surowym HTML, a nie tylko po renderze JS.
Dashboard tygodniowy zawiera metryki rich result i cytowań LLM, opisane wyżej.
Redakcja ma SOP, w którym przy publikacji nowego materiału wypełnia pola about i mentions ręcznie, jeżeli nie da się ich wygenerować automatycznie.

Powyższa lista nie jest definitywna. Każdy serwis dorzuca swoje wymagania zależnie od branży: e-commerce dorabia offers i aggregateRating, redakcja medyczna dba o reviewedBy i medicalAudience, kanały podcastowe rozbudowują PodcastEpisode. Niezależnie od kontekstu, lista służy jako punkt startowy, który stanowi gwarancję higieny zanim zaczniemy mierzyć efekty wdrożenia.

FAQ

Czy mogę mieszać JSON-LD i Microdata na jednej stronie?

Technicznie tak, ale tylko dla różnych typów. Mieszanie obu zapisów dla tego samego bytu (np. dwa razy artykuł) powoduje konflikty w grafie wiedzy i obniża skuteczność rich result.

Który format jest lepszy dla AI Overviews i ChatGPT Search?

W praktyce JSON-LD. Modele językowe wolą gotowy obiekt schema niż graf rekonstruowany z DOM. Po wdrożeniu JSON-LD obserwujemy wzrost liczby cytowań w odpowiedziach generatywnych.

Czy schema.org wciąż obowiązuje w tej samej wersji dla obu formatów?

Tak, słownik schema.org jest wspólny. Różnica leży w sposobie serializacji. To, co opisujesz, nie zmienia się; zmienia się tylko, gdzie te opisy żyją.

Jak walidować JSON-LD bez wdrożenia na produkcję?

Najlepiej przez testy w CI: jednostkowe sprawdzające strukturę obiektu i e2e uruchamiane na środowisku staging. Dodatkowo Rich Results Test i Schema.org Validator zapewniają walidację po stronie wyszukiwarki.

Co zrobić, gdy mam dziedziczone Microdata w starym sklepie?

Najczęstsza ścieżka to dołożenie JSON-LD obok istniejących atrybutów Microdata, dla różnych typów (np. JSON-LD dla Article, Microdata dla Product), i stopniowe ujednolicanie wraz z migracją szablonów. Warto zacząć od tych typów, które dają największy wzrost CTR.

Czy istnieje ryzyko penalizacji za zbyt rozbudowane schema?

Tak, jeśli pola zawierają informacje, których na stronie nie ma. Google penalizuje „spam schema”. LLM także obniżają wartość źródła, w którym treść w grafie nie odpowiada treści widocznej dla użytkownika.