Modelowane listy odbiorców nie zawierają konkretnych osób, tylko prawdopodobieństwa. Wyjaśniam, jak powstają, gdzie ich szukać w panelu i jak czytać ich raporty.
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.
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.
Nie wdrażam wszystkiego, co da się wdrożyć. Wybieram to, co odpowiada realnej treści strony i ma szansę zmienić wygląd wyniku.
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ń.
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.
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ć.
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ń.
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.
Używamy plików cookies, aby ułatwić Ci nawigację oraz wykonywanie określonych funkcji. Szczegółowe informacje o wszystkich plikach cookies znajdziesz w każdej kategorii zgody poniżej.
Pliki cookies oznaczone jako "Niezbędne" są przechowywane w Twojej przeglądarce, ponieważ są one kluczowe dla zapewnienia podstawowych funkcji strony.
Używamy również plików cookies firm trzecich, które pomagają nam analizować, w jaki sposób korzystasz z tej strony, zapamiętują Twoje preferencje oraz dostarczają treści i reklamy odpowiednie dla Ciebie. Te pliki cookies będą przechowywane w Twojej przeglądarce tylko za Twoją uprzednią zgodą.
Możesz zdecydować, czy chcesz włączyć lub wyłączyć niektóre bądź wszystkie te pliki cookies, jednak wyłączenie niektórych z nich może wpłynąć na Twoje doświadczenia podczas przeglądania strony.
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| __cf_bm | 13 minutes | Cloudflare bot management — distinguishes humans from bots. |
| rc::* | Persistent | Google reCAPTCHA — localStorage holding anti-bot challenge state. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| wpEmojiSettingsSupports | Session | WordPress — sessionStorage flag caching whether the browser can render emoji (feature detection). |
| ytidb* | Persistent | YouTube — IndexedDB storing playback/search state for embedded videos. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| _ga_* | 400 days | Google Analytics 4 — persists session state per property. |
| _ga | 400 days | Google Analytics — distinguishes unique users via a client id. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| NID | 183 days | Google — stores preferences for personalized ads. |
| fr | 90 days | Meta — encrypted Facebook id and browser id for ads. |
| _gcl_au | 90 days | Google AdSense/Ads — experiments with advertising efficiency (conversion linker). |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| __Secure-YNID | 180 days | |
| YSC | Session | |
| __Secure-ROLLOUT_TOKEN | 180 days | |
| VISITOR_INFO1_LIVE | 180 days | |
| VISITOR_PRIVACY_METADATA | 180 days | |
| datr | 400 days | |
| sb | 400 days | |
| wd | 7 days |