Dane strukturalne JSON-LD: 2 przykłady do skopiowania i testu

Autor: SEOgrinder · Opublikowano 4 listopada 2026 · 8 min czytania

Krótka odpowiedź: Dane strukturalne opisują stronę wyszukiwarkom w formie, którą mogą odczytać bezpośrednio. Google zaleca do tego format JSON-LD, czyli blok JSON w znaczniku <script type="application/ld+json">. Skopiuj jeden z dwóch przykładów poniżej, zamień wartości z example.com na informacje, które są widoczne na twojej stronie, i sprawdź wynik w Rich Results Test od Google (po polsku: test wyników z elementami rozszerzonymi). Poprawny kod sprawia, że strona może się kwalifikować do wyników rozszerzonych; Google nie gwarantuje, że się pojawią.

Czym są dane strukturalne i co Google robi z JSON-LD?

Google opisuje dane strukturalne jako „a standardized format for providing information about a page and classifying the page content” (Google), czyli ujednolicony format podawania informacji o stronie i klasyfikowania jej treści. Większość słownictwa pochodzi ze schema.org, a JSON-LD to jeden z trzech sposobów jego zapisu. Pozostałe dwa, Microdata i RDFa, dodają atrybuty do widocznego HTML. JSON-LD trzyma wszystko w jednym osobnym bloku, więc możesz go dodać lub naprawić bez ruszania układu strony.

Google mówi, że wszystkie trzy formaty są równie dobre, jeśli znaczniki są poprawne i właściwie wdrożone. Mimo to zaleca JSON-LD, gdy pozwala na to twoja technika, bo jest to „the easiest solution for website owners to implement and maintain at scale” (Google).

Co możesz zyskać: Google pisze, że dane strukturalne „can enable search results that are more engaging to users”, i nazywa to wynikami rozszerzonymi (rich results). Prowadzi galerię obsługiwanych funkcji, a w niej między innymi Article, Breadcrumb, Event, Organization, Product i Recipe. Jeszcze jedna uwaga z wprowadzenia Google: o tym, jak działa wyszukiwarka, rozstrzyga dokumentacja Google, a nie schema.org, które zna więcej atrybutów i obiektów, niż potrzebuje Google Search.

Zanim napiszesz jakikolwiek kod, obowiązują trzy reguły z ogólnych wytycznych Google dla danych strukturalnych:

Opisuj stronę, na której stoi znacznik, i tylko to, co odwiedzający tam widzą.
Nie blokuj przed Googlebotem stron z danymi strukturalnymi, ani przez robots.txt, ani przez noindex, ani w inny sposób.
Wypełnij wszystkie wymagane właściwości typu, którego używasz. Elementy, którym którejś brakuje, „are not eligible for rich results”.

Przykład 1: Organization dla strony głównej

Google zaleca umieścić znacznik Organization na stronie głównej albo na jednej stronie opisującej organizację, na przykład „O nas”. Na każdej stronie nie jest ci potrzebny (Google). Ten typ nie ma właściwości wymaganych; Google radzi dodać te zalecane, które pasują. Zamień każdą wartość:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Warsztat Rowerowy Przykład",
  "url": "https://www.example.com/",
  "logo": "https://www.example.com/images/logo.png",
  "description": "Warsztat Rowerowy Przykład buduje rowery na miarę.",
  "email": "kontakt@example.com"
}
</script>

Co robią poszczególne właściwości według strony Google:

name: ta sama nazwa, której używasz jako nazwy witryny.
url: adres twojej witryny; pomaga Google jednoznacznie rozpoznać organizację.
logo: co najmniej 112 × 112 px, możliwe do przeskanowania i zaindeksowania. Może pomóc Google zdecydować, które logo pokazać w wynikach wyszukiwania i w panelach wiedzy.
description i email: informacje opcjonalne. address, contactPoint lub sameAs (profil na innej stronie) dodaj tylko wtedy, gdy dotyczą ciebie.

Jeśli pasuje bardziej szczegółowy podtyp, Google go zaleca, na przykład OnlineStore dla sklepu albo podtyp LocalBusiness dla restauracji.

Przykład 2: Article i okruszki nawigacyjne na wpisie blogowym

Google rozumie kilka elementów na jednej stronie, niezależnie od tego, czy zagnieżdżasz je w sobie, czy wymieniasz osobno (Google). Ten przykład wymienia dwa elementy osobno w tablicy JSON, każdy z własnym @context, tak jak Google pokazuje to dla pojedynczych elementów:

<script type="application/ld+json">
[
  {
    "@context": "https://schema.org",
    "@type": "BlogPosting",
    "headline": "Jak wybrać kask rowerowy",
    "image": [
      "https://www.example.com/photos/kask-16x9.jpg",
      "https://www.example.com/photos/kask-4x3.jpg",
      "https://www.example.com/photos/kask-1x1.jpg"
    ],
    "datePublished": "2026-10-12T08:00:00+02:00",
    "dateModified": "2026-11-04T09:20:00+01:00",
    "author": [
      {
        "@type": "Person",
        "name": "Jan Kowalski",
        "url": "https://www.example.com/zespol/jan-kowalski"
      }
    ]
  },
  {
    "@context": "https://schema.org",
    "@type": "BreadcrumbList",
    "itemListElement": [
      { "@type": "ListItem", "position": 1, "name": "Blog", "item": "https://www.example.com/blog" },
      { "@type": "ListItem", "position": 2, "name": "Rowery", "item": "https://www.example.com/blog/rowery" },
      { "@type": "ListItem", "position": 3, "name": "Jak wybrać kask rowerowy" }
    ]
  }
]
</script>

Article. Google akceptuje Article, NewsArticle i BlogPosting. Nie podaje właściwości wymaganych, zaleca natomiast author, datePublished, dateModified, headline i image, żeby mógł „show better title text, images, and date information” (Google). Daty zapisuj według ISO 8601 ze strefą czasową; bez niej Google przyjmuje strefę czasową Googlebota. Każdego autora wpisz jako osobny element z typem, imieniem i nazwiskiem oraz adresem URL. Nagłówek trzymaj krótki, bo „long titles may be truncated on some devices”. Przy obrazach Google zaleca kilka plików w wysokiej rozdzielczości w proporcjach 16x9, 4x3 i 1x1, związanych z artykułem, a nie logo.

Okruszki nawigacyjne. Tu zasady są ścisłe. BreadcrumbList wymaga co najmniej dwóch elementów ListItem, a każdy zwykle potrzebuje position, name i item (adresu). Tylko ostatni może pominąć item; wtedy Google bierze adres samej strony (Google). Google zaleca typową ścieżkę użytkownika zamiast kopii struktury adresów URL i podaje, że funkcja jest dostępna na komputerach. Nasza interpretacja wytycznych: pokaż tę samą ścieżkę widocznie na stronie, bo znaczniki dla rzeczy, których czytelnicy nie widzą, są niedozwolone.

Jak testować JSON-LD przed publikacją i po niej?

Rich Results Test (search.google.com/test/rich-results). Google nazywa go „the official Google tool for testing your structured data”. Strona narzędzia przyjmuje adres albo wklejony kod, więc możesz przetestować przykład, zanim trafi na żywo. Najpierw popraw błędy krytyczne; według Google niekrytyczne wskazówki są dla kwalifikacji opcjonalne.
Schema Markup Validator (validator.schema.org). Strona Google o testowaniu opisuje go jako sprawdzenie wszystkich znaczników opartych na schema.org „without Google feature specific warnings”. Użyj go, gdy do twojego typu nie pasuje żadna funkcja Google.
Kontrola adresu URL w Search Console po wdrożeniu kilku stron. Google prosi, żebyś potwierdził, że strona nie jest zablokowana przez robots.txt, noindex ani logowanie; skanowanie nowej strony może potrwać kilka dni.
Raporty wyników rozszerzonych w Search Console. Google zauważa, że znaczniki mogą się zepsuć po wdrożeniu przez szablony lub problemy z serwowaniem, więc patrz ponownie po każdej zmianie szablonu (Google).

Tak sprawdziliśmy oba powyższe przykłady 4 listopada 2026: oba bloki dają się wczytać jako poprawny JSON (moduł json w Pythonie), a właściwości zgadzają się ze stronami Google o Organization, Article i Breadcrumb (ostatnia aktualizacja 8 września 2026). Nie wklejaliśmy ich do narzędzia Google, więc prawdziwym testem będzie twoje pierwsze wklejenie.

Czego dane strukturalne nie robią

Nie gwarantują wyniku rozszerzonego. Google pisze: „Google does not guarantee that your structured data will show up in search results” (Google). Wśród powodów jest to, że algorytm może uznać zwykły wynik tekstowy za lepiej pasujący, i to, że znaczniki mogą być błędne w sposób, którego test nie wychwytuje.
To nie obietnica pozycji. Na tych stronach Google nie znaleźliśmy stwierdzenia, że dane strukturalne podnoszą pozycje. Google opisuje korzyść jako kwalifikację do wyników rozszerzonych. Ręczne działanie z powodu danych strukturalnych odbiera tę kwalifikację i, jak dodaje Google, „doesn't affect how the page ranks in Google web search”.
Odpowiedzi AI ich nie potrzebują. Przewodnik Google o generatywnych funkcjach AI mówi: „Structured data isn't required for generative AI search, and there's no special schema.org markup you need to add” (Google). Mimo to nazywa dane strukturalne dobrym pomysłem ze względu na kwalifikację do wyników rozszerzonych. SEOgrinder nie mierzy, czy jakikolwiek system AI wymienia twoją witrynę.
Znaczniki FAQ nie mają już wyniku w Google. Dziennik zmian Google mówi: „This feature will no longer appear in Google Search starting May 7, 2026” (Google). Nie dodawaj więc FAQPage w tym celu.

Najczęstsze błędy: 5 błędów w JSON-LD

1. Oznaczanie tego, czego nikt nie widzi

