Schema.org w Next.js: LocalBusiness, Service i FAQ

Rola danych strukturalnych (SEO i AI)

Czym jest Schema.org? To słownik typów i właściwości, natomiast JSON-LD stanowi format pozwalający zapisać ten opis w kodzie HTML. Jaka jest rola danych strukturalnych? Ułatwiają robotom zrozumienie kontekstu treści, jednak nie dają pełnej kontroli nad ich finalną interpretacją ani nie wpływają bezpośrednio na indeksację, pozycję w rankingu czy szansę na cytowanie.

Google nie wymaga również dedykowanego schematu do obecności w modułach AI Overviews czy AI Mode. Oficjalna dokumentacja wskazuje jedynie na spełnienie podstawowych wytycznych wyszukiwarki oraz pełną spójność przekazywanych danych z treścią widoczną na stronie. Szerzej o przygotowaniu strony pod odpowiedzi AI piszę w przewodniku po GEO.

Walidacja słownika a Wyniki Wzbogacone (Rich Results)

Należy przy tym wyraźnie rozgraniczyć poprawność techniczną kodu od kwalifikacji do funkcji specjalnych. Wynik wzbogacony jest osobną funkcją wyszukiwarki, dostępną wyłącznie dla wybranych struktur i po spełnieniu dodatkowych warunków.

W efekcie poprawnie skonfigurowany typ Service bez problemu przejdzie formalną walidację Schema.org, a jednocześnie nie zostanie rozpoznany jako obsługiwana funkcja w narzędziu Rich Results Test — Google po prostu nie przewiduje ogólnego wyniku rozszerzonego dla usług w swoim oficjalnym katalogu.

Organization czy LocalBusiness? Najpierw opisz rzeczywisty biznes

LocalBusiness jest w Schema.org jednocześnie organizacją i miejscem, więc nie wybieraj go wyłącznie dlatego, że akurat sprzedajesz usługi. Z kolei typ ProfessionalService, obecny w wielu starszych poradnikach, jest oznaczony jako przestarzały z powodu mylenia go z Service.

Google wymaga dla swojej funkcji LocalBusiness właściwości name i address. To wymagania tej funkcji, a nie lista pól obowiązkowych każdego dokumentu Schema.org. W sytuacji, kiedy firma nie udostępnia oficjalnego adresu fizycznego, nie należy go sztucznie tworzyć tylko po to, by wyeliminować ostrzeżenie w walidatorze. W takim wypadku wystarczy ograniczyć się do opisu samej organizacji oraz świadczonej przez nią usługi, pamiętając, że szczegółowe wytyczne w tym zakresie określa dokumentacja typu LocalBusiness.

Dla fizycznego zakładu podstawowy opis może wyglądać tak. To fikcyjny przykład dydaktyczny; nazwę, adres i domenę trzeba zastąpić rzeczywistymi danymi przed publikacją.

{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "@id": "https://example.com/krakow/#business",
  "name": "Przykładowy zakład usługowy",
  "url": "https://example.com/krakow/",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "Przykładowa 10",
    "addressLocality": "Kraków",
    "postalCode": "30-001",
    "addressCountry": "PL"
  }
}

Informacje takie jak numer telefonu, zdjęcia czy godziny otwarcia dodawaj tylko wtedy, gdy pokrywają się z treścią widoczną na stronie. Właściwość areaServed pozwala określić obszar świadczenia usług, jednak nie zastępuje fizycznego adresu firmy. Z kolei pole sameAs powinno wskazywać wyłącznie oficjalne profile danego podmiotu, a nie przypadkowe katalogi czy artykuły branżowe. W przypadku poszczególnych oddziałów należy zastosować unikalne identyfikatory @id, zamiast przypisywać wiele różnych adresów do jednego skonsolidowanego profilu marki.

Kompletne wdrożenie JSON-LD w Next.js App Router

