Schemat LocalBusiness

TL;DR — LocalBusiness schema to kod dodawany do strony, który informuje wyszukiwarki o faktach dotyczących fizycznej firmy — jej nazwie, adresie, numerze telefonu i godzinach otwarcia. Google wymaga tylko dwóch rzeczy (nazwy i adresu); wszystko inne jest opcjonalne, ale wzbogaca wynik. To nie to samo co utworzenie profilu Google Business Profile, a jego dodanie nie gwarantuje efektownego wyniku w wyszukiwarce — jedynie czyni Cię kwalifikującym się do niego.

Czym jest LocalBusiness schema

Gdy wyszukiwarka czyta Twoją stronę „Kontakt”, widzi tekst. Nie potrafi automatycznie odróżnić adresu ulicy od numeru telefonu czy godzin otwarcia tak, jak Ty to robisz. LocalBusiness schema opisuje to w kodzie: to jest nazwa, to jest adres, to jest numer telefonu, to są godziny otwarcia.

Wykorzystuje wspólny słownik ze strony schema.org — ten sam słownik, który stoi za wszystkimi znacznikami schema — i zwykle zapisuje się go jako JSON-LD, mały blok kodu umieszczony na stronie bez zmiany jej wyglądu. Evidence for this claim Schema.org LocalBusiness is a subtype of both Organization and Place for describing a physical business or branch. Scope: Schema.org vocabulary; Google applies separate local-business search requirements. Confidence: high · Verified: 2026-07-14 Schema.org: LocalBusiness

Czego naprawdę potrzebuje Google

Oto zaskakująca część. schema.org definiuje dziesiątki właściwości, które możesz dodać, ale Google wymaga tylko dwóch:

• name — nazwa firmy.
• address — fizyczny adres ulicy.

Wszystko inne — numer telefonu, godziny otwarcia, przedział cenowy, współrzędne mapy — jest zalecane. Evidence for this claim Google's LocalBusiness feature documentation requires name and address and recommends additional applicable business details. Scope: Google Search LocalBusiness requirements; eligibility and display are not guaranteed. Confidence: high · Verified: 2026-07-14 Google: LocalBusiness structured data Nie musisz tego uwzględniać, ale im więcej dokładnych szczegółów dodasz, tym bardziej kompletna może być Twoja wizytówka w wynikach wyszukiwania.

Dwie rzeczy, które początkujący robią źle

1. Schema to nie Twój profil Google Business Profile. To dwa różne systemy. Twój profil Google Business Profile (darmowa wizytówka, którą zakładasz na business.google.com) to podstawa Twojej pinezki w Google Maps i „lokalnej paczki” trzech firm pod mapą. LocalBusiness schema to osobny kod na Twojej własnej stronie. Jedno nie zastępuje drugiego — zazwyczaj chcesz mieć oba, a Google rozlicza je osobno.

2. Nie oznaczaj własnej oceny gwiazdkowej. Kusi, aby dodać własną średnią pięciu gwiazdek za pomocą aggregateRating, ale wytyczne Google mówią, że ta właściwość jest przeznaczona dla witryn, które recenzują inne firmy (np. katalog recenzujący restauracje), a nie dla oceny samej firmy. Oznaczanie własnych opinii jako oceny to „samouwielbienie” i łamie zasady.

Jeszcze jedno: użyj konkretnego typu. Jeśli prowadzisz restaurację, oznacz ją jako Restaurant, a nie ogólny LocalBusiness. Google wyraźnie prosi o najbardziej konkretny typ, który pasuje.

Chcesz pełną wersję — dokładną tabelę właściwości, wybór podtypu, precyzję współrzędnych geograficznych, wzorce dla wielu lokalizacji i to, jak „spójność NAP” się w to wpisuje? Przełącz się na zakładkę Zaawansowane.

TL;DR — LocalBusiness to podtyp Organization i Place, więc pełna specyfikacja schema.org dziedziczy dziesiątki właściwości — ale Google wymaga tylko name + address i wykorzystuje ~12 zalecanych. Zyski: używaj najbardziej konkretnego podtypu (wiele typów umieszcza się w tablicy; additionalType nie jest obsługiwany), utrzymuj spójność NAP w swoim kodzie, profilu Google Business Profile i cytowaniach, oraz zadbaj o szczegóły — geo wymaga ≥5 miejsc po przecinku, priceRange musi pozostać poniżej 100 znaków. Nie oznaczaj własnego aggregateRating/review (to dla witryn recenzujących inne firmy; samouwielbienie łamie wytyczne), i nie traktuj schema jako zamiennika profilu Google Business Profile — to osobne rzeczy, rozliczane osobno, a prawidłowy kod tylko czyni Cię kwalifikującym się.

