Jak wdrożyć znaczniki schema.org w katalogu branżowym

Znaczniki schema.org w katalogu branżowym nie naprawią słabej jakości wizytówek i nie zagwarantują dodatkowych elementów w wynikach Google. Mogą jednak precyzyjnie opisać, czym jest dana strona, jakiej firmy dotyczy, gdzie przedsiębiorstwo działa i w jaki sposób poszczególne podstrony są ze sobą powiązane.

Największy błąd pojawia się już na etapie projektu. Administrator katalogu dodaje jeden ogólny schemat Organization do całego serwisu, mimo że strona kategorii, profil firmy i artykuł poradnikowy reprezentują zupełnie inne typy treści. Kod przechodzi podstawową walidację, lecz nie opisuje strony zgodnie z jej faktyczną zawartością. Technicznie działa. Semantycznie jest prawie bezużyteczny.

Dobre wdrożenie wymaga osobnego modelu danych dla każdego rodzaju podstrony oraz bezwzględnej zgodności między kodem JSON-LD a informacjami widocznymi dla użytkownika.

Najpierw zaprojektuj typy stron, a dopiero później kod

W katalogu branżowym zwykle występują co najmniej cztery rodzaje podstron:

• strona główna katalogu,
• lista firm w kategorii lub lokalizacji,
• indywidualna wizytówka przedsiębiorstwa,
• artykuł, poradnik albo aktualność.

Każdy z tych szablonów powinien otrzymać własny zestaw znaczników. Nie należy kopiować jednego skryptu JSON-LD do wszystkich podstron, zmieniając wyłącznie nazwę i adres firmy.

Na stronie głównej sensowne jest oznaczenie operatora serwisu jako Organization lub — gdy sam katalog jest lokalnym przedsiębiorstwem — odpowiedniego podtypu LocalBusiness. Obiekt powinien opisywać właściciela katalogu, a nie wszystkie firmy znajdujące się w bazie.

Najczęściej wykorzystywane właściwości to:

• name — oficjalna nazwa podmiotu,
• url — kanoniczny adres strony,
• logo — bezwzględny adres pliku z logo,
• sameAs — profile społecznościowe i inne oficjalne strony operatora,
• contactPoint — dane kontaktowe operatora,
• address — tylko wtedy, gdy adres jest rzeczywiście związany z oznaczaną organizacją.

Strona kategorii, na przykład „Biura rachunkowe w Poznaniu”, jest przede wszystkim listą elementów. Do opisania jej struktury można użyć ItemList, gdzie każda pozycja otrzymuje numer position i adres url.

Przykładowy fragment:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "ItemList",
  "name": "Biura rachunkowe w Poznaniu",
  "numberOfItems": 3,
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "url": "https://example.pl/firmy/biuro-alfa"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "url": "https://example.pl/firmy/ksiegowosc-beta"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "url": "https://example.pl/firmy/centrum-gamma"
    }
  ]
}
</script>

Trzeba przy tym rozdzielić dwie kwestie. ItemList pomaga opisać listę, ale sama obecność tego typu nie oznacza, że Google pokaże katalog jako karuzelę wyników. Obsługa wyników rozszerzonych zależy od rodzaju treści i aktualnie wspieranych funkcji wyszukiwarki. Zwykła lista hydraulików, księgowych czy kancelarii nie otrzymuje automatycznie karuzeli tylko dlatego, że zawiera poprawny ItemList.

Na stronach kategorii warto również wdrożyć BreadcrumbList. Okruszki powinny odpowiadać ścieżce widocznej na stronie, na przykład:

1. Strona główna,
2. Usługi,
3. Biura rachunkowe,
4. Poznań.

Nie należy dodawać do schematu poziomów, których użytkownik nie widzi w interfejsie. Takie „ulepszanie” struktury zwykle kończy się rozjazdem między kodem, nawigacją i adresem kanonicznym.

Wizytówka firmy wymaga pełnych i spójnych danych LocalBusiness

