Inspiracją do tego artykułu został … Booking.com, jednak nie domyślicie się, co się do tego bezpośrednio przyczyniło. O tym napiszę w dalszej części artykułu. Tymczasem przybliżę trochę temat. Zapewne tematyka SEO jest Wam wszystkim znana w przynajmniej podstawowym stopniu. Ewoluuje bardzo dynamicznie, więc nie powinno być zaskakujące, że twórcy stron internetowych muszą iść z duchem postępującego czasu. Tutaj właśnie poruszamy się w takim obszarze. Nie dalej jak 2 lata temu (2015) JSON-LD (JSON Linked Data) zagościł na dobre w dziedzinie SEO i stał się rekomendowanym standardem, pozwalającym zdefiniować rozszerzone opisy stron internetowych i w konsekwencji wpłynąć na pozycję serwisu w wyszukiwarce i ściśle związany z nim ruch na stronie.

 

Czy na pewno mikrodane są gorsze?

Mikrodane (ang. microdata) zostały zdetronizowane w kategorii rich snippets zapewne z uwagi na to, że nie są tak uniwersalne, jak JSON-LD. Nie jest rzeczą trudną do wywnioskowania, że dane w formacie JSON mogą zostać wykorzystane niemal wszędzie, natomiast mikrodane w formacie HTML już niekoniecznie. Oczywiście, gdyby się uprzeć, można upchnąć mikrodane w JSON API, czy jakimkolwiek innym API, jednak wydaje się to karkołomne. Summa summarum interesują nas surowe dane i w te wymagania w pełni wpisuje się standard JSON-LD. Mikrodane do 2015 roku były rekomendowane przez Google dlatego szybko nie zostaną wyparte całkowicie z mechanizmu pozycjonowania, czy ściśle z nim związanych grafów wiedzy i aplikacji wykorzystujących ten format danych strukturalnych. Myślę, że takie wsparcie wsteczne potrwa jeszcze sporo czasu z uwagi na jedną ważną przewagę, która dotyczy również formatu RDF, czyli XMLowego odpowiednika mikrodanych. Ich składnia jest mocno „przysadzista” w stosunku do surowego JSON-LD, ale jest ważny argument świadczący za tym, że jeszcze pozostaną – pozwalają uniknąć duplikacji danych. Ten argument przytoczę na jednym z przykładów w dalszej części artykułu.

Google udostępnia narzędzie internetowe do analizy danych strukturalnych: testing-tool. Pozwala ono wkleić kod do analizy lub przeanalizować publicznie dostępną stronę internetową. Jest bardzo przydatne w kontekście weryfikacji błędów, które przecież zawsze mogą wkraść się przypadkiem, a skutki błędów dość szybko mogą okazać się brutalne. Do tego narzędzia będziemy jeszcze wracać.

Teraz trochę informacji nt. samego JSON-LD. Dokumentację znajdziemy na stronie https://json-ld.org/spec/latest/json-ld/. Oczywiście domyślam się, że przedzieranie się przez takie specyfikacje nie jest niczym miłym, jednak warto pamiętać na przyszłość, że ewentualne kwestie problematyczne z pewnością są tam bezpośrednio lub pośrednio wyjaśnione.

Sporo już przetworzonej wiedzy na temat Linked Data znajdziecie w bardzo przyjemnym filmie, którego autorem jest Manu Sporny:

W podobnym tonie Manu wypowiada się na temat już stricte JSON-LD pod poniższymi adresami:

• „What is JSON-LD”
• „JSON-LD: Core Markup”
• „JSON-LD: Compaction and Expansion”

 

Rzeczywistość

Jak już przyczepiłem się do portalu Booking.com, na jego przykładzie sprawdzimy o co chodzi w praktyce z JSON-LD.

1. Wyszukajcie frazę „booking.com” w wyszukiwarce Google.
2. Rezultat powinien przedstawiać mniej więcej to, co na obrazku poniżej
   

   Wynik wyszukiwania Booking.com w Google

3. Trzy elementy powinny przykuć uwagę:
   • wyszukiwarka wewnętrzna serwisu
   • odnośniki organiczne dopasowane do użytkownika
   • blok zapytania powiązanego
4. Rozbierzmy stronę na czynniki pierwsze dzięki narzędziu do testowania danych strukturalnych (link)
   

   Wynik testowania danych strukturalnych serwisu Booking.com

5. Widzimy 4 elementy, których dane strukturalne zostały zawarte na stronie
   • wyszukiwarka wewnętrzna serwisu
     

     Wyszukiwarka serwisu Booking.com w danych strukturalnych

   • metadane powiązane z aplikacjami mobilnymi
     

     Metadane powiązanych aplikacji mobilnych w danych strukturalnych

   • dane organizacji do grafu zależności
     

     Dane do grafu wiedzy

      

Już mamy pełną jasność, skąd te wszystkie dodatkowe dane się biorą w wynikach wyszukiwania. Dodatkowo może przedstawię przykład, gdzie dodatkowymi informacjami są oceny (tzw. gwiazdki) w wynikach wyszukiwania, a także wzmianki o opiniach i cenach. Przykład dla konkretnego hotelu z konrektnej dzielnicy Warszawy:

Co jeszcze rzuca się oczy, to dedykowania ścieżka – popularne okruszki, które naprowadzają użytkownika. Pozwalają się upewnić, że o tę dzielnicę nam chodzi (to województwo itp. itd.), a to pozwala zmniejszyć zjawisko odrzutu na stronach w przypadku chybionego trafienia.

Analiza danych pozwala nam zidentyfikować skrypt JSON-LD, w którym zawarto dane o opiniach, ocenie i cenach oraz inne wyżej niewidoczne.

Widać, że zawarte zostały tam też informacje o adresie, link do mapy oraz zdjęcie, które wyszukiwarka pominęła w prezentacji.

Warto tutaj pochylić się jeszcze na wcześniej wspomnianymi okruszkami, które teraz już są obowiązkową praktyką SEO wśród twórców stron.

Jak widać analiza utwierdziła nas w przekonaniu, że RDF (potencjalnie również microdata) mają pewną przewagę nad JSON-LD. Mianowicie, jeżeli jakieś dane strukturalne są zawarte już w kodzie HTML, wystarczy dodać odpowiednie atrybuty, aby indeksowanie ich nie wymagało duplikacji danych. To miałoby miejsce, gdyby chcieć konsekwentnie korzystać z JSON-LD w w/w przykładzie.

Oczywiście można utworzyć tutaj odpowiednik w JSON-LD, bo w tym nie stoi nam nic na przeszkodzie. Testowy kod:

<script type="application/ld+json">
{
 "@context": "http://schema.org",
 "@type": "BreadcrumbList",
 "itemListElement": [{
  "@type": "ListItem",
  "position": 1,
  "item": {
   "@id": "https://example.com/books",
   "name": "Books",
   "image": "http://example.com/images/icon-book.png"
  }
 },
 {
  "@type": "ListItem",
  "position": 2,
  "item": {
   "@id": "https://example.com/books/authors",
   "name": "Authors",
   "image": "http://example.com/images/icon-author.png"
  }
 },
 {
  "@type": "ListItem",
  "position": 3,
  "item": {
   "@id": "https://example.com/books/authors/annleckie",
   "name": "Ann Leckie",
   "image": "http://example.com/images/author-leckie-ann.png"
  }
 },
 {
  "@type": "ListItem",
  "position": 4,
  "item": {
   "@id": "https://example.com/books/authors/ancillaryjustice",
   "name": "Ancillary Justice",
   "image": "http://example.com/images/cover-ancillary-justice.png"
  }
 }]
}
</script>

Informacje o opisywaniu okruszków znajdziecie tutaj.

Wspieranych jest bardzo dużo typów danych – informacje o nich znajdziecie na w/w stronie. Przykładowo: artykuły, książki, kursy, wydarzenia, muzyka, filmy i wiele innych. Cały szkopuł polega na umiejętnym ich zastosowaniu w tworzonym publicznym serwisie internetowym.

---

Sprawdźmy teraz jeszcze przykład z lokalizacją powiedzmy hotelu oraz produkt ze sklepu online.

1. Hotel Sheraton Poznań
   • mamy tutaj mapę, zdjęcia, wpis z Wikipedii, adres, telefon, dostępność pokojów, ceny i opinie
     

     Wynik wyszukiwania hotelu Sheraton Poznań

   • analiza danych strukturalnych pokazuje, że tylko koordynaty do mapy, opis strony, dane teleadresowe pochodzą bezpośrednio ze strony hotelu
     

     Analiza danych strukturalnych hotelu Sheraton Poznań

   • pozostałe dane pochodzą z grafu wiedzy, czyli z innych serwisów, których treść odwołuje się bezpośrednio do naszego źródła
     • ceny z poszczególnych serwisów rezerwacyjnych (np. Booking.com dane te zawiera w JSON-LD)
     • opinie z serwisu TrustYou – a dokładniej z jego API
     • zdjęcia to wiadomo – magia Google (przypięte do map, zaindeksowane ze stron …)
2. Okulary
   • otrzymujemy w wynikach blok, w którym wszystkie (lub większość) dopasowania wynikają z odpłatnej współpracy między Google, a docelowymi sklepami; widać zdjęcie i cenę z możliwością bezpośredniego przejścia do towaru w sklepie
     

     Wynik wyszukiwania okularów

   • analiza pierwszego z brzegu produktu „sponsorowanego”, daje nam informację m.in o cenie
     

     Analiza produktu ze sklepu online

   • w przypadku tego bloku z produktami sklepów online sprawa nie rozbija się wyłącznie o dane strukturalne; mechanika działania jest dużo bardziej skomplikowana, gdyż znalazłem przykład, gdzie cena zawarta w danych strukturalnych odbiegała znacznie od aktualnie prezentowanej przez Google i sam sklep

 

