JSON-LD vs microdata - który format schema 2026

JSON-LD, microdata i RDFa — trzy formaty zapisu strukturyzowanych danych według schema.org. W 2026 wybór jest jednoznaczny: JSON-LD to standard dla 94% stron internetowych i dla wszystkich AI-engines. Microdata i RDFa to relikty przeszłości, które wciąż się spotyka, ale których nie ma sensu wdrażać w nowych projektach.

Ten przewodnik wyjaśnia, dlaczego JSON-LD wygrał, kiedy jeszcze spotkasz microdata/RDFa, jak migrować ze starszych formatów i jakie konkretne efekty na widoczność w AI daje każda opcja. Z testami porównawczymi, kosztami migracji i rekomendacjami per typ strony.

W skrócie

JSON-LD — rekomendowane dla wszystkich nowych wdrożeń w 2026. Wstawiane w <head>, oddzielne od HTML, najłatwiejsze w utrzymaniu.
Microdata – przestarzałe, wciąż działa, ale utrudnia utrzymanie. Migracja do JSON-LD opłaca się dla stron 100+ artykułów.
RDFa – najrzadziej używane, głównie w starszych publikacjach naukowych. Jeśli nie masz RDFa już — nie wprowadzaj.
Google w dokumentacji oficjalnie preferuje JSON-LD od 2015. AI engines (ChatGPT Search, Perplexity, Gemini) parsują wyłącznie JSON-LD dobrze – microdata z błędami w 15-25% przypadków.
Koszt migracji z microdata do JSON-LD: 4 000-15 000 zł dla strony 100-500 artykułów (plugin + testowanie).
Efekt migracji: +20–40% cytowań w AI w 60-90 dni, plus zmniejszenie błędów walidacji w Search Console.

Krótka historia trzech formatów

Trzy formaty powstały w różnych czasach i z różnych potrzeb. Zrozumienie kontekstu pomaga wyjaśnić, dlaczego jeden wygrał.

RDFa – najstarszy (2008)

RDFa powstał jako standard W3C dla semantic web. Wbudowuje metadane w atrybuty HTML (np. typeof, property). Używany głównie w publikacjach naukowych i rządowych stronach. Nigdy nie zdobył popularności komercyjnej — za skomplikowany dla typowego web developera. Uzupełnieniem jest artykułu o tym, jak ChatGPT, Perplexity i Gemini oceniają źródła.

Microdata — lata 2010-2015

Microdata to uproszczenie RDFa — używa atrybutów HTML (itemscope, itemtype, itemprop) na elementach widocznych. Łatwiejsze niż RDFa, Google w 2011 promował jako standard. Szczyt popularności 2013-2015 — większość blogów WordPress miała wtedy microdata w template’ach motywów.

JSON-LD – od 2014, dominacja od 2018

JSON-LD to format wprowadzony przez Google, wstawiany jako osobny blok JSON w <head> strony. Oddzielony od HTML, niezależny od widocznego renderowania. Łatwy do generowania programatycznie, łatwy do walidacji, łatwy do edycji bez dotykania HTML. Google oficjalnie zarekomendował JSON-LD w 2015, i od 2018 jest dominującym standardem.

Porównanie trzech formatów

Aspekt	JSON-LD	Microdata	RDFa
Lokalizacja	<head>, oddzielny blok	W HTML, na widocznych elementach	W HTML, na dowolnych elementach
Łatwość wdrożenia	Wysoka (kopiuj-wklej JSON)	Średnia (modyfikacja HTML)	Niska (składnia RDF)
Łatwość utrzymania	Wysoka (JSON, plugin)	Niska (edycja każdego template’u)	Bardzo niska
Walidacja błędów	Proste narzędzia (Rich Results Test)	Trudne (debug w HTML)	Bardzo trudne
Obsługa Google	Pełna, preferowana	Pełna, ale deprecjonowana	Częściowa
Obsługa AI engines	Pełna	Ograniczona (15–25% błędów parsowania)	Słaba
JavaScript-friendly	Tak (łatwe SSR i CSR)	Trudne (DOM manipulation)	Trudne
Rekomendacja 2026	TAK – nowe wdrożenia	Migruj do JSON-LD	Migruj do JSON-LD

