Co to są wyniki z elementami rozszerzonymi i jak działają rich results?

Wyniki z elementami rozszerzonymi to specjalne sposoby prezentowania stron w wynikach wyszukiwania, które mogą zawierać więcej informacji niż klasyczny wynik składający się z tytułu, adresu i krótkiego opisu.

W języku angielskim określa się je jako rich results.

W zależności od rodzaju treści Google może lepiej zrozumieć między innymi:

• produkt i jego cenę,
• dostępność produktu,
• oceny i recenzje,
• wydarzenie i jego termin,
• przepis kulinarny,
• ofertę pracy,
• organizację,
• firmę lokalną,
• film,
• strukturę nawigacji.

Podstawą takiego zrozumienia są najczęściej dane strukturalne umieszczone w kodzie strony.

Trzeba jednak od razu rozróżnić trzy pojęcia, które bardzo często są używane zamiennie mimo że oznaczają coś innego:

• Schema.org,
• dane strukturalne,
• rich results.

Co to są wyniki z elementami rozszerzonymi?

Standardowy wynik wyszukiwania może zawierać przede wszystkim tytuł strony, adres i fragment tekstu opisujący jej zawartość.

Wynik rozszerzony może zostać wzbogacony o dodatkowe informacje wynikające z rodzaju treści.

Przykładowo przy produkcie Google może zrozumieć, że liczba 299 nie jest przypadkową wartością występującą w tekście, ale ceną konkretnego produktu.

Może również otrzymać informację, że:

• walutą jest PLN,
• produkt jest dostępny,
• posiada określoną markę,
• ma konkretny identyfikator,
• otrzymał oceny użytkowników.

Dzięki temu wyszukiwarka otrzymuje znacznie bardziej jednoznaczny opis zawartości dokumentu.

Co oznacza rich result?

Rich result oznacza wynik wyszukiwania, który może zostać przedstawiony w bardziej rozbudowanej formie dzięki lepszemu zrozumieniu treści strony.

Nie każdy wynik rozszerzony wygląda tak samo.

Forma prezentacji zależy między innymi od typu treści, zapytania użytkownika, urządzenia oraz sposobu, w jaki wyszukiwarka aktualnie prezentuje konkretny rodzaj informacji.

Dlatego nie należy myśleć o rich results jako o jednym konkretnym widżecie.

To cała grupa możliwych sposobów prezentacji informacji.

Rich results a rich snippets

W branży SEO często można spotkać również określenie rich snippets.

Historycznie było ono powszechnie używane do opisywania rozszerzonych fragmentów wyników.

Obecnie bardziej uniwersalnym określeniem jest rich results, czyli wyniki z elementami rozszerzonymi.

W codziennych rozmowach oba terminy nadal bywają używane zamiennie.

Czym są dane strukturalne?

Dane strukturalne to informacje zapisane w określonym, maszynowo czytelnym formacie, które opisują znaczenie treści znajdującej się na stronie.

Zwykły HTML może powiedzieć przeglądarce:

„wyświetl ten tekst jako nagłówek”.

Dane strukturalne mogą dodatkowo powiedzieć wyszukiwarce:

„ten dokument opisuje produkt, ten tekst jest jego nazwą, ta liczba ceną, a ta wartość oznacza dostępność”.

Nie zmieniają więc wyłącznie wyglądu strony.

Dodają warstwę semantyczną pozwalającą systemom lepiej interpretować zawartość dokumentu.

Co to jest Schema.org?

Schema.org to wspólny słownik pojęć służących do opisywania różnych rodzajów informacji w internecie.

Definiuje między innymi typy takie jak:

• Product,
• Organization,
• LocalBusiness,
• Article,
• Event,
• Recipe,
• Person,
• VideoObject,
• BreadcrumbList.

Każdy typ może posiadać określone właściwości.

Produkt może mieć na przykład:

• nazwę,
• markę,
• opis,
• identyfikator,
• ofertę,
• cenę,
• walutę,
• dostępność.

Schema.org nie jest jednak tym samym co Google Rich Results.

Schema.org a Google

Schema.org definiuje bardzo dużą liczbę typów i właściwości.

Google nie musi wykorzystywać każdego z nich do tworzenia specjalnego wyglądu wyniku wyszukiwania.

To bardzo ważne rozróżnienie.

Można poprawnie oznaczyć na stronie określony typ danych zgodny ze Schema.org, ale nie oznacza to automatycznie, że Google posiada dla niego specjalny rich result.

Dane nadal mogą pomagać systemom zrozumieć znaczenie treści, ale nie każda informacja posiada własny wizualny format w wynikach wyszukiwania.

Dane strukturalne nie służą wyłącznie Google

Choć najczęściej mówi się o nich w kontekście SEO, ich idea jest szersza.

Opisują informacje w sposób możliwy do interpretacji przez systemy komputerowe.

Mogą więc być wykorzystywane przez:

• wyszukiwarki,
• aplikacje,
• agregatory danych,
• systemy analizujące treść,
• inne automatyczne narzędzia.

To jeden z powodów, dla których traktuję poprawną semantykę strony szerzej niż tylko jako sposób na zdobycie dodatkowej gwiazdki w Google.

Jak dane strukturalne trafiają na stronę?

Istnieje kilka technicznych sposobów zapisywania danych strukturalnych.

Najczęściej można spotkać:

• JSON-LD,
• Microdata,
• RDFa.

Każdy z tych formatów pozwala opisać znaczenie informacji, ale robi to w inny sposób.

