tools

Structured Data: JSON-LD Schema Markup dla stron usługowych

Jak wdrożyć structured data (JSON-LD) dla strony usługowej: LocalBusiness, FAQPage, BreadcrumbList z gotowymi przykładami, walidacją w Rich Results Test i wpływem na SEO oraz wyszukiwarki AI.

Opublikowano: 24 lipca 20266 min czytaniaAktualizacja: 24 lipca 2026

Wdrażam structured data na każdej stronie, którą buduję – to jedno z najtańszych i najbardziej niedocenianych ulepszeń SEO. Nie wymaga nowych treści, nie wymaga backlinków, a daje wymierne efekty: rich results w Google, lepszy CTR i czytelność dla wyszukiwarek AI. W tym poście pokazuję kompletny zestaw JSON-LD dla strony usługowej – LocalBusiness, FAQPage i BreadcrumbList – z gotowymi przykładami i procedurą walidacji.

Czym jest structured data i po co ją wdrażać

Structured data to ustrukturyzowany opis treści strony w formacie zrozumiałym dla maszyn, oparty o słownik schema.org. Google, Bing i inne wyszukiwarki używają go do zrozumienia, co znajduje się na stronie, i do wyświetlania rozszerzonych wyników (rich results):

LocalBusiness / Service – panel firmy, godziny otwarcia, oceny, cennik w wynikach,
FAQPage – rozwijane pytania i odpowiedzi bezpośrednio w SERP,
BreadcrumbList – ścieżka nawigacji pod tytułem wyniku.

Efektów jest więcej niż widać na pierwszy rzut oka. Rich results zwiększają CTR – badania wskazują, że wyniki z elementami strukturalnymi klikają się nawet 2-3 razy częściej niż zwykłe. Dodatkowo schema.org to język, w którym wyszukiwarki budują swoją wiedzę o Twojej firmie – a w erze wyszukiwarek AI (Google AI Overviews, ChatGPT Search, Perplexity) precyzyjna struktura danych to jedna z najlepszych inwestycji w tzw. GEO (generative engine optimization). Zwięzłe, oznaczone odpowiedzi mają największą szansę trafić do odpowiedzi generowanych przez AI.

JSON-LD: format, który wybrał Google

JSON-LD to blok JavaScriptu (w rzeczywistości danych) wstawiany w sekcję <head> lub <body> strony. Google rekomenduje go wprost w dokumentacji, bo jest niezależny od treści wizualnej – wdrożenie nie wymaga dotykania HTML strony.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "name": "Przykładowa Firma Usługowa",
  "url": "https://firma.pl",
  "telephone": "+48 12 345 67 89",
  "email": "kontakt@firma.pl",
  "priceRange": "$$",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "ul. Przykładowa 12/3",
    "postalCode": "00-001",
    "addressLocality": "Warszawa",
    "addressCountry": "PL"
  },
  "geo": { "@type": "GeoCoordinates", "latitude": 52.2297, "longitude": 21.0122 },
  "openingHoursSpecification": [{
    "@type": "OpeningHoursSpecification",
    "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
    "opens": "09:00", "closes": "17:00"
  }],
  "sameAs": ["https://www.facebook.com/firma", "https://www.linkedin.com/company/firma"]
}
</script>

Uwaga na szczegóły, które Google faktycznie sprawdza: dane muszą zgadzać się z treścią strony (adres widoczny w stopce, godziny na podstronie kontakt), adres musi być zapisany jako struktura PostalAddress, a nie string, a sameAs to oficjalne profile – nie losowe katalogi.

Service: strona o usłudze, nie o firmie

Dla strony usługowej (np. jedna konkretna usługa na podstronie) lepszym typem niż LocalBusiness jest Service – opisuje ofertę, a nie firmę:

{
  "@context": "https://schema.org",
  "@type": "Service",
  "serviceType": "Projektowanie stron internetowych",
  "provider": {
    "@type": "Organization",
    "name": "Firma Usługowa",
    "url": "https://firma.pl"
  },
  "areaServed": { "@type": "Country", "name": "Polska" },
  "offers": {
    "@type": "Offer",
    "price": "3000",
    "priceCurrency": "PLN",
    "description": "Strona firmowa oparta o statyczny generator, WCAG 2.2, PageSpeed > 90"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.9",
    "reviewCount": "37"
  }
}

aggregateRating dodawaj tylko, jeśli masz realne, opublikowane opinie – Google traktuje zmyślone oceny jak spam i potrafi ukarać całą domenę.

FAQPage: pytania z SERP prosto na stronę

FAQPage to jeden z najskuteczniejszych typów – pozwala przejąć pytania, które użytkownicy wpisują w Google, i pokazać odpowiedzi bezpośrednio w wynikach:

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Ile kosztuje strona internetowa?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Strona firmowa oparta o statyczny generator to koszt 3-8 tys. PLN. WordPress z agencją: 15-30 tys. PLN."
      }
    },
    {
      "@type": "Question",
      "name": "Jak długo trwa wykonanie strony?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Typowy projekt zajmuje 2-4 tygodnie: tydzień na treści i projekt, tydzień na wdrożenie, tydzień na testy i poprawki."
      }
    }
  ]
}

Najważniejsza zasada: pytania i odpowiedzi muszą być widoczne na stronie (FAQ w treści). Google odrzuca FAQPage, gdy treść jest niewidoczna lub schowana w akordeonach bez pełnej treści w HTML.