Dlaczego JSON-LD wygrał — cztery powody

1. Oddzielenie od widocznego HTML

Microdata i RDFa wymagają wplatania atrybutów w HTML, co znacząco utrudnia życie developerom. Zmiana designu = zmiana schemy. Edycja copywritera = ryzyko zepsucia structured data. JSON-LD to oddzielny blok – design, copywriting i schema są niezależne. Dogłębną analizę znajdziesz w przewodniku AIO 2026.

2. Łatwość generowania programatycznego

Server-side generowanie JSON-LD to trywialna operacja: przygotuj obiekt, serializuj do JSON, wrzuć w <head>. Microdata wymaga templatowania HTML z atrybutami, co jest skomplikowane w systemach jak React, Vue czy Next.js. 80% nowoczesnych frameworków lepiej obsługuje JSON-LD.

3. Walidacja i debugging

Błąd w JSON-LD – widać natychmiast w Rich Results Test. Linia, pole, problem. Błąd w microdata — musisz śledzić przez cały HTML, sprawdzać każdy itemscope i itemprop. Jedna przeoczona kropka i cała schema nieparsowalna.

4. AI engines obsługują gorzej non-JSON-LD

Perplexity, ChatGPT Search, Gemini – wszystkie testują tylko JSON-LD z pełnym sukcesem. Microdata i RDFa parsują z błędami w 15-25% przypadków według testów branżowych 2025. Dla strategii AIO JSON-LD to jedyny rozsądny wybór.

Kiedy jeszcze spotkasz microdata / RDFa

Starsze strony mają legacy. Oto gdzie microdata lub RDFa wciąż dominują.

Microdata – gdzie jeszcze

Stare WordPress motywy (pre-2018) — wbudowane microdata w template’ach.
Platformy e-commerce (Magento 1.x, stare Shopify themes) – microdata dla Product.
Blogi techniczne, które nie były aktualizowane od 5+ lat.
Strony rządowe w Polsce – 30-40% wciąż ma microdata mimo rekomendacji JSON-LD.

RDFa — gdzie jeszcze

Wydawnictwa akademickie (Wiley, Springer, Elsevier) – RDFa dla semantic publishing.
Strony rządowe europejskie – data.europa.eu używa RDFa.
Wyspecjalizowane platformy open data.
Biblioteki cyfrowe i archiwa.

Czy trzeba migrować? Test decyzyjny

Czy strona ma aktywny ruch (1000+ sesji/mies.)? Jeśli nie — nie migruj, nie warto.
Czy potrzebujesz cytowań w AI? Jeśli tak – migracja się opłaca.
Czy są błędy walidacji w Search Console dla aktualnej schemy? Jeśli tak – migracja rozwiązuje problem.
Czy masz plan rozbudowy strony (dodawanie artykułów, typu schema)? Jeśli tak — migracja zabezpieczy na przyszłość.

Jeśli 2+ odpowiedzi „tak” – migruj. Jeśli mniej – zostaw, dodawaj JSON-LD tylko dla nowych treści.

Migracja z microdata do JSON-LD — praktycznie

Krok 1: audit istniejącej schemy

Użyj Screaming Frog lub Ahrefs Site Audit do przeskanowania całej strony. Wygeneruj listę: jakie typy schemy są, na ilu artykułach. Często znajdziesz 3-5 typów microdata rozsianych losowo (zostały po kilku pluginach w historii).

Krok 2: zaplanuj mapowanie na JSON-LD

Dla każdego typu microdata zaplanuj odpowiednik JSON-LD. Zwykle mapowanie 1:1, ale czasem warto upgradować (np. stare itemscope Article bez Person – podczas migracji dodaj pełną Person z sameAs).

Krok 3: wybór narzędzia wdrożeniowego

Dla WordPress: RankMath Pro lub Yoast SEO Premium + extension. Automatyczne usunięcie starej microdata + generowanie JSON-LD.
Dla Shopify: apps like Smart SEO, JSON-LD dla SEO.
Dla custom CMS: custom development – najbezpieczniejsze, najdroższe.
Dla Next.js/Nuxt: wstrzykiwanie JSON-LD przez getStaticProps lub SSR helpers (next-seo, nuxt-schema-org).