Co to jest JSON-LD?

JSON-LD to popularny sposób umieszczania danych strukturalnych w dokumencie.

Skrót pochodzi od JavaScript Object Notation for Linked Data.

Dane są zapisane w uporządkowanej strukturze, która może istnieć niezależnie od właściwego kodu odpowiedzialnego za wygląd strony.

Jest to wygodne podczas wdrożeń, ponieważ nie trzeba otaczać każdego widocznego elementu dodatkowymi atrybutami.

Co to jest Microdata?

Microdata pozwala dodawać informacje semantyczne bezpośrednio do elementów HTML.

Znaczenie danych jest więc powiązane z konkretnymi fragmentami dokumentu.

Takie rozwiązanie nadal można spotkać w wielu systemach i motywach.

Przy bardziej rozbudowanych strukturach kod może jednak stać się trudniejszy do utrzymania niż w przypadku osobnego JSON-LD.

Co to jest RDFa?

RDFa jest kolejnym sposobem dodawania danych semantycznych do dokumentów internetowych.

W klasycznych wdrożeniach stron i sklepów spotykam go zdecydowanie rzadziej niż JSON-LD lub Microdata.

Dla właściciela strony najważniejsze nie jest jednak zapamiętanie wszystkich formatów, lecz zrozumienie, że różne sposoby zapisu mogą reprezentować te same informacje.

Czy JSON-LD jest widoczny dla użytkownika?

Sam blok danych strukturalnych nie musi być prezentowany użytkownikowi jako osobny element strony.

Nie oznacza to jednak, że można umieszczać w nim dowolne informacje niewidoczne w serwisie.

Dane strukturalne powinny odpowiadać rzeczywistej zawartości strony.

Jeżeli oznaczenie mówi, że produkt kosztuje 199 zł, a użytkownik widzi na stronie 299 zł, powstaje sprzeczność.

Dane strukturalne muszą odpowiadać treści

To jedna z podstawowych zasad poprawnego wdrożenia.

Nie należy dodawać informacji wyłącznie do Schema w nadziei, że dzięki temu wynik będzie wyglądał lepiej.

Jeżeli strona nie zawiera określonej informacji dla użytkownika, nie powinno się przedstawiać jej wyszukiwarce jako czegoś, co faktycznie znajduje się na stronie.

Dotyczy to szczególnie:

• cen,
• ocen,
• recenzji,
• dostępności,
• danych firmy,
• wydarzeń.

Najczęstszy przykład: Product

Sklepy internetowe są jednym z najbardziej naturalnych miejsc stosowania danych strukturalnych.

Karta produktu posiada bardzo jednoznaczny zestaw informacji.

Można opisać między innymi:

• nazwę produktu,
• markę,
• zdjęcia,
• opis,
• SKU,
• GTIN lub EAN,
• cenę,
• walutę,
• dostępność,
• oceny.

Dzięki temu wyszukiwarka nie musi interpretować każdej liczby i fragmentu tekstu wyłącznie na podstawie układu wizualnego strony.

Product w WooCommerce

WooCommerce oraz wtyczki SEO mogą automatycznie generować część danych strukturalnych produktu.

Nie oznacza to jednak, że każde wdrożenie jest automatycznie poprawne.

Problemy mogą pojawić się, gdy kilka komponentów jednocześnie generuje własne dane.

Przykładowo Schema może pochodzić równocześnie z:

• WooCommerce,
• motywu,
• wtyczki SEO,
• dodatkowej wtyczki Schema,
• indywidualnego kodu.

Efektem mogą być duplikaty albo sprzeczne informacje.

Przy tworzeniu i rozwijaniu sklepów WooCommerce sprawdzam dlatego nie tylko to, czy dane strukturalne istnieją, ale również czy różne warstwy systemu nie generują sprzecznych wersji tego samego produktu.

Produkt z wariantami

Warianty produktów komplikują strukturę danych.

Produkt może występować w kilku:

• kolorach,
• rozmiarach,
• pojemnościach,
• konfiguracjach.

Każdy wariant może mieć własną:

• cenę,
• dostępność,
• SKU,
• GTIN,
• fotografię.

Nie wystarczy wtedy wygenerować jednego przypadkowego zestawu danych dla całej karty.

Struktura powinna odpowiadać rzeczywistemu modelowi produktu i sposobowi prezentowania wariantów.

Cena w danych strukturalnych

Cena jest jednym z pól, przy których łatwo o niespójność.

Może zmieniać się przez:

• promocje,
• dynamiczne reguły cenowe,
• walutę,
• grupę użytkownika,
• wariant produktu.

Jeżeli widoczna cena zmienia się, dane strukturalne również powinny prezentować właściwą wartość dla danego dokumentu i kontekstu.

Dostępność produktu

Podobnie wygląda sytuacja ze stanem magazynowym.

Produkt może być:

• dostępny,
• niedostępny,
• chwilowo niedostępny,
• dostępny w przedsprzedaży,
• dostępny na zamówienie.

Informacja przekazywana systemom powinna odpowiadać temu, co rzeczywiście może zrobić użytkownik.

Jeżeli produkt jest wyprzedany, ale Schema nadal przez kilka tygodni informuje o dostępności, dane przestają być wiarygodne.

Oceny i gwiazdki

Jednym z najbardziej rozpoznawalnych elementów rozszerzonych są informacje związane z ocenami.

Właśnie dlatego ten obszar jest również często nadużywany.

