Część przewodnika: SEO lokalne 2026, kompletny przewodnik dla małej firmy → Ten artykuł jest częścią praktyczną: gotowy kod danych strukturalnych i jego walidacja.

Masz zdecydowane, że chcesz dane strukturalne na stronie, i szukasz kodu do wklejenia, a nie kolejnego wyjaśnienia, po co to komu. Ten wpis jest właśnie tym: szablonem LocalBusiness, listą pól i procedurą sprawdzenia, czy działa.

Jeśli natomiast dopiero rozważasz, czy w ogóle warto, i chcesz wiedzieć, co schema realnie daje, a czego nie obiecuje, zacznij od wpisu o tym, czym jest schema.org i jak działa. Tutaj zakładam, że decyzja już zapadła, i przechodzę do wdrożenia.

Jedno zastrzeżenie na wejście, żeby nie było nieporozumień co do efektu. Google wprost zaznacza, że nie gwarantuje pojawienia się danych strukturalnych w wynikach, nawet gdy strona jest oznaczona poprawnie (fakt, zasady Google, weryfikacja 16 lipca 2026). Poprawny kod daje kwalifikację, nie obietnicę.

Gotowy szablon LocalBusiness

Poniżej kompletny, działający przykład dla salonu fryzjerskiego w Krakowie. Podmień dane na swoje. Celowo nie ma tu aggregateRating, i to nie przeoczenie, tylko decyzja, którą tłumaczę w osobnej sekcji niżej.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "HairSalon",
  "@id": "https://twojafirma.pl/#firma",
  "name": "Salon Marii",
  "url": "https://twojafirma.pl/",
  "telephone": "+48123456789",
  "image": [
    "https://twojafirma.pl/img/salon-1x1.jpg",
    "https://twojafirma.pl/img/salon-4x3.jpg",
    "https://twojafirma.pl/img/salon-16x9.jpg"
  ],
  "priceRange": "80-300 zł",
  "description": "Krótki opis firmy, zgodny z tym, co widać na stronie.",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "Ulica Przykładowa 12",
    "addressLocality": "Kraków",
    "postalCode": "30-001",
    "addressRegion": "Małopolskie",
    "addressCountry": "PL"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 50.06143,
    "longitude": 19.93658
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
      "opens": "09:00",
      "closes": "18:00"
    },
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": "Saturday",
      "opens": "10:00",
      "closes": "14:00"
    }
  ],
  "sameAs": [
    "https://www.facebook.com/twojafirma",
    "https://www.instagram.com/twojafirma"
  ]
}
</script>

Nadrzędna zasada przy podmianie danych jest jedna: wszystko, co wpiszesz, musi być prawdą widoczną na stronie. Zasady Google zakazują oznaczania treści niewidocznej dla czytelnika (fakt, zasady Google, weryfikacja 16 lipca 2026). Jeśli godzin nie ma na stronie, nie wpisuj ich do znacznika.

Pola wymagane: są tylko dwa

To najczęstsze zaskoczenie przy pierwszym wdrożeniu. W dokumentacji LocalBusiness Google jako wymagane podaje dokładnie dwie właściwości: name, czyli nazwę firmy, i address, czyli jej fizyczną lokalizację (fakt, dokumentacja LocalBusiness, weryfikacja 16 lipca 2026).

Cała reszta, łącznie z telefonem i godzinami otwarcia, jest opisana jako zalecana. Znacznik bez nich przejdzie walidację i nie będzie błędem. Warto je uzupełniać dlatego, że opisują firmę dokładniej, a nie dlatego, że ktoś każe.

To rozróżnienie ma praktyczny sens. Kiedy narzędzie pokazuje ostrzeżenie przy braku priceRange, to nie jest awaria do gaszenia w nocy. To podpowiedź, że można podać więcej. Błędy naprawiaj od razu, ostrzeżenia traktuj jak listę życzeń.

2 pola wymaga Google w LocalBusiness: name i address

5 minimalna liczba miejsc po przecinku dla współrzędnych geo

0 gwarancji, Google nie obiecuje rozszerzonego wyniku nawet przy poprawnym kodzie

Pola zalecane i co realnie wnoszą

Dokumentacja Google wymienia konkretny zestaw właściwości zalecanych dla LocalBusiness. Poniżej te, które w małej firmie mają sens, razem z tym, co Google o nich pisze.

