Wdrażanie Schema.org

Co realnie dają dane strukturalne w 2026 roku

Dane strukturalne dają uprawnienie do wyników rozszerzonych i jednoznaczny opis encji dla maszyn. Nie dają gwarancji wyświetlenia ani wyższej pozycji. O tym, czy gwiazdki lub cena faktycznie pojawią się w wynikach, decyduje Google, nawet gdy test przechodzi bez błędów.

Google na stronie wprowadzającej do danych strukturalnych publikuje kilka studiów przypadku: Rotten Tomatoes po oznaczeniu 100 000 stron zmierzył o 25% wyższy CTR stron z wynikami rozszerzonymi, a Nestlé podał o 82% wyższy CTR stron wyświetlanych jako wynik rozszerzony w porównaniu ze zwykłymi wynikami. To dane z materiałów Google, zebrane na dużych serwisach i dla typów, które dają widoczny dodatek w wynikach. Traktuję je jako dowód, że efekt istnieje, a nie jako prognozę dla konkretnej strony.

Druga korzyść jest mniej widowiskowa, ale trwalsza: spójny opis firmy, autora, produktów i usług, który wyszukiwarka może połączyć z resztą swojej wiedzy. Ta część nie znika, gdy Google wycofuje kolejny typ wyniku rozszerzonego, co w ostatnich latach zdarzało się regularnie.

Czego się nie spodziewać

• Wzrostu pozycji tylko dzięki markupowi. Według ogólnych wytycznych Google ręczne działanie za dane strukturalne odbiera uprawnienie do wyników rozszerzonych, ale nie wpływa na ranking strony. Działa to w obie strony: sam markup rankingu też nie podnosi.
• Rozwijanych pytań FAQ pod wynikiem na zwykłej stronie firmowej. Od 2023 roku Google pokazuje je tylko autorytatywnym serwisom rządowym i medycznym.
• Gwiazdek z opinii o własnej firmie na stronie głównej lub stronie usługi. Gwiazdki działają dla produktów i kilku innych typów, nie dla recenzji „o sobie”.

Mapa szablonów: który typ Schema.org na której stronie

Dane strukturalne planuję per szablon, nie per adres. Sklep z 20 000 produktów ma zwykle kilka do kilkunastu szablonów i to one decydują o jakości wdrożenia. Pierwszym dokumentem w projekcie jest tabela, w której każdy szablon ma przypisane typy, właściwości i źródło danych.

Ta tabela od razu pokazuje luki. Najczęściej brakuje kolumny „skąd biorę wartości”: ktoś wpisał w szablonie stałą cenę albo datę i od tamtej pory dane strukturalne mówią co innego niż strona.

Graf JSON-LD i stabilne identyfikatory @id

Wszystkie bloki JSON-LD na stronie traktuję jako jeden graf, w którym każda encja ma stały identyfikator @id i jest zdefiniowana raz. Strony odwołują się do firmy, autora i serwisu przez @id, zamiast za każdym razem opisywać je od nowa, często z różnymi danymi.

Konwencje, których się trzymam

• @id to adres kanoniczny z fragmentem, np. https://twojadomena.pl/#organization dla firmy i adres artykułu z #article dla wpisu. Identyfikator nie musi prowadzić do istniejącej kotwicy, ale nie może się zmieniać.
• Encje globalne (WebSite, Organization, Person) mają jedną definicję w całym serwisie. Ten serwis działa tak samo: jest jedna encja autora https://wiszniewsky.pl/#person, a artykuły, usługi i kursy tylko się do niej odwołują.
• Relacje zamiast powtórzeń: author, publisher, provider, brand, worksFor i founder wskazują @id, a nie wklejoną kopię obiektu.
• Wersje językowe: encje globalne zostawiam z tym samym @id we wszystkich językach, bo to wciąż ta sama firma i ta sama osoba. Strony i artykuły mają własne @id oraz inLanguage.
• sameAs tylko do profili, które naprawdę należą do encji: LinkedIn, Wikidata, rejestr firm, profile w serwisach branżowych. Bez katalogów firm, w których wpis założył ktoś inny.
• Jeden blok @graph na stronę, generowany w jednym miejscu kodu. Dwa źródła markupu, np. motyw i wtyczka, prawie zawsze kończą się dwiema sprzecznymi organizacjami.

