POWRÓT_DO_BLOGA
Aktualizacja: AI & SEO 12 min

Dane strukturalne Schema.org — kompletny przewodnik (2026)

Dane strukturalne to sposób, w jaki mówisz wyszukiwarce wprost, czym jest Twoja treść: że to artykuł z konkretnym autorem i datą, produkt z ceną, firma z adresem albo osoba z profilami w sieci. Zapisuje się je w formacie JSON-LD — to rekomendacja Google — i dzięki nim strona staje się uprawniona do rich results (rozszerzonych wyników z gwiazdkami, cenami, breadcrumbami), a wyszukiwarki i modele AI lepiej rozumieją encje na stronie. W tym przewodniku tłumaczę, co naprawdę dają dane strukturalne, które typy nadal działają w 2025–2026 (a które Google wycofał), jak wygląda poprawny graf JSON-LD i jakich błędów unikać.

Dane strukturalne (JSON-LD) czynią stronę uprawnioną do rich results i pomagają wyszukiwarkom rozumieć encje. Tłumaczę, które typy schema nadal działają w 2025–2026, a które Google wycofał (FAQ, HowTo, sitelinks search box), jak wygląda poprawny graf JSON-LD i jakich błędów unikać.

Zacznę od zdania, które oszczędzi Ci rozczarowań: dane strukturalne nie podniosą bezpośrednio Twojej pozycji w Google. To nie jest czynnik rankingowy. Co więc dają? Czynią Cię *uprawnionym* do funkcji, które realnie podnoszą CTR i widoczność. To jak wejściówka — sama nie wprowadzi cię na imprezę, ale bez niej w ogóle nie wejdziesz.

Czym są dane strukturalne i dlaczego JSON-LD

Dane strukturalne to czytelny maszynowo opis treści — encje (rzeczy) i relacje między nimi — dołączony do strony, by wyszukiwarka rozumiała ją ponad surowy tekst. Wspólnym słownikiem jest Schema.org: otwarta taksonomia typów i właściwości, powołana w 2011 przez Google, Microsoft (Bing) i Yahoo!.

Ten sam słownik można zapisać w trzech formatach: JSON-LD (obiekt w tagu `script`, oddzielony od HTML), Microdata (atrybuty wplecione w widoczny kod) i RDFa. Google obsługuje wszystkie trzy, ale rekomenduje JSON-LD, bo:

  • jest najłatwiejszy do wdrożenia i utrzymania na skalę;
  • jest oddzielony od widocznego HTML — nie psuje się przy zmianach interfejsu (Google przyznaje, że strony psują Microdata znacznie częściej, bo jest wplecione w kod);
  • można go generować dynamicznie po stronie serwera.

Gdzie go umieścić? W bloku `script type="application/ld+json"`, w sekcji `head` lub `body` — oba są poprawne. Najbezpieczniej osadzić go w HTML renderowanym serwerowo; wstrzykiwanie przez JavaScript czy Tag Manager działa, ale Googlebot odczyta je dopiero po renderze, w osobnym, opóźnionym kroku.

Dane strukturalne → rich results. Co naprawdę dają

Uporządkujmy pojęcia, bo bałagan terminologiczny jest tu ogromny:

  • Rich result — każdy rozszerzony wynik zasilany danymi strukturalnymi: gwiazdki recenzji, karta produktu, breadcrumbs, karta przepisu, karuzela.
  • Rich snippet — starszy termin na dodatki *wewnątrz* zwykłego wyniku tekstowego (gwiazdki, cena pod niebieskim linkiem).
  • Knowledge Panel — panel opisujący encję, zasilany z Knowledge Graph. Technicznie *nie* jest rich resultem i nie powstaje wprost ze schemy jednej strony, choć dane strukturalne i sygnały encji mogą się do niego przyczynić.

I dwie zasady, o których łatwo zapomnieć: uprawnienie to nie gwarancja (poprawny markup, nawet zaliczający test Google, nie gwarantuje wyświetlenia — decyduje Google), oraz dane strukturalne pomagają rozumieć encje i relacje, co zasila Knowledge Graph i — pośrednio — widoczność w wyszukiwaniu AI.