BreadcrumbList: nawigacja, którą Google rozumie

Breadcrumbs poprawiają CTR i pomagają Google zrozumieć strukturę serwisu. Dla strony wielopoziomowej (np. /uslugi/projektowanie):

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    { "@type": "ListItem", "position": 1, "name": "Strona główna", "item": "https://firma.pl" },
    { "@type": "ListItem", "position": 2, "name": "Usługi", "item": "https://firma.pl/uslugi" },
    { "@type": "ListItem", "position": 3, "name": "Projektowanie stron", "item": "https://firma.pl/uslugi/projektowanie" }
  ]
}

position musi zaczynać się od 1 i rosnąć bez przerw, a URL-e w item powinny prowadzić do faktycznie istniejących podstron.

Jak wdrożyć: procedura krok po kroku

Wybierz typy – dla strony usługowej standardowo: Organization lub LocalBusiness (strona główna), Service (podstrony usług), FAQPage (sekcja FAQ), BreadcrumbList (wszystkie podstrony), a dla bloga dodatkowo Article/NewsArticle i BlogPosting.
Generuj programowo – nie pisz JSON-LD ręcznie na każdej stronie. W Astro/Next wygeneruj dane z jednego źródła (np. pliku z danymi firmy) i wstrzyknij przez komponent. Jedno źródło prawdy = zero rozjazdów między danymi w stopce a schematem.
Waliduj – każdą zmianę sprawdzaj w Google Rich Results Test i w Search Console (raporty “Ulepszenia” → “Structured data”). Walidator pokaże ostrzeżenia (np. “błąd: pole geo wymagane dla LocalBusiness”), które naprawiasz od razu.
Obserwuj – po 2-4 tygodniach sprawdź w Search Console, czy rich results faktycznie się pojawiły i czy CTR się zmienił.

Częste błędy i jak ich unikać

Kopiowanie cudzych schematów – pola z innej branży (np. menu restauracji na stronie usługowej) generują ostrzeżenia i brak rich results.
Niespójność z treścią – schema mówi “ul. X 12”, stopka mówi “ul. Y 3”. Google traci zaufanie do całej domeny.
Zagnieżdżanie bez potrzeby – FAQPage zamiast Question zamiast listy mainEntity; lokalizacja jako string zamiast PostalAddress.
Brak identyfikatorów – @id na głównych węzłach pomaga Google łączyć encje (ta sama firma w Organization, LocalBusiness i BreadcrumbList).
Ignorowanie ostrzeżeń – ostrzeżenia nie blokują indeksacji, ale zwykle oznaczają, że rich result się nie pokaże.

Structured data a wyszukiwarki AI

W 2026 roku structured data ma nową, ważną rolę: karmi wyszukiwarki generatywne. Google AI Overviews, ChatGPT Search i Perplexity budują odpowiedzi z autorytatywnych źródeł – a strony z precyzyjną strukturą (jasne odpowiedzi na konkretne pytania, oznaczone encje, uporządkowane dane kontaktowe) są znacznie łatwiejsze do zacytowania. To nie jest spekulacja: schema.org to wspólny język całego ekosystemu wyszukiwania, a nie tylko Google. Strona usługowa z dobrym JSON-LD jest gotowa na oba światy – klasyczny SERP i odpowiedzi AI.

Checklist wdrożenia

Organization/LocalBusiness na stronie głównej (dane zgodne ze stopką)
Service na podstronach usług (cena, obszar, opinie tylko realne)
FAQPage – pytania widoczne w treści strony
BreadcrumbList na każdej podstronie (position bez przerw)
@id na głównych encjach
Walidacja w Rich Results Test + monitoring w Search Console

Co dalej

Chcesz, żebym wdrożył kompletny JSON-LD (LocalBusiness, Service, FAQPage, BreadcrumbList) na twojej stronie usługowej? Napisz do mnie – audyt struktury danych i wdrożenie zajmują 1-2 dni, koszt od 500 PLN.

Tagi:#seo#structured-data#schema#json-ld#local-business

Najczęściej zadawane pytania

Czy structured data faktycznie poprawia pozycje w Google?

Structured data nie jest bezpośrednim czynnikiem rankingowym, ale daje rich results (gwiazdki, FAQ, breadcrumbs) zwiększające CTR, a Google jawnie wspiera schema.org przy budowaniu wiedzy o stronach. To jedno z najtańszych ulepszeń SEO – samo wdrożenie JSON-LD zajmuje godzinę.

Jaki format wybrać: JSON-LD, mikrodata czy RDFa?

JSON-LD. Google rekomenduje go wprost, jest niezależny od treści (można go wstrzyknąć w sekcję head), nie psuje kodu HTML i najłatwiej go testować i wersjonować. Mikrodata i RDFa nadal działają, ale nie mają żadnej przewagi – nowe projekty zaczynaj od JSON-LD.

Czy błędy w schema markup mogą zaszkodzić stronie?

Złe dane (niezgodne z treścią strony) mogą skutkować brakiem rich results lub ręcznym działaniem Google, jeśli są mylące lub spamowe. Bezpieczna praktyka: generuj JSON-LD programowo z jednego źródła danych, waliduj każdą zmianę w Rich Results Test i nie kopiuj schematów z innych stron.