Graf jest też fundamentem pracy nad encją marki. Jeśli celem jest panel wiedzy albo poprawne informacje o firmie w odpowiedziach AI, zaczynam od niego i rozbudowuję go w usłudze inżynierii grafu wiedzy. Więcej o samych encjach piszę w artykule Entity SEO i graf wiedzy.

Skąd biorą się wartości w JSON-LD: jedno źródło z treścią strony

Wartości w danych strukturalnych muszą pochodzić z tego samego źródła co treść widoczna na stronie. Wytyczne Google zabraniają oznaczania treści, której użytkownik nie widzi, a najczęstszą przyczyną niezgodności nie jest zła wola, tylko dwie kopie tych samych danych, które z czasem się rozjeżdżają.

Google pisze to wprost nawet przy wdrożeniach przez Google Tag Manager: wartości należy pobierać ze strony zmiennymi, a nie przepisywać ich do kontenera, bo duplikat zwiększa ryzyko rozbieżności. W kodzie stosuję tę samą zasadę: komponent, który wyświetla cenę, i funkcja, która buduje Offer, korzystają z jednego obiektu produktu.

Pola, które najczęściej się rozjeżdżają

• Cena i dostępność po promocji, zmianie stanu magazynowego albo wyprzedaniu wariantu.
• dateModified ustawiane automatycznie przy każdym zapisie, także przy poprawce literówki. Datę modyfikacji zmieniam tylko przy istotnej zmianie treści.
• Oceny i liczba opinii pobierane z widżetu zewnętrznego, które na stronie pokazują inną liczbę niż w JSON-LD.
• Autor, gdy tekst przejął inny redaktor, a markup nadal wskazuje poprzednią osobę.
• Godziny otwarcia oddziału zmienione w wizytówce Google, ale nie na stronie.

W sklepach dochodzi trzecie miejsce, które musi się zgadzać: feed produktowy w Merchant Center. Dane na karcie produktu, w JSON-LD i w feedzie powinny pochodzić z jednej bazy. Ta sama zasada obowiązuje przy sprzedaży przez agentów AI, o której piszę w artykule o zakupach przez agentów AI i feedach produktowych.

Wdrożenie w Next.js, WordPressie i Shopify

Najpewniejsze jest JSON-LD w HTML-u zwracanym przez serwer. Google potrafi odczytać dane strukturalne dodane JavaScriptem, ale w dokumentacji ostrzega, że dynamicznie generowany markup produktów może sprawić, że crawle zakupowe będą rzadsze i mniej niezawodne. Dlatego przy produktach z często zmienianą ceną unikam wstrzykiwania danych skryptem.

Next.js i własny kod

Buduję funkcje, które z danych strony generują węzły grafu, i renderuję je po stronie serwera w jednym bloku script type="application/ld+json". Encje globalne pochodzą z jednego modułu konfiguracyjnego. Na stronach, które utrzymuję, test w CI przy każdej zmianie sprawdza, czy każdy blok JSON-LD się parsuje. Tak działa ten serwis. Przy przenoszeniu strony ze starego CMS-u buduję graf w ten sposób od początku, w ramach migracji do Next.js.

WordPress

Yoast SEO i Rank Math generują graf z @id, więc zwykle nie ma sensu budować go od zera. Problem pojawia się, gdy motyw, wtyczka sklepu, wtyczka opinii i wtyczka SEO dodają własne bloki. Wtedy wybieram jedno źródło grafu, wyłączam pozostałe, a brakujące typy dopisuję przez filtry wtyczki, żeby trafiły do tego samego grafu, a nie do osobnego bloku.