Nie powinno się tworzyć fikcyjnych ocen wyłącznie po to, żeby uzyskać atrakcyjniejszy wygląd wyniku.

Jeżeli strona oznacza ocenę, powinna ona wynikać z rzeczywistych danych dotyczących właściwego obiektu.

AggregateRating

AggregateRating opisuje zagregowaną ocenę wynikającą z wielu ocen użytkowników.

Może zawierać między innymi:

• średnią ocenę,
• liczbę ocen,
• skalę.

Nie należy jednak dodawać AggregateRating automatycznie do każdego rodzaju strony tylko dlatego, że technicznie jest to możliwe.

Znaczenie ma zarówno rodzaj obiektu, jak i zasady wykorzystywania takich danych przez wyszukiwarkę.

Review a AggregateRating

Review opisuje konkretną recenzję.

AggregateRating opisuje natomiast wynik zbiorczy.

To nie są te same informacje.

Jeżeli produkt otrzymał sto ocen, średnia może być przedstawiona jako agregat, natomiast pojedyncza opinia posiada własnego autora i treść.

LocalBusiness

LocalBusiness służy do opisywania firmy lub placówki działającej w określonej lokalizacji.

Dane mogą obejmować między innymi:

• nazwę,
• adres,
• telefon,
• godziny otwarcia,
• typ działalności.

Nie należy jednak utożsamiać danych LocalBusiness z Profilem Firmy w Google.

Są to dwa odrębne źródła informacji.

Organization

Organization pozwala opisać organizację stojącą za stroną.

Może zawierać informacje takie jak:

• nazwa,
• adres strony,
• logo,
• dane identyfikujące organizację.

Takie oznaczenie pomaga tworzyć bardziej jednoznaczny kontekst dotyczący podmiotu odpowiedzialnego za serwis.

Person

Schema.org pozwala również opisywać osoby.

Może mieć to zastosowanie między innymi przy:

• autorach artykułów,
• ekspertach,
• twórcach,
• profilach zawodowych.

Nie oznacza to jednak, że każda strona Person automatycznie otrzyma specjalny wygląd w Google.

Ponownie trzeba oddzielić semantyczne opisanie obiektu od konkretnego rich result.

Article

Dane dotyczące artykułu mogą opisywać między innymi:

• tytuł,
• autora,
• datę publikacji,
• datę modyfikacji,
• grafikę.

Ma to znaczenie szczególnie w serwisach redakcyjnych, blogach i portalach publikujących dużą liczbę treści.

Data publikacji i modyfikacji

Jeżeli w danych strukturalnych przekazywana jest data publikacji albo aktualizacji, powinna odpowiadać rzeczywistemu stanowi materiału.

Nie warto sztucznie zmieniać daty codziennie tylko po to, żeby artykuł wyglądał na świeży.

Aktualizacja powinna oznaczać rzeczywistą zmianę treści.

Event

Wydarzenia są kolejnym typem informacji, który można opisywać w sposób strukturalny.

Istotne mogą być:

• nazwa wydarzenia,
• data rozpoczęcia,
• miejsce,
• organizator,
• oferta biletowa.

To szczególnie przydatne dla stron koncertów, konferencji, wydarzeń kulturalnych i innych zdarzeń odbywających się w określonym czasie.

Recipe

Przepisy kulinarne mają bardzo charakterystyczną strukturę.

Można opisać między innymi:

• nazwę potrawy,
• zdjęcie,
• składniki,
• czas przygotowania,
• instrukcję,
• wartości odżywcze.

Dzięki temu wyszukiwarka może lepiej zrozumieć, że strona zawiera rzeczywisty przepis, a nie artykuł, w którym przypadkowo pojawia się nazwa potrawy.

JobPosting

Oferta pracy również posiada charakterystyczne pola.

Mogą obejmować:

• stanowisko,
• pracodawcę,
• lokalizację,
• opis,
• datę publikacji,
• termin ważności.

W tym przypadku szczególnie ważne jest również usuwanie albo aktualizowanie danych po zakończeniu rekrutacji.

VideoObject

Film osadzony na stronie może zostać opisany jako VideoObject.

Dane mogą wskazywać między innymi:

• tytuł,
• opis,
• miniaturę,
• czas publikacji,
• czas trwania.

Pomaga to systemom lepiej zrozumieć materiał wideo będący częścią strony.

BreadcrumbList

BreadcrumbList opisuje ścieżkę nawigacyjną strony.

Przykładowo:

Strona główna → Sklep → Obuwie → Buty trekkingowe

Każdy element otrzymuje własną pozycję i nazwę.

Dane strukturalne nie tworzą jednak dobrej architektury informacji same z siebie.

Jeżeli breadcrumb na stronie jest chaotyczny, oznaczenie go Schema nie naprawi problemu.

Dane strukturalne a breadcrumb widoczny na stronie

Najlepszym rozwiązaniem jest spójność.

Użytkownik powinien widzieć logiczną ścieżkę, a dane strukturalne powinny opisywać tę samą strukturę.

Nie warto tworzyć osobnej hierarchii wyłącznie dla wyszukiwarki.

Jak Google wykorzystuje dane strukturalne?

Wyszukiwarka może wykorzystać dane jako dodatkową wskazówkę pomagającą zrozumieć stronę.

Nie oznacza to jednak, że musi wykorzystać każdą przekazaną właściwość.

Google sam decyduje o sposobie prezentowania wyniku.

Dane strukturalne zwiększają możliwość zakwalifikowania strony do określonego typu rozszerzenia, ale nie są gwarancją jego wyświetlenia.

