Słownik  /  Dane strukturalne
Słownik · SEO

Dane strukturalne - co to jest i jak wdrożyć schema.org?

Paweł Wołoszyn
Paweł Wołoszyn · o autorze →
Publikacja: · Zaktualizowano: · ~8 min czytania
Słownik · SEO
Dane strukturalne
Paweł Wołoszyn - Konsultant SEO i AI
Spis treści ▾
Co to są dane strukturalne?Historia i słownik schema.orgJSON-LD, mikrodane i RDFa: trzy formaty zapisuJakie typy danych strukturalnych obsługuje Google w 2026 roku?Jak dane strukturalne wpływają na SEO?Dane strukturalne w AI Overviews i wyszukiwaniu generatywnymJak wdrożyć dane strukturalne krok po krokuNajczęstsze błędy przy wdrażaniu danych strukturalnychŹródła Komentarz eksperta Najczęściej zadawane pytania

Dane strukturalne to ustandaryzowany kod, najczęściej zapisany w formacie JSON-LD według słownika schema.org, który wprost mówi wyszukiwarce, czym jest dana treść na stronie: produktem, przepisem, artykułem czy wydarzeniem. Dzięki temu Google i inne systemy wyszukujące łatwiej rozpoznają kontekst strony i mogą pokazać ją jako rozszerzony wynik w wyszukiwarce.

Co to są dane strukturalne?

Google opisuje dane strukturalne jako ustandaryzowany format przekazywania informacji o stronie i klasyfikowania jej zawartości, na przykład na stronie z przepisem: jakie są składniki, ile trwa gotowanie, ile ma kalorii. W praktyce to fragment kodu dodany do HTML-a, który nie zmienia tego, co widzi użytkownik, tylko dokłada warstwę znaczeń czytelną dla maszyn. Zamiast zgadywać na podstawie samego tekstu, robot dostaje jednoznaczną etykietę: to jest cena, to ocena, to data wydarzenia.

Dane strukturalne opisują encje: konkretne, możliwe do zidentyfikowania byty, jak produkt, firma czy osoba, wraz z ich atrybutami i relacjami do innych encji. Bez tej warstwy wyszukiwarka też może rozpoznać, że strona dotyczy przepisu na pizzę, ale musi to wywnioskować z samego tekstu, co jest wolniejsze i bardziej podatne na pomyłki niż odczytanie gotowej etykiety.

Historia i słownik schema.org

Schema.org to wspólny słownik znaczników, który nadaje danym strukturalnym ujednolicone nazwy typów, jak Product, Article czy Event, i właściwości, jak price, author czy datePublished. Powstał 2 czerwca 2011 roku z inicjatywy Bing, Google i Yahoo, a w listopadzie tego samego roku dołączył do inicjatywy rosyjski Yandex. W 2012 roku do słownika włączono ontologię GoodRelations, co rozszerzyło opis produktów i ofert handlowych. Od kwietnia 2015 roku rozwojem słownika zajmuje się W3C Schema.org Community Group, a kluczowe wydania zatwierdza niewielka grupa nadzorcza, Steering Group.

Google zaczęło wspierać format JSON-LD w 2015 roku, a od września 2017 roku rekomenduje go jako domyślny sposób zapisu danych strukturalnych. Sam słownik systematycznie rośnie: według danych z października 2026 roku ma już 826 typów, a najnowsza wersja, V30.1, ukazała się 16 września 2026 roku. Według danych z 2024 roku znaczniki schema.org stosowało już ponad 45 milionów domen internetowych. Wszystkie typy dziedziczą po jednym, najbardziej ogólnym typie, Thing, który definiuje podstawowe właściwości, takie jak nazwa, opis, adres URL i obraz, a reszta słownika to coraz bardziej szczegółowe podtypy tej samej idei.

JSON-LD, mikrodane i RDFa: trzy formaty zapisu

Ten sam słownik schema.org da się zapisać w trzech różnych formatach technicznych: JSON-LD, mikrodanych i RDFa. Wybór formatu nie zmienia znaczenia znaczników, tylko sposób ich osadzenia w kodzie strony.

JSON-LD to notacja JavaScript, którą wkleja się jako osobny blok <script type="application/ld+json">, oddzielony od reszty HTML-a i widocznej treści strony. To format, który Google zaleca w pierwszej kolejności, bo najłatwiej go wdrożyć i utrzymać w skali całego serwisu, zwłaszcza gdy dane pochodzą z bazy danych albo CMS-a. Standard JSON-LD 1.0 stał się rekomendacją W3C 16 stycznia 2014 roku, a wersja 1.1 (między innymi z obsługą grafów nazwanych) 16 lipca 2020 roku.

