Dane strukturalne pod AI 2026: kompletny przewodnik

Dane strukturalne pod AI to dziś nie dodatek do SEO, tylko warstwa, którą modele językowe czytają szybciej i pewniej niż sam tekst strony. ChatGPT, Perplexity i Google AI Mode składają odpowiedzi z encji: firm, osób, produktów, artykułów. Jeśli witryna opisuje te encje w JSON-LD, model dostaje gotową mapę zamiast zgadywać z kontekstu. Ten przewodnik pokazuje, które typy schema mają znaczenie w 2026 roku, jak połączyć je w spójny graf i jak wdrożyć je na WordPressie bez kolejnej wtyczki.

W skrócie

• Modele AI nie „czytają” schema jak Google, ale korzystają z indeksów wyszukiwarek, które je czytają; znacznik działa pośrednio, lecz konsekwentnie.
• W 2026 roku liczą się cztery typy: Organization, Person, Article (lub BlogPosting) oraz Product z Offer; reszta to uzupełnienie.
• Kluczem jest graf encji: jeden @id dla marki, jeden dla autora i odwołania między nimi zamiast osobnych, niepowiązanych bloków.
• Na WordPressie wystarczy jeden filtr w functions.php lub własna mini wtyczka; wtyczki SEO generują schema, ale rzadko poprawnie łączą encje.
• Walidacja to dwa narzędzia (Rich Results Test i Schema Markup Validator) plus kontrola w Search Console co dwa tygodnie.

Po co modelom AI dane strukturalne

Modele językowe nie parsują JSON-LD w czasie odpowiedzi. Sięgają po wyniki wyszukiwarki (Bing dla ChatGPT, własny indeks dla Google AI Mode, mieszany dla Perplexity), a te wyszukiwarki budują swoje grafy wiedzy właśnie ze znaczników. Dane strukturalne wpływają więc na to, co model dostaje jako źródło, a nie na to, jak je czyta.

Efekt jest mierzalny w trzech miejscach. Po pierwsze, strona z poprawnym Organization i sameAs częściej pojawia się jako encja nazwana, a nie jako anonimowy adres URL. Po drugie, Article z datą modyfikacji i autorem ułatwia modelom ocenę świeżości, którą Perplexity pokazuje wprost w cytowaniach. Po trzecie, Product z ceną i dostępnością zasila odpowiedzi zakupowe, w tym ChatGPT Shopping, gdzie bez tych danych produkt po prostu nie istnieje.

Odwrotna sytuacja też jest prawdziwa: strona bez schema wciąż może być cytowana, jeśli ma silny tekst. Znacznik nie zastępuje treści, tylko zmniejsza niepewność modelu. Szczegółowo o tym, jak opisać samą markę, piszemy w artykule Schema Organization i sameAs: jak opisać markę dla AI.

Typy schema, które faktycznie mają znaczenie

Z ponad 800 typów w słowniku schema.org realny wpływ na widoczność w AI ma kilka. Poniższa tabela porządkuje je według tego, co dają i gdzie są konieczne.

Warto zwrócić uwagę na ostatni wiersz. Google zamknął raport FAQ w Search Console i wygasza rich results dla tego typu, o czym pisaliśmy w tekście Google wygasza FAQ rich results. Znacznik FAQPage nie szkodzi, ale nie ma sensu budować na nim strategii; sekcja pytań w HTML robi dla modeli tę samą robotę.

Graf encji: jak połączyć Organization, Person i Article

Największy błąd wdrożeń to trzy osobne bloki JSON-LD, które nic o sobie nie wiedzą. Model widzi wtedy „jakąś firmę”, „jakiegoś autora” i „jakiś artykuł”, ale nie wie, że autor pracuje w tej firmie, a artykuł należy do tego serwisu. Graf encji rozwiązuje to jednym mechanizmem: stabilnymi identyfikatorami @id i odwołaniami do nich.

Zasada jest prosta. Organization dostaje @id w postaci https://domena.pl/#organization, autor https://domena.pl/autor/imie-nazwisko/#person, a artykuł w polu author i publisher nie powtarza danych, tylko wskazuje te identyfikatory. Całość można zamknąć w jednym bloku z tablicą @graph.