Poprawny Schema nie gwarantuje rich result

To jedna z najważniejszych zasad.

Można posiadać:

• poprawną składnię,
• wszystkie wymagane pola,
• stronę dostępną dla Google,

a mimo to wyszukiwarka może pokazać zwykły wynik.

Nie należy więc obiecywać klientowi:

„wdrożę Schema i od jutra będziesz miał gwiazdki w Google”.

Takiej gwarancji nie ma.

Dlaczego Google może nie pokazać wyniku rozszerzonego?

Powodów może być wiele.

Między innymi:

• strona nie spełnia wszystkich wytycznych,
• dane są niekompletne,
• dane nie odpowiadają widocznej treści,
• wynik rozszerzony nie pasuje do danego zapytania,
• wyszukiwarka wybiera inny sposób prezentacji,
• dany typ prezentacji nie jest dostępny w konkretnym kontekście.

Dlatego wdrożenie należy oceniać pod kątem poprawności technicznej, a nie wyłącznie tego, czy przy jednym wyszukiwaniu pojawił się specjalny element.

Wymagane i zalecane właściwości

Dokumentacja konkretnych rodzajów danych może rozróżniać pola wymagane i zalecane.

Wymagane są potrzebne, aby określony obiekt mógł spełnić podstawowe kryteria danego zastosowania.

Zalecane mogą dostarczać dodatkowego kontekstu.

Nie należy jednak automatycznie wpisywać zmyślonych wartości tylko po to, żeby wypełnić większą liczbę pól.

Lepiej nie przekazać informacji niż przekazać informację nieprawdziwą.

Walidacja danych strukturalnych

Po wdrożeniu dane trzeba przetestować.

Nie wystarczy zobaczyć w kodzie słowo Schema i uznać, że wszystko działa.

Walidacja powinna sprawdzić:

• czy struktura jest poprawna,
• czy wymagane właściwości istnieją,
• czy typ danych jest właściwy,
• czy wartości mają odpowiedni format,
• czy nie występują sprzeczne obiekty.

Rich Results Test

Google udostępnia narzędzie pozwalające testować dane związane z obsługiwanymi wynikami rozszerzonymi.

Można sprawdzić konkretny adres albo fragment kodu.

Narzędzie może wskazać:

• wykryte typy danych,
• błędy,
• ostrzeżenia,
• problemy z właściwościami.

Brak błędu oznacza, że wdrożenie jest technicznie poprawniejsze, ale nadal nie stanowi gwarancji wyświetlenia rich result.

Schema Markup Validator

Istnieją również narzędzia służące do sprawdzania poprawności danych względem słownika Schema.org.

To nie jest dokładnie to samo co test kwalifikacji do konkretnych funkcji Google.

Ponownie widać tutaj różnicę pomiędzy:

• poprawnym Schema.org,
• obsługą danego typu przez konkretną wyszukiwarkę.

Dane strukturalne w Google Search Console

Google Search Console może pokazywać raporty związane z wybranymi rodzajami elementów rozszerzonych wykrytych w serwisie.

Można dzięki temu monitorować:

• liczbę poprawnych elementów,
• problemy,
• zmiany po wdrożeniach,
• błędy pojawiające się na wielu stronach.

Jest to szczególnie przydatne przy sklepach posiadających tysiące kart produktów.

Jedna poprawka może dotyczyć tysięcy stron

Dane strukturalne są często generowane przez szablon.

Jeżeli szablon produktu posiada błąd, problem może występować na wszystkich produktach jednocześnie.

To samo działa w drugą stronę.

Poprawienie generatora Schema może naprawić tysiące stron bez ręcznej edycji każdej z nich.

Dane strukturalne generowane automatycznie

W dużym serwisie praktycznie nie da się utrzymywać Schema ręcznie.

Dane powinny wynikać z rzeczywistych informacji zapisanych w systemie.

Przykładowo:

• nazwa Schema pochodzi z nazwy produktu,
• cena z aktualnej ceny WooCommerce,
• dostępność ze stanu produktu,
• SKU z pola SKU,
• marka z odpowiedniej cechy.

Dzięki temu zmiana produktu automatycznie aktualizuje jego opis strukturalny.

Największe zagrożenie automatyzacji

Jeżeli dane źródłowe są złe, automatyzacja powiela błąd na dużą skalę.

Przykładowo jeżeli pole marki jest wykorzystywane niezgodnie z przeznaczeniem, Schema może automatycznie generować błędnego producenta dla tysięcy produktów.

Dlatego przed automatyzacją trzeba uporządkować model danych.

Duplikaty Schema

Jednym z częstszych problemów w WordPressie jest generowanie tych samych danych przez kilka narzędzi.

Można wtedy znaleźć na jednej stronie kilka obiektów:

• Organization,
• Product,
• BreadcrumbList.

Sam fakt istnienia kilku obiektów nie jest błędem.

Problem pojawia się, gdy opisują ten sam element w sprzeczny sposób.

Dwie różne ceny w Schema

Wyobraźmy sobie kartę produktu.

WooCommerce generuje cenę 299 zł.

Wtyczka SEO generuje drugi Product z ceną 349 zł.

Motyw dokłada trzeci zestaw danych.

Wyszukiwarka otrzymuje kilka wersji prawdy.

W takim przypadku dodanie kolejnej wtyczki „do Schema” zazwyczaj pogarsza sytuację zamiast ją naprawiać.

Dane strukturalne a JavaScript