Gdzie to się znajduje: podtyp Organization i Place

Najbardziej przydatną rzeczą do zrozumienia na temat LocalBusiness jest jego pozycja w hierarchii schema.org. Jest podtypem zarówno Organization, jak i Place, co dokładnie wyjaśnia, dlaczego może przenosić ogólne właściwości firmy (name, logo, sameAs) oraz właściwości specyficzne dla lokalizacji (address, geo, openingHoursSpecification). To podwójne dziedziczenie jest również powodem, dla którego pełna specyfikacja jest tak obszerna — pobiera właściwości z dwóch dużych typów nadrzędnych.

To ma znaczenie dla sposobu, w jaki myślisz o szerszym obrazie Entity & Identity schema. Jednostka Organization obejmująca całą firmę (na całej stronie, na stronie głównej) i jednostka LocalBusiness dla każdej lokalizacji są powiązane, ale odrębne: jedna opisuje firmę, druga opisuje miejsce, do którego można wejść. W przypadku jednostki na poziomie firmy zobacz Organization schema; dla osób za nią stojących — Person schema.

Pełna specyfikacja a to, co faktycznie konsumuje Google

To jest rozróżnienie, które większość przewodników zaciera. schema.org/LocalBusiness dziedziczy dziesiątki właściwości z Organization i Place. Google konsumuje mały podzbiór. Nie myl “schema.org obsługuje X” z “Google zrobi coś z X.”

Wymagane (tylko dwa):

• address (PostalAddress) — fizyczna lokalizacja. Zalecenie Google: podaj jak najwięcej podwłaściwości adresu; im więcej podasz, tym wyższa jakość wyniku.
• name — nazwa firmy.

Zalecane (właściwości, które faktycznie wzbogacają wynik): aggregateRating, department, geo (z geo.latitude / geo.longitude), menu, openingHoursSpecification (z .opens, .closes, .dayOfWeek, .validFrom, .validThrough), priceRange, review, servesCuisine, telephone oraz url.

Wniosek dotyczący priorytetyzacji prac deweloperskich: opanuj wymaganą parę, a następnie dodaj zalecane właściwości, które sprawią, że Twoja wizytówka będzie bardziej kompletna (godziny otwarcia i geo dla sklepu; servesCuisine i menu dla restauracji). Wypełnianie niejasnych odziedziczonych właściwości, które Google ignoruje, to zmarnowany wysiłek.

Wybór właściwego podtypu

Google jest jednoznaczne: użyj najbardziej specyficznego podtypu LocalBusiness, jaki to możliwe — na przykład Restaurant, DaySpa, HealthClub. Ogólny LocalBusiness działa, ale konkretny podtyp daje wyszukiwarkom więcej do wykorzystania.

Kilka praktycznych mapowań:

• Restauracja / kawiarnia → Restaurant, CafeOrCoffeeShop, BarOrPub (w ramach FoodEstablishment)
• Kancelaria prawna → LegalService (lub Attorney)
• Dentysta / lekarz → Dentist, Physician (w ramach MedicalBusiness)
• Hydraulik / elektryk / generalny wykonawca → podtypy HomeAndConstructionBusiness (Plumber, Electrician, GeneralContractor)
• Firma konsultingowa / agencja bez lepszego dopasowania → ProfessionalService

Jeśli Twoja firma faktycznie obejmuje dwa typy, określ je jako tablicę — Google obsługuje w ten sposób wiele wartości @type. Zauważ, że additionalType nie jest obsługiwane w tym celu, więc nie sięgaj po nie.

Spójność NAP — schema, GBP i cytowania

“NAP” (Nazwa, Adres, Telefon) to od dawna stosowana dobra praktyka lokalnego SEO: ta sama nazwa, adres i telefon powinny pojawiać się identycznie w schema na stronie, w profilu Google Business Profile oraz w cytowaniach w katalogach (Yelp, BBB, katalogi branżowe). Niezgodności — stary numer lokalu tutaj, numer telefonu do śledzenia tam — zaciemniają sygnały, których wyszukiwarki używają do identyfikacji i zaufania do lokalizacji.

Jedna uczciwa uwaga: “NAP” to branżowy skrót, a nie termin ze specyfikacji Google. Dokumentacja Google dotycząca LocalBusiness nie używa tego słowa. Przedstawiaj to jako ugruntowany konsensus lokalnego SEO, a nie cytowany czynnik rankingowy Google. To wciąż ma znaczenie — prawdopodobnie bardziej niż jakakolwiek pojedyncza właściwość — ponieważ chodzi o spójność Twojej jednostki w całej sieci, a nie o jedno pole na jednej stronie.