Mikrodane to specyfikacja wpisana w standard HTML, obecnie część WHATWG HTML Living Standard, która osadza znaczniki wprost w atrybutach istniejących tagów HTML, jak itemscope, itemtype i itemprop. Wymaga to dodania atrybutów do każdego elementu, który ma być opisany, więc markup miesza się z treścią i trudniej go utrzymać przy większych zmianach szablonu.

RDFa to z kolei rozszerzenie HTML5, także oparte na atrybutach, rozwijane w ramach specyfikacji W3C, które łączy widoczną treść z danymi z szerszego modelu RDF (Resource Description Framework).

Jak wygląda to samo w praktyce, na przykładzie strony o filmie? W mikrodanych znaczniki wchodzą wprost w atrybuty tagów HTML:

<div itemscope itemtype="https://schema.org/Movie">
  <h1 itemprop="name">Avatar</h1>
  <div itemprop="director" itemscope itemtype="https://schema.org/Person">
    Reżyser: <span itemprop="name">James Cameron</span>
  </div>
  <span itemprop="genre">Science fiction</span>
</div>

Ten sam zestaw informacji w JSON-LD trafia do osobnego bloku, niezależnego od treści widocznej na stronie:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Movie",
  "name": "Avatar",
  "director": {
    "@type": "Person",
    "name": "James Cameron"
  },
  "genre": "Science fiction"
}
</script>
Kryterium JSON-LD Mikrodane / RDFa
Gdzie żyje w kodzie Osobny blok <script>, oddzielony od treści Atrybuty wplecione wprost w tagi HTML
Rekomendacja Google Tak, format zalecany od 2017 roku Wspierane, ale nie rekomendowane w pierwszej kolejności
Łatwość utrzymania przy skali Wysoka, łatwo generować automatycznie z bazy danych CMS-a Niższa, wymaga zmian w każdym szablonie HTML
Ryzyko literówek i błędów Niższe, jeden generowany blok danych Wyższe, znaczniki rozproszone po wielu tagach

Jakie typy danych strukturalnych obsługuje Google w 2026 roku?

Nie każdy typ ze słownika schema.org przekłada się na rozszerzony wynik w Google. Wyszukiwarka wybiera tylko wąski podzbiór, opisany w galerii wyników rozszerzonych (rich results gallery), i regularnie go aktualizuje: dodaje nowe typy albo wycofuje te, które się nie sprawdziły. Według stanu na wrzesień 2026 roku galeria obejmuje między innymi: Article, Breadcrumb, Carousel, Course list, Dataset, Discussion forum, Education Q&A, Employer aggregate rating, Event, Image metadata, Job posting, Local business, Math solver, Movie, Organization, Product, Profile page, Q&A, Recipe, Review snippet, Software app, Speakable, Subscription and paywalled content, Vacation rental oraz Video.

Dwa typy, które jeszcze niedawno były standardowym przykładem w podręcznikach SEO, zniknęły z tej listy. FAQ rich result od sierpnia 2023 roku był ograniczony wyłącznie do dobrze znanych, autorytatywnych witryn rządowych i medycznych, a od 7 maja 2026 roku Google całkowicie usunęło go z wyników wyszukiwania, niezależnie od typu strony. How-to rich result przestał wyświetlać się w wynikach w 2023 roku, zarówno na komputerach, jak i telefonach, a 14 września 2023 roku Google usunęło też jego dokumentację z Search Central, potwierdzając, że funkcja zniknęła na dobre. Dodanie znaczników FAQPage czy HowTo do kodu strony samo w sobie nie zaszkodzi, ale nie warto już liczyć na dodatkowy fragment w wynikach z ich powodu.

Pełną i zawsze aktualną listę warto sprawdzać bezpośrednio w galerii Google, bo lista rich results zmienia się częściej niż sam słownik schema.org. Dla porównania: słownik schema.org ma 826 typów, a Google z tego wybiera zaledwie ułamek, i to on, nie samo dodanie znacznika, decyduje, czy strona w ogóle może pokazać się jako rozszerzony wynik.

Jak dane strukturalne wpływają na SEO?

Google wprost mówi, że dane strukturalne same w sobie nie są czynnikiem rankingowym: nie podniosą pozycji tylko dlatego, że są obecne w kodzie. Ich realny wpływ na SEO jest pośredni, ale odczuwalny.

Po pierwsze, kwalifikują stronę do rozszerzonych wyników, które wyświetlają się jako rozbudowany snippet w wynikach wyszukiwania: gwiazdki, ceny, zdjęcia czy daty wydarzeń przyciągają wzrok i podnoszą współczynnik klikalności (CTR), nawet jeśli sama pozycja się nie zmienia.

