Co znaczy „natychmiastowy odczyt"

Rozbijmy to na coś sprawdzalnego, bo samo hasło niewiele znaczy.

Dane są odczytywalne natychmiast, kiedy trafiają do odbiorcy w pierwszej odpowiedzi serwera, bez konieczności uruchamiania czegokolwiek. To jest cała definicja i jednocześnie największy problem współczesnych wdrożeń: bardzo dużo znaczników jest dokładanych po stronie klienta, przez skrypt lub przez menedżera tagów.

Googlebot renderuje strony i taki znacznik zwykle zobaczy — z opóźnieniem, ale zobaczy. Kłopot jest w tym, że Googlebot przestał być jedynym odbiorcą. Crawlery, które zasilają odpowiedzi generatywne, bardzo różnią się między sobą tym, na ile potrafią i chcą wykonywać JavaScript. Część po prostu pobiera dokument. Jeżeli Twoje dane strukturalne żyją w skrypcie, dla części odbiorców one nie istnieją.

Stąd pierwsza reguła, którą stosuję bez wyjątków: JSON-LD wychodzi z serwera razem z HTML-em. Wstrzykiwanie znaczników przez menedżera tagów traktuję jako rozwiązanie awaryjne na czas, gdy dział IT nie ma wolnych rąk, a nie jako architekturę. Sprawdzenie jest banalne — podglądam źródło strony bez renderowania i patrzę, czy blok tam jest.

Jeden graf zamiast rozsypanych wysepek

Typowa strona sklepu ma dziś kilka osobnych bloków JSON-LD: jeden od motywu, jeden od wtyczki SEO, jeden od wtyczki opinii, czasem jeszcze jeden dorzucony ręcznie. Każdy jest formalnie poprawny. Razem nie tworzą żadnej całości.

Maszyna dostaje wtedy zbiór niepowiązanych obiektów i musi sama zgadnąć, że firma z jednego bloku i sprzedawca z drugiego to ta sama organizacja. Czasem zgadnie. Częściej po prostu potraktuje je jako niezależne byty i skorzysta z tego, który wygląda kompletniej.

Rozwiązaniem jest jeden blok z tablicą powiązanych obiektów i jawnymi identyfikatorami. Każdy obiekt dostaje własny, stały identyfikator w postaci adresu URL z fragmentem, a pozostałe obiekty odwołują się do niego przez ten identyfikator, zamiast powtarzać jego zawartość. Organizacja jest opisana raz, w jednym miejscu w serwisie, i wszystko inne na nią wskazuje.

Dwie zasady, których pilnuję przy porządkowaniu:

• Identyfikatory muszą być stabilne w czasie — jeżeli po każdym wdrożeniu zmieniają się fragmenty adresów, tracisz jedyną rzecz, która pozwalała powiązać dane z różnych podstron.

• Jedno źródło prawdy na typ obiektu — opis organizacji utrzymuję w jednym szablonie, a nie w trzech wtyczkach, które nadpisują się wzajemnie w zależności od kolejności wczytywania.

Powiąż markę z tożsamością, którą maszyna już zna

Sam opis w znaczniku mówi, jak firma się nazywa. Nie mówi, o którą z pięciu firm o podobnej nazwie chodzi. To rozstrzyga dopiero powiązanie z identyfikatorami, które istnieją poza Twoim serwisem.

Praktycznie oznacza to uzupełnienie właściwości wskazujących na zewnętrzne profile i rejestry: oficjalne konta w serwisach społecznościowych, wpisy w bazach wiedzy, numery rejestrowe, identyfikator w rejestrze przedsiębiorców. Nie chodzi o długość listy, a o to, żeby prowadziła do miejsc, w których dane są takie same jak u Ciebie.

Najczęstszy błąd w tej warstwie jest przyziemny: rozjazd między znacznikiem a resztą świata. Znacznik podaje nazwę w wersji rejestrowej, wizytówka firmy w Google w wersji handlowej, faktura w trzeciej. Dla człowieka to oczywiste, że to jedna firma. Dla systemu, który buduje obraz podmiotu z wielu źródeł, to trzy słabe sygnały zamiast jednego mocnego. Ujednolicenie nazwy i adresu w całej infrastrukturze daje więcej niż dopisanie kolejnych pól.