Szczegóły implementacji, które sprawiają problemy

• Współrzędne geograficzne wymagają co najmniej 5 miejsc po przecinku. Google podaje, że precyzja musi wynosić co najmniej 5 miejsc po przecinku dla latitude i longitude. Częstym błędem jest zaokrąglanie współrzędnych przez CMS lub narzędzie do geokodowania do 2–3 miejsc — co wystarczy, aby umieścić pinezkę w złym bloku.
• priceRange ma limit 100 znaków. Musi być krótszy niż 100 znaków; przy 100 lub więcej Google w ogóle nie wyświetli zakresu cen. Trzymaj się krótko ($$ lub $10–30), a nie w formie akapitu.
• Składnia i przypadki brzegowe openingHoursSpecification. dayOfWeek akceptuje pełne adresy URL schema.org (https://schema.org/Monday) lub krótką nazwę (Monday). Przykłady Google używają 24-godzinnego formatu opens/closes bez sekund (hh:mm); szerszy typ Time w schema.org akceptuje również hh:mm:ss, jeśli Twój generator go dodaje. Cztery wzorce pokrywają prawie każdy przypadek, prosto z dokumentacji Google: zwykły dzień ("opens": "09:00", "closes": "17:00"), godziny przekraczające północ ("opens": "18:00", "closes": "03:00" dla nocnej soboty), otwarte cały dzień ("opens": "00:00", "closes": "23:59") i zamknięte cały dzień ("opens": "00:00", "closes": "00:00"). W przypadku zamknięć sezonowych lub świątecznych dodaj validFrom / validThrough w formacie YYYY-MM-DD (przykład Google używa "validFrom": "2015-12-23", "validThrough": "2016-01-05") — to niuans, który większość podstawowych implementacji całkowicie pomija.
• Konwencja nazewnictwa działów. Gdy zagnieżdżasz department, dołącz nazwę sklepu wraz z nazwą działu (np. “gMart” i “gMart Pharmacy”) — chyba że dział jest niezależną marką (np. “Best Buy” i “Geek Squad”), w którym to przypadku nazwij go samodzielnie.

Recenzje i oceny: pułapka samowystawianych ocen

To marnuje dużo wysiłku wdrożeniowego. Dokumentacja Google jasno stwierdza, że aggregateRating i review są zalecane tylko dla witryn, które zbierają recenzje na temat innych lokalnych firm — katalogu lub platformy recenzyjnej, a nie oceny samej firmy. Firma oznaczająca własną średnią gwiazdek na własnej stronie robi „samowystawianą recenzję”, co narusza wytyczne Google dotyczące fragmentów recenzji; Google zaprzestało wyświetlania samowystawianych gwiazdek recenzji dla LocalBusiness/Organization lata temu. Evidence for this claim Google's review snippet rules make self-serving reviews for LocalBusiness and Organization ineligible for the star review feature. Scope: Google Search review snippet eligibility policy; genuine third-party review contexts are treated differently. Confidence: high · Verified: 2026-07-14 Google: Review snippet structured data

Więc jeśli planowałeś wrzucić referencje ze strony głównej do aggregateRating: nie rób tego. Nie przyniesie to gwiazdek, które sobie wyobrażasz, i może przekroczyć granicę od „braku korzyści” do „naruszenia wytycznych”.

Firmy z wieloma lokalizacjami: jedna strona czy wiele

Konkurenci dają tu ogólnikowe rady, więc pozwól, że będę konkretny. Właściwy wzorzec zależy od Twojej architektury:

• Jedno LocalBusiness na stronę lokalizacji. Najczystsze podejście dla sieci: każda lokalizacja ma własną stronę z własnym znacznikiem LocalBusiness opisującym ten adres. Możesz powiązać je z rodzicem za pomocą parentOrganization / branchOf.
• Zagnieżdżanie w Organization. Na poziomie firmy możesz wyrazić markę jako Organization z lokalizacjami jako subOrganization.

Czego nie robić: układać płasko pięć niepowiązanych bloków LocalBusiness na swojej stronie głównej. Jeśli strona ma jeden adres w stopce, ale pięć różnych adresów LocalBusiness w znacznikach, staje się niejednoznaczne, o którym adresie strona faktycznie mówi. Oznacz lokalizację, którą strona reprezentuje.

Schema LocalBusiness a wizytówka Google Business Profile

Powiedzmy to wprost, bo większość przewodników to ukrywa: znaczniki schema ≠ Google Business Profile. To różne systemy, które Google rozlicza osobno.

• Twój profil Google Business zasila Mapy i lokalny pakiet bezpośrednio przez systemy Google. To główny czynnik widoczności w wynikach “near me” i lokalnym pakiecie.
• Znaczniki LocalBusiness na stronie to potwierdzający sygnał on-site, który Google może wykorzystać do paneli wiedzy i wzbogaconych wyników. To nie jest zamiennik profilu firmowego — a profil firmowy nie jest zamiennikiem znaczników na stronie.

Chcesz obu, utrzymywanych spójnie (to znowu kwestia NAP). Żaden z nich samodzielnie nie wykonuje pracy drugiego.

Co gwarantuje — a czego nie

Poprawne, zgodne z wytycznymi znaczniki sprawiają, że strona jest kwalifikowalna do lokalnego panelu wiedzy lub karuzeli firm — chociaż “kwalifikowalność” różni się zakresem w zależności od funkcji. Karuzela restauracji Google, na przykład, jest obecnie ograniczona do małego zestawu uczestniczących dostawców restauracji, więc same poprawne znaczniki Restaurant nie wprowadzą dowolnej strony do niej. Poza tym zakresem kwalifikowalność nadal nie gwarantuje wyświetlania — Google wprost mówi, że nie gwarantuje, iż funkcje korzystające z danych strukturalnych pojawią się w wynikach. I uwaga na statystyki krążące na blogach konkurencji: liczby takie jak “30–50% częściej w lokalnym pakiecie” czy “20–35% wzrost CTR” krążą szeroko bez pierwotnego źródła. Traktuj je jako niezweryfikowane twierdzenia marketingowe, a nie potwierdzone przez Google wyniki.

Zweryfikuj przed wdrożeniem

1. Dodaj wymagane właściwości (name, address), a następnie zalecane, które pasują do Twojej firmy.
2. Zweryfikuj za pomocą Rich Results Test i Schema Markup Validator.
3. Wdróż, a następnie sprawdź za pomocą URL Inspection w Search Console i poproś o ponowne przeszukanie.
4. Monitoruj raporty danych strukturalnych w Search Console w czasie.

Zweryfikuj, potem wdróż — nie odwrotnie.

Podsumowanie AI

Skrócona wersja wersji zaawansowanej:

• Co to jest: dane strukturalne schema.org/LocalBusiness (zwykle JSON-LD) opisujące fizyczną firmę — nazwę, adres, telefon, godziny otwarcia, geolokalizację, przedział cenowy.
• Hierarchia: podtyp zarówno Organization, jak i Place, dlatego dziedziczy dziesiątki właściwości i dlatego pełna specyfikacja jest obszerna.
• Pełna specyfikacja a Google: Google wymaga tylko name + address i korzysta z ~12 zalecanych właściwości (geo, openingHoursSpecification, priceRange, telephone, url, department, menu, servesCuisine, plus aggregateRating/review). Nie zakładaj, że „schema.org obsługuje X” oznacza „Google używa X”.
• Podtyp: używaj najbardziej szczegółowego podtypu (Restaurant, LegalService, Dentist), a nie ogólnego LocalBusiness. Wiele typów umieszczaj w tablicy; additionalType nie jest obsługiwany.
• Spójność NAP: utrzymuj identyczną nazwę/adres/telefon w znacznikach, profilu Google Business Profile i cytowaniach. „NAP” to skrót branżowy, a nie termin specyfikacji Google — ale spójność ma znaczenie bardziej niż jakakolwiek pojedyncza właściwość.
• Pułapki szczegółów: geo wymaga ≥5 miejsc po przecinku; priceRange musi mieć mniej niż 100 znaków, inaczej Google go ignoruje; godziny otwarcia używają hh:mm:ss oraz krótkiego lub pełnego dayOfWeek, z validFrom/validThrough dla sezonowych zamknięć.
• Opinie: aggregateRating/review są przeznaczone dla witryn oceniających inne firmy. Oznaczanie własnej oceny to samouwielbienie naruszające wytyczne Google (gwiazdki samouwielbienia zostały usunięte około 2019 roku).
• Wiele lokalizacji: jeden LocalBusiness na stronę lokalizacji (powiązany z parentOrganization/branchOf) lub zagnieżdżony w Organization przez subOrganization. Nie układaj płasko niepowiązanych adresów na stronie głównej.
• Schema ≠ Google Business Profile: osobne systemy, uzgadniane osobno. GBP zasila Mapy/pakiet lokalny; znaczniki na stronie potwierdzają dla paneli wiedzy. Chcemy obu.
• Brak gwarancji: prawidłowe znaczniki czynią Cię kwalifikowanym, nie gwarantują. Ignoruj niecytowane statystyki „30–50% więcej w pakiecie lokalnym” / „20–35% CTR” — brak źródła pierwotnego.
• Walidacja: Rich Results Test + Schema Markup Validator, następnie URL Inspection i raporty Search Console. Waliduj, potem wdrażaj.

Oficjalna dokumentacja

Dokumentacja źródłowa od wyszukiwarek i schema.org.

Google

• Local business (LocalBusiness) structured data — źródło prawdy: wymagane/zalecane właściwości, wskazówki dotyczące podtypów, precyzja geo, limit priceRange, nazewnictwo działów i proces walidacji.
• Organization structured data — encja na poziomie firmy, dla rozróżnienia LocalBusiness-vs-Organization.
• Review snippet structured data — wytyczne stojące za ograniczeniem samouwielbienia w aggregateRating/review.
• Rich Results Test — sprawdza kwalifikowalność do wyników rozszerzonych i błędy wymaganych właściwości.
• Schema Markup Validator — waliduje dowolny typ schema.org, w tym LocalBusiness.

schema.org

• schema.org/LocalBusiness — pełne słownictwo: każda odziedziczona właściwość z Organization i Place (strona „pełnej specyfikacji” w porównaniu i kontraście).

Bing / Microsoft

• Marking Up Your Site with Structured Data — Bing Webmaster Tools — ogólne wskazówki Bing dotyczące danych strukturalnych i walidator (Schema.org / Microdata / RDFa / OpenGraph).
• Bing Places for Business — osobny produkt Bing do list, odpowiednik Google Business Profile (ta sama różnica „platforma list ≠ znaczniki na stronie”).

Cytaty ze źródła

Oświadczenia na piśmie z dokumentacji LocalBusiness Google. Tam, gdzie strona udostępnia tekst, link jest linkiem bezpośrednim, który przeskakuje do cytowanego fragmentu.

Dokumenty Google — co umożliwiają

• “When users search for businesses on Google Search or Maps, Search results may display a prominent Google knowledge panel with details about a business that matched the query. When users search for a type of business (for example, ‘best NYC restaurants’), they may see a carousel of businesses related to the query.” (tłumaczenie) „Gdy użytkownicy szukają firm w Google Search lub Maps, wyniki wyszukiwania mogą wyświetlać widoczny panel wiedzy Google ze szczegółami dotyczącymi firmy, która pasowała do zapytania. Gdy użytkownicy szukają typu firmy (na przykład „najlepsze restauracje w Nowym Jorku”), mogą zobaczyć karuzelę firm związanych z zapytaniem.” Strukturalne dane lokalnej firmy

Dokumenty Google — wskazówki dotyczące podtypów

• “Use the most specific LocalBusiness sub-type possible; for example, Restaurant, DaySpa, HealthClub, and so on.” (tłumaczenie) „Użyj najbardziej szczegółowego podtypu LocalBusiness, jaki to możliwe; na przykład Restaurant, DaySpa, HealthClub i tak dalej.” Przejdź do cytatu

Dokumenty Google — precyzja geograficzna

• “The precision must be at least 5 decimal places.” (tłumaczenie) „Precyzja musi wynosić co najmniej 5 miejsc po przecinku.” Przejdź do cytatu

Dokumenty Google — recenzje na własny temat

• W przypadku aggregateRating i review: “This property is only recommended for sites that capture reviews about other local businesses.” (tłumaczenie) „Ta właściwość jest zalecana tylko dla witryn, które zbierają recenzje o innych lokalnych firmach.” Przejdź do cytatu

Ściągawka właściwości

Wymagane vs. zalecane (co Google faktycznie konsumuje)

Typowe podtypy LocalBusiness

Szybkie fakty

• Wymagane = 2 (name, address); wszystko inne jest zalecane.
• Użyj najbardziej szczegółowego podtypu; wiele typów umieszcza się w tablicy; additionalType nie jest obsługiwane.
• Geo ≥ 5 miejsc po przecinku; priceRange < 100 znaków.
• aggregateRating/review = dla witryn recenzujących inne firmy, nie własne recenzje.
• Schema ≠ Google Business Profile — osobne systemy, uzgadniane osobno.
• Spójność NAP (termin branżowy, nie słowo ze specyfikacji Google) w znacznikach, GBP i cytowaniach ma większe znaczenie niż jakakolwiek pojedyncza właściwość.
• Poprawne znaczniki = kwalifikacja, nigdy gwarancja. Waliduj → wdrażaj.

Antywzorce: jak znaczniki LocalBusiness zawodzą

Błędy, które widzę najczęściej, i co zamiast nich robić.

1. Niespójność NAP. Twój schema mówi “123 Main St, Suite 200,” Twój Google Business Profile mówi “123 Main Street,” a Yelp nadal ma Twój stary numer telefonu. Te niezgodności podważają cały sens — wyszukiwarki używają spójności nazwy/adresu/telefonu w sieci, aby zidentyfikować i zaufać lokalizacji. Rozwiązanie: wybierz jeden kanoniczny NAP i spraw, aby znaczniki, Business Profile i każde cytowanie dokładnie się z nim zgadzały.

2. Używanie ogólnego typu, gdy istnieje konkretny. Oznaczanie restauracji jako gołego LocalBusiness, gdy istnieje Restaurant, wyrzuca sygnał, o który Google wyraźnie prosi. Rozwiązanie: użyj najbardziej szczegółowego podtypu, który pasuje (Restaurant, LegalService, Dentist); użyj wielu wartości @type w tablicy, jeśli naprawdę obejmujesz dwa — ale nie additionalType.

3. Własne recenzje. Oznaczanie własnych opinii jako aggregateRating/review, aby zdobyć oceny w gwiazdkach. Wytyczne Google zastrzegają te właściwości dla witryn recenzujących inne firmy; własne gwiazdki zostały porzucone lata temu i może to prowadzić do naruszenia wytycznych. Rozwiązanie: nie oceniaj siebie. Zdobywaj prawdziwe recenzje stron trzecich (które żyją na platformach recenzyjnych, nie w Twoich znacznikach).

4. Układanie wielu lokalizacji na jednej stronie. Pięć różnych bloków LocalBusiness z pięcioma różnymi adresami na jednej stronie głównej, gdy strona naprawdę reprezentuje jeden podmiot (lub żaden). To niejednoznaczne, którego adresu dotyczy strona. Rozwiązanie: jeden LocalBusiness na stronę lokalizacji (powiąż z marką przez parentOrganization/branchOf) lub zamodeluj firmę jako Organization z subOrganization.

5. Mylenie schema z Google Business Profile. Zakładanie, że znaczniki na stronie wprowadzą Cię do Maps i lokalnego pakietu, albo że posiadanie Business Profile oznacza, że nie potrzebujesz schema. To osobne systemy, które Google uzgadnia osobno — GBP napędza Maps/lokalny pakiet, schema potwierdza dla Panelów wiedzy. Rozwiązanie: skonfiguruj oba i utrzymuj je spójne.

Dodatkowe pułapki: zaokrąglanie współrzędnych geo poniżej 5 miejsc po przecinku (pinezka w złym bloku), priceRange powyżej 100 znaków (Google po cichu to pomija) i oczekiwanie gwarantowanego wyniku rozszerzonego z poprawnych znaczników (kwalifikacja ≠ wyświetlanie).

Sprawdź się: LocalBusiness Schema

Pięć szybkich pytań o schema LocalBusiness — wymagane właściwości, podtypy, pułapka recenzji i związek z Google Business Profile. Wybierz odpowiedź na każde, a następnie sprawdź.

Który podtyp LocalBusiness powinienem zastosować?

Wskazówki dotyczące podtypów z artykułu zamieniają się w prostą gałąź: dopasuj kategorię swojej firmy do najbardziej szczegółowego podtypu LocalBusiness, który definiuje schema.org, i używaj ogólnego typu tylko wtedy, gdy nic nie pasuje.

Jedna strona na lokalizację, czy zagnieżdżać w Organization?

Drugi prawdziwy punkt rozgałęzienia w artykule ma charakter architektoniczny: jak oznaczyć firmę z więcej niż jedną lokalizacją fizyczną?

Przykłady praktyczne: JSON-LD LocalBusiness

Trzy opatrzone komentarzami bloki, każdy zbudowany z wymaganych i zalecanych właściwości omówionych powyżej.

Przykład 1: minimalny działający znacznik (tylko wymagane właściwości)

{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "name": "Riverside Dental Care",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "412 Riverside Ave",
    "addressLocality": "Columbus",
    "addressRegion": "OH",
    "postalCode": "43215",
    "addressCountry": "US"
  }
}