Po drugie, ułatwiają wyszukiwarce jednoznaczne rozpoznanie encji, o której mówi strona, i połączenie jej z istniejącym wpisem w grafie wiedzy Google: spójna nazwa firmy, jeden adres, identyfikator sameAs prowadzący do Wikidanych czy Wikipedii, to sygnały ułatwiające takie dopasowanie. Pośrednio wspiera to też E-E-A-T, bo znacznik author czy Organization jasno wskazuje, kto stoi za treścią, zamiast zostawiać to domysłom algorytmu.

Po trzecie, w SEO semantycznym dane strukturalne to jeden z języków, w jakich strona opisuje własną strukturę tematyczną, obok wewnętrznego linkowania i architektury treści. Nie zastępują dobrze napisanej treści, tylko dokładają do niej czytelną dla maszyn etykietę.

Dane strukturalne w AI Overviews i wyszukiwaniu generatywnym

AI Overviews i AI Mode w Google Search nie mają osobnego, specjalnego trybu kwalifikacji: według oficjalnej dokumentacji Google Search Central obowiązują te same fundamenty co w klasycznym wyszukiwaniu, czyli techniczna dostępność strony dla robota, zgodność z zasadami wyszukiwarki i treść tworzona faktycznie dla ludzi. Samo dodanie danych strukturalnych nie gwarantuje więc cytowania w odpowiedzi generowanej przez AI.

To, co dane strukturalne realnie ułatwiają, to jednoznaczność. Gdy system rozbija pytanie użytkownika na wiele powiązanych podzapytań, technika znana jako query fan-out, musi szybko rozpoznać, które źródła dotyczą dokładnie tej encji, o którą pyta użytkownik, a nie encji o podobnej nazwie. Jasno oznaczone typy i właściwości skracają tę drogę. Ten sam mechanizm stoi za AEO, czyli optymalizacją pod odpowiedzi generowane przez systemy AI, gdzie liczy się przede wszystkim to, czy fakt na stronie da się łatwo wyodrębnić i przypisać do właściwego źródła, a nie tylko czy strona zajmuje wysoką pozycję w klasycznym rankingu. Dobrze opisana encja zwiększa też szansę na cytowanie w odpowiedziach AI, choć podobnie jak w klasycznym SEO, żaden znacznik tego nie gwarantuje.

Jak wdrożyć dane strukturalne krok po kroku

Wdrożenie nie musi być skomplikowane, jeśli trzymasz się kolejności: najpierw ustal właściwy typ, potem zapisz go poprawnym formatem i przetestuj, zanim trafi na produkcję.

  1. Wybierz właściwy typ. Ustal, jaki typ ze słownika schema.org najlepiej opisuje główną treść strony (Article, Product, Event, LocalBusiness), zamiast dodawać kilka naraz na wszelki wypadek.
  2. Zapisz go w JSON-LD. W formacie zalecanym przez Google, w osobnym bloku <script>, najlepiej generowanym automatycznie z tych samych danych, które CMS już wyświetla na stronie.
  3. Uzupełnij właściwości zgodnie z widoczną treścią. Markup musi odzwierciedlać to, co realnie widać na stronie: oznaczanie danych, których w treści nie ma, łamie ogólne wytyczne Google dotyczące danych strukturalnych.
  4. Przetestuj znacznik. Narzędziem Rich Results Test albo Schema Markup Validator, zanim treść trafi na produkcję.
  5. Monitoruj w Search Console. Raport „Ulepszenia” pokazuje błędy i ostrzeżenia wykryte już po indeksacji, więc warto do niego wracać po każdej większej zmianie szablonu.

Prosty przykład znacznika Article w JSON-LD:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Dane strukturalne - co to jest i jak wdrożyć schema.org?",
  "image": "https://przyklad.pl/dane-strukturalne.jpg",
  "datePublished": "2026-09-10",
  "author": {
    "@type": "Person",
    "name": "Paweł Wołoszyn"
  },
  "publisher": {
    "@type": "Organization",
    "name": "pawelwoloszyn.pl"
  }
}
</script>

Najczęstsze błędy przy wdrażaniu danych strukturalnych

  • Znacznik niezgodny z treścią widoczną na stronie. To złamanie ogólnych wytycznych Google i ryzyko ręcznej akcji, nie tylko brak rich resultu.
  • Wdrażanie typów, które Google już wycofał z wyników (FAQPage, HowTo), w nadziei na dodatkowy fragment, który się nie pojawi.
  • Brak testowania po zmianie szablonu CMS-u. Jeden błąd w motywie potrafi po cichu wyłączyć markup na całej witrynie, bez żadnego widocznego objawu.
  • Niespójne dane w różnych miejscach, na przykład inna nazwa firmy w stopce niż w znaczniku Organization, co utrudnia jednoznaczne rozpoznanie encji.
  • Traktowanie samego dodania znacznika jako gwarancji wyższej pozycji, zamiast jednego z wielu sygnałów pomocniczych, obok treści i linkowania.