Pole	Co warto wiedzieć
`geo`	Współrzędne z dokładnością minimum 5 miejsc po przecinku
`telephone`	Główny numer kontaktowy, z numerem kierunkowym kraju
`url`	Pełny adres tej konkretnej lokalizacji, musi być działającym linkiem
`priceRange`	Tekst krótszy niż 100 znaków
`openingHoursSpecification`	Godziny z `dayOfWeek`, `opens`, `closes`, obsługuje daty sezonowe
`department`	Zagnieżdżony dział wewnątrz firmy, jeśli taki istnieje

Dwie rzeczy warto wyjaśnić, bo krążą o nich mity. geo nie jest czynnikiem rankingowym i jego brak nie obniża pozycji lokalnej. Dokumentacja opisuje je jako pole zalecane, którym doprecyzowujesz położenie, i tyle.

Z priceRange jest podobnie. Google podaje tylko limit długości, nie narzuca formatu. Zapis w złotówkach zamiast symboli w stylu dolarów jest po prostu czytelniejszy dla polskiego klienta, ale to moja opinia o czytelności, nie wymóg dokumentacji.

Wybierz konkretny typ, nie ogólny LocalBusiness

Google zaleca użycie możliwie najbardziej szczegółowego podtypu LocalBusiness (fakt, dokumentacja LocalBusiness, weryfikacja 16 lipca 2026). Konkretny typ daje pola, których typ ogólny nie ma. Poniżej najczęstsze dopasowania dla polskich firm.

Branża	Typ Schema.org
Restauracja	`Restaurant`
Kawiarnia	`CafeOrCoffeeShop`
Bar, pub	`BarOrPub`
Piekarnia, cukiernia	`Bakery`
Hotel, pensjonat	`Hotel`, `BedAndBreakfast`
Domki letniskowe	`Campground`, `LodgingBusiness`
Gabinet stomatologiczny	`Dentist`
Przychodnia, klinika	`MedicalClinic`
Weterynarz	`VeterinaryCare`
Salon kosmetyczny	`BeautySalon`
Salon fryzjerski	`HairSalon`
Masaż, SPA	`DaySpa`, `MassageStudio`
Siłownia, joga	`ExerciseGym`
Warsztat samochodowy	`AutoRepair`
Biuro nieruchomości	`RealEstateAgent`
Kancelaria prawna	`LegalService`
Doradca finansowy	`FinancialService`
Elektryk, hydraulik	`Electrician`, `Plumber`

Jedno ostrzeżenie o typie ProfessionalService, który wciąż podsuwa sporo poradników dla architektów, fotografów czy freelancerów. Schema.org opisuje go jako wycofany, bo mylił się użytkownikom z typem Service (fakt, schema.org, weryfikacja 16 lipca 2026).

Jeśli nie ma dokładnego dopasowania dla Twojej branży, użyj ogólnego LocalBusiness. To poprawny wybór, a nie ostateczność. Lepszy uczciwy typ ogólny niż naciągnięty typ szczegółowy, który opisuje firmę nietrafnie.

Opinie i gwiazdki: tu większość poradników się myli

To najważniejsza sekcja tego wpisu, bo dotyczy pola, które ludzie dodają jako pierwsze, licząc na gwiazdki w wynikach. Zwykle liczą na próżno, i lepiej wiedzieć to przed wdrożeniem.

Google podaje, że jeśli podmiot kontroluje opinie na swój temat, jego strony używające LocalBusiness lub innego typu Organization nie kwalifikują się do gwiazdek (fakt, dokumentacja Review snippet, weryfikacja 16 lipca 2026). Dotyczy to również opinii osadzonych przez widgety zewnętrzne.

Dokumentacja LocalBusiness mówi to samo z drugiej strony. aggregateRating i review są tam opisane jako zalecane wyłącznie dla witryn, które zbierają opinie o innych lokalnych firmach (fakt, dokumentacja LocalBusiness, weryfikacja 16 lipca 2026). Czyli dla katalogów i porównywarek, nie dla firmy opisującej samą siebie.