Shopify

Motywy Shopify często mają wbudowany markup produktu, a aplikacje do opinii lub SEO dodają drugi. Zaczynam od wyrenderowanego HTML-u karty produktu i liczę, ile razy występuje Product. Warianty (rozmiar, kolor) opisuję przez ProductGroup, które Google obsługuje od lutego 2024 roku, z właściwościami hasVariant, variesBy i productGroupID.

Google Tag Manager

Traktuję go jako rozwiązanie przejściowe, gdy nie ma dostępu do kodu. Działa, jeśli wartości są pobierane ze strony, ale dodaje zależność od renderowania i łatwo go zepsuć zmianą układu strony, z której zmienne czytają dane.

Dane strukturalne w sklepie: merchant listings, warianty, zwroty i dostawa

W sklepie markup produktu obsługuje dwa różne wyniki: fragmenty produktów i informacje o produktach sprzedawcy (merchant listings). Google ma dla nich osobne raporty w Search Console, bo wymagania się różnią. Merchant listings dotyczą stron, na których klient może kupić produkt; fragmenty produktów obejmują też recenzje redakcyjne i porównywarki.

Od listopada 2025 roku ustawienia „Dostawa i zwroty” w Search Console są dostępne dla każdej witryny, którą Google rozpoznaje jako sklep, a nie tylko dla kont z Merchant Center. Dla mniejszych sklepów to często najszybsza droga. Markup polityk dodaję wtedy, gdy zasady są złożone albo gdy chcę mieć je w kodzie razem z resztą danych. W obu przypadkach pilnuję, żeby ustawienia w Search Console i markup nie mówiły dwóch różnych rzeczy.

Szerzej o widoczności sklepów w Google i w zakupach przez AI piszę w artykule SEO i GEO dla e-commerce.

Walidacja danych strukturalnych: cztery poziomy testów

Poprawny wynik w Rich Results Test to dopiero jeden z czterech testów, które robię. Narzędzia Google sprawdzają składnię i wymagane pola, ale nie sprawdzą, czy cena w JSON-LD zgadza się z ceną na stronie ani czy markup nie zniknie po kolejnym wdrożeniu.

1. Składnia. Każdy blok musi się parsować jako JSON. Ten test uruchamiam automatycznie przy każdej zmianie kodu, bo jeden przecinek potrafi wyłączyć cały graf na wszystkich stronach szablonu.
2. Słownik Schema.org. Schema Markup Validator sprawdza typy i właściwości niezależnie od tego, czy Google je wykorzystuje.
3. Uprawnienie w Google. Rich Results Test na żywym adresie (nie na wklejonym kodzie, bo wtedy test ma ograniczenia JavaScriptu) i Sprawdzenie adresu URL w Search Console, które pokazuje wyrenderowany HTML.
4. Zgodność z treścią. Na próbce stron z każdego szablonu porównuję wartości w JSON-LD z tym, co widać na stronie: cenę, dostępność, autora, daty, liczbę opinii. Przy dużych sklepach robię to skryptem, który pobiera stronę i porównuje oba źródła.

Po wdrożeniu monitoruję raporty ulepszeń w Search Console. Rosnąca liczba „nieprawidłowych elementów” po aktualizacji motywu albo wtyczki to najczęstszy sygnał, że ktoś zmienił szablon bez sprawdzenia markupu.

Jak mierzę efekty wdrożenia Schema.org

Efekt mierzę w raporcie Skuteczność w Search Console z filtrem „Wygląd w wynikach wyszukiwania”, który pokazuje kliknięcia i CTR wyników z danym typem wyniku rozszerzonego. Porównuję te same zapytania i strony przy podobnej średniej pozycji przed wdrożeniem i po nim, bo zmiana CTR przy zmianie pozycji niczego nie dowodzi.

