
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.
/// RICH RESULTS 2026 — CO DZIAŁA, CO WYCOFANE
- ▸Article / BlogPosting
- ▸Product + Offer + Review
- ▸BreadcrumbList
- ▸Event / Recipe / VideoObject
- ▸JobPosting
- ▸FAQPage (raport usunięty 2026)
- ▸HowTo (2023)
- ▸Course Info (VI 2025)
- ▸Sitelinks Search Box (XI 2024)
| 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
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.
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.
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.
Signal received?
Przerwij
Ciszę
Zainicjuj protokół. Nawiąż połączenie. Zbudujmy coś głośnego.
