Po co to robić, jeśli nie ma z tego wyniku rozszerzonego

To pierwsze pytanie, które słyszę od klientów, i uczciwa odpowiedź brzmi: efekt jest pośredni i rozłożony w czasie.

Wyszukiwarka od dawna nie pracuje wyłącznie na słowach kluczowych — próbuje rozpoznać, o jakich obiektach mówi strona i jak te obiekty łączą się z innymi. Dane strukturalne są dla tego procesu najtańszym możliwym wejściem. Nie zmuszają do wnioskowania z układu strony, nie zależą od tego, czy nazwisko autora jest w nagłówku czy w stopce.

Praktyczne skutki widzę w trzech miejscach. Po pierwsze, w tym, jak wygląda panel wiedzy i sekcja informacji o firmie, gdy ktoś szuka jej z nazwy. Po drugie, w spójności prezentacji marki, która działa pod inną nazwą niż spółka. Po trzecie, w materiałach eksperckich, gdzie identyfikacja autora ma znaczenie dla oceny wiarygodności.

Nie obiecuję klientowi, że oznaczenie autora podniesie pozycje. Mówię, że usuwa niejednoznaczność, a niejednoznaczność w wyszukiwarkach zawsze działa przeciwko mniejszym podmiotom.

Mikrodane czy JSON-LD

Formalnie oba formaty są obsługiwane, praktycznie wybór jest prosty.

Mikrodane wplata się w znaczniki HTML, atrybutami przy elementach, które i tak są na stronie. Zaleta: oznaczenie jest fizycznie połączone z widoczną treścią, więc trudniej o rozjazd między jednym a drugim. Wada: przy opisywaniu relacji między obiektami, które nie są wyświetlone na tej samej podstronie, konstrukcja staje się nieczytelna, a każda zmiana szablonu grozi rozsypaniem struktury.

JSON-LD to osobny blok danych w kodzie strony, niezależny od szablonu. Przy opisywaniu powiązań — autor pracuje w firmie, firma jest właścicielem marki, marka wydaje serwis — jest po prostu praktyczniejszy. Można też opisać obiekty, których na danej podstronie nie widać, i wskazać je identyfikatorem.

Przy nowych wdrożeniach wybieram JSON-LD i nie mieszam formatów w obrębie jednej podstrony. Współistnienie obu bywa źródłem sprzecznych deklaracji, a wtedy nie mamy kontroli nad tym, która wersja zostanie uznana.

Identyfikatory jako szkielet całej konstrukcji

To najważniejszy fragment tego tekstu i najczęściej pomijany element wdrożeń.

Jeżeli na każdej podstronie opisujesz firmę od nowa, tworzysz w oczach maszyny osobny obiekt za każdym razem. Rozwiązaniem jest nadanie każdemu bytowi trwałego identyfikatora — właściwości @id z adresem, który się nie zmienia. Firma dostaje jeden identyfikator, każdy autor swój, marka swój. Potem, w każdym innym miejscu, zamiast powtarzać dane, wskazujesz sam identyfikator.

Dobrą praktyką jest wiązanie identyfikatora z realnym adresem w serwisie, uzupełnionym o fragment po znaku krzyżyka — na przykład adres strony „o nas” z dopiskiem oznaczającym organizację, albo adres profilu autora z dopiskiem oznaczającym osobę. Adres musi istnieć i nie może się zmieniać przy każdej przebudowie serwisu.

Konsekwencją takiego podejścia jest potrzeba osobnych podstron autorów. Bez nich nie ma do czego przypiąć identyfikatora osoby i cała konstrukcja wisi w powietrzu. Strona autora powinna zawierać to, co człowiek uzna za sensowne: kim jest, czym się zajmuje, gdzie pracuje, gdzie go znaleźć, co napisał.

Firma, marka i to, co je łączy

Tu zaczyna się miejsce, w którym łatwo o niespójność, bo struktura prawna rzadko pokrywa się z tym, co widzi klient.

Obiekt organizacji opisuję pełną nazwą, adresem serwisu, logotypem i danymi kontaktowymi. Do tego dochodzi lista adresów zewnętrznych identyfikujących ten sam podmiot — właściwość sameAs z profilami w mediach społecznościowych, wpisami w rejestrach i innymi miejscami, w których firma jest opisana. Nie dorzucam tam wszystkiego, co pod ręką; wyłącznie miejsca, w których dane są zgodne z tym, co podaliśmy na stronie.

Jeżeli firma sprzedaje pod marką różną od nazwy spółki, opisuję markę jako osobny obiekt i wiążę go z organizacją. Ma to znaczenie także dla sklepów: dane produktowe zwykle odwołują się do marki, nie do spółki, a rozbieżność między jednym a drugim potrafi utrudnić powiązanie sygnałów.

