Dane strukturalne LocalBusiness krok po kroku: JSON-LD dla małej firmy i jak go sprawdzić

Krok 1 — wybierz typ, a nie tylko „LocalBusiness"

LocalBusiness w schema.org ma bardziej szczegółowe podtypy, między innymi HealthAndBeautyBusiness, HomeAndConstructionBusiness, LegalService, LodgingBusiness, MedicalBusiness i ProfessionalService (Schema.org, LocalBusiness). Im dokładniejszy typ, tym jednoznaczniejszy opis tego, czym firma się zajmuje.

Gdy żaden z podtypów nie pasuje dokładnie, zostaje ogólny typ LocalBusiness — to wciąż poprawny i akceptowany wybór, tylko mniej precyzyjny.

Krok 2 — zbierz fakty w jedną tabelę, zanim napiszesz kod

Zanim pojawi się jakikolwiek nawias klamrowy, warto spisać w jednym miejscu dokładnie te dane, które i tak są już publiczne: nazwę firmową taką samą jak na szyldzie i w profilu Google, adres, telefon w formacie międzynarodowym, adres strony, godziny pracy według dni tygodnia i orientacyjny zakres cen (priceRange). Zasada jest prosta: w kodzie mają się znaleźć te same dane, które widać na stronie i w wizytówce Google — nazwa w profilu firmy ma odpowiadać realnej nazwie firmy, a profil pokazuje też adres lub obszar działania, godziny otwarcia i kategorię (Google, wytyczne dotyczące reprezentowania firmy). Sam profil, jego kategorie i godziny warto trzymać w porządku niezależnie od kodu — tym zajmuje się Google Business Profile.

Jeśli którejś z tych danych brakuje na samej stronie — na przykład godzin pracy — najpierw dopisz ją do widocznej treści, a dopiero potem do kodu. Dane strukturalne mają odpowiadać treści widocznej dla użytkowników, a nie zastępować jej ani jej wyprzedzać.

Krok 3 — kod JSON-LD na przykładzie

Poniższy blok to przykład na danych umownych — same nawiasy i pola są prawdziwe i zgodne z dokumentacją Google, ale nazwa, adres i telefon są wymyślone i służą wyłącznie jako szablon do podstawienia własnych danych:

{
  "@context": "https://schema.org",
  "@type": "HomeAndConstructionBusiness",
  "name": "Zakład Remontowy Przykład",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "ul. Przykładowa 12",
    "addressLocality": "Warszawa",
    "postalCode": "00-001",
    "addressCountry": "PL"
  },
  "telephone": "+48123456789",
  "url": "https://przyklad.pl",
  "priceRange": "$$",
  "openingHoursSpecification": [
    { "@type": "OpeningHoursSpecification", "dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"], "opens": "08:00", "closes": "16:00" },
    { "@type": "OpeningHoursSpecification", "dayOfWeek": "Saturday", "opens": "09:00", "closes": "13:00" }
  ]
}

Pole priceRange — orientacyjny zakres cen — pojawia się w przykładach Google obok telefonu i godzin jako jedna z zalecanych właściwości (Google Search Central, LocalBusiness). @type zmień na dokładny podtyp z tabeli wyżej, a resztę pól podstaw własnymi danymi z tabeli faktów.

Godziny w różne dni, przerwa i sobota

Gdy godziny różnią się w zależności od dnia — inne w dni robocze, inne w sobotę, przerwa obiadowa w środku dnia — openingHoursSpecification przyjmuje listę osobnych obiektów, po jednym na każdy odrębny wzorzec godzin, dokładnie jak w przykładzie restauracji w dokumentacji Google, gdzie poniedziałek i wtorek mają inne godziny niż środa, czwartek i piątek, a sobota i niedziela własne wpisy (Google Search Central, LocalBusiness). Przerwę obiadową zapisuje się jako dwa osobne obiekty dla tego samego dnia — jeden do przerwy, drugi po niej.

Krok 4 — gdzie wkleić kod

Kod JSON-LD wkleja się w znaczniku <script type="application/ld+json">, zwykle w sekcji <head> strony. Jeśli firma ma jeden adres, wystarczy jeden blok kodu na stronie głównej albo — jeszcze lepiej — na wszystkich podstronach naraz, żeby każda z nich niosła ten sam opis firmy.

WordPress i konstruktor stron

W WordPressie kod najczęściej trafia przez pole na kod w ustawieniach motywu, wtyczkę SEO z sekcją danych strukturalnych albo edytor kodu w nagłówku szablonu. W konstruktorach stron zwykle jest osobne pole „kod w sekcji head” w ustawieniach strony lub całej witryny — dokładna nazwa różni się między platformami, ale mechanizm jest ten sam: wklejony kod ląduje w <head> bez zmian.

Firma z dwoma adresami

Gdy firma ma dwa lub więcej punktów, każdy adres opisuje osobny blok danych strukturalnych na osobnej podstronie kontaktowej tego oddziału, z własnym telefonem i własnymi godzinami — tak samo jak w profilu Google, gdzie każdy oddział ma osobny profil z godzinami otwarcia tego oddziału, a główna siedziba dodatkowo swój (Google, wytyczne dotyczące reprezentowania firmy). Jeden wspólny blok na wszystkie adresy naraz myli maszynę co do tego, gdzie faktycznie jest firma.

Krok 5 — sprawdź kod, zanim go opublikujesz

Rich Results Test to narzędzie Google do walidacji danych strukturalnych, które w części przypadków pokazuje też podgląd wyniku w wyszukiwarce (Google Search Central, wprowadzenie do danych strukturalnych). Działa na dwa sposoby: wklej adres opublikowanej strony albo wklej sam kod, jeszcze zanim trafi na serwer.

