Dane uporządkowane schema.org: wybór, wdrożenie i kontrola

Dane uporządkowane schema.org opisują znaczenie informacji znajdujących się na stronie. Pozwalają wskazać, że określony fragment dotyczy produktu, organizacji, artykułu, firmy lokalnej albo elementu ścieżki nawigacyjnej.

Schema.org jest słownikiem, natomiast Google samodzielnie określa, które typy i właściwości wykorzystuje w swoich funkcjach wyszukiwania. Poprawny znacznik schema.org nie musi więc kwalifikować strony do wyniku rozszerzonego.

Zacznij od funkcji szablonu

Nie należy wybierać znacznika na podstawie frazy, którą strona ma zdobywać. Typ powinien wynikać z rzeczywistej zawartości i roli dokumentu.

  • Strona firmowa może opisywać organizację albo firmę lokalną.
  • Artykuł poradnikowy może zawierać dane typu Article lub BlogPosting.
  • Karta produktu może wykorzystywać Product i powiązaną ofertę.
  • Widoczna ścieżka nawigacyjna może być opisana jako BreadcrumbList.
  • Strona wydarzenia może użyć typu Event, jeżeli zawiera rzeczywiste wydarzenie i wymagane informacje.

Nie każda podstrona potrzebuje wszystkich znaczników. Kod organizacji może być osadzony w kontrolowany sposób w odpowiednim miejscu serwisu, zamiast tworzyć na każdym URL-u niezależne i potencjalnie różne wersje danych firmy.

Schema.org a funkcje obsługiwane przez Google

Schema.org zawiera znacznie więcej typów niż lista elementów obsługiwanych przez wyszukiwarkę. Przed wdrożeniem sprawdź galerię uporządkowanych danych Google oraz dokumentację konkretnej funkcji.

Dokumentacja rozróżnia właściwości wymagane i zalecane. Brak wymaganej wartości może uniemożliwić zakwalifikowanie strony do danego sposobu prezentacji. Dodawanie przypadkowych właściwości nie rekompensuje braku podstawowych danych.

Kod musi odpowiadać treści widocznej na stronie

Dane uporządkowane nie są miejscem na ukrywanie alternatywnej wersji oferty. Cena, dostępność, nazwa, autor czy data powinny odpowiadać informacjom dostępnym dla użytkownika.

Nie dodawaj:

  • oceny, której nie można znaleźć na stronie;
  • ceny promocyjnej, która już nie obowiązuje;
  • pytań i odpowiedzi istniejących wyłącznie w kodzie;
  • danych innej firmy albo innego produktu;
  • informacji wygenerowanych tylko w celu uzyskania atrakcyjniejszego wyniku.

Znacznik może być poprawny składniowo i jednocześnie niezgodny z treścią. Walidator nie zastępuje więc kontroli strony przez człowieka.

JSON-LD jako format wdrożenia

Google obsługuje JSON-LD, mikrodane i RDFa. W większości przypadków JSON-LD jest najłatwiejszy do utrzymania, ponieważ dane można generować w jednym fragmencie kodu na podstawie pól szablonu.

Przykład dla artykułu:

<script type="application/ld+json"> { "@context": "https://schema.org", "@type": "Article", "@id": "https://example.pl/poradnik/#article", "headline": "Tytuł widoczny na stronie", "datePublished": "2026-09-10", "dateModified": "2026-09-10", "mainEntityOfPage": { "@type": "WebPage", "@id": "https://example.pl/poradnik/" }, "author": { "@type": "Person", "@id": "https://example.pl/o-autorze/#person", "name": "Imię i nazwisko" } } </script>

Wartości muszą być pobierane z tego samego źródła co informacje widoczne na stronie. Ręczne wpisanie daty albo nazwy autora w szablonie szybko prowadzi do rozbieżności.

Używaj jednego źródła danych

Najbezpieczniejsza architektura generuje widoczną treść, dane uporządkowane i pliki produktowe z tych samych pól w CMS-ie lub systemie sklepowym. Zmiana ceny w jednym miejscu aktualizuje wtedy wszystkie kanały.

