Co to są mikrodane (Schema.org) i jak wpływają na wygląd wyników wyszukiwania?

Dane, które czyta maszyna, nie człowiek

Baner wejsciowyParallax

Co to są mikrodane (Schema.org) i jak wpływają na wygląd wyników wyszukiwania?

Dane, które czyta maszyna, nie człowiek

Autor nie posiada zdjęcia
Tomasz Piasecki
30 czerwca 2021

Wyniki wyszukiwania od kilku lat nie są już listą dziesięciu niebieskich odnośników. Jedne pozycje mają gwiazdki z oceną, inne cenę i informację o dostępności, jeszcze inne rozwijaną listę pytań albo zdjęcie z czasem przygotowania.

Te dodatki nie pojawiają się przypadkiem. Google potrzebuje jednoznacznej informacji o tym, czym jest treść na stronie, i człowiek czytający tekst wie to od razu, a program niekoniecznie. Dane strukturalne są sposobem powiedzenia tego wprost, w formacie przewidzianym do odczytu maszynowego.

Warto od początku ustawić właściwe oczekiwania. Wdrożenie danych strukturalnych nie podnosi pozycji. Zmienia natomiast wygląd wyniku, a przez to jego klikalność — i to jest realny, mierzalny zysk.

Czym jest Schema.org i skąd się wzięło

Schema.org to wspólny słownik pojęć opracowany przez największe wyszukiwarki. Definiuje typy obiektów — produkt, przepis, wydarzenie, firma lokalna, artykuł — i właściwości, jakie każdy z nich może mieć.

Sam słownik nie jest formatem zapisu. Do zapisania go na stronie służą trzy sposoby: mikrodane wplecione w atrybuty znaczników HTML, format RDFa oraz JSON-LD, czyli osobny blok danych umieszczany w kodzie strony.

Google od dawna rekomenduje JSON-LD i ja też przy nim zostaję. Powód jest praktyczny: to jeden blok, który da się dodać, zmienić albo usunąć bez dotykania szablonu wyświetlanej treści. Mikrodane wymagają wplecenia atrybutów w konkretne znaczniki, więc każda zmiana wyglądu strony grozi ich uszkodzeniem — i regularnie do tego dochodzi.

Nazwa „mikrodane” bywa używana potocznie na wszystkie dane strukturalne i tak też ją tu traktuję, ale techniczne rozróżnienie warto znać, bo pojawia się w dokumentacji.

Typy, które wdrażam najczęściej

Nie wdrażam wszystkiego, co da się wdrożyć. Wybieram to, co odpowiada realnej treści strony i ma szansę zmienić wygląd wyniku.

  • Produkt — z ceną, walutą, dostępnością i oceną. Podstawa dla sklepu, bo cena i dostępność widoczne w wynikach wyraźnie wpływają na klikalność.
  • Firma lokalna — adres, telefon, godziny otwarcia, obszar obsługi. Porządkuje dane o firmie i wspiera wyniki lokalne.
  • Ścieżka nawigacyjna — zamienia adres w wyniku na czytelną ścieżkę kategorii. Prosta w implementacji i przydatna szczególnie w sklepach o głębokiej strukturze.
  • Lista pytań i odpowiedzi — potrafi rozbudować wynik o rozwijane pozycje, przez co zajmuje więcej miejsca na ekranie.
  • Artykuł — autor, data publikacji, nagłówek. Nie daje spektakularnych efektów wizualnych, ale porządkuje interpretację treści blogowych.
  • Wydarzenie, przepis, oferta pracy, kurs — typy dla konkretnych branż, gdzie efekt w wynikach bywa najbardziej widoczny.

Kolejność wdrożenia zależy od tego, czym jest serwis. W sklepie zaczynam od produktu i ścieżki nawigacyjnej. W firmie usługowej — od danych firmy lokalnej i sekcji pytań.

Czego dane strukturalne nie zrobią

Powtórzę, bo to najczęstsze nieporozumienie: to nie czynnik rankingowy. Wdrożenie znaczników nie przeniesie strony z drugiej strony wyników na pierwszą.

Druga rzecz: obecność znaczników nie gwarantuje, że dodatki w wyniku się pokażą. Google decyduje o tym samodzielnie, biorąc pod uwagę typ zapytania, urządzenie i to, czy uznaje dane za wiarygodne. Poprawnie wdrożone znaczniki są warunkiem koniecznym, nie wystarczającym.

Trzecia: dane muszą opisywać to, co widzi użytkownik na stronie. Ocena w znacznikach bez widocznej oceny na stronie, cena inna niż wyświetlana, pytania i odpowiedzi, których na stronie nie ma — to naruszenia wytycznych. Konsekwencją bywa utrata wszystkich rozszerzeń dla domeny, nie tylko tego jednego, a przywrócenie wymaga zgłoszenia i czekania.