• name i address to jedyne dwie właściwości wymagane przez Google — to przechodzi walidację, ale pozostawia zalecane właściwości (i konkretny podtyp) niewykorzystane.
• Nawet na tym minimalnym poziomie zalecenie Google brzmi: uwzględnij jak najwięcej podwłaściwości address — dlatego wszystkie pięć jest tutaj wypełnionych zamiast pojedynczej linii streetAddress.

Przykład 2: konkretny podtyp z wypełnionymi zalecanymi właściwościami

{
  "@context": "https://schema.org",
  "@type": "Dentist",
  "name": "Riverside Dental Care",
  "telephone": "+1-614-555-0142",
  "url": "https://www.riversidedentalcare.example/",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "412 Riverside Ave",
    "addressLocality": "Columbus",
    "addressRegion": "OH",
    "postalCode": "43215",
    "addressCountry": "US"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 39.96199,
    "longitude": -83.00275
  },
  "priceRange": "$$",
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday"],
      "opens": "08:00:00",
      "closes": "17:00:00"
    }
  ]
}

• @type to Dentist, a nie ogólny LocalBusiness — konkretny podtyp, o który prosi Google.
• geo.latitude/geo.longitude mają po 5 miejsc po przecinku, co odpowiada wymaganiu Google dotyczącemu minimalnej precyzji.
• priceRange to krótkie $$, znacznie poniżej limitu 100 znaków.
• openingHoursSpecification używa czasu hh:mm:ss i krótkich nazw dayOfWeek, pogrupowanych dla dni o tych samych godzinach otwarcia.