Szczególną uwagę trzeba zwrócić na:

  • nazwę oraz podstawowy adres podmiotu;
  • URL i identyfikator opisywanej strony;
  • cenę, walutę oraz dostępność produktu;
  • datę publikacji i rzeczywistej aktualizacji artykułu;
  • autora, wydawcę i logo;
  • średnią ocenę i liczbę recenzji.

Stabilne identyfikatory @id pomagają łączyć ten sam podmiot z różnymi obiektami. Przykładowo artykuł może wskazywać autora zdefiniowanego pod stałym identyfikatorem, zamiast tworzyć kilka niepowiązanych osób o tej samej nazwie.

Usuń sprzeczne znaczniki generowane przez wtyczki

W WordPressie lub sklepie dane mogą być dodawane jednocześnie przez motyw, wtyczkę SEO, moduł opinii i własny kod. Powstają wtedy dwa produkty z różnymi cenami, kilku autorów albo dwie ścieżki breadcrumbs.

Przed dodaniem kolejnego skryptu:

  1. sprawdź źródło i wyrenderowany kod strony,
  2. wyszukaj wszystkie wystąpienia application/ld+json, mikrodanych i RDFa,
  3. ustal, który komponent generuje każdy zestaw,
  4. wybierz jedno źródło dla danego typu informacji,
  5. wyłącz albo dostosuj pozostałe generatory.

Scalanie danych jest bezpieczne tylko wtedy, gdy obiekty rzeczywiście opisują ten sam podmiot i wykorzystują zgodne identyfikatory.

Jak wdrażać dane w całym serwisie?

Nie testuj wyłącznie jednej wygodnej podstrony. Przygotuj listę reprezentatywnych przypadków, np. artykuł z autorem, produkt dostępny, produkt przeceniony, produkt wycofany, kategoria i strona firmowa.

Proces może wyglądać następująco:

  1. wybierz funkcję obsługiwaną przez Google;
  2. zapisz wymagane i zalecane właściwości;
  3. wskaż źródło każdej wartości w systemie;
  4. wdróż kod na środowisku testowym;
  5. porównaj dane ze stroną widoczną dla użytkownika;
  6. sprawdź składnię i wymagania funkcji;
  7. opublikuj ograniczoną próbę;
  8. monitoruj błędy po ponownym przetworzeniu stron.

Jak testować wdrożenie?

Test wyników z elementami rozszerzonymi pokazuje, czy Google rozpoznaje obsługiwaną funkcję i wykrywa problemy. Walidator schema.org może dodatkowo pomóc sprawdzić ogólną strukturę słownika.

Po publikacji trzeba również:

  • sprawdzić wyrenderowany HTML;
  • zweryfikować adres w Google Search Console;
  • obserwować raporty dotyczące odpowiednich ulepszeń;
  • ponowić test po zmianie wtyczki, motywu lub szablonu;
  • porównać dane na kilku typach stron, a nie tylko jednym URL-u.

Pozytywny wynik testu nie gwarantuje wyświetlenia elementu rozszerzonego. Decyzję podejmują systemy wyszukiwarki na podstawie strony, zapytania i obowiązujących zasad.

Jak ocenić rezultat?

Najpierw mierz jakość techniczną: liczbę prawidłowych elementów, brak sprzecznych wartości i zgodność danych z treścią. Następnie obserwuj sposób prezentacji strony, wyświetlenia oraz CTR.

Najlepiej wdrożyć zmianę na wybranej grupie porównywalnych adresów i zapisać datę publikacji. Równoczesna zmiana tytułów, cen i układu strony utrudni określenie, co wpłynęło na wynik.

Szczegółowe zasady dotyczące nawigacji i typu BreadcrumbList znajdują się w osobnym poradniku o breadcrumbs. Nie ma potrzeby powtarzać tej samej konfiguracji w dwóch artykułach.

Jeżeli chcesz sprawdzić dane uporządkowane generowane przez motyw, wtyczkę lub szablon sklepu, napisz na czesc@seomariusz.pl albo zadzwoń: 665 015 610.

Copyright 2012-2026. SEO Mariusz