Dane mogą być również generowane dynamicznie.

Trzeba jednak sprawdzić, czy robot rzeczywiście otrzymuje końcową prawidłową strukturę oraz czy wartości pojawiają się odpowiednio szybko i konsekwentnie.

Jeżeli kluczowe dane można wygenerować bezpośrednio przy tworzeniu dokumentu, rozwiązanie jest zwykle bardziej przewidywalne.

Schema po stronie serwera

Generowanie danych na serwerze posiada ważną zaletę: są dostępne już w otrzymanym dokumencie.

Nie trzeba czekać na dodatkowy kod JavaScript, który dopiero zbuduje strukturę.

W przypadku produktów i innych danych pochodzących bezpośrednio z backendu jest to często najbardziej naturalne rozwiązanie.

Dane strukturalne a API

W bardziej złożonym systemie wartości używane w Schema mogą pochodzić z wielu źródeł.

Przykładowo:

• produkt z PIM,
• cena z ERP,
• stan z magazynu,
• opinie z zewnętrznego systemu.

Strona musi połączyć te informacje w jeden spójny obraz produktu.

Jeżeli integracje działają z opóźnieniem, również dane strukturalne mogą stać się nieaktualne.

Schema nie naprawia złej treści

Dane strukturalne są opisem zawartości.

Nie zastępują jej.

Dodanie Article nie sprawi, że słaby artykuł stanie się wartościowy.

Dodanie Product nie naprawi karty produktu bez opisu, parametrów i zdjęć.

Dodanie LocalBusiness nie zastąpi poprawnych informacji o firmie.

Schema wzmacnia czytelność struktury dla maszyn, ale nie tworzy jakości tam, gdzie jej nie ma.

Schema nie jest magicznym czynnikiem rankingowym

Nie warto traktować danych strukturalnych jako prostego sposobu:

„dodam Schema i będę wyżej”.

Ich podstawową funkcją jest lepsze opisanie treści i umożliwienie kwalifikacji do określonych sposobów prezentacji.

Na widoczność wpływa znacznie szerszy zestaw czynników związanych z:

• treścią,
• autorytetem,
• architekturą,
• linkowaniem,
• indeksowaniem,
• jakością techniczną.

Czy rich result zwiększa CTR?

Bardziej rozbudowany wynik może być dla użytkownika bardziej zauważalny i przekazywać więcej informacji jeszcze przed kliknięciem.

Może to wpływać na współczynnik klikalności, ale nie istnieje gwarancja, że każdy rich result zwiększy CTR.

Przykładowo pokazanie ceny może:

• zachęcić użytkownika, jeśli oferta jest atrakcyjna,
• zniechęcić go jeszcze przed wejściem, jeśli cena nie odpowiada jego oczekiwaniom.

Z biznesowego punktu widzenia nie zawsze jest to złe.

Użytkownik otrzymuje bardziej precyzyjną informację jeszcze przed wejściem na stronę.

CTR a jakość ruchu

Nie zawsze celem jest maksymalna liczba kliknięć.

Lepszym wynikiem może być mniejsza liczba wejść, ale od użytkowników rzeczywiście zainteresowanych ofertą.

Jeżeli cena widoczna w wyniku eliminuje osoby szukające znacznie tańszego produktu, ogranicza niepotrzebny ruch.

Dane strukturalne a AI

Rosnąca rola systemów automatycznie interpretujących treść powoduje, że uporządkowane informacje mają znaczenie wykraczające poza klasyczny niebieski link w wyszukiwarce.

Nie należy jednak traktować Schema jako specjalnego przełącznika:

„włącz widoczność w AI”.

Systemy analizują znacznie więcej elementów strony.

Dane strukturalne pomagają jednoznacznie opisywać obiekty i relacje, ale nie zastępują dobrej treści i poprawnej technicznie witryny.

Schema a plik dla AI

Dane strukturalne są częścią samego dokumentu i opisują jego znaczenie.

Nie należy mylić ich z dodatkowymi plikami przeznaczonymi dla określonych crawlerów lub narzędzi AI.

Jeżeli chcę powiedzieć systemowi:

„ta liczba jest ceną produktu”,

Schema jest znacznie bardziej bezpośrednim sposobem niż tworzenie osobnego tekstowego dokumentu streszczającego stronę.

Najczęstszy błąd: Schema nie odpowiada stronie

Produkt kosztuje 499 zł, ale dane pokazują 399 zł.

Firma zmieniła telefon, ale Organization nadal posiada stary numer.

Wydarzenie zostało odwołane, ale Event pozostaje niezmieniony.

Dane strukturalne powinny żyć razem z właściwą treścią.

Najczęstszy błąd: fikcyjne recenzje

Firma dodaje sobie pięć gwiazdek bez rzeczywistych opinii użytkowników.

To nie jest optymalizacja techniczna.

To przekazywanie wyszukiwarce informacji, które nie odpowiadają rzeczywistości.

Najczęstszy błąd: oznaczanie wszystkiego

Więcej Schema nie oznacza automatycznie lepszego SEO.

Nie ma potrzeby oznaczania każdego zdania dziesiątkami typów tylko dlatego, że istnieją w Schema.org.

Dane powinny opisywać rzeczywiste, istotne obiekty znajdujące się na stronie.

Najczęstszy błąd: instalowanie kilku wtyczek Schema

Każda obiecuje lepsze dane strukturalne.

Po instalacji czterech narzędzi strona może generować cztery wersje tego samego obiektu.