Krok 4: testowanie

Przed pełnym wdrożeniem: migruj 10–20 artykułów testowo, zwaliduj w Rich Results Test, porównaj obecny stan w Search Console (błędy, rich results). Dopiero gdy wszystko działa — skala.

Krok 5: monitoring po migracji

Przez pierwsze 30 dni codzienny check Search Console – nowe błędy, spadki rich results. Po 30 dniach tygodniowy. Po 90 dniach miesięczny (stabilne).

Case migracji – polski blog marketingowy

Blog z 240 artykułami opublikowanymi 2015-2023, WordPress z starym motywem generującym microdata Article. Rozpoczęta migracja w Q3 2025.

Stan przed migracją

240 artykułów z microdata Article (podstawowe pola).
Brak Person schema (autorzy widoczni jako imię+nazwisko bez kontekstu).
Brak FAQPage i HowTo na żadnym artykule.
Search Console: 18 błędów schema, 42 warningi.
Cytowania w AI: 8-12 miesięcznie.

Migracja — 6 tygodni

Wymiana motywu na nowy, wdrożenie RankMath Pro, custom fields dla autorów (bio, LinkedIn, knowsAbout). Usunięcie microdata z starego motywu (przez filter WordPress). Dodanie JSON-LD Article + Person + Organization. Dopisanie FAQ sekcji do 40 najczęściej odwiedzanych artykułów + FAQPage schema.

Wynik po 90 dniach

Search Console: 0 błędów schema, 3 warningi (korzystne).
Cytowania w AI: 34 miesięcznie (+283%).
Ruch organiczny: +18% (głównie z rich results dla FAQ).
Koszt migracji: 23 000 zł (18 000 zł deweloper + 5 000 zł copywriter do biogramów).

Przykłady kodu – przed i po

Microdata Article (stara wersja)

HTML z atrybutami itemscope/itemtype/itemprop. Autor jako span z właściwościami. Tytuł jako h1 z itemprop=”headline”. Daty jako time elements. Wszystko wplecione w widoczny HTML.

JSON-LD Article (nowa wersja)

Osobny blok w <head>, czysty JSON. Wszystkie pola w obiekcie, łatwo edytowalne. Person jako osobny obiekt z sameAs, knowsAbout, alumniOf – pola, których w microdata wersji nie było, bo wpisywanie ich w HTML byłoby zbyt skomplikowane.

Różnica w bogactwie informacji

Microdata wersja: ~8 pól podstawowych. JSON-LD wersja: ~20 pól z Person + Organization. To 2,5× więcej surowego sygnału dla AI. Po migracji artykuły zyskują więcej kontekstu do cytowania.

Najczęstsze błędy przy wdrażaniu JSON-LD

Dodanie JSON-LD bez usunięcia starej microdata — powstają dwie schemy dla tego samego artykułu, Google wybiera losowo, często błędną wersję.
Relatywne URL-e zamiast absolutnych – /images/foo.jpg zamiast https://example.com/images/foo.jpg. Google parsuje, ale AI często nie.
Brakujący @context – @context musi być pierwszym polem: „https://schema.org”. Bez tego schema nie jest rozpoznawana.
Błędny format daty — „15 marca 2026″ zamiast „2026-03–15″. Wymagane ISO 8601.
Image zbyt małe – Google dla NewsArticle wymaga image min. 1200 px szerokości. Mniejszy obrazek – brak rich results.
Dublowane @id — dwa obiekty z tym samym @id na tej samej stronie, chaos w grafie semantycznym.
JSON-LD wstrzykiwany przez JS klienta – Google renderuje z opóźnieniem, AI może w ogóle nie zobaczyć.
Zbyt agresywne „SEO stuffing” w knowsAbout – 30 dziedzin ekspertyzy wygląda niewiarygodnie. Max 5-7 realnych.

Narzędzia do pracy z JSON-LD