Na profilu przedsiębiorstwa podstawowym typem będzie zwykle LocalBusiness albo jego bardziej precyzyjny podtyp. Zamiast ogólnego LocalBusiness lepiej zastosować na przykład:

• Dentist dla gabinetu stomatologicznego,
• LegalService dla kancelarii,
• AccountingService dla biura rachunkowego,
• AutoRepair dla warsztatu,
• Restaurant dla restauracji,
• Store lub odpowiedni podtyp sklepu dla placówki handlowej.

Zasada jest prosta: wybieramy najbardziej szczegółowy typ, który rzeczywiście pasuje do działalności. Nie trzeba tworzyć egzotycznej kombinacji kilku typów tylko po to, aby objąć wszystkie kody PKD przedsiębiorstwa. Jeśli firma prowadzi warsztat samochodowy i dodatkowo sprzedaje części, profil może być opisany jako AutoRepair, o ile naprawa pojazdów jest główną usługą prezentowaną na stronie.

Minimalny, praktyczny zestaw danych dla wizytówki obejmuje:

• nazwę firmy,
• adres URL profilu,
• numer telefonu,
• adres pocztowy,
• zdjęcie lub logo,
• współrzędne geograficzne,
• godziny otwarcia,
• zakres cenowy, jeżeli da się go uczciwie określić.

Przykład dla polskiej firmy:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "AccountingService",
  "@id": "https://example.pl/firmy/biuro-alfa#business",
  "name": "Biuro Rachunkowe Alfa",
  "url": "https://example.pl/firmy/biuro-alfa",
  "telephone": "+48611234567",
  "image": "https://example.pl/media/biuro-alfa.jpg",
  "priceRange": "150–1500 PLN",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "ul. Głogowska 18",
    "postalCode": "60-734",
    "addressLocality": "Poznań",
    "addressRegion": "wielkopolskie",
    "addressCountry": "PL"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 52.3993,
    "longitude": 16.9012
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": [
        "Monday",
        "Tuesday",
        "Wednesday",
        "Thursday",
        "Friday"
      ],
      "opens": "08:00",
      "closes": "16:00"
    }
  ]
}
</script>

Numer telefonu najlepiej zapisywać w międzynarodowym formacie, na przykład +48221234567, bez lokalnego zera kierunkowego. Kod kraju w adresie powinien mieć wartość PL. Współrzędne muszą wskazywać faktyczną lokalizację firmy, a nie środek Warszawy, Krakowa czy całej gminy.

Najbardziej problematyczne są godziny otwarcia. Firmy zmieniają je w wakacje, święta i długie weekendy, natomiast dane w katalogach pozostają nietknięte przez kilka lat. Jeśli katalog nie ma procedury aktualizacji, lepiej nie publikować godzin niż automatycznie powielać informacje pobrane z przypadkowego źródła.

Dla wyjątków można wykorzystać specialOpeningHoursSpecification, lecz ma to sens tylko wtedy, gdy operator katalogu otrzymuje aktualne dane i potrafi je terminowo usunąć lub zastąpić. W przeciwnym razie kod będzie informował o godzinach świątecznych jeszcze wiele miesięcy po wskazanej dacie.

Oddziały tej samej firmy powinny mieć osobne podstrony, osobne adresy URL i osobne obiekty LocalBusiness. Łączenie pięciu placówek w jednej wizytówce prowadzi do nieczytelnego modelu: jeden obiekt otrzymuje kilka telefonów, adresów i zestawów godzin, bez jasnej informacji, które dane należą do konkretnego punktu.

Każdej placówce dobrze nadać trwały identyfikator @id, przykładowo:

https://example.pl/firmy/biuro-alfa-poznan#business

Ten sam identyfikator powinien być używany konsekwentnie w innych obiektach odnoszących się do danej firmy. Zmiana @id przy każdej przebudowie szablonu odbiera mu sens jako stabilnemu identyfikatorowi encji.