Wniosek praktyczny jest niewygodny, ale prosty. Wpisanie własnej średniej ocen do znacznika nie da gwiazdek przy Twoim wyniku. Jeśli je tam trzymasz, bo są prawdziwe i spójne z opiniami w Profilu Firmy w Google, nie jest to naruszenie zasad. Ale nie jest to też droga do gwiazdek.

Nie da się przy okazji obejść tego sprytem. Wymyślone oceny bez pokrycia w realnych opiniach to już fałszywe opinie, których Google zakazuje wprost. Co grozi za złamanie zasad, rozkłada wpis o schema.org: działanie ręczne odbiera kwalifikację do rozszerzonych wyników.

Gdzie wkleić kod

Tu można sobie odpuścić stres, bo dokumentacja jest liberalna. Google podaje, że blok skryptu z danymi JSON-LD może być umieszczony zarówno w sekcji head, jak i w body (fakt, dokumentacja Google, weryfikacja 16 lipca 2026). Obie lokalizacje są poprawne.

Rozpowszechniony jest też mit, że schema wstrzykiwane przez JavaScript nie liczy się i trzeba renderować je po stronie serwera. Google podaje wprost, że czyta dane JSON-LD wstrzykiwane dynamicznie do treści strony, na przykład przez kod JavaScript lub widgety w systemie CMS (fakt, ta sama dokumentacja).

Praktycznie oznacza to, że wtyczka WordPressa wstawiająca znacznik przez skrypt nie jest z definicji zepsuta. Renderowanie w HTML od razu jest wygodniejsze przy debugowaniu, bo widać kod w źródle strony bez otwierania narzędzi deweloperskich (obserwacja z wdrożeń, nie wymóg Google).

Co do @id, dokumentacja LocalBusiness w ogóle o nim nie wspomina, więc nie jest to pole wymagane ani zalecane przez Google. To konwencja porządkowa: nadajesz firmie stały identyfikator, a inne bloki na stronie odwołują się do niego zamiast powielać komplet danych (opinia oparta na wdrożeniach).

Walidacja krok po kroku

Sprawdzenie zajmuje kilka minut i nie wymaga płatnego narzędzia. Kolejność ma znaczenie, bo każde narzędzie łapie co innego.

Walidator schema.org jako pierwszy. Wyłapie literówki w nazwach pól, złe typy i błędy składni JSON, niezależnie od tego, co z tego wykorzysta Google.
Rich Results Test na żywym adresie. Pokazuje, jakie rozszerzone wyniki mogą zostać wygenerowane z danych strukturalnych strony, plus błędy i ostrzeżenia.
Google Search Console, raporty ulepszeń, po kilku dniach od zaindeksowania. Pokazuje, które typy Google faktycznie rozpoznał na Twoich stronach.

Rich Results Test przyjmuje też sam kod wklejony do okna, bez adresu. To wygodne przy pisaniu znacznika, zanim strona pójdzie na produkcję. Testuj wtedy fragment, potem i tak sprawdź żywy adres, bo dopiero on pokazuje, co realnie wychodzi z szablonu.

Czego walidacja nie powie: kiedy i czy w ogóle rozszerzony wynik się pojawi. Nie ma tu terminu do podania. Każdy, kto obiecuje gwiazdki w konkretną liczbę tygodni, obiecuje coś, czego Google nie obiecuje.

Częste błędy

Znacznik niezgodny z treścią strony. Godziny w kodzie inne niż na stronie, adres sprzed przeprowadzki, usługa, której na stronie nie ma. To najpoważniejszy błąd z tej listy, bo łamie zasady wprost, a nie tylko marnuje potencjał.

Liczenie na gwiazdki z własnego aggregateRating. Opisane wyżej. Pole samo w sobie nie jest zakazane, ale nie zrobi tego, po co zwykle się je dodaje.

priceRange jako liczba zamiast tekstu. To pole tekstowe. Wpisz "80-300 zł", a nie 80. Walidator to wyłapie od razu.

Współrzędne z dwoma miejscami po przecinku. Google podaje minimum pięć. Przy dwóch pinezka ląduje w innej części miasta, a pole traci sens.

Powielanie kompletu danych firmy w każdym bloku. Osobny Service, Article i okruszki, każdy z pełnym adresem i telefonem w środku. Nie jest to błąd walidacji, ale przy zmianie numeru telefonu masz do poprawienia siedem miejsc zamiast jednego (obserwacja z wdrożeń).

