Wyróżnij lokalny biznes metadanymi schema

/ / SEO

Co to są metadata Schema?

Schema metadata to schemat znaczników danych strukturalnych. Pomagają wyszukiwarkom internetowym indeksować nasze strony i przyporządkowywać je do odpowiednich kategorii. To również one, między innymi odpowiadają za skojarzenie Twojego biznesu z Twoją lokalizacją na Mapach Google. Dlatego jeśli chcesz pozycjonować się na Mapach Google, wprowadzenie metadanych staje się obowiązkiem. 

Mówiąc wprost schema metadata to z góry określone etykiety, którymi możemy pokazywać robotom wyszukiwarek, gdzie znajdują się elementy takie jak nazwa produktu, cena, rodzaj prowadzonej działalności, dane adresowe i inne.

Struktura metadanych schema może pojawiać się w kilku postaciach. Najczęściej występującymi jest: zamieszczanie ich w postaci elementów HTML (mikrodanych) lub w postaci kodu script typu JSON. 

Istnieje wiele różnych informacji, jakie możemy umieszczać z ich pomocą: informacje o produktach, wpisach, oceny użytkowników oraz dane dotyczące lokalizacji biznesu. To na tym ostatnim skupimy się w obecnym artykule. 

Jak wyglądają schema metadata?

Spójrz na przykład poniżej zapisany w formacie JSON. Wspólnie przeanalizujemy go, abyś miał świadomość za co odpowiadają poszczególne pola.

 <script type="application/ld+json">
 {
   "@context": "https://schema.org",
   "@type": "LocalBusiness",
   "image": [
     "https://example.com/photos/1x1/photo.jpg",
     "https://example.com/photos/4x3/photo.jpg",
     "https://example.com/photos/16x9/photo.jpg"
    ],
   "@id": "http://example.com",
   "url": "https://example.com",
   “sameAs” : [
     "https://example2.com.jpg",
     "https://facebook.com/example"
    ],
   "name": "Example",
   "address": {
     "@type": "PostalAddress",
     "streetAddress": "900 Linton Blvd",
     "addressLocality": "Delray Beach",
     "addressRegion": "FL",
     "postalCode": "33444",
     "addressCountry": "US"
   },
   "geo": {
     "@type": "GeoCoordinates",
     "latitude": 40.761293,
     "longitude": -73.982294
   },
   "telephone": "+12122459600",
   "email": "example@example.com",
   "openingHoursSpecification": [
     {
       "@type": "OpeningHoursSpecification",
       "dayOfWeek": [
         "Monday",
         "Tuesday"
       ],
       "opens": "11:30",
       "closes": "22:00"
     },
     {
       "@type": "OpeningHoursSpecification",
       "dayOfWeek": [
         "Wednesday",
         "Thursday",
         "Friday"
       ],
       "opens": "11:30",
       "closes": "23:00"
     },
     {
       "@type": "OpeningHoursSpecification",
       "dayOfWeek": "Saturday",
       "opens": "16:00",
       "closes": "23:00"
     },
     {
       "@type": "OpeningHoursSpecification",
       "dayOfWeek": "Sunday",
       "opens": "16:00",
       "closes": "22:00"
     }
   ],
   "priceRange":"100-10000"
  }
 </script>
 <script type="application/ld+json">
 …
 </script> 

Pierwszym i najważniejszym elementem jest opisanie znacznika script, w którym będzie kod JSON jako typ “application/ld+json”. Gdybyśmy pozostawili ten element niezdefiniowany lub opisali go inaczej przeglądarka nie zinterpretowałaby kodu poprawnie. To tak, jakbyśmy mówili, czy od tego momentu będziemy posługiwali się mową czy językiem migowym.

"@context": "https://schema.org",

Następnym pojawiającym się elementem jest “@context”. Mówi on tyle, że dany kod należy interpretować jako element schema. Używając przykładu jest to ekwiwalent określenia, że będziemy mówili po polski (jako śe tak samo brzmiące słowa w różnych językach mogą oznaczać zupełnie coś innego)

"@type": "LocalBusiness",

@type odnosi się do typu informacji, jaki będziemy zamieszczali. O ile poprzednie dwa elementy zawsze pozostaną niezmienne, nie zależnie od zamieszczanych danych, o tyle @type określa “temat” następujących dalej elementów. W tym przypadku tematem będzie biznes lokalny.
Samo określenie “LocalBusiness” jest bardzo ogólne. Możemy je zastąpić bardziej specyficzna branżą, na przykład Restauracją albo Biblioteką. Więcej specyficznych pypów biznesu znajdziesz tutaj: https://schema.org/LocalBusiness#subtypes . Nie wszystkie biznesy mają zdefiniowane swoje bardziej specyficzne typy. Jeśli nie znajdziesz podtypu odpowiadającego Twojej branży, możesz zastosować albo najbardziej zbliżony, albo możesz zostać przy bardziej ogólnym, “LocalBusiness”. 

 "image": [
     "https://example.com/photos/1x1/photo.jpg",
     "https://example.com/photos/4x3/photo.jpg",
     "https://example.com/photos/16x9/photo.jpg"
    ], 

