Dane strukturalne schema.org opisują znaczenie treści w formacie czytelnym dla maszyn. Nie poprawiają słabej oferty, nie gwarantują rozszerzonego wyniku i nie powinny zawierać informacji ukrytych przed użytkownikiem. Najpierw trzeba mieć poprawną stronę, a dopiero potem oznaczyć właściwy typ encji.
Wybierz typ odpowiadający widocznej treści, użyj spójnych identyfikatorów, połącz organizację, stronę i artykuł, zweryfikuj JSON-LD oraz kontroluj go po zmianach. Nie dodawaj ocen, cen, autorów ani usług, których użytkownik nie widzi na stronie.
Znaczniki opisują to, co już istnieje na stronie
Nagłówek, nazwa autora, data i treść są zrozumiałe dla człowieka. Dane strukturalne mogą wskazać, że dokument jest artykułem, kto go opublikował i jaki obraz pełni funkcję główną. W przypadku firmy można opisać organizację, adres, kontakt i oficjalne profile. Kod nie powinien tworzyć drugiej, bogatszej wersji strony dostępnej tylko robotom.
Schema.org jest słownikiem, a sposób wykorzystania zależy od odbiorcy. Wyszukiwarki publikują własne wymagania dla funkcji wyników i mogą je zmieniać. Poprawny typ schema nie oznacza automatycznie specjalnego wyglądu w Google. Wartość wdrożenia polega przede wszystkim na jednoznacznym opisie encji oraz spójności danych.
| Treść strony | Możliwy typ | Warunek |
|---|---|---|
| Serwis firmy | Organization lub właściwy podtyp | Prawdziwe dane podmiotu |
| Lokalna placówka | LocalBusiness i podtyp branżowy | Realny adres oraz obsługa |
| Poradnik redakcyjny | Article | Autor, data i treść artykułu |
| Produkt | Product | Konkretny produkt widoczny na stronie |
| Nawigacja okruszkowa | BreadcrumbList | Ścieżka odpowiadająca strukturze |
| Pytania i odpowiedzi | FAQPage w odpowiednim kontekście | Pełna treść dostępna użytkownikowi |
Jeśli strona nie pokazuje ceny, nie dodawaj jej tylko w kodzie. Jeśli opinie pochodzą z innego produktu, nie przypisuj ich aktualnej karcie. Jeśli biuro jest wirtualne i klienci nie są tam obsługiwani, oznaczenie lokalnej placówki może być mylące. Kod musi wynikać z modelu biznesowego i treści.
Ta sama zasada dotyczy dostępności produktu, wydarzenia i godzin otwarcia: automatyzacja jest przydatna tylko wtedy, gdy pobiera bieżący status z wiarygodnego źródła. Przestarzały znacznik jest gorszy niż brak opcjonalnej właściwości.
Dane strukturalne nie zastępują tytułu, opisu, linkowania ani poprawnej indeksacji. Najpierw sprawdź, czy adres jest dostępny, ma właściwy canonical i nie jest blokowany. Pomaga w tym poradnik jak sprawdzić indeksację strony.
Wybierz najbardziej szczegółowy typ, który potrafisz obronić
Podtyp jest użyteczny, gdy odpowiada rzeczywistej działalności. Firma prowadząca placówkę weterynaryjną może użyć właściwego typu branżowego dla konkretnej lokalizacji, ale nie powinna jednym obiektem opisywać kilku oddziałów z różnymi adresami. Każda placówka potrzebuje własnych danych, a organizacja nadrzędna może je łączyć.
Przykładem podmiotu z dwiema lokalizacjami i rozdzielonymi rezerwacjami jest centrum weterynaryjne w Krakowie i Michałowicach. W takim układzie znaczniki powinny odzwierciedlać oddzielne adresy, telefony i godziny, zamiast składać je w jeden nieistniejący punkt.
- Nazwa jest zgodna z marką używaną publicznie, bez dopisywania fraz.
- Adres odpowiada konkretnej placówce widocznej na stronie.
- Telefon i godziny należą do opisywanej lokalizacji.
- Adres URL wskazuje kanoniczną stronę encji.
- Logo i obrazy są dostępne pod stabilnymi adresami.
- Profile w
sameAssą oficjalne, a nie przypadkowo podobne.
Dla artykułu rozróżnij autora od wydawcy. Autor może być osobą, zespół redakcyjny wymaga konsekwentnej reprezentacji, a wydawcą jest organizacja. Data publikacji i modyfikacji powinny odpowiadać rzeczywistym zmianom. Nie aktualizuj daty automatycznie przy każdym wyświetleniu, ponieważ traci znaczenie.
Na kartach produktów cena, waluta, stan i wariant muszą być zgodne z interfejsem. Przy wielu wariantach struktura zależy od modelu URL-i oraz danych sklepu. Najpierw uporządkuj warianty według poradnika o wariantach produktów, a dopiero potem opisuj je w schema.
Połącz encje stabilnymi identyfikatorami
Oddzielne bloki mogą opisywać witrynę, organizację, stronę i artykuł, ale powinny wskazywać na te same encje. Stabilny identyfikator @id pozwala powiedzieć, że wydawca artykułu jest tą samą organizacją, którą opisuje serwis. Bez spójności kilka wtyczek może stworzyć konkurujące wersje nazwy, logo i adresu.
Identyfikator zwykle opiera się na kanonicznym adresie z fragmentem, np. #organization lub #website. Nie powinien zmieniać się przy każdej aktualizacji motywu. Jeżeli domena lub struktura URL-i ulega zmianie, trzeba zaplanować aktualizację całego grafu wraz z canonicalami i przekierowaniami.
@id dla powtarzalnych obiektów.BreadcrumbList opisuje ścieżkę nawigacyjną, a nie historię kliknięć użytkownika. Pozycje powinny odpowiadać strukturze i prowadzić do dostępnych stron. Nie dodawaj poziomu kategorii tylko w kodzie, jeśli interfejs i linkowanie go nie pokazują. Spójna architektura zaczyna się od planu opisanego w poradniku o strukturze strony internetowej.
Osoba jako autor powinna mieć własną stronę lub przynajmniej jednoznaczne dane w serwisie. Nie twórz fikcyjnych profili i nie używaj tej samej anonimowej osoby do wszystkich branż. E-E-A-T wynika z odpowiedzialnej redakcji i treści, nie z samego pola author.
JSON-LD generuj z tych samych danych co widok
JSON-LD jest zwykle najwygodniejszy, ponieważ nie wymaga rozsypywania atrybutów po całym HTML-u. Kod powinien powstawać z danych CMS, które zasilają widoczną stronę. Ręczne wpisanie ceny lub autora w szablonie tworzy ryzyko rozjazdu po aktualizacji.
W WordPressie wtyczka SEO może już generować WebSite, Organization, WebPage, Article i BreadcrumbList. Zanim dodasz własny kod, obejrzyj źródło oraz wynikowy graf. Druga wtyczka do schema może powielić te same obiekty albo wprowadzić inne logo i identyfikatory. Rozszerzaj istniejący graf tam, gdzie jest to możliwe.
Nie oznaczaj strony jednocześnie jako kilku niepasujących typów tylko dlatego, że narzędzie pozwala je wybrać. Typ powinien wynikać z głównej zawartości konkretnego URL-a.
Znaki specjalne, cudzysłowy i adresy muszą być prawidłowo kodowane. Nie składaj JSON-u przez ręczne łączenie tekstu bez funkcji serializującej. Puste właściwości lepiej pominąć niż publikować jako pusty ciąg. Listy, takie jak zdjęcia lub profile, powinny zachować prawidłową strukturę tablicy.
Jeżeli strona jest wielojęzyczna, każdy URL powinien opisywać treść danego języka, a nazwy i adresy pozostawać zgodne z wersją. Nie wstawiaj jednego bloku po polsku na wszystkich wersjach. Relacje między językami nadal obsługuj prawidłowym hreflangiem, zgodnie z poradnikiem o stronie wielojęzycznej WordPress.
Walidator sprawdza składnię, nie prawdziwość biznesu
Test wyników rozszerzonych może potwierdzić obsługiwany format i wskazać wymagane lub zalecane pola. Ogólny walidator schema pomaga ocenić zgodność ze słownikiem. Żaden z nich nie wie, czy adres jest prawdziwy, cena aktualna, a opinia rzeczywiście dotyczy produktu. Potrzebna jest również kontrola merytoryczna.
| Warstwa | Pytanie | Dowód |
|---|---|---|
| Składnia | Czy JSON-LD jest poprawny? | Parser i walidator |
| Słownik | Czy właściwości pasują do typu? | Walidacja schema.org |
| Wymagania odbiorcy | Czy spełniono kryteria funkcji? | Test właściwej wyszukiwarki |
| Zgodność treści | Czy dane są widoczne na stronie? | Porównanie renderu i kodu |
| Prawdziwość | Czy dane odpowiadają działalności? | Właściciel biznesowy |
Typowe błędy to kilka obiektów Organization z różnymi nazwami, brak połączenia autora z artykułem, stara cena, ocena bez źródła, logo o niedostępnym adresie i BreadcrumbList prowadzący przez strony z błędem. Często problem pojawia się dopiero po migracji albo zmianie domeny.
Sprawdź kod zarówno na pojedynczym artykule, jak i stronie kategorii, produktu, wynikach wyszukiwania oraz błędzie 404. Szablony archiwalne nie powinny dziedziczyć Article tylko dlatego, że zawierają listę postów. Strony techniczne mogą wymagać innego typu lub braku dodatkowego oznaczenia.
Canonical w schema i w sekcji head powinien wskazywać tę samą wersję adresu. Rozbieżności protokołu, hosta, końcowego ukośnika lub języka utrudniają spójność. Zasady wyboru adresu omawia poradnik o adresie kanonicznym.
Kontroluj znaczniki po zmianie treści, wtyczki i szablonu
Schema jest częścią publikacji, nie jednorazowym dodatkiem. Zmiana numeru, godzin, autora, ceny, dostępności i logo musi aktualizować zarówno widok, jak i kod. Ustal jedno źródło danych i osobę odpowiedzialną. Informacje wpisane w trzech panelach szybko przestają być zgodne.
Po aktualizacji wtyczki SEO lub motywu sprawdź reprezentatywne typy stron. Monitoruj raporty dotyczące danych strukturalnych, ale nie reaguj masowym dodawaniem pól bez oceny. Ostrzeżenie zalecanej właściwości może wskazywać szansę, lecz pole trzeba uzupełnić prawdziwą informacją.
- Każdy typ wynika z widocznej treści konkretnego adresu.
- Organizacja, witryna, strony i autorzy używają spójnych identyfikatorów.
- Wtyczki nie generują konkurujących obiektów z innymi danymi.
- JSON-LD przechodzi kontrolę składni, słownika i zgodności treści.
- Canonical, adresy encji i linki w grafie są zgodne.
- Zmiana danych biznesowych uruchamia ponowną walidację.
Efektu nie oceniaj wyłącznie przez wygląd wyników. Rozszerzenia mogą pojawiać się i znikać niezależnie od poprawności kodu. Monitoruj błędy, widoczność, kliknięcia i spójność, ale nie przypisuj każdej zmiany samemu schema. Najważniejszym kryterium pozostaje brak fałszywych lub przestarzałych danych.
Wdrożenie schema.org jest gotowe, gdy znaczniki opisują widoczną treść, korzystają z jednego źródła danych, tworzą spójny graf, przechodzą walidację i mają właściciela aktualizacji. Rozszerzony wynik w wyszukiwarce nie jest gwarantowanym kryterium odbioru.