Co to są dane strukturalne? Definicja, przykłady i zastosowanie

Dane strukturalne opisują znaczenie informacji na stronie za pomocą typów i właściwości zrozumiałych dla systemów. Zwykły tekst "KC Mobile, Czeladź" informuje człowieka o nazwie i miejscowości, a oznaczenie może wskazać, że nazwa należy do firmy, a Czeladź jest jej lokalizacją.

Dane strukturalne nie zastępują widocznej treści ani nie zmieniają jej przeznaczenia dla czytelnika. Stanowią dodatkowy opis, który pomaga systemom rozpoznawać encje, czyli konkretne obiekty, takie jak firma, produkt, artykuł lub osoba.

Na stronie produktu opis może zawierać nazwę, cenę i dostępność. Oznaczenie tych pól ma sens tylko wtedy, gdy wartości odpowiadają aktualnej ofercie widocznej na stronie. Jeśli kod podaje inną cenę niż strona produktu, opis nie przedstawia rzetelnie oferty.

Dane strukturalne można porównać do etykiet przypisanych do informacji: etykieta "cena" wskazuje, jak interpretować liczbę, a etykieta "nazwa" odróżnia nazwę produktu od innych słów na stronie. System nadal ocenia stronę w szerszym kontekście, więc same oznaczenia nie zastępują jakościowego opisu ani dostępności strony dla robotów wyszukiwarki.

Schema.org dostarcza słownik typów i właściwości, a JSON-LD pozwala zapisać wybrane terminy w kodzie strony. Typ określa opisywany obiekt, właściwość opisuje jego cechę, a format wskazuje sposób zapisania opisu.

Mapę pojęć można streścić w czterech elementach:

• Schema.org to słownik terminów, takich jak Product, Article i LocalBusiness.
• Typ to kategoria obiektu, na przykład Product dla produktu.
• Właściwość to pole opisujące obiekt, na przykład name dla nazwy lub offers dla oferty.
• JSON-LD to format zapisu danych w skrypcie umieszczonym w kodzie strony.

Przykład produktu może mieć typ Product, właściwość name z nazwą produktu oraz offers opisujące ofertę. Wewnątrz oferty można opisać między innymi cenę i walutę, jeśli strona rzeczywiście pokazuje te informacje. Dobór pól zależy od treści strony i wymagań funkcji Google, którą witryna chce obsłużyć.

Google obsługuje formaty JSON-LD, Microdata i RDFa, a JSON-LD rekomenduje, gdy konfiguracja witryny na to pozwala. Schema.org opisuje znaczenie typów i właściwości, natomiast Google określa osobno wymagania dla obsługiwanych wyników rozszerzonych. Przewodnik po wdrażaniu danych Schema.org pokazuje, jak dobierać typ, właściwości i format. Jeśli oznaczenia mają wspierać szerszą pracę nad widocznością, pozycjonowanie SEO dla firm może objąć analizę strony i jej obecności w wyszukiwarce.

Terminy Schema.org i wymagania Google odpowiadają na różne pytania. Słownik pozwala nazwać elementy opisu, a dokumentacja Google wskazuje, które oznaczenia i pola są potrzebne do kwalifikacji do konkretnego wyniku wyszukiwania.

Typ danych strukturalnych należy dopasować do zawartości konkretnego adresu URL. Tabela pokazuje typowe zastosowania i przykładowe właściwości, które można wykorzystać, gdy opisują rzeczywistą treść strony.

Tabela pomaga przypisać rodzaj treści do typu Schema.org, ale nie oznacza, że należy automatycznie dodać wszystkie typy do każdej witryny. Strona produktu może opisywać Product, wpis poradnikowy Article, a serwis firmy Organization lub LocalBusiness, jeśli uzasadniają to treść i charakter działalności.