Narzędzie rozróżnia błędy krytyczne, które blokują funkcję całkowicie, od ostrzeżeń — pól zalecanych, ale niewymaganych. Po publikacji tę samą stronę warto obserwować w raporcie wyników rozszerzonych w Search Console, bo strona, która działała poprawnie w dniu wdrożenia, może się zepsuć po kolejnej zmianie szablonu.

Częste błędy, które psują dane strukturalne

Najczęstszy błąd to rozjazd między kodem a stroną: godziny w JSON-LD inne niż w widocznej treści, albo dane o usłudze, której strona w ogóle nie opisuje. Google traktuje to jako wprowadzanie w błąd — dane strukturalne mają odpowiadać treści widocznej dla użytkowników, nie stanowić osobnej, wygodniejszej wersji rzeczywistości (Google Search Central, zasady danych strukturalnych).

Drugi błąd to wymyślanie ocen i opinii o sobie w kodzie, których nikt naprawdę nie wystawił — to samo zastrzeżenie o zgodności z rzeczywistością dotyczy ocen tak samo jak godzin i adresu. Trzeci — skopiowanie jednego bloku kodu na wszystkie podstrony-klony bez zmiany adresu i telefonu, co przy kilku oddziałach prowadzi do tego, że każda podstrona twierdzi, że jest tym samym miejscem.

Kto aktualizuje dane, gdy coś się zmienia

Dopóki te trzy miejsca — strona, kod i profil Google — aktualizuje jedna osoba według jednej listy, rozjazd się nie pojawia. Gdy każde z nich zmienia ktoś inny w innym momencie, rozjazd jest kwestią czasu.

Zrób to sam w godzinę

1. Spisz fakty w jednej tabeli: nazwa, adres, telefon, URL, godziny po dniach, priceRange.
2. Wybierz dokładny podtyp z tabeli branż wyżej, a jeśli żaden nie pasuje — zostań przy LocalBusiness.
3. Skompletuj kod JSON-LD na wzór przykładu, podstawiając własne dane.
4. Wklej go w <head> strony głównej albo wszystkich podstron.
5. Sprawdź kod w Rich Results Test i popraw błędy krytyczne.
6. Zapisz w kalendarzu datę sprawdzenia i wróć do tabeli przy każdej zmianie godzin, telefonu albo adresu.

Jak to wygląda w systemie

W Aurze to zaczyna się od SEO i map (SEO i mapy), gdzie porządkujemy profil Google i uzupełniamy stronę o dane, których szuka wyszukiwarka. Samą stronę i jej kod budujemy w usłudze Strony i sklepy, a spójność opisu firmy na stronie, w danych strukturalnych i w źródłach, które go potwierdzają, pilnuje GEO / AI visibility. Gdy dane firmy żyją w kilku systemach naraz, Integracje łączą je tak, żeby aktualizacja w jednym miejscu rozchodziła się dalej sama. System nie obiecuje wyników rozszerzonych — pilnuje tylko, żeby dane były spójne wszędzie, gdzie się pojawiają.

Więcej o tym, kto w ogóle powinien aktualizować dane firmy na bieżąco i dlaczego to się rozjeżdża w praktyce, opisujemy w danych restauracji w Google, na stronie i na portalach — mechanizm aktualizacji jest ten sam niezależnie od branży. Jeśli dopiero zaczynasz porządkować obecność firmy w sieci, cztery progi zamiast ogólnej analizy są rozpisane w automatyzacji małej firmy. O tym, dlaczego niespójne albo niepełne dane odstraszają zapytania, zanim ktoś w ogóle zadzwoni, piszemy w analizie stron warszawskich firm, a jak ustawić liczby, na które właściciel naprawdę patrzy, pokazujemy w automatyzacji raportowania.

Najczęściej zadawane pytania

Czy dane strukturalne poprawią moją pozycję w Google?

Nie ma na to gwarancji. Google wprost zastrzega, że oznaczenie umożliwia pokazanie danej funkcji wyników rozszerzonych, ale jej nie zapewnia — o pozycji decydują inne czynniki.

Czy muszę używać dokładnie podtypu LocalBusiness, jeśli mam gabinet medyczny?

Lepiej użyć dokładniejszego podtypu, jeśli istnieje — na przykład MedicalBusiness dla gabinetu medycznego. Dokładniejszy typ jednoznaczniej opisuje, czym firma się zajmuje, niż ogólny LocalBusiness.

Co zrobić, jeśli Rich Results Test pokaże ostrzeżenie, a nie błąd?

Ostrzeżenia dotyczą pól zalecanych, ale niewymaganych — strona będzie działać bez nich, ale warto je uzupełnić, jeśli dane są dostępne, bo zwiększają kompletność opisu.

Czy mogę wpisać w kodzie wyższą ocenę, niż firma naprawdę ma?

Nie. Dane strukturalne mają odpowiadać rzeczywistości i treści widocznej dla użytkowników — wymyślona ocena albo opinia, której nikt nie wystawił, łamie zasady Google i może skończyć się ręczną karą.

Jak często sprawdzać dane strukturalne w Rich Results Test?

Przy każdej zmianie szablonu strony i przy każdej zmianie godzin, telefonu albo adresu — strona, która działała poprawnie w dniu wdrożenia, może się zepsuć po kolejnej aktualizacji motywu czy wtyczki.

Czy jeden blok kodu na wszystkich podstronach wystarczy dla firmy z jednym adresem?

Tak, jeśli firma ma jeden adres, jeden wspólny blok kodu na wszystkich podstronach jest wystarczający i prostszy w utrzymaniu niż osobne bloki na każdej podstronie.