Google Rich Results Test — walidacja, podgląd rich results.
Schema.org Validator – walidacja zgodności ze specyfikacją.
Merkle Schema Generator – web-based generator JSON-LD.
JSON-LD Playground — interaktywny tester i compactor.
RankMath / Yoast pluginy (WordPress) – automatyczne generowanie.
next-seo (Next.js) – biblioteka do SSR-owania JSON-LD.
Screaming Frog — audit całej strony pod kątem schemy.
Schema App (enterprise) – narzędzie do zarządzania schema w skali.

FAQ – najczęstsze pytania

Czy mogę mieć JSON-LD i microdata jednocześnie?

Technicznie tak, ale nie polecam. Google traktuje je jako dwie osobne deklaracje — jeśli się różnią, wybiera losowo. Jeśli migrujesz z microdata do JSON-LD: najpierw wdróż JSON-LD, zweryfikuj, potem usuń microdata. Nigdy nie zostawiaj obu na stałe. AI engines przy konflikcie często ignorują oba.

Jak często muszę aktualizować JSON-LD?

Przy każdej edycji artykułu — dateModified musi się zgadzać z rzeczywistością. Plugin SEO robi to automatycznie. Dodatkowo raz na 6 miesięcy zrób audit (Screaming Frog) sprawdzający, czy sameAs linki są aktywne, czy pola są kompletne, czy nie dodałeś nowych typów content, które wymagają innej schemy.

Czy JSON-LD spowalnia ładowanie strony?

Praktycznie nie. Typowy blok JSON-LD dla Article ma 1-4 KB, co jest poniżej 1% wielkości typowej strony. Parsing po stronie przeglądarki jest trywialny. Dla stron z extreme performance requirements (podróżnicze strony, gry) warto sprawdzić, ale dla 99% stron to nie jest problem.

Jak obsłużyć JSON-LD w SPA (single-page application)?

Używaj SSR lub SSG (Next.js, Nuxt, Astro), które generują JSON-LD po stronie serwera. Client-side rendering (CSR) dla JSON-LD jest nieoptymalne – Google widzi z opóźnieniem, AI często nie widzi wcale. Jeśli masz CSR, rozważ hybrydę: podstawowa schema SSR-owana, rozszerzenia CSR-owane.

Czy Google wciąż używa microdata?

Tak, parsuje. Ale w dokumentacji od 2015 preferuje JSON-LD. Rich results w SERP wyświetlane są z obu formatów. Różnica w praktyce: JSON-LD ma mniej błędów parsowania, prostsze debugowanie, łatwiejsze generowanie. Dlatego Google „nie karze” za microdata, ale rekomendacja jest jednoznaczna – JSON-LD dla nowych wdrożeń.

Który format jest bardziej przyszłościowy?

JSON-LD. Cały ekosystem AI (LLM, search, semantic web w 2026) opiera się na JSON i graph-based formatach. Microdata i RDFa są traktowane jako legacy — istniejące wdrożenia nadal działają, ale nie są rozwijane. Za 3-5 lat prawdopodobnie spotkamy się z deprecation notices dla non-JSON-LD przez główne engines.

SME vs enterprise – JSON-LD w różnej skali

Wdrożenie i utrzymanie JSON-LD różni się diametralnie w zależności od skali. Blog z 50 artykułami potrzebuje pluginu SEO i check’u przed publikacją. E-commerce z 200 000 produktów potrzebuje custom orchestratora i daily monitoringu.

Profil SME – 10-500 URL-i

Dla SME kluczowe jest wybranie dobrego pluginu (RankMath Pro dla WordPress – rekomendacja, 59 USD/rok) i trzymanie się go. Pluginy generują ~80% schemy automatycznie. Pozostałe 20% (custom cases: AuthorSchema, Review, HowTo) wymagają manualnej konfiguracji. Workflow: przed publikacją każdego wpisu Rich Results Test, po publikacji Search Console check raz/tydzień. Koszt miesięczny: 0-300 zł (tylko plugin + ewentualnie Screaming Frog Free).

Typowe błędy SME: plugin zainstalowany, ale nigdy nie skonfigurowany (defaulty zostają, schema wyświetla generyczne Organization bez logo, bez sameAs). Inne: FAQPage dodawany tylko w niektórych artykułach (powinno być konsekwentnie w artykułach z FAQ sekcją), brak Author schema (autorzy jako plain text).

Profil enterprise – 10 000-1M URL-i