Wdrożenie i zero walidacji. Znacznik wstawiony raz i nigdy niesprawdzony, a potem przebudowa strony i cichy błąd składni. Sprawdzenie po każdej większej zmianie szablonu zajmuje minutę.

Rozbieżność z Profilem Firmy w Google. Nazwa, adres i telefon w znaczniku powinny zgadzać się z wizytówką. To nie jest wymóg z dokumentacji danych strukturalnych, ale utrzymywanie dwóch wersji danych firmy zawsze kończy się tym, że jedna jest nieaktualna (opinia).

Ile to kosztuje

Danych strukturalnych zwykle nie kupuje się osobno. Są częścią audytu albo budowy strony. Poniżej orientacyjne ceny startowe.

Zakres	Cena startowa
Audyt SEO, w tym przegląd danych strukturalnych	890 zł netto
Strona-wizytówka, znacznik w standardzie	1 299 zł netto
Strona firmowa, znacznik w standardzie	2 499 zł netto

Strony, które buduję, mają dane strukturalne wpisane w szablon od pierwszego dnia: konkretny typ firmy, usługi, okruszki nawigacji i artykuły blogowe, wszystko spięte jednym @id. Bez wtyczek i bez osobnej opłaty za sam znacznik. Pełny zakres jest w cenniku i na stronie pozycjonowania w Google.

Powiązane wpisy

Najczęstsze pytania

Jakie pola są wymagane w LocalBusiness?

Google wymaga dwóch: name i address. Cała reszta, czyli geo, telephone, url, priceRange, openingHoursSpecification i department, jest w dokumentacji LocalBusiness opisana jako zalecana, a nie obowiązkowa. Znacznik bez nich przejdzie walidację. Pola zalecane warto uzupełnić dlatego, że opisują firmę dokładniej, a nie dlatego, że bez nich kod jest błędny.

Czy aggregateRating na własnej stronie da gwiazdki w Google?

Nie. Google podaje w dokumentacji Review snippet, że jeśli podmiot kontroluje opinie na swój temat, jego strony z danymi LocalBusiness lub Organization nie kwalifikują się do gwiazdek. Dotyczy to też osadzonych widgetów z opiniami. W dokumentacji LocalBusiness aggregateRating i review są zalecane tylko dla serwisów zbierających opinie o innych firmach, na przykład katalogów.

Gdzie wkleić kod JSON-LD, w sekcji head czy body?

Google podaje w dokumentacji danych strukturalnych, że blok skryptu z danymi JSON-LD może znajdować się zarówno w sekcji head, jak i w body. Nie ma tu reguły, którą da się złamać. Google czyta też dane wstrzykiwane dynamicznie przez JavaScript lub widgety systemu CMS, więc renderowanie po stronie serwera nie jest wymogiem.

Czym JSON-LD różni się od mikrodanych?

Dla Google wszystkie trzy formaty, czyli JSON-LD, mikrodane i RDFa, są tak samo dobre. Google zaleca JSON-LD, o ile konfiguracja strony na to pozwala, bo jest najłatwiejszy do wdrożenia i utrzymania na dużą skalę. Przewaga jest praktyczna: to osobny blok kodu, który nie miesza się z HTML treści. Szerzej rozkłada to wpis o schema.org.

Jak sprawdzić, czy moje JSON-LD działa?

Zacznij od walidatora schema.org, który wyłapie literówki i złe typy. Potem uruchom Rich Results Test na żywym adresie, żeby zobaczyć, do których rozszerzonych wyników strona się kwalifikuje. Na końcu, po kilku dniach od zaindeksowania, sprawdź raporty ulepszeń w Search Console. Google nie podaje terminu, w jakim rozszerzony wynik się pojawia, ani nie gwarantuje, że w ogóle się pojawi.

Czy mogę mieć kilka bloków JSON-LD na jednej stronie?

Tak, to normalna praktyka. Strona może mieć osobne bloki dla firmy, usługi, okruszków nawigacji i artykułu. Warto połączyć je identyfikatorem @id, żeby zamiast powielać dane firmy w każdym bloku, odwoływać się do jednego. To konwencja porządkowa, a nie wymóg z dokumentacji Google.

JSON-LD dla lokalnej firmy, przykład LocalBusiness