Pierwsze dane oceniam po pełnym cyklu ponownego indeksowania kluczowych szablonów. Przy dużych sklepach Google potrzebuje czasu, żeby ponownie odwiedzić tysiące kart produktów, więc prawidłowe elementy w raportach przyrastają stopniowo.

Dane strukturalne a widoczność w AI: realistyczne oczekiwania

Dane strukturalne nie są warunkiem pojawienia się w AI Overviews, AI Mode ani w ChatGPT. Google w dokumentacji o funkcjach AI zaznacza, że nie ma dodatkowych wymagań technicznych poza zwykłymi zasadami indeksowania, a dostawcy innych asystentów nie potwierdzają, że ich systemy czytają JSON-LD.

Mimo to wdrażam schema z myślą o AI z dwóch powodów. Po pierwsze, spójny graf ułatwia Google połączenie strony z encją firmy, a z indeksu Google korzystają funkcje AI w wyszukiwarce. Po drugie, praca nad markupem wymusza porządek w treści: jasno podany autor, data, cena i zakres usługi pomagają każdemu systemowi, który czyta stronę, także temu, który ignoruje JSON-LD. Jak tę warstwę rozwijam w GEO, opisuję przy usłudze pozycjonowania w AI Overviews i AI Mode.

Osobno sprawdzam, co asystenci AI mówią o firmie. Jeśli podają zły adres, nieaktualną ofertę albo mylą markę z inną, poprawny markup jest jednym z elementów naprawy, ale nie jedynym. Szerzej piszę o tym w artykule Reputacja marki w AI.

Typy wycofane w 2025 i 2026 roku: co zrobić z istniejącym markupem

Markup typów, których Google już nie wyświetla, zwykle zostawiam, jeśli jest poprawny i zgodny z treścią, ale nie wdrażam go od nowa tylko dla wyników rozszerzonych. Google w czerwcu 2025 roku zapowiedział wycofanie siedmiu typów z wyników wyszukiwania: Book Actions, Course Info, Claim Review, Estimated Salary, Learning Video, Special Announcement i Vehicle Listing. Zaznaczył, że zmiana nie wpływa na ranking, a użycie tych typów poza wyszukiwarką Google się nie zmienia.

W listopadzie 2025 roku Google dodał, że od stycznia 2026 usuwa obsługę tych typów z Search Console i jej API. Raporty dla nich znikają, więc ewentualnych błędów nie zobaczysz już w panelu. To kolejny powód, żeby walidacja składni działała w Twoim własnym procesie, a nie tylko w narzędziach Google.

Utrzymanie po wdrożeniu: dokumentacja dla zespołu

Dane strukturalne psują się najczęściej przy zmianach, które nie dotyczą SEO: nowy szablon, aktualizacja wtyczki, migracja sklepu. Dlatego częścią wdrożenia jest krótka dokumentacja, z której korzysta zespół, a nie tylko raport dla działu marketingu.

• Mapa szablonów z typami, właściwościami i źródłem danych (tabela z początku tego poradnika, wypełniona dla Twojego serwisu).
• Lista identyfikatorów @id encji globalnych i zasada, że nie wolno ich zmieniać.
• Instrukcja dla nowego szablonu: który moduł generuje graf, jak dodać nowy typ, jak przetestować.
• Lista zdarzeń, po których trzeba ponownie zwalidować markup: zmiana motywu lub wtyczki, migracja, nowa wersja językowa, zmiana cennika lub regulaminu zwrotów.
• Właściciel tematu po stronie firmy, który dostaje alerty z Search Console.

Przy migracji serwisu sprawdzam dane strukturalne w tej samej checkliście co przekierowania i canonicale, bo nowy motyw często startuje bez nich. Opisuję to przy usłudze migracji SEO. Jeśli nie wiesz, w jakim stanie jest technika serwisu, punktem wyjścia jest audyt SEO techniczny, a cały kontekst usług SEO znajdziesz na stronie pozycjonowania i SEO technicznego.