Znacznik nie może opowiadać innej historii niż strona

To reguła, która obowiązywała od zawsze, ale konsekwencje jej łamania są dziś inne.

Kiedy znacznik służył tylko do wyniku rozszerzonego, rozjazd między nim a treścią kończył się utratą wyróżnienia w wynikach. Teraz dane z znacznika mogą trafić do odpowiedzi, którą użytkownik czyta zamiast strony. Jeśli oznaczona cena różni się od ceny na stronie, użytkownik zobaczy jedną, a zapłaci drugą — i to nie jest problem SEO, tylko problem obsługi klienta.

Dlatego przy każdym wdrożeniu sprawdzam trzy pary: cenę i dostępność w znaczniku wobec karty produktu, ocenę i liczbę opinii wobec tego, co widać w sekcji opinii, oraz dane kontaktowe wobec stopki. W sklepach z częstą zmianą cen dokładam jeszcze pytanie o to, kiedy znacznik jest generowany — jeżeli strona produktu jest agresywnie cache’owana, a ceny zmieniają się kilka razy dziennie, rozjazd jest kwestią czasu.

Higiena techniczna, która realnie coś zmienia

Kilka rzeczy, które poprawiam w niemal każdym audycie i które nic nie kosztują.

• Puste i placeholderowe wartości — pola z „N/A”, zerem albo tekstem z instalacji szablonu są gorsze niż brak pola, bo maszyna traktuje je jako zadeklarowaną informację.

• Daty w formacie z datą i strefą — data publikacji i modyfikacji w pełnym formacie, a nie „12 lutego”. I data modyfikacji zmieniana tylko wtedy, gdy treść faktycznie się zmieniła.

• Jeden język na dokument — deklaracja języka w znaczniku zgodna z deklaracją w dokumencie i z językiem treści. Przy wielojęzycznych serwisach to najczęstsze źródło pomyłek.

• Rozsądny rozmiar bloku — widziałem wdrożenia, w których JSON-LD ważył więcej niż treść strony, bo wtyczka dorzucała pełną listę wszystkich kategorii do każdej podstrony. To nie pomaga w odczycie, to go utrudnia.

Jak to sprawdzać, żeby nie sprawdzać raz na dwa lata

Jednorazowa weryfikacja przy wdrożeniu nie wystarcza, bo znaczniki psują się przy okazji zmian, które z nimi formalnie nie mają nic wspólnego: aktualizacji wtyczki, podmiany szablonu, migracji cennika.

Mój minimalny zestaw wygląda tak. Test wyników z elementami rozszerzonymi i walidator Schema.org na kilku reprezentatywnych szablonach podstron, nie na stronie głównej. Raport elementów rozszerzonych w Search Console przeglądany co miesiąc pod kątem nagłych skoków liczby błędów. Pobranie surowego dokumentu bez renderowania, żeby potwierdzić, że dane są w odpowiedzi serwera. I proste porównanie kilku pól ze znacznika z tym, co pokazuje strona.

Czego Schema nie zrobi za Ciebie

Na koniec zastrzeżenie, bo wokół danych strukturalnych narosło sporo nadziei.

Znaczniki są opisem treści, nie jej zamiennikiem. Nie sprawią, że słaba strona zostanie potraktowana jako wiarygodne źródło, i nie są czynnikiem, który samodzielnie podnosi pozycje. Dają coś innego, co jest w tej chwili wartościowe: zmniejszają liczbę miejsc, w których maszyna musi się domyślać. Mniej domysłów to mniejsze ryzyko, że o Twojej firmie powstanie zdanie, którego byś nie podpisał.

Dlatego układam to w tej kolejności: najpierw spójność danych o firmie i produkcie w całym serwisie, potem jeden porządny graf zamiast kilku wysepek, a dopiero na końcu poszerzanie listy oznaczanych typów. Odwrotna kolejność to najczęstszy sposób, żeby mieć dużo znaczników i niewiele z nich.