Źródła

  • Understand how structured data works – Google Search Central – https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data
  • Search result types (rich results) gallery – Google Search Central – https://developers.google.com/search/docs/appearance/structured-data/search-gallery
  • FAQPage structured data – Google Search Central – https://developers.google.com/search/docs/appearance/structured-data/faqpage
  • About schema.org – https://schema.org/docs/about.html
  • Getting started with schema.org using Microdata – https://schema.org/docs/gs.html
  • Schema.org – Wikipedia – https://en.wikipedia.org/wiki/Schema.org
  • JSON-LD 1.1 – W3C Recommendation – https://www.w3.org/TR/json-ld11/
  • Microdata – HTML Living Standard, WHATWG – https://html.spec.whatwg.org/multipage/microdata.html

Komentarz eksperta

Przy każdym audycie technicznym sprawdzam trzy rzeczy: czy markup w ogóle jest, czy pasuje do typu strony i czy dane zgadzają się z tym, co widać na ekranie. Najczęstszy błąd, jaki widzę, to skopiowany szablon JSON-LD z innej strony z zostawionymi starymi wartościami, np. ceną czy autorem, których na stronie już dawno nie ma.

Dane strukturalne nie są same w sobie czynnikiem rankingowym ani przełącznikiem widoczności w AI Overviews. To warstwa opisu, która kwalifikuje stronę do rozszerzonego wyniku, jeśli treść na to zasługuje. Pierwsze pytanie, jakie zadaję, brzmi zawsze: po co konkretnie ten typ ma tu być. Zaczynam od jednego, najważniejszego dla danej branży typu, zamiast obwieszać stronę wszystkim naraz.

Paweł Wołoszyn, Konsultant SEO i AI Paweł Wołoszyn, Konsultant SEO i AI

Najczęściej zadawane pytania (FAQ)

Czy dane strukturalne wpływają na pozycję strony w Google?

Nie bezpośrednio. Dane strukturalne kwalifikują stronę do rozszerzonych wyników, co podnosi CTR, i ułatwiają wyszukiwarce jednoznaczne rozpoznanie encji, o której mówi strona.

Jaki format danych strukturalnych warto wybrać: JSON-LD czy mikrodane?

W większości przypadków JSON-LD, bo to format, który Google rekomenduje od 2017 roku jako najłatwiejszy do wdrożenia i utrzymania w skali. Mikrodane mają sens głównie tam, gdzie markup trzeba wpleść ręcznie w konkretny, niewielki fragment HTML-a, bez możliwości generowania osobnego bloku skryptu.

Czy FAQ i HowTo rich results nadal działają w Google w 2026 roku?

Nie. Google ograniczyło FAQ rich results do wybranych stron rządowych i medycznych w sierpniu 2023 roku, a od 7 maja 2026 roku usunęło je z wyników całkowicie, niezależnie od typu witryny. HowTo rich results zniknęły z wyników jeszcze wcześniej i również nie ma sensu liczyć na ich powrót.

Jak sprawdzić, czy dane strukturalne na stronie są poprawne?

Najszybciej narzędziem Rich Results Test od Google, które pokazuje, czy dany adres kwalifikuje się do rozszerzonego wyniku i jakie błędy lub ostrzeżenia zawiera markup. Do bieżącego monitorowania całej witryny służy raport „Ulepszenia” w Google Search Console, który wychwytuje problemy już po indeksacji.

Czy trzeba mieć dane strukturalne, żeby strona pojawiła się w AI Overview?

Nie, to nie jest warunek konieczny. Dane strukturalne mogą jedynie ułatwić jednoznaczne rozpoznanie encji, skracając drogę, gdy system rozpoznaje źródła dla konkretnego podzapytania.

Czym różnią się dane strukturalne od mikrodanych?

Dane strukturalne to szersze pojęcie: ustandaryzowana informacja o treści strony, zapisana według słownika takiego jak schema.org. Mikrodane to tylko jeden z trzech formatów technicznych, w jakich można te dane zapisać w kodzie HTML, obok JSON-LD i RDFa.

Rozwijaj swoją markę!

Dzięki współpracy ze mną!

Zostaw kontakt - odezwę się z bezpłatną analizą widoczności Twojej domeny i propozycją kolejnych kroków.

Umów bezpłatną konsultację SEO