Opinie, duplikaty i automatyzacja — tutaj najłatwiej o kosztowny błąd

Oceny przyciągają uwagę, dlatego właściciele katalogów często zaczynają wdrożenie właśnie od AggregateRating. To zła kolejność. Najpierw trzeba ustalić pochodzenie opinii, sposób liczenia średniej oraz możliwość ich moderacji.

Ocena zbiorcza powinna wynikać z recenzji dostępnych w danym katalogu i widocznych dla użytkownika. Nie należy kopiować średniej z Profilu Firmy w Google, Facebooka, Booksy czy innego serwisu i przedstawiać jej jako własnej oceny katalogu. Problem nie kończy się na regulaminie zewnętrznej platformy. Użytkownik widzący ocenę 4,8 na podstawie 127 opinii powinien móc dotrzeć do tych 127 opinii na oznaczonej stronie.

Przykładowa struktura:

"aggregateRating": {
  "@type": "AggregateRating",
  "ratingValue": "4.7",
  "bestRating": "5",
  "worstRating": "1",
  "ratingCount": "38"
}

Jeżeli katalog ma tylko formularz „poleć firmę”, bez publicznej treści opinii, dat, autorów i zasad moderacji, dodawanie AggregateRating jest ryzykowne. Podobnie wygląda sytuacja z ocenami wygenerowanymi automatycznie na podstawie liczby kliknięć, odsłon albo płatnego pakietu. To nie są recenzje klientów.

Trzeba też zaakceptować niewygodny fakt: nawet poprawne oznaczenie prawdziwych opinii nie gwarantuje wyświetlenia gwiazdek w Google. Dane strukturalne tworzą możliwość zakwalifikowania strony do określonej prezentacji, ale wyszukiwarka samodzielnie decyduje, czy i w jakiej formie ją pokaże.

Drugim problemem są duplikaty firm. W katalogach powstają najczęściej przez:

• różne warianty nazwy, na przykład „ABC Sp. z o.o.” i „ABC”,
• zmianę adresu bez aktualizacji starej wizytówki,
• osobne wpisy dodane przez właściciela i import danych,
• różny zapis numeru telefonu,
• utworzenie oddziału jako kolejnej kopii całej firmy,
• import z kilku baz bez mechanizmu deduplikacji.

Przed wygenerowaniem schema.org system powinien ustalić, który rekord jest główny. Pomagają w tym numery NIP i REGON, domena, numer telefonu, współrzędne oraz dokładny adres. Samo porównywanie nazw nie wystarcza — w Polsce działa wiele przedsiębiorstw o nazwach typu „Alfa”, „Omega”, „Expert” czy „Centrum Usługowe”.

Jeśli dwa adresy URL opisują tę samą placówkę, należy najpierw uporządkować indeksację: wybrać właściwy adres, ustawić przekierowanie 301 albo poprawny adres kanoniczny, a dopiero potem wdrażać dane strukturalne. Oznaczenie obu duplikatów identycznym LocalBusiness nie rozwiązuje problemu. Utrwala go w kodzie.

Automatyzacja ma sens, gdy katalog zawiera setki lub tysiące profili. Skrypt JSON-LD powinien być generowany z tych samych pól bazy danych, które są prezentowane w HTML. Dzięki temu telefon, adres i godziny nie rozjeżdżają się między treścią a znacznikiem.

W praktyce trzeba wprowadzić co najmniej trzy zabezpieczenia:

• brak publikacji właściwości, gdy pole jest puste,
• kontrolę formatu telefonu, kodu pocztowego, adresu URL i współrzędnych,
• ponowną walidację po każdej zmianie szablonu wizytówki.

Nie wolno zastępować brakujących wartości fikcyjnymi danymi. Telefon 000000000, cena 0 PLN, współrzędne centrum kraju albo domyślne godziny 8:00–16:00 są gorsze niż brak właściwości. Tworzą fałszywy opis firmy, a nie kompletny schemat.