Element image w schemacie biznesu lokalnego odpowiada za obraz, który najlepiej odpowiada wizerunkowi działalności Twojej firmy. Może to być zdjęcie głównego biura, hali produkcyjnej, samochodu, jeśli jesteś przewoźnikiem, albo, jeśli nie posiadasz jakiegoś wyróżniającego Cię zdjęcia ostatecznie może to być Twoje logo. Jeśli posiadasz więcej obrazków, możesz je dodać po przecinku, jak na przykładzie.

"@id": "http://example.com",

@id jako identyfikator powinien być indywidualny w przypadku, jeśli umieszczasz ten sam kod schema na różnych podstronach / domenach. W praktyce unikaj dodawania unikalnych kodów, takich jak schema local business w wielu miejscach. Nie jest to jakoś karane przez google, jednak kod schema local business powinien znajdować się raczej na stronie głównej, kontaktu albo strony o firmie. Jeśli zamieścisz je na wszystkich trzech prawidłowym rozwiązaniem byłoby element @id opisać w różny sposób, np. 
dla strony głównej: „@id”: „http://example.com”,
dla strony kontaktu: „@id”: „http://example.com/kontakt”,
dla strony o firmie: „@id”: „http://example.com/o-firmie”,

"url": "http://example.com",

Url jest adresem Twojej strony biznesowej. Jeśli posiadasz kilka stron, tak jak posiadasz tylko jeden biznes powinieneś uznać tylko jedną z nich za główną, najlepiej oddającą Twoją działalność. Najczęstszy taki przypadek występuje, kiedy ktoś ma stronę i sklep, znajdujące się na różnych domenach lub subdomenach. Twoje pozostałe strony nie pozostaną potraktowane po macoszemu i istnieje metoda, aby one również mogły zostać włączone do schema. Można do tego wykorzystać kolejny element: 

   “sameAs” : [
     "https://example2.com.jpg",
     "https://facebook.com/example"
    ], 

Na tą listę mogą trafić wszystkie inne strony należące do danej firmy, obojętne, czy są to strony internetowe, sklepy, landing page czy profile w social media

  "name": "Example",

Name odpowiada za nazwę Twojego biznesu. Powinna to być oficjalna, pełna nazwa. Najlepiej, aby pokrywał się z nazwą firmy figurującą w Twoim profilu Google Moja Firma, jeśli go posiadasz. 

  "address": {
     "@type": "PostalAddress",
     "streetAddress": "ulica",
     "addressLocality": "miasto",
     "addressRegion": "województwo/region",
     "postalCode": "12-345",
     "addressCountry": "PL"
   }, 

Atrybut adresu jest prosty do interpretacji. Pierwszy zawarty w nim elementy: @type pokazuje, że opisywany element należy interpretować jako adres fizyczny – “PostalAddress”. Kolejne wartości wskazują na:

streetAddress – ulicę
addressLocality – miasto
addressRegion – województwo
postalCode – kod pocztowy
addressCountry – kraj

   "geo": {
     "@type": "GeoCoordinates",
     "latitude": 52.237049,
     "longitude": 21.017532
   } 

Atrybut “geo” wskazuje na podanie lokalizacji geograficznej. Pamiętajmy, że lokalny biznes oparty jest głównie na swojej lokalizacji i każdemu, kto skupia się na jego promowaniu zależy by być odnajdywaniem, kiedy potencjalni klienci szukają podobnej firmy interesując się danym obszarem lub będąc blisko – co jest określane na podstawie geolokalizacji w telefonach komórkowych. Umiejscowienie naszego biznesu na mapie podając szerokość i długość geograficzną pomoże w tym procesie. 

Wracając jednak do atrybutów, ponownie zpotykamy się z elementem “@type” wskazującym na geolokalizację “GeoCoordinates”. Latitude odpowiada za wysokość geograficzną (y), a longitude za szerokość geograficzną (x).
Jeśli chcesz wiedzieć, jakie współrzędne posiada Twoja firma, możesz skorzystać ze stron internetowych, które podadzą Ci je na podstawie Twojego adresu, np: https://www.latlong.net/

   "telephone": "+12122459600",
   "email": "example@example.com" 