{
  "@context": "https://schema.org",
  "@graph": [
    { "@type": "Organization", "@id": "https://domena.pl/#organization",
      "name": "Nazwa firmy", "url": "https://domena.pl/",
      "sameAs": ["https://www.linkedin.com/company/nazwa", "https://www.wikidata.org/wiki/Q123"] },
    { "@type": "Person", "@id": "https://domena.pl/autor/anna-nowak/#person",
      "name": "Anna Nowak", "worksFor": { "@id": "https://domena.pl/#organization" },
      "sameAs": ["https://www.linkedin.com/in/annanowak"] },
    { "@type": "Article", "@id": "https://domena.pl/wpis/#article",
      "headline": "Tytuł wpisu", "datePublished": "2026-06-26T09:00:00+02:00",
      "dateModified": "2026-06-26T09:00:00+02:00",
      "author": { "@id": "https://domena.pl/autor/anna-nowak/#person" },
      "publisher": { "@id": "https://domena.pl/#organization" } }
  ]
}

Trzy szczegóły decydują o jakości grafu. Identyfikatory muszą być identyczne na każdej podstronie (ten sam ciąg znaków, ta sama końcówka). Pole sameAs powinno wskazywać profile, które faktycznie istnieją i mają tę samą nazwę; pusty lub błędny wpis Wikidata obniża zaufanie zamiast je budować. Wreszcie dateModified ma się zmieniać tylko przy realnej aktualizacji treści, nie przy każdym zapisie w edytorze.

Graf encji jest też fundamentem sygnałów EEAT: bez powiązania autora z organizacją model nie ma jak ocenić, kto stoi za treścią. Jak to udowodnić w małej firmie, opisujemy w tekście o EEAT dla jednoosobowej firmy.

Dane strukturalne w e-commerce

W sklepie schema przestaje być sygnałem pomocniczym, a staje się nośnikiem danych. Odpowiedzi zakupowe w ChatGPT, Perplexity i Google AI Mode budują się z trzech pól: price, priceCurrency i availability. Brak któregokolwiek oznacza, że produkt nie wchodzi do porównania.

1. Product: nazwa, obraz, sku, gtin13 (EAN) i brand jako obiekt Organization, nie jako tekst.
2. Offer: cena jako liczba (nie „199,00 zł”), waluta w ISO 4217, dostępność z listy schema.org (InStock, OutOfStock, PreOrder).
3. AggregateRating tylko wtedy, gdy oceny są widoczne na stronie; ukryte oceny to najczęstsza przyczyna ręcznych działań Google.
4. ProductGroup dla wariantów (rozmiar, kolor), żeby każdy wariant miał własny Offer, a nie jedną uśrednioną cenę.

Znacznik Product powinien zgadzać się z feedem produktowym co do grosza. Rozbieżność między ceną w schema a ceną w Merchant Center kończy się odrzuceniem oferty w Google Shopping i wypadnięciem z AI Overviews. Całość wymagań dla sklepu, od feedu przez opisy po kategorie, zebraliśmy w przewodniku Sklepy pod AI 2026.

Wdrożenie na WordPressie: wtyczka czy własny kod

Rank Math, Yoast i AIOSEO generują schema automatycznie i dla typowego bloga to wystarcza. Problem zaczyna się przy grafie encji: wtyczki tworzą osobne bloki dla Organization i Article, często z różnymi @id, a pole sameAs wypełniają tylko z ustawień globalnych. Konfiguracja autora jako Person z worksFor wymaga w większości z nich edycji szablonu lub płatnego rozszerzenia.

Własny kod to około 60 linii PHP. Filtr wp_head wypisuje jeden blok @graph, który czerpie dane z natywnych pól WordPressa: get_the_author_meta() dla autora, get_the_modified_date() dla daty, get_bloginfo('name') dla wydawcy. Wtyczkę SEO zostawia się do meta tytułów i opisów, ale jej generator schema trzeba wyłączyć, inaczej Google dostanie dwa sprzeczne opisy tej samej strony.

Rozsądny kompromis dla większości serwisów: wtyczka SEO do meta, własny blok @graph do encji, WooCommerce do Product. Zasady walidacji poszczególnych pól opisuje dokumentacja Google Search Central, a pełny słownik typów jest na schema.org.

Walidacja i monitoring poprawności

Znacznik trzeba sprawdzać w dwóch narzędziach, bo każde odpowiada na inne pytanie. Rich Results Test od Google mówi, czy strona kwalifikuje się do wyników rozszerzonych; Schema Markup Validator (schema.org) mówi, czy JSON-LD jest składniowo i semantycznie poprawny. Strona może przejść drugi test i oblać pierwszy, na przykład gdy Product nie ma obrazu.

