Dane strukturalne Schema.org dla firmy usługowej — jak oznaczyć usługi, obszar działania i opinie

Co dają dane strukturalne i kiedy warto je wdrożyć

Dane strukturalne to tekst w kodzie strony, który opisuje treść w sposób czytelny dla wyszukiwarek. Zamiast zgadywać, że „hydraulik Bytom" to nazwa usługi i miasta, Google dostaje jawny zapis: typ usługi, obszar działania, numer telefonu, godziny otwarcia. Dla firmy usługowej to bezpośredni sygnał do Map Google i wyników organicznych.

Wdrożenie ma sens, gdy strona jest kodowana od zera lub przechodzi modernizację — wtedy dane strukturalne można wbudować w szablon raz i zapomnieć. W systemach szablonowych najczęściej wymaga to wtyczek, które dodają nadmiarowy kod lub konfliktują z motywem. Jeśli Twoja strona jest w Astro lub SvelteKit, dane strukturalne to kilka linii JSON-LD w sekcji head strony.

Dane strukturalne nie zastępują treści — ją opisują. Jeśli na stronie nie ma ceny, nie wpiszesz jej w Schema.org. Jeśli nie masz opinii, nie oznaczysz AggregateRating. Każde pole w danych strukturalnych musi odpowiadać widocznej treści na stronie.

Które typy Schema.org wybrać dla firmy usługowej

Nie oznaczaj wszystkiego. Wybierz typy, które odpowiadają realnej działalności i hierarchii strony:

• LocalBusiness (lub dokładniejszy podtyp: Plumber, Electrician, ProfessionalService) — podstawowy typ dla lokalnej firmy. Zawiera NAP (Name, Address, Phone), godziny otwarcia, geolokalizację.
• Service — pojedyncza usługa z opisem, obszarem działania i typem usługi (serviceType).
• Offer — cena lub zakres cenowy za usługę. Tylko jeśli masz realne ceny na stronie.
• Review / AggregateRating — opinie klientów. Wymaga faktycznych opinii, nie wygenerowanych.
• FAQPage — sekcja pytań i odpowiedzi, jeśli masz na stronie realne FAQ.

Zasada: jeden główny typ na stronę. Strona główna to LocalBusiness. Podstrona usługi to Service powiązany z LocalBusiness przez pole provider. Podstrona kontakt to LocalBusiness z pełnym NAP i godzinami.

Jak oznaczyć obszar działania bez nadużyć

Najczęstszy błąd: oznaczanie całego województwa lub kraju jako obszaru działania, gdy firma realnie obsługuje kilka miast. Google weryfikuje spójność między danymi strukturalnymi, treścią strony i Profilem Firmy Google. Jeśli Schema.org mówi „cały Śląsk", a treść strony i opinie wskazują na Bytom i Katowice, sygnał jest niespójny.

Użyj areaServed z typem City dla każdego miasta, w którym realnie pracujesz:

{
  "@context": "https://schema.org",
  "@type": "Service",
  "provider": {
    "@type": "LocalBusiness",
    "name": "Nazwa Firmy"
  },
  "serviceType": "Usługi hydrauliczne",
  "areaServed": [
    { "@type": "City", "name": "Bytom" },
    { "@type": "City", "name": "Katowice" },
    { "@type": "City", "name": "Gliwice" }
  ]
}

Jeśli obsługujesz promień kilometrów od siedziby, użyj GeoCircle z geoMidpoint (współrzędne) i geoRadius (metry). To precyzyjniejsze niż wpisanie całego województwa i lepiej odpowiada realnemu zasięgu firmy usługowej.

Spójność jest kluczowa: lista miast w areaServed musi zgadzać się z miastami wymienionymi w treści strony i z obszarem ustawionym w Profilu Firmy Google. Jeśli dodajesz podstrony lokalizacyjne dla poszczególnych miast, każda z nich może mieć własny Service z jednym miastem w areaServed.

Jak oznaczyć usługi i ceny — kiedy pomaga, a kiedy szkodzi