Telefon i adres email to chyba najbardziej oczywiste wartości ze wszystkich schema znaczników. W numerze kierunkowym podawanie + na początku, podobnie jak numeru kierunkowego czy oddzielanie kolejnych numerów myślnikami i spacjami jest całkowicie opcjonalne i algorytmy wyszukiwarek z łatwością dają sobie z tym radę.

   "openingHoursSpecification": [
     {
       "@type": "OpeningHoursSpecification",
       "dayOfWeek": [
         "Monday",
         "Tuesday"
       ],
       "opens": "11:30",
       "closes": "22:00"
     },
  {
    …
  }
] 

Dni i godziny otwarcia są jednymi z opcjonalnych wartości, które coraz częściej traktuje się jako must be.
Najistotniejsza rzeczą, na jaką należy zwrócić uwagę to klamry, jakie zostały tu użyte. Jeżeli godziny pracy Twojej firmy są niezmienne w ciągu tygodnia i wyglądają mniejwięcej tak:
poniedziałek – piątek, od 8:00 do 16:00
Twój zapis będzie wyglądał w ten sposób:

  "openingHoursSpecification": 
  {
       "@type": "OpeningHoursSpecification",
       "dayOfWeek": [
         "Monday",
         "Tuesday",
         "Wednesday",
         "Thursday",
         "Friday"
       ],
       "opens": "08:00",
       "closes": "16:00"
   } 

Jeżeli jednak w niektóre dni pojawiają się odstępstwa, dla każdego dnia, musisz utworzyć kolejną grupę z nowymi godzinami, a wszystkie grupy musisz objąć klamrami kwadratowymi [ … ] . W uproszczeniu wygląda to tak:

"openingHoursSpecification": [
 { pierwsza grupa dni i godzin }, 
 { druga grupa dni i godzin }, 
  … 
 { ostatnia grupa dni i godzin }
] 

Łatwo się domyśleć, że każde wystąpienie “okienka” w godzinach pracy będzie skutkowało wydzieleniem danego dnia do dwóch osobnych grup.

Kontynuując jednak analizę szczegółową czasu otwarcia, w dayOfWeek pojawiają się dni tygodnia, natomiast wartości “opens” i “closes” odpowiadają kolejno godzinie otwarcia i zamknięcia. 

Można tu stosować format 12-godzinny, określając godzinę 18 jako “06:00 pm” a godzinę siódmą rano “07:00 am”. Jak widać system schema będzie interpretowany dosyć elastycznie. Warto jednak stosować zapis uniwersalnie jak najpowszechniej znany i klarowny. 

Pozwolę tu sobie na pewną dygresję wobec zapisu czasu. Co, jeśli chcemy poinformować naszych klientów, że w dane dni nie pracujemy, lub, że dany grafik obowiązuje dopiero od jakiejś konkretnej daty? Spójrz na poniższy zapis, zaczerpnięty z przykładów na schema.org:

   "openingHours": "Mo,Tu,We,Th,Fr,Sa,Su 09:00-14:00",
   "openingHoursSpecification":
   [
     {
       "@type": "OpeningHoursSpecification",
       "validFrom": "2013-12-24",
       "validThrough": "2013-12-25",
       "opens": "09:00:00",
       "closes": "11:00:00"
     },
     {
       "@type": "OpeningHoursSpecification",
       "validFrom": "2014-01-01",
       "validThrough": "2014-01-01",
       "opens": "12:00:00",
       "closes": "14:00:00"
     }
   ] 

Zapis ten oznacza, że:

"openingHours": "Mo,Tu,We,Th,Fr,Sa,Su 09:00-14:00",

Godziny otwarcia standardowo są od poniedziałku do niedzieli, od 9 rano do 14 po południu. 

     {
       "@type": "OpeningHoursSpecification",
       "validFrom": "2013-12-24",
       "validThrough": "2013-12-25",
       "opens": "09:00:00",
       "closes": "11:00:00"
     } 

Zaś w dniach od 24 grudnia 2013 roku, do 25 grudnia 2013 otwarcie następuje o 9 rano, ale zamknięcie już o 11:00.

W ten sposób możemy tworzyć w naszym harmonogramie wyjątki dotyczące konkretnych dat. 

"priceRange":"200-20000"

Atrybut priceRange określa, w jakich cenach oferujemy produkty lub usługi. Jeżeli nie mamy jakiś zdefiniowanych wastości możemy je nawet zastąpić znakami $. Jeśli napiszemy:

"priceRange":"$$-$$$"

będzie to oznaczało, że nasze ceny przyjmują wartości od dwucyfrowych do trzycyfrowych. 

Istnieją jeszcze inne formy danych, jakie możemy dołączyć do schema lokalnego biznesu, takie jak np. ocena użytkowników, lecz jest to osobny temat, który wypadałoby omówić szerzej nie tylko w perspektywie lokalnego biznesu, ale również produktów czy artykułów.