Zanim dołożę kolejne rozwiązanie, sprawdzam najpierw, co już znajduje się w kodzie.

Najczęstszy błąd: test tylko strony głównej

Strona główna może posiadać poprawne Organization, ale błędy występują na produktach.

W dużym serwisie trzeba testować reprezentatywne typy dokumentów:

• stronę główną,
• produkt prosty,
• produkt wariantowy,
• kategorię,
• artykuł,
• stronę kontaktową,
• inne ważne szablony.

Najczęstszy błąd: sprawdzenie tylko jednego produktu

Produkt testowy może być poprawny, ale setki innych posiadają brakujące:

• ceny,
• SKU,
• identyfikatory,
• zdjęcia.

W dużym sklepie potrzebna jest analiza na poziomie całego zbioru, nie tylko pojedynczego przykładu.

Najczęstszy błąd: ignorowanie ostrzeżeń

Nie każde ostrzeżenie oznacza krytyczny błąd.

Może jednak wskazywać brak wartościowej informacji.

Nie należy więc ani panikować przy każdym warningu, ani ignorować wszystkich bez sprawdzenia.

Trzeba ustalić, czego dokładnie dotyczy komunikat.

Najczęstszy błąd: poprawianie Schema bez poprawienia źródła

Jeżeli WooCommerce posiada błędną cenę albo produkt ma nieprawidłowy EAN, można próbować ręcznie poprawić JSON-LD.

To leczenie objawu.

Lepszym rozwiązaniem jest poprawienie danych źródłowych i sposobu ich generowania.

Dane strukturalne a EAN i GTIN

Jednoznaczne identyfikatory produktów są bardzo wartościowe w e-commerce.

Pomagają określić, jaki dokładnie produkt jest opisywany.

Nie należy jednak zgadywać identyfikatora ani kopiować go z podobnego produktu.

Błędny GTIN jest gorszy niż brak identyfikatora.

Marka a producent

To kolejne pola, które bywają mylone.

Marka widoczna dla klienta nie zawsze jest tożsama z prawnym producentem albo sprzedawcą.

Model danych powinien rozróżniać te pojęcia, jeżeli w danym katalogu mają inne znaczenie.

Schema a marketplace

Jeżeli produkt jest prezentowany we własnym sklepie, dane opisują ofertę dostępną właśnie na tej stronie.

Nie należy automatycznie kopiować informacji z marketplace bez sprawdzenia, czy:

• cena jest identyczna,
• dostępność jest identyczna,
• wariant jest ten sam,
• sprzedawca jest ten sam.

Każdy kanał może posiadać inny kontekst oferty.

Dane strukturalne a cache

Cache może spowodować, że widoczna strona albo dane strukturalne pozostają nieaktualne po zmianie produktu.

Jeżeli cena zmienia się często, warto sprawdzić cały proces:

1. zmiana danych w sklepie,
2. generowanie dokumentu,
3. cache strony,
4. cache CDN,
5. końcowy kod widoczny dla robota.

Problem nie zawsze znajduje się w samej warstwie Schema.

Dane strukturalne a CDN

Podobnie jak przy zwykłym HTML, warstwa CDN może przechowywać starszą wersję dokumentu.

Po krytycznej zmianie warto sprawdzić rzeczywisty kod dostępny publicznie, a nie wyłącznie podgląd w panelu CMS.

Schema a wersja mobilna

Jeżeli serwis generuje różne wersje treści zależnie od urządzenia, dane powinny pozostawać spójne z właściwą zawartością.

W responsywnych stronach ten problem występuje rzadziej, ponieważ ten sam dokument dostosowuje się wizualnie do ekranu.

Dane strukturalne a strony wielojęzyczne

Każda wersja językowa powinna opisywać właściwą wersję strony.

Nazwa organizacji może pozostać taka sama, ale:

• opis,
• adres URL,
• oferta,
• waluta,
• inne informacje

mogą zależeć od rynku.

Dane strukturalne a wiele walut

Sklepy międzynarodowe mogą prezentować różne ceny i waluty.

Schema powinno odpowiadać ofercie faktycznie prezentowanej pod konkretnym adresem i w określonym modelu strony.

Nie wystarczy wpisać jednej domyślnej ceny we wszystkich wersjach.

Dane strukturalne a canonical

Canonical wskazuje preferowany adres dokumentu.

Dane strukturalne opisują jego zawartość.

Oba elementy powinny być logicznie spójne.

Jeżeli kilka adresów jest wariantami tego samego dokumentu, trzeba uważać, żeby Schema nie sugerowało kilku sprzecznych obiektów przy jednoczesnym wskazywaniu jednego canonicala.

Dane strukturalne a noindex

Można technicznie posiadać Schema na stronie oznaczonej noindex.

Jeżeli jednak dokument nie ma znajdować się w wynikach wyszukiwania, oczekiwanie rich result dla tej strony jest wewnętrznie sprzeczne.

Najpierw trzeba ustalić rolę konkretnego adresu.

Dane strukturalne a robots.txt

Jeżeli robot nie może pobrać strony z powodu blokady w robots.txt, nie może normalnie analizować znajdujących się w niej danych.

Dlatego nie powinno się jednocześnie blokować ważnej podstrony i oczekiwać pełnego wykorzystania jej danych strukturalnych.

Dane strukturalne a sitemap XML

Sitemap pomaga wyszukiwarce odkrywać właściwe adresy.

Schema pomaga lepiej zrozumieć ich zawartość.