Oznaczanie cen w Offer pomaga, gdy masz stałe ceny (np. „przegląd instalacji — 150 zł"). Google może pokazać cenę w wynikach. Szkodzi, gdy cena zależy od wielu czynników, a na stronie nie ma konkretnej kwoty — wtedy Offer bez ceny lub z wymyśloną kwotą generuje niespójność i może zostać odrzucone.

Decyzje:

• Masz stałą cenę za usługę? Oznacz Offer z price i priceCurrency.
• Cena zależy od wyceny? Pomiń Offer lub użyj Offer z priceSpecification i opisem „wycena indywidualna".
• Masz zakres cenowy? Użyj minPrice i maxPrice w PriceSpecification.

Nie wymyślaj cen, których nie ma na stronie. Dane strukturalne powtarzają treść widoczną dla użytkownika, nie ją zastępują. Jeśli na stronie jest napisane „cena po oględzinach", nie wpisuj w Schema.org konkretnej kwoty.

Opinie i AggregateRating — co wolno, a czego nie

Google surowo traktuje fałszywe opinie w danych strukturalnych. AggregateRating bez linku do źródła opinii lub z liczbą niezgodną z widocznymi opiniami na stronie to najszybsza droga do ręcznej kary w Search Console.

Zasady:

• AggregateRating musi odzwierciedlać opinie widoczne na stronie — ta sama liczba, ta sama średnia ocen.
• Review musi zawierać author, datePublished i treść opinii.
• Opinie mogą pochodzić z Profilu Firmy Google, ale muszą być powiązane z konkretnym LocalBusiness.
• Nie używaj AggregateRating na stronie, która nie wyświetla żadnych opinii.

Jeśli nie masz systemu opinii na stronie, pomiń Review i AggregateRating. Profil Firmy Google z opiniami wystarczy jako sygnał dla Map — nie musisz duplikować ich w danych strukturalnych na stronie.

Jak zweryfikować poprawność danych strukturalnych

Po wdrożeniu sprawdź dane przed publikacją i po indeksacji:

1. Rich Results Test (Google) — wklej URL lub kod, sprawdź które typy są wykrywane i czy nie ma błędów. Narzędzie pokazuje, które pola są wymagane, zalecane i opcjonalne.
2. Schema Markup Validator (schema.org) — waliduje zgodność ze słownikiem Schema.org, nie tylko typy obsługiwane przez Google. Przydatne, gdy używasz typów, które Google jeszcze nie renderuje w wynikach, ale które są poprawne strukturalnie.
3. Search Console — po indeksacji sprawdź raporty „Ulepszenia" i „Wyniki z elementami rozszerzonymi" pod kątem ostrzeżeń i błędów.

Błędy krytyczne: brak @type, brak wymaganych pól (np. name w LocalBusiness), niespójność NAP między Schema.org a widoczną treścią. Ostrzeżenia: brak pól zalecanych (np. openingHours, image, url). Ostrzeżenia nie blokują wyświetlania, ale zmniejszają szansę na elementy rozszerzone w wynikach.

Checklista wdrożenia danych strukturalnych

• Strona główna: LocalBusiness z NAP, godzinami, geolokalizacją
• Podstrona usługi: Service z serviceType, areaServed, provider
• Obszar działania: lista miast zgodna z treścią strony i Profilem Firmy Google
• Ceny: Offer tylko jeśli kwoty są na stronie; w przeciwnym razie pomiń
• Opinie: Review i AggregateRating tylko jeśli opinie są widoczne na stronie
• FAQ: FAQPage jeśli masz sekcję pytań i odpowiedzi
• Test: Rich Results Test bez błędów krytycznych
• Spójność: NAP w Schema.org = NAP na stronie = NAP w Profilu Firmy Google

Dane strukturalne to nie ranking booster, który sam podniesie pozycje. To sposób, w jaki Google rozumie Twoją stronę — i jeśli rozumie ją dobrze, ma większą szansę pokazać Cię w odpowiednich wynikach i Mapach. Jeśli planujesz nową stronę lub modernizację obecnej, wdrożenie Schema.org jest częścią procesu budowy, a nie dodatkiem po fakcie. W ramach bezpłatnej konsultacji mogę sprawdzić, czy Twoja obecna strona ma poprawne dane strukturalne i co warto dodać.