Trafiam na tę pokusę regularnie. Ktoś dowiaduje się, że gwiazdki podnoszą klikalność, więc wpisuje ocenę pięć na pięć przy każdym produkcie, choć nikt żadnej opinii nie wystawił. To działa, dopóki nie przestanie działać dla całego serwisu.

Wdrożenie w praktyce

Sposób zależy od tego, na czym stoi strona.

W popularnych systemach zarządzania treścią i platformach sklepowych część znaczników generuje się sama albo z pomocą wtyczek. Warto to sprawdzić przed jakąkolwiek pracą, bo najczęstszym problemem, jaki znajduję, nie jest brak danych, ale ich zdublowanie — dwie wtyczki opisujące tę samą stronę różnymi wartościami.

Przy własnych rozwiązaniach blok danych generuje się na serwerze razem ze stroną. Zwracam uwagę, żeby dane pochodziły z tego samego źródła co treść wyświetlana, a nie były wpisane osobno — inaczej rozjadą się przy pierwszej zmianie oferty.

Osobna sprawa to wstrzykiwanie znaczników skryptem po stronie przeglądarki, na przykład przez menedżera tagów. Technicznie jest możliwe i Google zwykle je odczyta, ale traktuję to jako rozwiązanie zastępcze na czas, gdy zmiana w szablonie jest niedostępna. Zależność od wykonania skryptu dodaje punkt awarii tam, gdzie nie musi go być.

Jak sprawdzać poprawność

Nie zostawiam wdrożenia bez weryfikacji, bo błędy w danych strukturalnych są niewidoczne dla użytkownika i mogą trwać latami.

Do sprawdzenia pojedynczej strony służy narzędzie testowe Google dla wyników z elementami rozszerzonymi. Pokazuje, jakie typy zostały rozpoznane, jakie właściwości są uzupełnione i co jest błędem, a co tylko ostrzeżeniem. Ostrzeżenia dotyczą zwykle właściwości zalecanych, ale nieobowiązkowych — warto je uzupełniać, bo zwiększają szansę na wyświetlenie rozszerzenia.

Do obserwacji całego serwisu służą raporty w Search Console, osobne dla każdego typu znaczników. Tam widać skalę: ile adresów jest poprawnych, ile ma błędy i czy liczba błędów rośnie. Sprawdzam je po każdym większym wdrożeniu na stronie, bo zmiana szablonu potrafi wywrócić dane strukturalne bez żadnego innego objawu.

Warto też patrzeć na dane o klikalności w podziale na strony przed i po wdrożeniu. To jedyny sposób, żeby ocenić, czy praca coś dała — pozycje się nie zmienią, więc wzrostu trzeba szukać w liczbie kliknięć przy tej samej liczbie wyświetleń.

Błędy, które spotykam najczęściej

Kilka powtarzalnych usterek z audytów.

Znaczniki opisujące szablon, nie treść: ta sama nazwa produktu i ta sama cena na wszystkich kartach, bo dane zostały wpisane na sztywno w szablonie zamiast pobrane z bazy.

Brak wymaganych właściwości. Produkt bez ceny albo bez informacji o dostępności bywa uznany za niekompletny i nie kwalifikuje się do rozszerzenia, choć znacznik formalnie istnieje.

Dane strukturalne na stronie zablokowanej przed indeksowaniem albo z wskazaniem kanonicznym na inny adres. Wysiłek wkładany w opis strony, której Google nie zamierza pokazywać.

Nieaktualne typy i właściwości. Słownik się zmienia, Google wycofuje obsługę części rozszerzeń, a wtyczki nie zawsze za tym nadążają. Raz na jakiś czas warto sprawdzić, czy to, co wdrożono dwa lata temu, jest jeszcze obsługiwane.

I ostatnia, najbardziej ludzka: wdrożenie znaczników jako zamiennika pracy nad treścią. Dane strukturalne pomagają stronie, która i tak jest dobra. Nie zastąpią odpowiedzi na zapytanie użytkownika.

Podziel się tym artykułem z innymi!

Twitter Facebook Linke.din
Autor nie posiada zdjęcia
Tomasz Piasecki
Specjalista Google Ads / SEM
Zajmuję się kampaniami Google Ads i widocznością stron w wyszukiwarce. Na blogu UDI Group piszę o tym, jak ustawienia kampanii i decyzje techniczne przekładają się na realne wyniki. Staram się tłumaczyć mechanizmy, a nie tylko podawać gotowe przepisy.