Mechanizmy te uzupełniają się, ale nie zastępują.

Schema a architektura strony

Dane strukturalne mogą opisywać relacje, ale nie naprawiają źle zaprojektowanej architektury.

Jeżeli produkt jest przypisany do przypadkowych kategorii, breadcrumb jest chaotyczny, a adresy generują duplikaty, idealny JSON-LD nie rozwiąże tych problemów.

Jak sprawdzam dane strukturalne?

Przy analizie nie ograniczam się do pytania:

„czy jest Schema?”

Sprawdzam:

1. jakie obiekty są generowane,
2. który system je tworzy,
3. czy występują duplikaty,
4. czy wartości odpowiadają treści,
5. czy wymagane dane są kompletne,
6. czy struktura odpowiada typowi strony,
7. czy rozwiązanie działa na wielu reprezentatywnych adresach.

To część szerszej analizy wykonywanej przeze mnie w ramach SEO technicznego.

Audyt danych strukturalnych w sklepie

W e-commerce warto sprawdzić przynajmniej:

• produkty proste,
• produkty wariantowe,
• produkty promocyjne,
• produkty niedostępne,
• produkty bez opinii,
• produkty z opiniami,
• kategorie,
• stronę główną.

Każdy przypadek może wygenerować trochę inną strukturę.

Test po aktualizacji wtyczek

Aktualizacja WooCommerce, motywu albo wtyczki SEO może zmienić sposób generowania Schema.

Nie oznacza to, że trzeba kontrolować ręcznie każdy update.

Przy większym sklepie warto jednak okresowo sprawdzać najważniejsze szablony, szczególnie po dużych zmianach technologicznych.

Monitoring błędów

Jeżeli serwis posiada tysiące stron, ręczne testowanie każdej z nich jest nierealne.

Potrzebne są narzędzia pozwalające wykrywać wzorce problemów.

Przykładowo nagły wzrost błędów Product po wdrożeniu może wskazywać na problem w jednym wspólnym szablonie.

Dane strukturalne w dedykowanych systemach

Własny CMS lub aplikacja nie posiada automatycznie ograniczeń typowych dla WordPressa.

Można zaprojektować generowanie danych bezpośrednio jako część modelu treści.

Przykładowo podczas tworzenia wydarzenia administrator podaje:

• nazwę,
• datę,
• lokalizację,
• organizatora.

Te same dane mogą być użyte jednocześnie:

• w widoku strony,
• w API,
• w danych strukturalnych.

To znacznie bezpieczniejsze niż ręczne przepisywanie tych samych informacji do kilku miejsc.

Jedno źródło prawdy

Najlepszy model polega na tym, że konkretna informacja istnieje w systemie tylko raz jako dane źródłowe.

Przykładowo cena produktu pochodzi z jednego miejsca.

Z tej wartości korzystają:

• karta produktu,
• koszyk,
• API,
• feed produktowy,
• Schema.

Jeżeli każda warstwa posiada własną ręcznie wpisaną cenę, rozbieżności są tylko kwestią czasu.

Schema a automatyzacja treści

Automatyczne generowanie stron powinno obejmować również poprawne generowanie danych strukturalnych.

Jeżeli system tworzy tysiące podstron produktów, wydarzeń lub lokalizacji, nie można później ręcznie dodawać Schema do każdej z nich.

Model powinien być częścią architektury aplikacji.

Dane strukturalne a strony statyczne

Strona statyczna może posiadać dokładnie takie same dane strukturalne jak WordPress.

Schema nie wymaga konkretnego CMS.

Może zostać wygenerowane podczas budowania statycznego HTML i znaleźć się od razu w gotowym dokumencie.

To bardzo czyste rozwiązanie, ponieważ robot otrzymuje pełną strukturę razem z pierwszą odpowiedzią serwera.

Schema a headless CMS

W architekturze headless dane pochodzą z CMS, ale warstwa frontendowa sama tworzy dokument.

Trzeba wtedy świadomie zaprojektować również sposób generowania danych strukturalnych.

CMS może przechowywać informacje, ale frontend odpowiada za ich prawidłowe odwzorowanie w finalnym HTML.

Elementy rozszerzone nie są stałe na zawsze

Wyszukiwarki rozwijają sposób prezentowania wyników.

Niektóre typy rozszerzeń mogą się pojawiać, zmieniać albo przestać być wykorzystywane.

Dlatego nie warto projektować całej strategii SEO wokół jednego konkretnego elementu wizualnego.

Znacznie bardziej trwałym podejściem jest poprawne opisywanie rzeczywistej treści oraz utrzymywanie danych zgodnych z aktualnym stanem strony.

Nie kopiuj starego poradnika bez sprawdzenia

Artykuł dotyczący rich results sprzed kilku lat może opisywać rozwiązania, które zmieniły się od momentu publikacji.

Przed wdrożeniem konkretnego typu zawsze warto sprawdzić aktualne wymagania wyszukiwarki.

Dotyczy to szczególnie:

• obsługiwanych typów,
• wymaganych pól,
• zalecanych właściwości,
• zasad kwalifikacji.

Schema.org również się rozwija

Sam słownik Schema.org nie jest zamkniętym dokumentem, który raz zdefiniowano i pozostawiono bez zmian.

Pojawiają się nowe właściwości i typy, a istniejące mogą być rozwijane.

Dlatego przy dużych projektach warto traktować dane strukturalne jak element technologii wymagający okresowej kontroli.

Czy każda strona potrzebuje rozbudowanego Schema?

