Dane strukturalne Schema.org - kompletny przewodnik (2026)
POWRÓT_DO_BLOGA
Aktualizacja: AI & SEO 13 min

Dane strukturalne Schema.org - kompletny przewodnik (2026)

Paweł Wiszniewski
Paweł Wiszniewski
Specjalista SEO & GEO · AI Engineer

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.

/// RICH RESULTS 2026 — CO DZIAŁA, CO WYCOFANE

✓ Aktywne
  • ▸Article / BlogPosting
  • ▸Product + Offer + Review
  • ▸BreadcrumbList
  • ▸Event / Recipe / VideoObject
  • ▸JobPosting
✕ Wycofane
  • ▸FAQPage (raport usunięty 2026)
  • ▸HowTo (2023)
  • ▸Course Info (VI 2025)
  • ▸Sitelinks Search Box (XI 2024)
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:

/// RELATED_RECORDS

AI & SEO

Bing, Microsoft Copilot i IndexNow - zapomniany ekosystem, który zasila odpowiedzi AI

1 lipca 2026 Fabrice Canel, wieloletni szef zespołu crawlowania i indeksowania w Bingu i główny architekt protokołu IndexNow, przeszedł na emeryturę z Microsoftu. To dobry moment, żeby zauważyć, jak duża część odpowiedzi AI faktycznie stoi na infrastrukturze, którą zbudował. Cały świat SEO dyskutuje o Google AI Overviews, a tymczasem Microsoft Copilot w całości i ChatGPT w istotnej części pobierają źródła z indeksu Bing - i od lutego 2026 Bing sam pokazuje, kiedy Cię cytuje. Pokazuję, jak działa ten ekosystem, jak go skonfigurować i ile realnie daje ruchu.

13 min
AI & SEO

Marka osobista eksperta w erze AI - jak zostać osobą, którą cytują modele

Zapytaj ChatGPT „kogo polecacie na specjalistę od X w Polsce” - model odpowie nazwiskami, nie tylko nazwami firm. Jeśli Twoje nazwisko nie istnieje jako jednoznaczna encja połączona z dowodami ekspertyzy, jesteś niewidzialny, nawet gdy firma ma świetne SEO. Google od lat mówi wprost, że autorstwo liczy się tam, gdzie czytelnik go oczekuje - a modele AI idą o krok dalej: sprawdzają, czy ten sam człowiek stoi za tekstem, profilem LinkedIn i wpisem w Wikidata. Jak zbudować siebie jako encję, którą da się zweryfikować i zacytować - na przykładzie własnego rekordu, który już raz pokazałem na tym blogu.

14 min
AI & SEO

YouTube i wideo w strategii widoczności AI - najsilniejszy sygnał, którego nie używasz

Ahrefs przebadał 75 000 marek i znalazł jeden sygnał silniej skorelowany z widocznością w ChatGPT, AI Mode i AI Overviews niż cokolwiek innego - mocniej niż domain rating, mocniej niż linki, mocniej niż liczba stron na blogu. To wzmianki na YouTube. Korelacja rzędu 0,737 wobec ~0,19 dla objętości treści na stronie. AI Overviews już dziś cytuje transkrypcje wideo wprost, a rozdziały działają jak znaczniki tematyczne dla modelu. Jak zbudować minimalny, powtarzalny warsztat wideo bez studia telewizyjnego - i jak z jednego nagrania zrobić wpis, film, shorty i cytowania naraz.

14 min
/// 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Ł...