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.

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.

W sklepie internetowym najważniejsze są Product, Offer i BreadcrumbList, spójne z feedem w Merchant Center. Ich wdrożenie w szablonach to część usługi pozycjonowanie sklepów internetowych.

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).

{  "@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:

• SEO obrazów - Google Lens i grafiki w odpowiedziach AI
• Core Web Vitals - jak poprawić LCP, INP i CLS
• GEO - czym jest i czym różni się od SEO