Wytyczna Google: „Don't mark up content that is not visible to readers of the page.” Własny przykład Google: jeśli znacznik opisuje wykonawcę, treść strony musi opisywać tego samego wykonawcę.

2. Zepsuty JSON

Jeden błąd składni psuje cały blok. Raport Google o nieodczytywalnych danych strukturalnych w Search Console (po angielsku „Unparsable structured data report”) wymienia rodzaje błędów, takie jak brakujący przecinek lub nawias zamykający, brakujący dwukropek i niepoprawna sekwencja ucieczki w tekście, na przykład zabłąkany ukośnik odwrotny, jak \q, wewnątrz wartości tekstowej. Wskazówka Google, jak znaleźć usterkę: zacznij od pustego obiektu i dodawaj swój kod z powrotem kawałek po kawałku.

3. Brakujące właściwości wymagane

Według Google elementy bez wymaganych właściwości nie kwalifikują się do wyników rozszerzonych. Typowy przypadek to elementy okruszków nawigacyjnych bez position, name lub item.

4. Typ, który nie pasuje do strony

Google oczekuje najbardziej szczegółowego pasującego typu. Jego przykłady nietrafnych znaczników: serwis ze strumieniowaniem sportu, który oznacza transmisje jako wydarzenia lokalne, i strona stolarska, która oznacza instrukcje jako przepisy.

5. Blokowanie strony albo jej obrazów

Strony z danymi strukturalnymi muszą pozostać otwarte dla Googlebota, a adresy obrazów w znacznikach muszą dać się przeskanować i zaindeksować. Reguła Disallow dla folderu z obrazami może zniweczyć starannie przygotowane znaczniki.

Jak SEOgrinder sprawdza dane strukturalne?

SEOgrinder to nasze narzędzie i my je budujemy. Przeskanuj stronę, otwórz zakładkę „Strona w Google” i spójrz na dwie karty. „Dane strukturalne” wymienia typy znalezione w JSON-LD i Microdata. „Kontrola pól” liczy elementy i pokazuje, ile jest „Nieprawidłowe” (brakuje pola wymaganego) lub „Niekompletne” (brakuje tylko pól zalecanych), razem z nazwami brakujących pól. Na liście zadań pojawiają się jako „W danych strukturalnych brakuje pól obowiązkowych”, „Dane strukturalne są niekompletne”, „Brak danych strukturalnych” oraz, gdy kodu nie da się odczytać, „Jeden zepsuty blok danych strukturalnych”. Po poprawce kliknij Sprawdź ponownie.

Cztery ograniczenia. SEOgrinder czyta HTML, który dostarcza twój serwer, więc JSON-LD, który dopiero skrypt dodaje w przeglądarce, nie jest widoczny, choć Google potrafi go odczytać. Czyta JSON-LD i Microdata, nie RDFa. Zna pola wymagane dla listy popularnych typów, nie dla każdego typu. I nie rozstrzyga, czy Google pokaże wynik rozszerzony; ten podgląd daje Rich Results Test.

Własne strony odczytaliśmy tak samo 4 listopada 2026. To polecenie wypisuje 1 dla artykułu i 0 dla strony głównej:

curl -sS https://seogrinder.com/pl/blog/checklista-seo-audyt | grep -c 'application/ld+json'

Jedyny blok w artykule zawiera BlogPosting i BreadcrumbList z trzema pozycjami (SEOgrinder, Blog, artykuł). Na stronie głównej nie mamy danych strukturalnych.

Najczęstsze pytania

Czy JSON-LD jest lepszy niż Microdata?

Dla Google wszystkie trzy formaty są równorzędne, jeśli znaczniki są poprawne. JSON-LD zaleca dlatego, że najłatwiej go wdrożyć i utrzymywać na dużą skalę.

Czy dane strukturalne są potrzebne na każdej stronie?

Nie. Dodawaj typ tylko tam, gdzie pasuje do strony: Organization na stronie głównej lub „O nas”, Article przy wpisach. Dla wielu stron nie ma pasującego typu i to jest w porządku.

Czy mogę dodać JSON-LD wtyczką albo JavaScriptem?

Tak. Google pisze, że w CMS często znajdziesz stronę ustawień albo wtyczkę do danych strukturalnych i że Google potrafi odczytać JSON-LD wstawiony skryptem (Google). Sprawdź wynik w Rich Results Test i pamiętaj, że SEOgrinder widzi tylko to, co dostarcza serwer.

Czy JSON-LD poprawia moje pozycje?

Strony Google opisują kwalifikację do wyników rozszerzonych, a nie lepsze pozycje. Pozycji nie obieca nikt.

Twój następny krok

Wybierz stronę, która jest dla ciebie najważniejsza. Wklej przykład 1 lub 2 z własnymi wartościami do Rich Results Test i popraw to, co zgłosi. Opublikuj, potem przeskanuj stronę w SEOgrinder, otwórz „Strona w Google” i przeczytaj kartę „Kontrola pól”. Szerszy obraz, czyli miejsce danych strukturalnych wśród innych kontroli, pokazuje nasza checklista SEO.