Osobna sprawa to serwis internetowy. Warto opisać go jako obiekt witryny i wskazać wydawcę identyfikatorem organizacji. Dostajemy wtedy prosty łańcuch: strona należy do serwisu, serwis jest wydawany przez firmę, firma jest właścicielem marki.

Autor jako byt, nie jako podpis pod tekstem

Różnica między jednym a drugim jest zasadnicza. Podpis to napis. Byt ma identyfikator, historię i powiązania.

Obiekt osoby opisuję imieniem i nazwiskiem, stanowiskiem, adresem strony autora i listą profili zewnętrznych. Dodaję właściwość mówiącą, w jakiej organizacji ta osoba pracuje — wskazując firmę identyfikatorem, nie powtórzoną nazwą. Jeśli osoba ma udokumentowaną specjalizację, opisuję ją właściwością knowsAbout, ale wyłącznie w zakresie, który da się potwierdzić treścią na stronie autora.

Kilka zasad, których się trzymam, bo widziałem skutki ich pomijania:

• Jedna osoba, jeden identyfikator — nawet jeśli publikuje w kilku serwisach klienta. Dwa różne identyfikatory dla tego samego człowieka niweczą cały sens tej pracy.

• Zgodność z widoczną treścią — stanowisko w danych strukturalnych musi być tym samym stanowiskiem, które widzi czytelnik. Rozbieżność to prosta droga do uznania oznaczeń za niewiarygodne.

• Tylko realne osoby — wymyślony ekspert z wygenerowanym zdjęciem i listą specjalizacji, których nikt nie potwierdzi, jest ryzykiem, nie korzyścią.

• Profile, które faktycznie istnieją i faktycznie należą do tej osoby. Najlepiej takie, na których po drugiej stronie widnieje odnośnik z powrotem do serwisu.

Spinanie artykułu z autorem i wydawcą

Na poziomie pojedynczego wpisu wszystko sprowadza się do trzech wskazań.

Obiekt artykułu dostaje autora — wskazanego identyfikatorem osoby, nie tekstem z nazwiskiem. Dostaje wydawcę, wskazanego identyfikatorem organizacji. I dostaje właściwość mówiącą, że opisuje właśnie tę podstronę, na której się znajduje.

To wystarczy, żeby powstał komplet powiązań: tekst napisała konkretna osoba, ta osoba pracuje w konkretnej firmie, ta firma wydaje ten serwis i jest właścicielem marki. Cała reszta to szczegóły — daty publikacji i modyfikacji, nagłówek, język.

Zwracam uwagę na jedną rzecz, o którą łatwo się potknąć w systemach zarządzania treścią z wtyczkami do danych strukturalnych: bardzo często wtyczka wstawia własny blok z autorem podanym jako zwykły tekst, obok naszego bloku z identyfikatorami. Powstają wtedy dwa opisy tego samego artykułu, sprzeczne w najważniejszym punkcie. Zawsze sprawdzam, ile bloków danych strukturalnych faktycznie znajduje się w kodzie strony.

Jak to weryfikuję i co najczęściej nie działa

Weryfikacja składa się z dwóch etapów i oba są konieczne.

Etap pierwszy to sprawdzenie poprawności formalnej — czy blok jest poprawnym dokumentem, czy typy i właściwości są zgodne ze słownikiem. Do tego wystarczy publiczny walidator danych strukturalnych. Test wyników z elementami rozszerzonymi w Search Console nie zawsze pokaże te oznaczenia, bo nie generują one wyników rozszerzonych, i to normalne, a nie błąd wdrożenia.

Etap drugi to sprawdzenie spójności grafu, którego żadne narzędzie nie zrobi za mnie. Przechodzę po identyfikatorach i pytam: czy adres, którego użyłem jako identyfikatora, faktycznie istnieje; czy ten sam autor ma ten sam identyfikator na wszystkich swoich tekstach; czy nazwa firmy w danych zgadza się z tą na stronie kontaktowej; czy profile podane we właściwości sameAs prowadzą tam, gdzie powinny.

Trzy błędy powtarzają się najczęściej. Identyfikatory generowane z adresu bieżącej podstrony, przez co każdy artykuł tworzy nowego autora. Deklaracje niepotwierdzone widoczną treścią — specjalizacje bez śladu w serwisie. I oznaczenia dodane raz, przy wdrożeniu, a potem nieaktualizowane, mimo że autor od dwóch lat pracuje w innej firmie. Ostatni przypadek jest najgorszy, bo zamiast usuwać niejednoznaczność, sami ją dokładamy.