Po wdrożeniu monitoring wygląda tak:

• Search Console, zakładka „Ulepszenia”: raport per typ znacznika z liczbą prawidłowych i błędnych adresów; sprawdzać co 14 dni.
• Crawl własny (Screaming Frog z włączonym parsowaniem JSON-LD) po każdej zmianie szablonu; wychwytuje duplikaty i brakujące @id.
• Test ręczny trzech losowych adresów po każdej aktualizacji wtyczki SEO, bo aktualizacje potrafią przywrócić wyłączony generator.

Warto też co kwartał zapytać wprost ChatGPT i Perplexity o markę i autorów. Jeśli model podaje poprawną nazwę firmy, branżę i osoby, graf encji działa. Jeśli myli firmę z podobną nazwą, pierwsze do sprawdzenia jest pole sameAs.

Najczęstsze błędy, które unieważniają znacznik

Większość problemów ze schema to nie brak znacznika, tylko znacznik, który mówi coś innego niż strona. Google i wyszukiwarki zasilające modele traktują taką rozbieżność jak spam.

• Dane niewidoczne na stronie: ocena 4,9 w AggregateRating, której użytkownik nigdzie nie widzi. To najczęstsza przyczyna ręcznych działań za dane strukturalne.
• Zduplikowane bloki: wtyczka SEO i motyw generują po jednym Organization z różnymi nazwami. Wyszukiwarka wybiera jeden losowo lub ignoruje oba.
• Zmienne @id: identyfikator organizacji różni się na stronie głównej i w artykułach, więc graf rozpada się na niepowiązane wyspy.
• Data jako tekst: „26 czerwca 2026″ zamiast ISO 8601 z przesunięciem strefy. Parser to odrzuci.
• Cena z walutą w jednym polu: "price": "199 zł" zamiast "price": 199 i osobnego priceCurrency.
• Puste lub przypadkowe sameAs: link do profilu innej firmy o podobnej nazwie robi więcej szkody niż brak pola.
• Znacznik w treści zamiast w nagłówku: WordPress potrafi wyciąć tag script z ciała wpisu i zostawić surowy JSON jako widoczny tekst.

Kolejność wdrożenia w 30 dni

Plan zakłada jeden serwis i jedną osobę techniczną. Kolejność wynika z zależności: bez stabilnych identyfikatorów organizacji nie ma sensu opisywać autorów, a bez autorów artykuły tracą połowę wartości.

1. Dni 1–3: audyt. Crawl całego serwisu z parsowaniem JSON-LD, lista wszystkich bloków, źródeł (wtyczka, motyw, widget) i duplikatów.
2. Dni 4–7: Organization. Jeden blok globalny z @id, logo, adresem, sameAs do 3–6 zweryfikowanych profili. Wyłączenie generatorów w innych wtyczkach.
3. Dni 8–12: Person. Strony autorów z biogramem, zdjęciem i profilami; blok Person z worksFor wskazującym na organizację.
4. Dni 13–18: Article. Blok na każdym wpisie z author i publisher jako odwołaniami do @id, poprawne daty w ISO 8601.
5. Dni 19–25: Product i BreadcrumbList. W sklepie: kontrola zgodności ceny z feedem, warianty jako osobne Offer. Wszędzie: okruszki odzwierciedlające realną strukturę kategorii.
6. Dni 26–30: walidacja i monitoring. Testy w obu narzędziach, zgłoszenie kluczowych adresów do ponownego zaindeksowania, ustawienie cyklicznej kontroli w Search Console.

Pierwsze efekty w raportach Search Console pojawiają się po 2–4 tygodniach od ponownego przeskanowania. W odpowiedziach modeli zmiany widać później, zwykle po 6–10 tygodniach, bo indeksy Binga i Google muszą odświeżyć graf wiedzy, a nie tylko pojedyncze adresy.

FAQ: najczęstsze pytania

Co dalej

Najlepszy pierwszy krok to audyt tego, co serwis już wypisuje: jeden crawl z parsowaniem JSON-LD pokazuje duplikaty i braki w godzinę. Potem warto zacząć od bloku Organization, zgodnie z zasadami z artykułu o schema Organization i sameAs, bo od niego zależy każdy kolejny typ w grafie. W sklepie internetowym równolegle trzeba wyrównać dane w schema Product i w feedzie, co opisujemy w przewodniku po sklepach pod AI.