Po wdrożeniu należy sprawdzić reprezentatywną próbkę podstron:

1. jedną kompletną wizytówkę,
2. profil bez godzin otwarcia,
3. profil bez zdjęcia,
4. firmę z kilkoma oddziałami,
5. kategorię z paginacją,
6. wizytówkę z opiniami,
7. stronę ze znakami specjalnymi w nazwie.

Do testów służą dwa różne narzędzia. Rich Results Test pokazuje obsługiwane przez Google rodzaje wyników rozszerzonych. Schema Markup Validator kontroluje zgodność ze słownikiem schema.org, także w przypadku typów, które nie mają własnego wyniku rozszerzonego w Google. Przejście tylko jednego testu nie daje pełnego obrazu.

Następnie trzeba użyć inspekcji adresu URL w Google Search Console. Kod widoczny w przeglądarce może nie być identyczny z kodem odczytanym po renderowaniu przez Google, zwłaszcza gdy JSON-LD jest wstawiany przez JavaScript, system tagów lub zewnętrzny moduł.

Najbardziej irytujący błąd pojawia się po drobnej zmianie front-endu. Programista zmienia nazwę pola albo usuwa element HTML, lecz generator schema.org nadal publikuje starą wartość. Walidator pokazuje poprawny JSON, mimo że dane nie zgadzają się już z treścią strony. Dlatego test wdrożenia musi obejmować nie tylko składnię, ale też porównanie kodu z tym, co rzeczywiście widzi użytkownik.

FAQ

Czy JSON-LD jest lepszy od mikrodanych?
W większości katalogów tak. JSON-LD łatwiej generować, testować i aktualizować bez rozbudowywania znaczników HTML. Nie zwalnia to jednak z obowiązku zachowania zgodności z widoczną treścią strony.

Czy każda firma powinna otrzymać typ LocalBusiness?
Tylko firma obsługująca klientów w określonej lokalizacji lub na określonym obszarze. Dla podmiotu działającego wyłącznie internetowo bardziej odpowiedni może być Organization, OnlineBusiness albo inny typ zgodny z rzeczywistym modelem działalności.

Czy można oznaczyć firmę, która nie ma własnej strony internetowej?
Tak. Właściwość url może prowadzić do jej indywidualnej, kanonicznej wizytówki w katalogu. Nie należy jednak wpisywać adresu strony głównej katalogu jako strony każdej firmy.

Czy schema.org poprawia pozycję katalogu?
Nie jest bezpośrednią gwarancją wzrostu pozycji. Pomaga wyszukiwarce zrozumieć encje i relacje na stronie oraz może otworzyć drogę do wybranych form prezentacji. Nie zastąpi unikalnych opisów, poprawnej indeksacji, wiarygodnych danych i użytecznej struktury serwisu.

Czy można wdrożyć kilka typów schema.org na jednej podstronie?
Tak, o ile opisują różne, faktycznie obecne elementy. Wizytówka może zawierać LocalBusiness, BreadcrumbList oraz opinie powiązane z firmą. Obiekty najlepiej połączyć za pomocą @id, zamiast publikować kilka niezależnych i częściowo sprzecznych zestawów danych.

Jak często kontrolować wdrożenie?
Po każdej zmianie szablonu, generatora, systemu opinii lub struktury adresów URL. Przy stabilnym katalogu kontrola próby profili raz w miesiącu zwykle wystarcza, ale błędy i ostrzeżenia w Search Console trzeba sprawdzać na bieżąco.

Pierwszym działaniem nie powinno być pisanie rozbudowanego generatora JSON-LD. Najpierw wybierz dziesięć wizytówek, porównaj ich nazwy, telefony, adresy, godziny i duplikaty, a następnie usuń rozbieżności między bazą a treścią strony. Dopiero na uporządkowanych rekordach wdrażaj LocalBusiness. Schemat zasilany błędnymi danymi jedynie szybciej rozpowszechnia bałagan.

Więcej informacji na: katalog NAP – https://biznap.pl