Technologia, praktyka i inspiracje na co dzień

SEO i widoczność

Dane strukturalne Schema.org – jak wdrożyć je na swojej stronie

Dwie strony o podobnej treści mogą wyglądać w wynikach Google zupełnie inaczej. Jedna pokazuje tylko tytuł i opis, a druga także gwiazdki ocen, cenę, ścieżkę okruszków albo datę wydarzenia. Różnicę często robią dane strukturalne Schema.org, czyli znaczniki, które mówią wyszukiwarce, czym jest zawartość strony: artykułem, produktem, firmą lokalną czy przepisem.

Wdrożenie nie wymaga zaawansowanego programowania, ale łatwo o błędy, przez które znaczniki nic nie dają albo wręcz szkodzą. Najczęściej są to zdublowany kod z motywu i wtyczki, nieaktualne ceny, samodzielnie wystawione oceny albo typy, które Google przestał szeroko wyświetlać. Dobrze dobrane i regularnie sprawdzane znaczniki same nie podniosą pozycji. Pomagają jednak wyszukiwarce poprawnie zrozumieć stronę i zwiększają szansę na bardziej widoczny wynik.

Czym są dane strukturalne Schema.org i co realnie dają

Dane strukturalne to dodatkowe znaczniki w kodzie strony, które w ustandaryzowany sposób opisują jej zawartość. Mówią wyszukiwarce wprost, że dana podstrona to artykuł z autorem i datą publikacji, produkt z ceną, firma z adresem albo wydarzenie z terminem i miejscem. Nazwy typów i właściwości pochodzą ze Schema.org, wspólnego słownika rozwijanego z udziałem największych wyszukiwarek.

Znaczniki można zapisać w trzech formatach: JSON-LD, Microdata i RDFa. Dwa ostatnie wplatają atrybuty bezpośrednio w kod HTML treści, więc przebudowa szablonu łatwo je psuje. JSON-LD to osobny blok danych, niezależny od układu strony, dlatego Google zaleca go jako najprostszy we wdrażaniu i utrzymaniu.

Najbardziej widocznym efektem są wyniki rozszerzone (rich results), czyli gwiazdki ocen, cena i dostępność produktu, ścieżka okruszków zamiast samego adresu URL (obecnie głównie w wynikach na komputerach) czy daty wydarzeń. Taki wynik zwykle lepiej przyciąga uwagę, ale dane strukturalne Schema.org nie są bezpośrednim czynnikiem rankingowym. Nie podniosą pozycji słabej podstrony, a poprawny kod nie gwarantuje rozszerzonego wyglądu, bo o jego wyświetleniu decyduje wyszukiwarka. O tym, jak budować widoczność strony w wynikach, przesądzają przede wszystkim treść i jej dopasowanie do zapytań.

Obsługa poszczególnych typów zmienia się w czasie. Google ograniczył wyniki rozszerzone FAQ do nielicznych, wiarygodnych serwisów (np. rządowych i medycznych), a wyniki HowTo całkowicie wycofał, więc znaczniki, które kiedyś dawały efektowny wynik, dziś często nie zmieniają jego wyglądu.

Jakie typy schematów wybrać dla swojej strony

Dane strukturalne Schema.org dobiera się do rodzaju treści, a nie do wyników rozszerzonych, które chciałoby się zobaczyć w Google. Inny zestaw typów sprawdzi się na blogu, inny w sklepie, a jeszcze inny na stronie gabinetu czy warsztatu.

Typy dla bloga i serwisu z poradnikami

  • Article lub BlogPosting – dla pojedynczych wpisów, z tytułem, datą publikacji i aktualizacji, autorem oraz obrazem.
  • BreadcrumbList – odwzorowuje ścieżkę okruszków, np. Strona główna › SEO › wpis.
  • Organization lub Person – wskazuje autora i wydawcę. Przy blogu prowadzonym przez jedną osobę naturalnym wyborem jest Person, przy redakcji lub firmie – Organization.
  • WebSite – opisuje serwis jako całość i zwykle trafia na stronę główną.

Typy dla firm lokalnych i sklepów internetowych

Firma z siedzibą lub punktem obsługi korzysta z typu LocalBusiness albo jego bardziej szczegółowego podtypu, np. Restaurant czy Dentist. Podaje się w nim adres, godziny otwarcia i telefon, zgodne z danymi na stronie i w Profilu Firmy w Google.

W sklepie podstawą jest Product z zagnieżdżonym Offer, który zawiera cenę, walutę i dostępność. Opinie opisują Review i AggregateRating, pod warunkiem że pochodzą od prawdziwych klientów i są widoczne na karcie produktu.

Często używane są też typy Event (wydarzenia), Recipe (przepisy), VideoObject (filmy) i JobPosting (oferty pracy). Hierarchia na schema.org obejmuje typy dla wielu branż, np. Course dla kursów czy SoftwareApplication dla aplikacji, więc przed wdrożeniem dobrze ją przejrzeć.

Jak wdrożyć znaczniki na stronie krok po kroku

Zbliżenie ekranu laptopa z kodem źródłowym otwartym w edytorze Sublime Text
Kod JSON-LD najczęściej umieszcza się w sekcji head lub bezpośrednio w treści strony.

Ręczne dodanie kodu JSON-LD

Najprostszą metodą jest wklejenie bloku JSON-LD w tagu script w sekcji head albo w treści strony. Minimalny przykład dla wpisu blogowego wygląda tak:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Tytuł wpisu",
  "image": "https://example.com/obraz.jpg",
  "datePublished": "2024-05-10",
  "author": {
    "@type": "Person",
    "name": "Imię Nazwisko"
  }
}
</script>