Przykład 3: restauracja z notatką o sezonowym zamknięciu i zagnieżdżaniu działów

{
  "@context": "https://schema.org",
  "@type": "Restaurant",
  "name": "gMart Pharmacy",
  "servesCuisine": "American",
  "menu": "https://www.example-diner.example/menu/",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "88 Harbor Rd",
    "addressLocality": "Portland",
    "addressRegion": "ME",
    "postalCode": "04101",
    "addressCountry": "US"
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": "https://schema.org/Monday",
      "opens": "11:00:00",
      "closes": "21:00:00",
      "validFrom": "2026-01-01",
      "validThrough": "2026-12-24"
    }
  ]
}

• servesCuisine i menu to zalecane właściwości, które mają największe znaczenie dla podtypu FoodEstablishment, takiego jak Restaurant.
• dayOfWeek używa tutaj pełnej formy URL schema.org zamiast krótkiej nazwy — obie są poprawne, to tylko pokazuje alternatywę.
• validFrom/validThrough oznaczają sezonowe okno w formacie YYYY-MM-DD — szczegół, który większość podstawowych implementacji pomija.
• Wartość name jest zgodna z konwencją nazewnictwa działów z artykułu: “gMart Pharmacy” zachowuje nazwę sklepu z nazwą działu, co jest wzorem do stosowania, chyba że dział jest niezależnie markowanym podmiotem (jak “Best Buy” i “Geek Squad”).