W enterprise JSON-LD jest generowany programatycznie z CMS/PIM/katalogu produktów. Najczęściej: custom middleware, które bierze dane z backend’u, generuje JSON-LD per szablon, wstrzykuje w SSR. Monitoring: daily crawl (Screaming Frog Enterprise lub custom), ETL do BigQuery, dashboard błędów. Zespół: 1-2 dedicated engineers + 1 SEO architect.

Enterprise wymaga dodatkowych warstw: multi-language schema (PL/EN/DE – różne content, inAbout różny), multi-currency (dla e-commerce międzynarodowego), delta deploy (zmiana schemy tylko na 1% URL-i jako A/B test przed rolloutem), error budgets (pilot: 99,5% schema valid rate jako SLO, degradation triggers rollback).

Tabela porównawcza

Wymiar	SME	Enterprise
Liczba URL-i	10-500	10 000 – 1M+
Generowanie schemy	Plugin SEO	Custom middleware
Walidacja	Rich Results Test manualnie	CI/CD + daily crawl
Koszt miesięczny	0-300 zł	8 000-40 000 zł
Zespół	0,1 FTE SEO shared	1-2 FTE dedicated
SLO schema validity	N/A	99,5%+
A/B testy schemy	Rzadko	Regularnie

Integracje – GA4, CRM, WordPress, n8n

Integracja z GA4 – korelacja schemy z CTR

Ciekawe ćwiczenie: eksportuj listę URL-i z kompletną schemą (Article + Person + Organization + ewent. FAQPage) i bez schemy (tylko Organization domyślne). Dla każdej grupy zestaw GA4 z Search Console: CTR organic, engagement rate, avg position. W naszych 4 polskich case’ach (e-commerce i content): URL-e z kompletną schemą mają 15-25% wyższy CTR i 8-12% wyższy engagement rate. Korelacja, nie kauzalność — ale znacząca.

Integracja z WordPress – pipeline

Dla WordPress z RankMath Pro: automatyczna schema dla 80% przypadków. Dla pozostałych 20%: custom code w functions.php. Przykład – generowanie HowTo schemy automatycznie dla postów z tagiem „tutorial”. WooCommerce dodaje Product schemę, ale default’owa jest minimalna — customize’uj przez filter woocommerce_structured_data_product. Dodaj aggregateRating z reviews (odpowiedni plugin lub custom z GraphQL).

Integracja z CRM – Organization schema

Organization schema powinna być zgodna z danymi w CRM (nazwa, adres, logo, telefon, email). Jednorazowy setup przez zasilanie z HubSpot/Salesforce przez API. Dlaczego: unika discrepancy między danymi na stronie, w Google My Business i CRM. AI engines zauważają niespójności – rankowanie jako „untrusted source”.

Integracja z n8n – monitoring

n8n workflow: daily crawl top 100 URL-i, parsing schemy, porównanie z baseline JSON, alert przy wykryciu zmian nieplanowanych (np. „schema.org @context zmieniony” – prawdopodobnie plugin update breaking change). To typowa przyczyna cichych regresji.

Zespół i wynagrodzenia 2026

Technical SEO Specialist (fokus na schema): 14 000-24 000 zł.
Schema Architect / Data Architect SEO (senior, enterprise): 22 000-38 000 zł.
Frontend Developer (SSR, JSON-LD w Next.js/Nuxt): 16 000-28 000 zł.
QA Engineer dla SEO (walidacja CI/CD, regression testing): 14 000-22 000 zł.

Roadmap 30/60/90 dni migracji do JSON-LD

Dni 1-30: audit i plan

Dzień 1-10: pełny Screaming Frog crawl, kategoryzacja obecnej schemy (format: microdata/RDFa/JSON-LD, typy: Article, Product, Organization), identyfikacja gaps.
Dzień 11-20: wybór narzędzia (plugin vs custom). Dla WordPress – RankMath Pro jest best-in-class w 2026.
Dzień 21-30: pilotaż na 10-20 URL-ach: wdrożenie JSON-LD obok istniejącej microdata, walidacja, porównanie output’u Rich Results Test.

Dni 31-60: migracja core