Nie.

Prosta podstrona tekstowa nie musi posiadać kilkunastu obiektów tylko po to, żeby kod wyglądał bardziej zaawansowanie.

Najpierw trzeba ustalić, jakie rzeczywiste obiekty znajdują się na stronie.

W wielu przypadkach wystarczy poprawnie opisana:

• organizacja,
• strona internetowa,
• breadcrumb,
• główny typ treści.

Więcej danych nie zawsze oznacza lepiej

Schema powinno być precyzyjne.

Dodanie dwudziestu przypadkowych typów może utrudnić zrozumienie struktury zamiast je poprawić.

Podobnie jak w kodzie strony, prostota i jednoznaczność są zaletą.

Co najpierw: treść czy Schema?

Najpierw powinien istnieć prawidłowy model treści.

Przykładowo produkt powinien posiadać:

• dobrą nazwę,
• cenę,
• dostępność,
• identyfikatory,
• opis.

Dopiero później opisuję te informacje w strukturze maszynowej.

Jeżeli dane źródłowe są niepełne, Schema jedynie ujawni ten problem.

Rich results a użytkownik

Element rozszerzony jest przede wszystkim częścią wyników wyszukiwania widzianą przez użytkownika.

Powinien pomagać mu szybciej ocenić, czy wynik odpowiada jego potrzebie.

Może zobaczyć na przykład:

• cenę,
• ocenę,
• termin wydarzenia,
• inne informacje charakterystyczne dla treści.

W tym sensie dane strukturalne łączą SEO techniczne z doświadczeniem użytkownika jeszcze przed wejściem na stronę.

Rich results a marka

Bardziej jednoznaczna prezentacja wyników może również poprawić rozpoznawalność i wiarygodność serwisu.

Nie powinno się jednak próbować uzyskać tego efektu przez sztuczne dane.

Najlepszy wynik jest konsekwencją dobrze uporządkowanej strony, a nie manipulowania oznaczeniami.

Jak wdrożyć dane strukturalne poprawnie?

Proces warto podzielić na kilka etapów.

1. Ustal typ strony.
2. Określ rzeczywiste dane znajdujące się w systemie.
3. Sprawdź odpowiedni typ Schema.
4. Sprawdź wymagania konkretnego zastosowania w wyszukiwarce.
5. Wygeneruj dane z prawdziwych wartości.
6. Przetestuj wynik.
7. Sprawdź kilka różnych typów podstron.
8. Monitoruj błędy po wdrożeniu.

W dużym serwisie warto od początku projektować generowanie automatyczne.

Co sprawdzić przed dodaniem kolejnej wtyczki?

Zanim zainstaluję rozwiązanie obiecujące „pełne Schema”, najpierw sprawdzam:

• co generuje obecny CMS,
• co generuje motyw,
• co generuje wtyczka SEO,
• jakie dane są już dostępne,
• czego rzeczywiście brakuje.

Bardzo często problemem nie jest brak Schema, ale jego nadmiar.

Kiedy potrzebny jest indywidualny kod?

Gotowe rozwiązania dobrze obsługują standardowe przypadki.

Dedykowane wdrożenie może być potrzebne, gdy:

• strona posiada własny typ danych,
• produkty mają nietypową strukturę,
• dane pochodzą z kilku systemów,
• standardowa wtyczka generuje nieprawidłowe informacje,
• serwis wykorzystuje własny CMS lub frontend.

Wtedy najważniejsze jest poprawne odwzorowanie modelu danych, a nie dokładanie kolejnych ręcznych wyjątków.

Jak rozpoznać dobre wdrożenie?

Dobre dane strukturalne są przede wszystkim spójne.

Jeżeli patrzę na stronę produktu, informacje dla użytkownika i informacje maszynowe opisują ten sam produkt.

Nie ma:

• kilku sprzecznych cen,
• fikcyjnych ocen,
• starej dostępności,
• przypadkowych typów,
• kilku konkurujących ze sobą obiektów tego samego rodzaju.

Struktura wynika bezpośrednio z danych serwisu.

Co warto zapamiętać o elementach rozszerzonych?

Wyniki z elementami rozszerzonymi, czyli rich results, to specjalne sposoby prezentowania informacji w wyszukiwarce.

Ich podstawą mogą być dane strukturalne opisujące znaczenie treści strony w sposób zrozumiały dla systemów komputerowych.

Schema.org jest słownikiem pojęć wykorzystywanych do opisywania obiektów takich jak produkty, organizacje, wydarzenia, artykuły czy breadcrumbs. Nie każdy typ Schema posiada jednak odpowiadający mu specjalny wynik w Google.

Poprawne dane strukturalne zwiększają możliwość wykorzystania strony w odpowiednim formacie, ale nie gwarantują, że wyszukiwarka pokaże rich result przy każdym zapytaniu.

Najważniejsza jest zgodność danych z rzeczywistą zawartością strony. Cena, dostępność, ocena, autor czy termin wydarzenia nie mogą istnieć wyłącznie w warstwie przeznaczonej dla robotów.

W dużych sklepach i serwisach dane strukturalne najlepiej generować automatycznie z jednego źródła prawdy. Dzięki temu zmiana ceny produktu, jego dostępności albo innych informacji aktualizuje jednocześnie widok użytkownika i strukturę maszynową.

Rich results warto więc traktować nie jako sztuczkę SEO, lecz jako rezultat dobrze uporządkowanych danych, poprawnej semantyki i technicznie spójnej strony internetowej.