Organization opisuje podmiot jako całość, natomiast LocalBusiness może opisać firmę działającą lokalnie i jej dane lokalizacyjne. BreadcrumbList odwzorowuje ścieżkę nawigacji widoczną na stronie. Właściwości powinny zawierać zgodne i aktualne wartości, a kod należy oceniać dla konkretnego adresu, nie tylko całej domeny.

Właściwość Schema.org nie oznacza automatycznie, że Google wyświetli ją w wynikach wyszukiwania. Przed wdrożeniem trzeba sprawdzić, czy wybrany typ jest powiązany z funkcją Google, której dotyczy strona, i czy spełnia jej wymagania.

Dane strukturalne same w sobie nie gwarantują wyższej pozycji strony w wynikach wyszukiwania. Mogą pomóc systemom zrozumieć zawartość i kwalifikować stronę do obsługiwanych wyników rozszerzonych, jeśli oznaczenia spełniają wymagania techniczne i dotyczące treści.

Google nie gwarantuje wyświetlenia wyniku rozszerzonego nawet po poprawnym teście. Na decyzję wpływają między innymi zgodność oznaczeń z treścią, jakość strony i kontekst wyszukiwania. Błąd może pozbawić stronę kwalifikacji do określonego wyniku, ale problem z danymi strukturalnymi sam w sobie nie oznacza automatycznie obniżenia pozycji w zwykłych wynikach.

Zalecamy traktować dane strukturalne jako warstwę opisu strony, a nie samodzielną metodę poprawy rankingu. W Search Console można kontrolować raporty wyników rozszerzonych i skuteczność witryny, ale zmiany należy interpretować razem z innymi czynnikami widoczności. Wpływ funkcji wyszukiwania na prezentowanie stron omawiamy w materiale o AI Overviews i pozycjach w Google.

Test wyników rozszerzonych Google sprawdza publiczny adres strony albo wklejony kod pod kątem typów wyników obsługiwanych przez Google. Raport pokazuje wykryte elementy i problemy techniczne, ale nie potwierdza, że Google wyświetli rozszerzenie w wynikach.

Kontrolę adresu można wykonać w następującej kolejności:

1. Otwórz Test wyników rozszerzonych Google i wybierz test adresu albo kodu.
2. Wprowadź publiczny adres strony lub fragment kodu i uruchom test.
3. Rozwiń wykryte elementy, przeczytaj błędy i ostrzeżenia, a następnie sprawdź wskazane właściwości.
4. Porównaj odczytane wartości z treścią widoczną dla użytkownika, na przykład nazwę produktu, cenę, adres firmy lub datę publikacji.
5. Po wdrożeniu zmiany sprawdź raporty wyników rozszerzonych i inspekcję adresu w Search Console.

Błąd wskazuje problem, który może uniemożliwić kwalifikację elementu do wyniku rozszerzonego. Ostrzeżenie zwykle dotyczy pola zalecanego albo innej kwestii wymagającej oceny, lecz nie musi blokować kwalifikacji. Brak wykrytych elementów może oznaczać brak obsługiwanego typu, kod niedostępny dla testu albo problem z dostępem do strony.

Test wyniku rozszerzonego nie sprawdza każdego terminu Schema.org ani wszystkich wytycznych jakościowych. Pozytywny wynik techniczny warto uzupełnić kontrolą zgodności kodu z treścią, dostępności strony dla Google i raportów w Search Console. Po naprawie błędów ponownie uruchom test dla tego samego adresu.

Przed dodaniem własnego kodu trzeba sprawdzić, które elementy witryny już generują dane strukturalne, i wybrać spójne źródło opisu dla każdej encji. Kod może pochodzić z motywu, wtyczki SEO, modułu sklepowego, aplikacji lub własnego wdrożenia programisty.

Zalecamy sprawdzić kilka reprezentatywnych adresów, a następnie przypisać wykryte oznaczenia do ich źródła:

1. Zapisz adres strony głównej, produktu, artykułu i kontaktu.
2. Uruchom test wyników rozszerzonych dla każdego adresu i zanotuj typy, właściwości oraz wartości.
3. Sprawdź ustawienia motywu i wtyczek pod kątem opcji Schema, danych strukturalnych lub JSON-LD.
4. W sklepie sprawdź, czy platforma lub moduł produktowy generuje typy Product i Offer.
5. Porównaj powtarzające się typy i wartości, a następnie ustal, które źródło ma je dostarczać.
6. Po wyłączeniu albo skonfigurowaniu zbędnego źródła ponownie przetestuj stronę.

Dwa fragmenty kodu na jednej stronie nie zawsze są błędem, ponieważ mogą opisywać różne encje. Problem pojawia się wtedy, gdy kilka źródeł powiela ten sam obiekt albo podaje sprzeczne dane, na przykład dwa różne adresy firmy lub ceny produktu. Przy diagnozie porównaj kod źródłowy strony z wyrenderowanym HTML, bo część platform dodaje JSON-LD po załadowaniu strony.

Po zmianie motywu, aktualizacji wtyczek i imporcie produktów ponownie sprawdź oznaczenia. Jeśli zespół nie wie, który komponent generuje dane, zmieniaj jedną warstwę naraz i po każdej zmianie sprawdzaj wynik testu.

Najczęstsze błędy wynikają z różnicy między kodem a widoczną treścią, powielania oznaczeń albo niewłaściwego typu właściwości. Tabela łączy objaw z możliwym źródłem problemu i pierwszą kontrolą, która może zawęzić diagnozę.

Tabela służy do postawienia hipotezy diagnostycznej, a nie do przypisania jednej pewnej przyczyny do objawu. Dla ceny porównaj stronę produktu, dane z feedu oraz kod po odświeżeniu cache. Przy powielonym typie ustal, czy dwa fragmenty opisują tę samą encję, czy różne obiekty.

Zgodność kodu z treścią ma pierwszeństwo przed dodawaniem kolejnych właściwości. Google wymaga, aby oznaczenia rzetelnie opisywały zawartość strony i nie wprowadzały użytkownika w błąd.

Audyt danych strukturalnych warto zlecić, gdy sklep ma wiele szablonów produktów, kilka systemów generuje JSON-LD albo błędy wracają po aktualizacji strony. Kontrola przydaje się też przed migracją, zmianą motywu lub przebudową katalogu, ponieważ te prace mogą zmienić sposób generowania kodu.

Perspektywa KC Mobile: w pracy nad witrynami punktem wyjścia jest porównanie kodu z tym, co rzeczywiście widzi klient. Test automatyczny wykrywa część problemów technicznych, ale nie rozstrzyga sam, która wtyczka powinna dostarczać dane ani czy opis odpowiada modelowi oferty.

Do wykonawcy warto przekazać:

• adresy stron reprezentujących różne typy treści;
• listę aktywnych wtyczek, modułów sklepu i integracji;
• wyniki testu wyników rozszerzonych i komunikaty Search Console;
• informację o ostatnich aktualizacjach, migracji lub imporcie produktów.

Audyt powinien wskazać typy i właściwości wykryte na każdej grupie stron, źródło generowania kodu oraz miejsca, w których wartości odbiegają od widocznej treści. Przydatnym wynikiem jest też kolejność napraw i zestaw adresów do ponownego testu po wdrożeniu.

Problemy z oznaczeniami mogą dotyczyć widoczności i spójności informacji o firmie, produkcie lub artykule. Osobno omawiamy Schema.org a widoczność w AI oraz diagnozę rich snippets na stronie. Jeśli potrzebujesz wykonawcy do uporządkowania widoczności i diagnostyki serwisu, oferta pozycjonowania SEO obejmuje pracę nad stroną i jej obecnością w wyszukiwarce.

• Google Helpful Content: jak oceniać i poprawiać treści na stronie
• Google nie pokazuje featured snippets? Sprawdź przyczyny i napraw problem
• AI Mode Google: jak zmienia wyszukiwanie i widoczność firmy
• Internet Offer Format (IOF): jak czytać strukturę pliku full.xml