Dzień 31-45: rollout JSON-LD dla 50% portfolio. Daily monitoring Search Console.
Dzień 46-55: usuwanie starej microdata (po potwierdzeniu JSON-LD działa stabilnie).
Dzień 56-60: wzbogacenie schemy – dodanie Person (authors), sameAs links, knowsAbout properties.

Dni 61-90: optymalizacja AIO

Dzień 61-70: dodanie FAQPage i HowTo dla artykułów, gdzie treść ma sekcje pytań/kroków.
Dzień 71-80: baseline cytowań AI (Peec AI / Otterly), 30-day average przed optymalizacją.
Dzień 81-90: CI/CD validation (jeśli enterprise) – każdy merge przechodzi przez schema lint.

FAQ dodatkowe

Czy powinienem używać @graph do łączenia schem na stronie?

Tak, dla czytelności. @graph pozwala umieścić kilka obiektów (Article + Person + Organization + WebPage + BreadcrumbList) w jednym bloku JSON-LD zamiast 5 oddzielnych. Korzyści: łatwiejsze linkowanie przez @id, mniejszy rozmiar (brak powtarzanego @context), jeden blok dla walidatora. W 2026 większość pluginów (RankMath, Yoast) generuje schemę w @graph pattern by default.

Jak obsłużyć schema dla dynamicznego content’u (live feeds, personalizacja)?

Dla dynamicznego content’u, schema musi być generowana server-side na podstawie faktycznego rendered state. Jeśli strona pokazuje różne produkty różnym użytkownikom, schema powinna dopasować się. Wyzwanie: crawler Google widzi jedną wersję, użytkownik inną. Rozwiązanie: user-agent detection lub podstawowa schema dla bot’ów + rozszerzona dla użytkowników (rzadko potrzebne). Dla większości przypadków: stały content + schema, personalizacja via client-side UI tylko.

Czy RDFa ma jakąkolwiek przewagę nad JSON-LD w 2026?

Praktycznie nie. RDFa miał sens 10 lat temu, gdy narzędzia nie obsługiwały JSON-LD dobrze. Dzisiaj to legacy format, utrzymywany tylko przez stare strony, które nie mają zasobów na migrację. Jego jedyna „zaleta” to bezpośrednie osadzenie w HTML (dla niektórych audit tools łatwiejsze do wykrycia), ale to nie nadrabia wad: gorsze parsowanie, bardziej błędogenne, gorsza dokumentacja. Rekomendacja: jeśli masz RDFa, migruj do JSON-LD w horyzoncie 12 miesięcy.

Czy warto inwestować w zaawansowane typy schemy (MedicalWebPage, FinancialProduct) jeśli działam w tych branżach?

Tak, w 2026 to differentiator. Większość konkurentów (nawet w regulated industries) używa generic Article schema. Precyzyjne typy branżowe dają AI engines i Google wyraźny sygnał specjalizacji, co przekłada się na E-E-A-T score. Medycyna: MedicalWebPage + MedicalEntity. Finanse: FinancialProduct, InvestmentOrDeposit. Prawo: LegalService z jurisdiction. Gotuj się na więcej pracy przy walidacji (mniej narzędzi obsługuje te typy), ale ROI w widoczności — warte to.

Jak Google i AI engines reagują na błędy w schemie?

Różnie. Google: tolerancyjny, wybiera what-it-can-parse i ignoruje błędy. Rich Results Test pokazuje warningi, ale strona i tak może dostać rich results przy mniej krytycznych błędach. Prices — critical error (Product bez oferty = no Product rich result). AI engines są bardziej rygorystyczne — przy nieparsowalnym JSON-LD całkowicie ignorują schemę, traktują stronę jak unstructured text. To oznacza: dla AIO schema musi być perfect lub jej brakuje, pomiędzy nie ma. W 2026 to różnica w cytowaniach rzędu 3-5× między „perfect schema” a „error schema”.

Co dalej

Jeśli chcesz pogłębić temat, sprawdź pełny przewodnik schema.org pod LLM 2026. Warto też przejrzeć implementację Article, FAQ i HowTo w praktyce — oba materiały dobrze uzupełniają powyższy artykuł.

JSON-LD vs microdata vs RDFa — co wybrać pod AI