Trzy modele myślowe dotyczące schematu LocalBusiness

1. Pełna specyfikacja a to, co Google faktycznie konsumuje. schema.org/LocalBusiness dziedziczy dziesiątki właściwości zarówno z Organization, jak i Place, ale Google wymaga tylko name + address i w praktyce konsumuje około tuzina zalecanych właściwości (geo, openingHoursSpecification, priceRange, telephone, url, department, menu, servesCuisine, aggregateRating/review). Zasada: nigdy nie zakładaj, że “schema.org obsługuje właściwość X” oznacza “Google zrobi coś z właściwością X”. Priorytetowo traktuj wymaganą parę, potem zalecane właściwości pasujące do Twojej firmy, a niejasne odziedziczone właściwości, które Google ignoruje, traktuj jako zmarnowany wysiłek wdrożeniowy.

2. Schemat to nie Google Business Profile. To dwa oddzielne systemy, które Google uzgadnia niezależnie. Google Business Profile zasila Mapy i lokalny pakiet bezpośrednio przez własne systemy Google — to główny czynnik widoczności w wynikach “near me” i lokalnym pakiecie. Schemat LocalBusiness na stronie to potwierdzający sygnał na stronie, który Google może wykorzystać do Panelów wiedzy i wzbogaconych wyników. Żaden nie zastępuje drugiego; zasada brzmi: “skonfiguruj oba i nie oczekuj, że jeden wykona pracę drugiego.”