Które typy nadal działają w 2025–2026 (a które Google wycofał)

To najważniejsza, najbardziej aktualna część. Google przez ostatnie lata sporo wyciął — i dodawanie wycofanych typów „dla rich resultu" to dziś strata czasu.

Typ schemaStatus rich result (2025–2026)Uwagi
Article / BlogPostingAktywnyheadline, image, author, datePublished/dateModified, publisher
Product + Offer + ReviewAktywnygwiazdki, cena, dostępność; recenzje produktu OK
BreadcrumbListAktywny — tylko desktopod stycznia 2025 Google nie pokazuje breadcrumbs na mobile
Event / Recipe / VideoObjectAktywnywymagają kompletu właściwości (np. Event: name, startDate, location)
JobPostingAktywny (Google Jobs)samodzielny „Estimated Salary" wycofany VI 2025
Organization / LocalBusiness / PersonBrak własnego rich resultzasilają logo, Knowledge Panel, zrozumienie encji
FAQPageWycofanyrich result mocno ograniczony w 2023, raport usunięty w 2026 — markup można zostawić, ale nie da gwiazdkowego wyniku
HowToWycofany (2023)rich result już się nie pokazuje
Course (karta „Course Info")Wycofany VI 2025karuzela „Course List" nadal działa
WebSite + SearchAction (sitelinks search box)Wycofany XI 2024markup nie szkodzi, ale nie da pola wyszukiwania

Najważniejsza pułapka praktyczna: nie dodawaj `FAQPage` ani `HowTo` w nadziei na rich result, który już się nie pojawia. Markup wolno zostawić (pomaga w rozumieniu treści i w AI), ale nie licz na rozszerzony wynik w SERP-ach.

I jedna reguła, która zaskakuje firmy: recenzje „o samym sobie" (self-serving) nie dają gwiazdek. Jeśli umieścisz `Review`/`AggregateRating` o własnej firmie na stronie typu `LocalBusiness` lub `Organization` — Google nie pokaże gwiazdek (egzekwowane od 2019). Wyjątkiem jest `Product` — recenzje produktów nadal uprawniają do gwiazdek.

Jak wygląda poprawny graf JSON-LD

Dobry wzorzec to jeden blok `@graph` z węzłami połączonymi przez `@id` (kanoniczny URL z fragmentem). Encje ogólnostronowe (`WebSite`, `Organization`/`ProfessionalService`, `Person`) definiujesz raz, a strony (`WebPage`, `BreadcrumbList`) odwołują się do nich przez `@id`. Profile zewnętrzne podpinasz przez `sameAs` (najsilniejszy sygnał dla Knowledge Graph to Wikidata).

JSON-LD — marka osobista / firma usługowa
{  "@context": "https://schema.org",  "@graph": [    {      "@type": "ProfessionalService",      "@id": "https://example.pl/#organization",      "name": "Jan Kowalski — Doradztwo SEO",      "url": "https://example.pl/",      "telephone": "+48-12-345-67-89",      "priceRange": "$$",      "founder": { "@id": "https://example.pl/#person" },      "areaServed": "PL",      "sameAs": ["https://www.linkedin.com/in/jankowalski"]    },    {      "@type": "Person",      "@id": "https://example.pl/#person",      "name": "Jan Kowalski",      "jobTitle": "Konsultant SEO",      "worksFor": { "@id": "https://example.pl/#organization" },      "sameAs": ["https://www.wikidata.org/wiki/Q000000"]    },    {      "@type": "BreadcrumbList",      "@id": "https://example.pl/uslugi#breadcrumb",      "itemListElement": [        { "@type": "ListItem", "position": 1, "name": "Strona główna", "item": "https://example.pl/" },        { "@type": "ListItem", "position": 2, "name": "Usługi" }      ]    }  ]}Zasady wzorca: spójne `@id` dla tej samej encji w całej witrynie; relacje przez referencje (`founder`, `worksFor`); ostatni `ListItem` w breadcrumb bez `item` (to bieżąca strona); daty i godziny zawsze w formacie ISO 8601.

Dane strukturalne a widoczność w AI (GEO)

Tu trzeba oddzielić fakty od marketingu. Potwierdzone: Google nie ma osobnych wymagań technicznych dla AI Overviews poza tym, że strona jest zaindeksowana — schema nie jest gwarantowaną drogą do odpowiedzi AI. John Mueller konsekwentnie powtarza, że dane strukturalne nie wpływają wprost na ranking; ich rola to umożliwianie funkcji i pomoc w rozumieniu treści, encji i relacji.

Spekulatywne (i tak właśnie warto to traktować): twierdzenie, że modele jak ChatGPT czy Perplexity *bezpośrednio czytają* Twój JSON-LD, nie jest potwierdzone przez dostawców — większość silników AI konsumuje wyrenderowaną treść. Wniosek praktyczny: dane strukturalne to dobra praktyka fundamentowa dla klarowności encji i rozumienia maszynowego, ale nie obiecuj sobie po nich bezpośredniego skoku w cytowaniach AI. Szerzej o tym piszę w SEO vs GEO oraz GEO w praktyce.

Najczęstsze błędy (i jak audytujemy schemę w praktyce)

  • Oznaczanie treści niewidocznej na stronie (albo dostępnej dopiero po zalogowaniu) — to główna przyczyna nieuprawnienia, a w skrajnych przypadkach kary ręcznej. Reguła Google jest dosłowna: nie oznaczaj treści, której użytkownik nie widzi.
  • Niezgodność danych — cena lub ocena w schemie inna niż na stronie.
  • Złe lub zbyt ogólne typy (np. `Thing` zamiast właściwego typu).
  • Brak wymaganych pól — element staje się nieuprawniony (Error w Search Console).
  • Zduplikowana lub sprzeczna schema — rozwiązuje się ją spójnymi `@id` zamiast redefiniowania tej samej encji.
  • Oczekiwanie wycofanych rich results (FAQ, HowTo).

To nie jest teoria. Robiąc audyt danych strukturalnych tej witryny, naprawialiśmy dokładnie takie rzeczy: `PostalAddress` bez wymaganego `streetAddress`, `ImageObject` bez wymiarów i podpisu, `Offer` bez `price`/`priceCurrency`, `BlogPosting` bez `author`, czy `Course` bez `description`. Każdy z tych braków to potencjalny „Error" w Search Console i utrata uprawnienia do rich resultu.

Narzędzia do walidacji

  • Google Rich Results Test — sprawdza uprawnienie do rich results *wspieranych przez Google*. Testuje żywy URL albo wklejony kod, renderuje stronę i pokazuje wykryte typy oraz błędy.
  • Schema Markup Validator (validator.schema.org) — waliduje ogólną składnię i słownik Schema.org dla wszystkich typów; *nie* sprawdza uprawnienia do rich results Google.
  • Search Console → raporty Enhancements — status dla każdego typu (Error / Warning / Valid) oparty na ostatnim indeksowaniu, z przyciskiem „Validate Fix". To narzędzie do monitorowania na skalę.

---

Wdrażam i audytuję dane strukturalne Schema.org — od pełnego grafu encji po naprawę błędów blokujących rich results. Schema to też fundament inżynierii grafu wiedzy i Entity SEO. Całość rozkładam na czynniki pierwsze w kursie SEO & GEO. Napisz do mnie — zacznę od audytu Twojej obecnej schemy w Rich Results Test i pokażę, co blokuje rozszerzone wyniki.

Warto przeczytać dalej:

/// AUTHOR
Paweł Wiszniewski – AI & Web Engineer

Paweł Wiszniewski

SEO & GEO Specialist & AI Engineer

Specjalista SEO/GEO (10 lat) i AI engineer (3 lata). Buduję widoczność w wyszukiwarkach, systemy AI i automatyzacje, które redukują koszty i zwiększają efektywność operacyjną firm.

Signal received?

Przerwij
Ciszę

Zainicjuj protokół. Nawiąż połączenie. Zbudujmy coś głośnego.

> OCZEKIWANIE_NA_SYGNAŁ...