Poniższy przykład zakłada App Router, TypeScript i alias @/* wskazujący katalog src. Powstają trzy pliki: komponent serializujący, dane firmy i strona audytu. Standardowy app/layout.tsx pozostaje częścią aplikacji. Wszystkie dane firmy w przykładzie są demonstracyjne.

1. Jeden komponent do bezpiecznej serializacji

// src/components/JsonLd.tsx
type JsonValue =
  | string
  | number
  | boolean
  | null
  | JsonValue[]
  | { [key: string]: JsonValue | undefined }
 
export function JsonLd({ data }: { data: JsonValue }) {
  const html = JSON.stringify(data).replace(/</g, '\\u003c')
 
  return (
    <script
      type="application/ld+json"
      dangerouslySetInnerHTML={{ __html: html }}
    />
  )
}

Brak deklaracji 'use client' jest zamierzony — komponent może zostać wyrenderowany w całości po stronie serwera razem z pozostałą treścią. Zwykły element <script> z typem JSON-LD jest w zupełności wystarczający i nie wymaga żadnych mechanizmów opóźniających wykonywanie JavaScriptu, co pozostaje w pełni zgodne z dokumentacją Next.js.

Warto jednak pamiętać, że samo JSON.stringify nie zabezpiecza w pełni osadzenia danych bezpośrednio w kodzie HTML. W sytuacji, kiedy treść z CMS-a zawiera ciąg </script>, parser HTML zinterpretuje go jako wcześniejsze zamknięcie znacznika. Zamiana znaku < na kod ucieczki \u003c skutecznie zapobiega przełamaniu skryptu, zachowując oryginalny tekst po stronie odbierającej (JSON.parse). Jest to dedykowana ochrona dla tego konkretnego sposobu wstrzykiwania JSON-a.

2. Wspólna tożsamość firmy i adresy absolutne

// src/lib/business.ts
export const site = {
  origin: 'https://example.com',
  name: 'Przykładowe Studio',
  email: 'kontakt@example.com',
}
 
export const organization = {
  '@type': 'Organization',
  '@id': `${site.origin}/#organization`,
  name: site.name,
  url: `${site.origin}/`,
  email: site.email,
}

@id to unikalny identyfikator encji — fragment #organization nie wymaga osobnej podstrony ani endpointu. Używaj go spójnie za każdym razem, gdy odwołujesz się do tej samej firmy, np. jako provider usługi czy publisher artykułu, podczas gdy url wskazuje stronę z informacjami o podmiocie.

W przykładzie adres podstrony budujemy bezpiecznie za pomocą new URL na podstawie kontrolowanej ścieżki, unikając łączenia domeny z niepewnym ciągiem znaków. Pobierając ścieżkę z CMS-a, weryfikuj domenę docelową oraz dozwolone adresy, a na poziomie aplikacji zadbaj o jednolity kanoniczny URL, obsługę przekierowań i spójne stosowanie końcowego ukośnika.

3. Strona usługi, breadcrumbs i FAQ z tych samych danych

// src/app/uslugi/audyt-techniczny/page.tsx
import type { Metadata } from 'next'
import { JsonLd } from '@/components/JsonLd'
import { organization, site } from '@/lib/business'
 
const url = new URL('/uslugi/audyt-techniczny/', site.origin).href
const service = {
  name: 'Audyt techniczny strony',
  description:
    'Sprawdzamy indeksowalność, renderowanie i wydajność strony. Otrzymasz raport z priorytetami poprawek.',
  area: 'Polska',
}
const breadcrumbs = [
  { name: 'Strona główna', url: `${site.origin}/` },
  { name: service.name, url },
]
const faqs = [
  {
    question: 'Co otrzymam po audycie?',
    answer:
      'Raport z wykrytymi problemami, ich wpływem i kolejnością wdrożenia poprawek.',
  },
  {
    question: 'Ile kosztuje audyt?',
    answer:
      'Wycena jest indywidualna i zależy od wielkości serwisu oraz zakresu analizy.',
  },
].filter(({ question, answer }) => question.trim() && answer.trim())
 
export const metadata: Metadata = {
  title: service.name,
  description: service.description,
  alternates: { canonical: url },
}
 
export default function ServicePage() {
  const data = {
    '@context': 'https://schema.org',
    '@graph': [
      organization,
      {
        '@type': 'Service',
        '@id': `${url}#service`,
        url,
        name: service.name,
        description: service.description,
        provider: { '@id': organization['@id'] },
        areaServed: { '@type': 'Country', name: service.area },
      },
      {
        '@type': 'BreadcrumbList',
        '@id': `${url}#breadcrumb`,
        itemListElement: breadcrumbs.map((item, index) => ({
          '@type': 'ListItem',
          position: index + 1,
          name: item.name,
          item: item.url,
        })),
      },
      ...(faqs.length
        ? [
            {
              '@type': 'FAQPage',
              '@id': `${url}#webpage`,
              url,
              mainEntity: faqs.map(({ question, answer }) => ({
                '@type': 'Question',
                name: question,
                acceptedAnswer: { '@type': 'Answer', text: answer },
              })),
            },
          ]
        : []),
    ],
  }
 
  return (
    <main>
      <JsonLd data={data} />
      <nav aria-label="Okruszki nawigacyjne">
        <ol>
          {breadcrumbs.map((item) => (
            <li key={item.url}>
              <a
                href={item.url}
                aria-current={item.url === url ? 'page' : undefined}
              >
                {item.name}
              </a>
            </li>
          ))}
        </ol>
      </nav>
      <h1>{service.name}</h1>
      <p>{service.description}</p>
      <p>
        Usługodawca: <a href={organization.url}>{organization.name}</a>.
      </p>
      <p>Obszar obsługi: {service.area}. Współpraca zdalna.</p>
      <p>
        Kontakt: <a href={`mailto:${site.email}`}>{site.email}</a>.
      </p>
      {faqs.length > 0 && (
        <section aria-labelledby="faq-title">
          <h2 id="faq-title">Pytania o audyt</h2>
          {faqs.map(({ question, answer }) => (
            <details key={question}>
              <summary>{question}</summary>
              <p>{answer}</p>
            </details>
          ))}
        </section>
      )}
    </main>
  )
}

Opis usługi, dane usługodawcy, obszar obsługi, ścieżka nawigacji oraz odpowiedzi w sekcji pytań pochodzą ze wspólnego źródła danych. Dzięki temu usunięcie pytań automatycznie wyeliminuje zarówno sekcję wizualną, jak i odpowiadający jej węzeł FAQPage. Odpowiedzi umieszczone w elementach <details> pozostają w pełni dostępne dla użytkowników po ich rozszerzeniu, w związku z czym nie są treścią generowaną wyłącznie na potrzeby robotów.

Zastosowanie tablicy @graph pozwala na zgrupowanie kilku powiązanych encji w ramach jednego dokumentu JSON-LD. Nie jest to jednak warunek konieczny, ponieważ równie dobrze można użyć osobnych znaczników skryptu. Kluczowe znaczenie ma utrzymanie spójnej tożsamości firmy oraz pełna zgodność przekazywanych informacji. W zaprezentowanym przykładzie firma posiada kompletny opis również na podstronie usługi, co sprawia, że relacja provider pozostaje całkowicie zrozumiała w obrębie tego samego dokumentu.

W przypadku witryny zasilanej z CMS-a wystarczy pobrać dany rekord jednorazowo na poziomie komponentu serwerowego, a następnie przekazać te same wartości do warstwy widoku i generatora schematu. W sytuacji, kiedy CMS zwraca treść odpowiedzi w formacie HTML, należy ustalić bezpieczny sposób jej renderowania oraz prawidłowego odwzorowania w strukturze danych — powyższy przykład celowo operuje na czystym tekście.

Service i Offer: jak opisać zakres oraz cenę

Typ Service precyzyjnie definiuje, co oferujesz i kto realizuje usługę — nie czyni go to jednak automatycznie produktem kwalifikującym się do wyników zakupowych. Nie należy sztucznie zmieniać typu na Product tylko po to, by wymusić zaliczenie testu i wywołać dodatkowe funkcje w wynikach wyszukiwania.

W naszym przykładzie wycena jest indywidualna, więc pomijamy offers. W sytuacji, kiedy sprzedajesz konkretny pakiet ze stałą ceną, możesz opisać go przez Offer z price, priceCurrency i adresem oferty. Użytkownik powinien widzieć ten sam pakiet, zakres, cenę i informację o podatku, ale przypadkiem nie zapisuj ceny np. „od 2000 zł” jako bezwarunkowej ceny całej usługi. Wartość 0 również nie zastępuje komunikatu „zapytaj o wycenę”. Znaczenie pól opisują Service i Offer.

FAQ i opinie: czego obecnie nie obiecywać

Google wycofało wyniki wzbogacone FAQ 7 maja 2026 r. Wcześniejsze ograniczenie do wybranych serwisów rządowych i zdrowotnych nie jest już pełnym opisem aktualnego stanu. Zmianę potwierdza dziennik aktualizacji Google.

FAQPage pozostaje częścią słownika Schema.org. W przykładzie pokazujemy je jako opcjonalny opis dostępnych pytań, a nie sposób na dodatkowe miejsce w wynikach. Jeśli nie masz zastosowania dla tego opisu, możesz pozostawić samą sekcję pytań. Nie ma podstaw do obiecywania, że FAQ schema zapewni cytowanie odpowiedzi przez AI.

Z opiniami łatwo pomylić prawdziwość danych z kwalifikacją do funkcji Google:

Z tego względu w niniejszym poradniku nie dodajemy typu AggregateRating do opisu własnej firmy. Autentyczne referencje warto oczywiście zaprezentować użytkownikom na stronie, jednak nie należy traktować ich jako gwarancji uzyskania gwiazdek w wynikach wyszukiwania — tym bardziej że oficjalne zasady dotyczące modułu review snippet obejmują również osadzone widgety zewnętrznych dostawców.

Ewentualne naruszenie wytycznych dotyczących danych strukturalnych może skutkować nałożeniem ręcznego działania, które ograniczy kwalifikację witryny do wyświetlania wyników wzbogaconych. Google wyraźnie podkreśla jednak, że taka kara sama w sobie nie wpływa na pozycję strony w organicznych wynikach wyszukiwania i nie oznacza automatycznego usunięcia domeny z indeksu. Różnicę tę precyzyjnie wyjaśniają ogólne zasady stosowania danych strukturalnych.

Gdzie umieścić schematy: page czy layout?

Wspólny moduł danych firmy nie oznacza konieczności emitowania wszystkich schematów w root layoucie. Dobieraj miejsce do treści:

• Organization umieść na stronie głównej lub stronie opisującej firmę. Na podstronach możesz ponownie opisać tę samą firmę albo odwołać się do jej stabilnego @id.

• LocalBusiness opisuj tam, gdzie prezentujesz konkretną lokalizację. Osobne oddziały wymagają rozróżnienia danych.

• WebSite dla nazwy witryny umieść na stronie głównej. Google nie wymaga powielania go na każdej podstronie.

• Service, BreadcrumbList i opcjonalne FAQPage generuj dla bieżącej strony i jej treści.

• Artykuł poradnikowy opisuj jako Article lub BlogPosting; występowanie słowa „usługa” w tekście nie czyni go stroną oferty.

Powtórzenie tej samej encji nie jest samo w sobie błędem. Natomiast problemem są już sprzeczne nazwy, adresy czy typy dla jednego @id albo kilka generatorów utrzymujących różne kopie danych. Przy integracji CMS sprawdź, czy nie dodaje on własnego JSON-LD obok Twojego.

Minimalny WebSite zawiera @context, @type, name i url; możesz dodać stabilne @id. Rich Results Test nie obsługuje testowania nazw witryn — stosuj instrukcję Google dotyczącą site names. Dawny sitelinks search box został wycofany w listopadzie 2024, więc dodanie SearchAction nie przywróci tego pola w Google. Informacja o wycofaniu funkcji dotyczy funkcji wyszukiwarki, a nie usunięcia typu ze Schema.org.

Nawigacja breadcrumb powinna dokładnie odzwierciedlać rzeczywistą strukturę serwisu. W zaprezentowanym przykładzie występują dwa poziomy, dlatego nie wprowadzamy sztucznie nieistniejącego katalogu nadrzędnego. Warto pamiętać, że Google dopuszcza pominięcie właściwości item w ostatnim elemencie listy. Ponadto funkcja ta dotyczy obecnie prezentacji wyników na komputerach, stąd brak takiego modułu na telefonie nie świadczy o błędzie wdrożenia. Szczegółowe wymagania w tym zakresie określa dokumentacja typu BreadcrumbList.

Walidacja: trzy narzędzia i trzy różne odpowiedzi

Po uruchomieniu przykładu:

1. Otwórz źródło odpowiedzi HTML i znajdź application/ld+json. Sprawdź, czy dane są dostępne razem z treścią strony, bez kliknięcia zgody lub formularza.
2. Wklej HTML do Schema Markup Validator. Sprawdź wszystkie encje, absolutne adresy i powiązanie Service.provider z firmą.
3. Uruchom Rich Results Test. Dla tego przykładu oceniaj przede wszystkim rozpoznanie breadcrumbs; brak funkcji Service i FAQ nie oznacza błędnego JSON-LD.
4. Porównaj nazwę, opis, kontakt i wszystkie odpowiedzi z widoczną stroną. Walidator nie potwierdzi prawdziwości tych informacji.
5. Po publikacji przetestuj docelowy URL, nie tylko kod z edytora. CDN, szablon albo CMS mogą zmienić końcowy HTML.

W testach komponentu warto podać odpowiedź zawierającą </script><script>alert(1)</script> i sprawdzić, że pozostaje danymi w pojedynczym skrypcie JSON-LD. Drugi sensowny przypadek to pusta lista FAQ: nie powinien powstać pusty węzeł FAQPage. Samo poprawne wykonanie JSON.parse sprawdza składnię JSON, a nie zgodność ze Schema.org.

Czy poprawa schematu wpłynie na indeksację?

Warto odpowiedzieć na powyższe pytanie: uporządkowanie danych strukturalnych bywa mylone, jako czynnik wpływający na indeksację lub nawet pozycje w SERP. Rzeczywistość wygląda tak, że poprawny JSON-LD opisuje treść w sposób zrozumiały dla maszyn, natomiast o samym wejściu do indeksu decydują inne czynniki, takie jak: dostępność treści po renderowaniu, spójność linków kanonicznych, sposób odkrywania adresu i wartość strony na tle pozostałych wyników. Schemat po prostu porządkuje stronę i to jest jego rola.

Diagnostykę statusów indeksacji, wraz z ich odczytem w raporcie Stron i przykładami charakterystycznymi dla Next.js, rozpisuję osobno w tekście o Search Console dla Next.js.