3. NAP jako spójność, a nie pojedyncze pole. Spójność nazwy/adresu/telefonu w znacznikach schematu, Google Business Profile i cytowaniach w katalogach nie polega na tym, że jakakolwiek pojedyncza właściwość jest poprawna — chodzi o spójność Twojego podmiotu w całej sieci. Niezgodny numer mieszkania lub nieaktualny numer telefonu śledzącego w jednym miejscu zaciemnia sygnały, których silniki używają do identyfikacji i zaufania lokalizacji, nawet jeśli każde pole jest technicznie poprawne na swojej stronie. Traktuj “NAP” jako ugruntowany konsensus lokalnego SEO (sam termin nie występuje w dokumentacji Google), a nie pojedyncze pole do zaznaczenia raz.

Narzędzia do walidacji znaczników LocalBusiness

• Rich-Result Eligibility Checker — moje własne darmowe narzędzie. Wklej swój JSON-LD LocalBusiness, stronę HTML lub pobierz żywy URL, a pokaże dokładnie, które wymagane pola brakują, a które zalecane pomijasz, specyficzne dla lokalnego wyniku rozszerzonego. Działa w całości w Twojej przeglądarce, więc nic, co wkleisz, nie opuszcza Twojego urządzenia.
• Schema Markup Validator — również moje. Waliduje słownictwo schema.org JSON-LD bezpośrednio (nie tylko podzbiór specyficzny dla Google), sprawdza referencje @id między blokami, jeśli łączysz LocalBusiness z nadrzędną organizacją, i zwraca poprawiony, gotowy do skopiowania blok.
• Rich Results Test — własne narzędzie Google. Użyj go po dwóch powyższych, aby potwierdzić, że żywy parser Google zgadza się, że strona jest kwalifikowalna.
• URL Inspection (Search Console) — po wdrożeniu sprawdź, jak Google faktycznie przeszukał i wyrenderował stronę, oraz poproś o ponowne przeszukanie.

