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 schema | Status rich result (2025–2026) | Uwagi |
|---|---|---|
| Article / BlogPosting | Aktywny | headline, image, author, datePublished/dateModified, publisher |
| Product + Offer + Review | Aktywny | gwiazdki, cena, dostępność; recenzje produktu OK |
| BreadcrumbList | Aktywny — tylko desktop | od stycznia 2025 Google nie pokazuje breadcrumbs na mobile |
| Event / Recipe / VideoObject | Aktywny | wymagają kompletu właściwości (np. Event: name, startDate, location) |
| JobPosting | Aktywny (Google Jobs) | samodzielny „Estimated Salary" wycofany VI 2025 |
| Organization / LocalBusiness / Person | Brak własnego rich result | zasilają logo, Knowledge Panel, zrozumienie encji |
| FAQPage | Wycofany | rich result mocno ograniczony w 2023, raport usunięty w 2026 — markup można zostawić, ale nie da gwiazdkowego wyniku |
| HowTo | Wycofany (2023) | rich result już się nie pokazuje |
| Course (karta „Course Info") | Wycofany VI 2025 | karuzela „Course List" nadal działa |
| WebSite + SearchAction (sitelinks search box) | Wycofany XI 2024 | markup 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).
{ "@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_SERVICES
Potrzebujesz wdrożenia tych koncepcji? Zobacz usługi powiązane z tym tematem.
/// RELATED_RECORDS
SEO Umarło. Witaj w Erze GEO — Generative Engine Optimization
Gdy użytkownicy pytają ChatGPT zamiast Google, zasady gry się zmieniają. Poznaj GEO — inżynierię widoczności w erze modeli językowych. Zaktualizowano czerwiec 2026: nowe dane o AI Overviews, udziałach rynkowych ChatGPT/Claude/Perplexity i strategiach cytowania.
SEO i GEO w 2026 — co jeszcze działa, co odpada i jak ułożyć strategię na dziś
Google AI Overviews w Polsce, ChatGPT Search, Perplexity — krajobraz wyszukiwania zmienił się fundamentalnie w ciągu 12 miesięcy. Strona na pozycji #1 może dziś tracić połowę kliknięć. Sprawdź, które taktyki SEO wciąż działają, które tracą na znaczeniu i co konkretnie dodać, żeby marka pojawiała się w odpowiedziach AI.
Jak mierzyć Share of Voice marki w modelach AI — od ręcznych testów po automatyczny monitoring
Marketing manager odkrywa, że konkurent pojawia się w ChatGPT zamiast nich — mimo pozycji TOP 3 w Google. Tradycyjne narzędzia SEO tego nie rejestrują. Pokazuję jak zbudować metodologię pomiaru AI Share of Voice: od ręcznego audytu po automatyczny monitoring z Perplexity API i AnswerLyzerem.
Signal received?
Przerwij
Ciszę
Zainicjuj protokół. Nawiąż połączenie. Zbudujmy coś głośnego.