Dane strukturalne dają podstawy do mechanizmu tworzenia zależności, jednak małą częścią całego mechanizmu tworzenia grafu wiedzy na jakikolwiek temat. W dodatku wynikowo zazębiają się z personalizacją dla konkretnego wyszukującego.

 

Geneza artykułu

Wreszcie dochodzimy do sedna, czyli nieintuicyjnego wykorzystania JSON-LD w Internecie. Temat zrodził się, gdy otrzymałem tą wiadomość mailową:

Tak, rozchodzi się o bezpośredni link zawarty w bloku skrótu wiadomości mailowej. Szybkie zbadanie źródła wiadomości pozwoliło zidentyfikować istnienie skryptu JSON-LD w treści wiadomości.

<script type=3D"application/ld+json">
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"url": "https://secure.booking.com/review/xxxxxxxxxxxxxxxxxx.pl.html?aid=3Dxx=
xxxx&email_source=3Dinvitation&b_ref=3Dgmail_cta",
"target": "https://secure.booking.com/review/xxxxxxxxxxxxxxxxxx.pl.html?aid=
=3Dxxxxxx&email_source=3Dinvitation&b_ref=3Dgmail_cta",
"name": "Napisz opini=C4=99 dotycz=C4=85c=C4=85 pobytu"
},
"description": "Napisz opini=C4=99 dotycz=C4=85c=C4=85 pobytu"
}
</script>

 

Jak się okazuje Google pozwala w pewnym określonym stopniu na integrację mikrodanych i JSON-LD z wiadomością mailową. Temat jest bardzo ciekawy. Typy zaaprobowane:

• jednorazowa akcja (link)
• przekierowanie (link wielokrotnego użytku)
• akcja potwierdzenia udziału w wydarzeniu
• przypięte artykuły
• wsparcie zamówień, rezerwacji

Mi szczególnie przypadły do gusty dwa pierwsze chociaż każde ma potencjał. Dla przykładu potwierdzenie rejestracji jakie często trzeba zainicjować klikając w link zawarty w wiadomości automatycznej można uwzględnić w formie przekierowania i mieć możliwość kliknięcia już z poziomu listy wiadomości.

Niestety jest też zła wiadomość. Jest małe prawdopodobieństwo, by jakikolwiek inny dostawca usług mailowych wspierał, którykolwiek z „Email markups”. Tak, czy inaczej nawet dla samego GMaila można się postarać. Widać do na wcześniej przytoczonym przykładzie.

 

Podsumowanie

Sam format danych strukturalnych JSON-LD jest tylko alternatywą, jednak alternatywą rekomendowaną od 2015 roku przez potentata rynku wyszukiwania danych. Nic nowego nie wnosi w technicznym aspekcie, ale pozwala działać na surowych danych, które możemy użyć wszędzie. To niesie za sobą możliwość umieszczenia danych strukturalnym w jednym wydzielonym miejscu i wpływa na jakość serwisu.

RDF i mikrodane szybko jednak nie znikną z jednego ważnego powodu – pozwalają doprecyzować już istniejące fragmenty kodu serwisu, aby stały się jasne dla robotów indeksujących treści.

Poprawność danych strukturalnych jest niezwykle ważna. Mamy dedykowane narzędzie pozwalające zwalidować kod źródłowy. Dlatego, nawet jeśli z czasem z powodu zmiany wytycznych, taki błąd się pojawi w naszych danych nie należy zwlekać z naprawą, gdyż możemy się narazić na karę ręczną, prowadzącą do wyłączenia wyników rozszerzonych dla naszego serwisu. To w konsekwencji zapewne doprowadzi do zmniejszenia ruchu na stronie i ewentualnych przychodów z tego tytułu.

JSON-LD został stworzony, aby umożliwić systemom wykorzystującym do wymiany danych format JSON wprowadzenie Linked Data. Przeznaczenie z czasem rozszerzyło się na serwisy internetowe, w których umożliwiono wprowadzenie skryptów zawierających JSON-LD.

Dane strukturalne już są bardzo popularne, a dodatkowo mam wrażenie, że jeszcze ich znaczenie wzrośnie. Wpływając na widoczność serwisu w wynikach wyszukiwania pozwalają zmniejszyć zjawisko odrzutu w serwisach, wypromować się wśród innych stron. Dane semantyczne są kluczowe przede wszystkim dla robotów, które mogą w bardziej „ludzki” sposób zaszufladkować strony internetowe lub ich części.

Należy tutaj podkreślić, że lista wspieranych typów danych strukturalnych się zmienia, co możemy zaobserwować zwłaszcza w wynikach wyszukiwania Google. Wyniki rozszerzone zawierają coraz nowsze rich snippets i przykuwają oko. A skoro jakaś konkurencja tak się promuje, dlaczego nie zrobić tego w jakimś serwisie internetowym, który aktualnie robimy?! Trzeba wykorzystywać takie dobrodziejstwa techniki, by nie zniknąć w tłumie.

 

Dodatkowe materiały źródłowe:

• JSON-LD Playground
• wtyczki wspierające dane strukturalne w WordPressie
• wsparcie JSON-LD w WordPressie bez wtyczek