Propozycja: uruchom Rich-Result Eligibility Checker lub Schema Markup Validator zanim opublikujesz zmianę, a następnie potwierdź za pomocą Rich Results Test i URL Inspection po — to ta sama sekwencja, którą soczewka Validation Tests poniżej szczegółowo omawia.

Udowodnienie, że zmiana znaczników LocalBusiness zadziałała

Test 1: walidacja wymaganych właściwości i składni

Test do uruchomienia: Wklej zaktualizowany JSON-LD do mojego Rich-Result Eligibility Checker lub Schema Markup Validator. Oczekiwany wynik: Brak błędów brakujących wymaganych pól dla name lub address, a narzędzie pokazuje lokalny wynik rozszerzony jako kwalifikowalny. Interpretacja błędu: Oznaczona brakująca właściwość oznacza, że naprawdę nie jest obecna w opublikowanych znacznikach — sprawdź ponownie źródło JSON-LD, zamiast zakładać problem z buforowaniem. Okno monitorowania: Natychmiastowe — narzędzie czyta znaczniki bezpośrednio, bez oczekiwania na przeszukanie. Wyzwalacz wycofania: Walidacja nadal kończy się niepowodzeniem po bezpośredniej poprawce szablonu — wycofaj zmianę i porównaj ponownie z ostatnim znanym poprawnym JSON-LD.

Test 2: własny Rich Results Test Google zgadza się

Test do uruchomienia: Uruchom żywy URL przez Rich Results Test Google. Oczekiwany wynik: Strona jest wykrywana jako kwalifikowalna dla lokalnego wyniku biznesowego, a wymagane i zalecane właściwości widziane przez parser Google zgodne z tym, co opublikowałeś. Interpretacja błędu: Jeśli narzędzie Google nie zgadza się z dwoma narzędziami powyżej, żywa strona prawdopodobnie różni się od tej, którą zweryfikowałeś — sprawdź warstwę buforowania lub krok budowy serwujący nieaktualne znaczniki. Okno monitorowania: Natychmiastowe. Wyzwalacz wycofania: Kontrola kwalifikowalnej strony nadal pokazuje brakujące wymagane pola po wdrożeniu — poprawka nie dotarła do żywej strony.

Test 3: raporty danych strukturalnych Search Console w czasie

Test do uruchomienia: Raporty danych strukturalnych / Ulepszeń Search Console dla dotkniętych URL-i, po poproszeniu o ponowne przeszukanie przez URL Inspection. Oczekiwany wynik: Liczba URL-i z błędami LocalBusiness spada do zera, a wcześniej oznaczone strony przechodzą do prawidłowego zasobnika. Interpretacja błędu: Nadal oznaczone po ponownym przeszukaniu oznacza albo poprawka nie dotarła do wersji pobranej przez Google, albo brakuje również innej wymaganej właściwości — uruchom ponownie Test 1 dla dokładnego URL-a wymienionego przez Search Console. Okno monitorowania: 2–4 tygodnie — aktualizacje raportów danych strukturalnych opóźniają się w stosunku do pojedynczego ponownego przeszukania. Wyzwalacz wycofania: Liczby błędów rosną zamiast spadać po szerokim wdrożeniu zmiany — wycofaj i ponownie zweryfikuj przed ponownym wdrożeniem.

Dziennik zmian