Dokumentacja Google dzieli właściwości na wymagane i zalecane. Brak wymaganych zwykle wyklucza stronę z wyników rozszerzonych. Zalecane dodają szczegóły, które mogą poprawić prezentację. Dla Article Google nie wymaga żadnych właściwości, ale zaleca m.in. headline, image, datePublished i author.

Wtyczki, CMS i inne narzędzia

Popularne wtyczki SEO do WordPressa zwykle same generują znaczniki WebSite, Organization lub Person, BreadcrumbList i Article. Własne typy, np. Event czy Recipe, dodasz przez ustawienia wtyczki, blok schematu w edytorze albo filtr w pliku functions.php motywu potomnego.

Przed wdrożeniem sprawdź w kodzie źródłowym, co już generują motyw, wtyczki i ręcznie dodany kod. Dwa różne bloki Article lub Organization na jednej stronie potrafią wprowadzić wyszukiwarkę w błąd. Najlepiej zostawić jedno źródło dla każdego typu.

Google Tag Manager przydaje się wtedy, gdy nie masz dostępu do kodu szablonu. Znaczniki wstrzykiwane przez JavaScript Google odczyta jednak dopiero po wyrenderowaniu strony, a przy zmianie treści łatwo o rozjazd, np. nieaktualną cenę. Kod z generatorów online jest statyczny, dlatego nadaje się głównie do stron, które rzadko się zmieniają.

Testowanie, monitorowanie i najczęstsze błędy w danych strukturalnych

Do sprawdzania znaczników służą dwa narzędzia o różnym przeznaczeniu. Test wyników z elementami rozszerzonymi od Google pokazuje tylko typy, które mogą dać wynik rozszerzony w Google, i ocenia je według wymagań wyszukiwarki. Schema Markup Validator sprawdza zgodność ze słownikiem Schema.org dla wszystkich typów, ale nie mówi, czy Google je wykorzysta. Brak błędów w walidatorze nie oznacza więc, że strona kwalifikuje się do rich results.

W Google Search Console dane strukturalne monitoruje się w sekcji ulepszeń, gdzie każdy obsługiwany typ ma osobny raport. Błędy wykluczają element z wyników rozszerzonych, a ostrzeżenia dotyczą zwykle brakujących pól zalecanych. Po poprawce użyj opcji weryfikacji. Google ponownie sprawdzi adresy, co może potrwać, a szybsze indeksowanie podstron skraca ten czas.

Najczęstsze problemy to:

  • znaczniki opisujące treść, której nie widać na stronie,
  • nieaktualne ceny i dostępność produktów,
  • oceny wystawione firmie przez nią samą lub dodane bez prawdziwych opinii,
  • brak pól wymaganych dla danego typu.

Celowe wprowadzanie w błąd może skończyć się działaniem ręcznym. Strona traci wtedy możliwość wyświetlania wyników rozszerzonych, dopóki nie usuniesz problemu i nie złożysz prośby o ponowne rozpatrzenie.

Zmiana szablonu, migracja lub aktualizacja wtyczki potrafi po cichu usunąć albo zdublować znaczniki.

Przygotuj listę kilku najważniejszych adresów, na przykład stronę główną, typowy wpis, kartę produktu i stronę kontaktową. Sprawdzaj je w teście Google po każdej większej zmianie technicznej i dodatkowo raz w miesiącu.

Najczęściej zadawane pytania

Czy dane strukturalne poprawiają pozycję strony w Google?

Nie bezpośrednio, bo nie są czynnikiem rankingowym. Pomagają wyszukiwarce zrozumieć, czym jest zawartość podstrony, i zwiększają szansę na wynik rozszerzony z ocenami, ceną czy ścieżką okruszków, który zwykle lepiej przyciąga uwagę. O samej pozycji decydują przede wszystkim jakość treści i jej dopasowanie do zapytań.

Jak sprawdzić, czy strona ma dane strukturalne?

Najszybciej otworzyć kod źródłowy i poszukać bloku application/ld+json albo atrybutów itemscope i itemprop, typowych dla mikrodanych. Adres możesz też wkleić do Testu wyników z elementami rozszerzonymi od Google, który ocenia typy obsługiwane przez wyszukiwarkę, oraz do Schema Markup Validator, który sprawdza zgodność ze słownikiem dla wszystkich typów. Dla całego serwisu najwygodniej korzystać z raportów w sekcji ulepszeń Google Search Console.

Czy JSON-LD jest lepszy od mikrodanych?

W większości przypadków tak – to format rekomendowany przez Google. JSON-LD to osobny blok danych, więc zmiana układu strony go nie psuje, a mikrodane wplecione w HTML łatwo uszkodzić przy przebudowie szablonu. Poprawnie działających mikrodanych nie trzeba przepisywać, ale przy nowym wdrożeniu wygodniej wybrać JSON-LD.

Po jakim czasie Google pokazuje wyniki rozszerzone?

Nie ma stałego terminu, bo wyszukiwarka musi najpierw ponownie odwiedzić i przetworzyć podstronę. Przyspieszyć to może prośba o zaindeksowanie adresu lub weryfikacja poprawki w Search Console. Trzeba też pamiętać, że nawet bezbłędny kod nie gwarantuje rozszerzonego wyglądu, bo o jego wyświetleniu decyduje Google.

Czy dane strukturalne są potrzebne na małej stronie firmowej?

Nie są obowiązkowe, ale niewielkim nakładem pracy porządkują informacje o firmie dla wyszukiwarki. Zwykle wystarczy typ LocalBusiness lub jego podtyp z adresem, telefonem i godzinami otwarcia zgodnymi z treścią strony i danymi w Profilu Firmy w Google, a do tego Organization i WebSite. Jeśli strona działa na WordPressie, część tych znaczników może już generować wtyczka SEO, więc przed dodaniem własnych sprawdź, czy się nie zdublują.

Zobacz również