Bezpłatne narzędzia

Przewodnik po Schema.org i JSON-LD dla danych strukturalnych

Generator Schema.org pomaga tworzyć znaczniki JSON-LD dla artykułów, produktów, organizacji, wydarzeń, FAQ i innych typów stron. Gotowy kod można skopiować i dodać do witryny, aby wyszukiwarki lepiej rozumiały jej treść.

Bezpłatnie Działa w przeglądarce Bez rejestracji

Wybierz obiekt, który jest faktycznie opisany na stronie, wypełnij jego właściwości i uzyskaj kod JSON-LD do umieszczenia w HTML. Generator pomaga zbudować składnię, ale przed publikacją należy sprawdzić zgodność z widoczną treścią, wymagania wybranego konsumenta danych oraz aktualność wartości.

Schema.org, JSON-LD i wynik rozszerzony to różne rzeczy

Schema.org

To wspólny słownik typów i właściwości: Article, Product, Organization, Event, name, image, offers i wiele innych. Opisuje, jakie encje i relacje można przedstawić w sposób ustrukturyzowany.

JSON-LD

To jeden z formatów zapisu danych strukturalnych. Kod umieszcza się wewnątrz:

<script type="application/ld+json">
    {
    "@context": "https://schema.org",
    "@type": "Article",
    "headline": "Tytuł artykułu"
    }
    </script>

Google zaleca JSON-LD, gdy jest odpowiedni do implementacji, ale Schema.org można również zapisać za pomocą Microdata lub RDFa.

Wynik rozszerzony Google

To specjalne przedstawienie wyniku w wyszukiwarce, które obsługuje tylko ograniczony zestaw typów i wymaga przestrzegania oddzielnych zasad Google. Prawidłowe znaczniki Schema.org nie gwarantują wyniku rozszerzonego, wysokiej pozycji ani nawet użycia wszystkich przesłanych właściwości. Dlatego nie należy oceniać znaczników tylko pytaniem „czy wyświetli ładny fragment?”. Przede wszystkim muszą one poprawnie opisywać rzeczywistą encję strony.

Jak wybrać typ znaczników

Wybierz typ na podstawie głównego obiektu strony, a nie pożądanego wyglądu w wyszukiwarce.

Typ	Kiedy stosować	Co szczególnie sprawdzić
`Article`	artykuł, wiadomość, recenzja, publikacja	tytuł, autor lub wydawca, daty, obraz, powiązanie z bieżącą stroną
`BreadcrumbList`	widoczny lub logiczny łańcuch nawigacyjny	prawidłowa kolejność pozycji i URL każdego kroku
`Event`	konkretne wydarzenie z datą i formą	data i strefa czasowa, miejsce lub URL online, status i aktualność
`FAQPage`	strona z jedną oficjalną odpowiedzią serwisu na każde pytanie	wszystkie pytania i odpowiedzi widoczne dla użytkownika; nie dla forów lub odpowiedzi użytkowników
`HowTo`	rzeczywista instrukcja krok po kroku	kroki odpowiadają widocznemu materiałowi; nie liczyć na wynik rozszerzony HowTo Google
`JobPosting`	pojedyncza dostępna oferta pracy	pracodawca, lokalizacja lub forma zdalna, data publikacji, termin ważności, opis
`LocalBusiness`	konkretny punkt fizyczny lub organizacja lokalna	najdokładniejszy podtyp, adres, telefon, godziny otwarcia i URL tego punktu
`Organization`	firma, instytucja, marka lub stowarzyszenie	oficjalna nazwa, URL, logo, kontakty i stabilny `@id`
`Person`	profil konkretnej osoby	imię i nazwisko, rola, przynależność do organizacji, oficjalne profile; nie podawać przypuszczeń jako faktów
`Product`	konkretny produkt lub wariant produktu	produkt istnieje na stronie; cena, waluta, dostępność, oferta i opinie są aktualne
`Recipe`	przepis kulinarny	składniki, kroki, czas, porcje i obraz dostępne dla użytkownika
`VideoObject`	pojedynczy film na stronie	tytuł, opis, podgląd, data przesłania i dostępny URL filmu lub odtwarzacza
`WebSite`	strona internetowa jako pojedynczy obiekt	główny kanoniczny URL, nazwa i powiązanie z organizacją; ten typ zwykle nie jest potrzebny na każdej stronie jako niezależna encja

Na jednej stronie dopuszczalnych jest kilka powiązanych obiektów. Na przykład artykuł może mieć autora Person, wydawcę Organization, okruszki chleba BreadcrumbList i osadzone wideo VideoObject. Lepiej powiązać je przez @id, niż tworzyć sprzeczne kopie.

Ważne aktualne ograniczenia Google

FAQPage

Google znacznie ograniczył wyświetlanie rozszerzonych wyników FAQ: są one zazwyczaj dostępne tylko dla znanych, autorytatywnych stron rządowych i medycznych. Dla zwykłej komercyjnej lub informacyjnej strony, poprawne znaczniki FAQ mogą nie przynieść zauważalnego rozszerzenia w wynikach. Nie czyni to typu FAQPage nieważnym w Schema.org, ale nie można obiecywać użytkownikowi, że „pytania pojawią się w Google”.

HowTo

Google zaprzestał wyświetlania rozszerzonych wyników HowTo. Typ HowTo pozostaje w słowniku Schema.org i może być używany przez innych konsumentów, ale dodawanie go wyłącznie dla dawnego rozszerzonego wyniku Google nie ma już sensu.

Inne typy

Organization, Person i WebSite pomagają opisywać encje, ale nie każdy z nich tworzy oddzielny wizualny wynik rozszerzony. Wsparcie i wygląd funkcji wyszukiwania zmieniają się, dlatego przed wdrożeniem sprawdź aktualną galerię Google Search Central.

Główna zasada: znaczniki muszą odpowiadać widocznej treści

Nie dodawaj do JSON-LD informacji, których brakuje na stronie lub które są z nią sprzeczne. Dotyczy to w szczególności:

ceny i dostępności produktu;
oceny i liczby opinii;
pytań i odpowiedzi;
daty i miejsca wydarzenia;
autora materiału;
adresu i grafiku firmy;
warunków oferty pracy;
składników i kroków przepisu.

Znaczniki nie są miejscem na ukryty tekst reklamowy ani dodatkowe słowa kluczowe. Użytkownik i wyszukiwarka powinni otrzymywać spójne informacje.

Pola obowiązkowe zależą od tego, kto czyta znaczniki

Schema.org definiuje słownik, ale nie uniwersalną listę „pól obowiązkowych” dla wszystkich systemów. Konkretny konsument, np. Google Search, ustanawia własne obowiązkowe i zalecane właściwości dla określonej funkcji wyszukiwania. Dlatego możliwe są trzy różne wyniki walidacji:

JSON jest składniowo poprawny.
Typy i właściwości istnieją w Schema.org.
Znaczniki spełniają wymagania konkretnego rozszerzonego wyniku Google.

Pomyślne przejście pierwszego lub drugiego etapu nie gwarantuje trzeciego.

Jak wypełniać URL, daty i identyfikatory

Używaj absolutnych URL

Preferowane:

https://example.pl/katalog/produkt-1

Zamiast:

/katalog/produkt-1

Linki muszą być dostępne dla robota wyszukiwarki, nie wymagać autoryzacji i prowadzić do stabilnego zasobu.

Podawaj daty w ISO 8601

Data:

2026-08-04

Data i godzina ze strefą czasową:

2026-08-04T18:30:00+03:00

W przypadku wydarzeń szczególnie ważne jest, aby nie zgubić strefy czasowej. W przeciwnym razie czas może zostać błędnie zinterpretowany.

Twórz stabilny `@id`

@id to identyfikator encji, często w formie URL z fragmentem:

https://example.pl/#organization
    https://example.pl/artykul/#webpage
    https://example.pl/artykul/#author

Ta sama organizacja na różnych stronach powinna odwoływać się do jednego stabilnego identyfikatora, a nie wyglądać jak wiele niezależnych firm.

Jak opisywać wiele encji przez `@graph`

Dla powiązanych obiektów wygodnie jest użyć jednego bloku:

{
    "@context": "https://schema.org",
    "@graph": [
        {
        "@type": "Organization",
        "@id": "https://example.pl/#organization",
        "name": "Firma Przykładowa",
        "url": "https://example.pl/"
        },
        {
        "@type": "Article",
        "@id": "https://example.pl/blog/artykul/#article",
        "headline": "Tytuł artykułu",
        "publisher": {
            "@id": "https://example.pl/#organization"
        }
        }
    ]
    }

W ten sposób obiekty są jawnie powiązane i nie trzeba powtarzać wszystkich informacji o organizacji wewnątrz każdego artykułu.

Gdzie wstawić JSON-LD

Blok <script type="application/ld+json"> można umieścić w <head> lub <body> strony HTML. Ważniejsze jest, aby:

kod był obecny w końcowym HTML lub dostępny po poprawnym renderowaniu;
odnosił się konkretnie do bieżącej strony;
CMS odpowiednio go znakował, nie uszkadzając cudzysłowów i znaków;
jeden szablon nie wstawiał tych samych danych na różne strony;
dynamiczna cena, dostępność i daty były aktualizowane wraz z widoczną treścią.

Po wdrożeniu sprawdzaj nie tylko kod z generatora, ale także opublikowany URL: szablon, wtyczka lub JavaScript mogą zmienić końcowe znaczniki.

Dwa różne poziomy walidacji

Schema Markup Validator

Sprawdza składnię i użycie słownika Schema.org. Nadaje się do zobaczenia znalezionych typów, właściwości i ogólnych problemów znaczników.

Google Rich Results Test

Pokazuje, czy Google rozpoznaje na stronie obsługiwany typ wyniku rozszerzonego i czy spełnione są jego specjalne wymagania. Narzędzie nie potwierdza, że rozszerzenie pojawi się w wyszukiwarce. Po publikacji warto również sprawdzić URL za pomocą Inspekcji URL w Google Search Console, aby zobaczyć przetworzoną przez Google wersję strony i wykryte elementy.

Błąd i ostrzeżenie to nie uniwersalne kategorie

Walidator może uznać brak właściwości za ostrzeżenie, podczas gdy dla konkretnego konsumenta okaże się ona obowiązkowa. I odwrotnie, Schema.org dopuszcza właściwość, której Google nie używa do danej funkcji. Oceniaj komunikat według czterech pytań:

Czy składnia JSON jest uszkodzona?
Czy typ i właściwość istnieją w Schema.org?
Czy właściwość jest prawidłowo zagnieżdżona i ma poprawną wartość?
Czy jest wymagana przez wybraną funkcję wyszukiwania lub inną integrację?

Częste błędy

Niewłaściwy typ: strona kategorii produktów jest oznaczona jako pojedynczy Product, mimo że nie ma na niej pojedynczego produktu ani jednolitej oferty. Lub zwykły artykuł otrzymuje FAQPage tylko dlatego, że na dole jest mały blok pytań.
Znaczniki nie odpowiadają stronie: w kodzie podano starą cenę, nieistniejącą ocenę, ukryte pytania lub innego autora.
Konfliktujące encje: kilka wtyczek tworzy różne bloki Organization z różniącymi się nazwami, logo i URL. Obiekty nie są połączone przez wspólny @id.
Nieprawidłowe zagnieżdżenie: na przykład price jest zapisane bezpośrednio w Product, chociaż oferta jest zwykle opisywana przez obiekt Offer we właściwości offers.
Nieprawidłowy typ wartości: data zapisana jako dowolny tekst, cena zawiera walutę w tym samym ciągu, wartość logiczna przekazana jako fraza, a pole oczekujące URL zawiera ścieżkę względną.
Niedostępne obrazy i strony: URL zwraca błąd, jest zablokowany przez autoryzację lub robots.txt, prowadzi przez niestabilny tymczasowy link lub wskazuje na obraz, którego wyszukiwarka nie może pobrać.
Nieaktualne dane dynamiczne: wydarzenie już się zakończyło, oferta pracy jest zamknięta, produkt niedostępny, a znaczniki nadal przekazują stary status.
Błędy JSON: pojedyncze lub typograficzne cudzysłowy; przecinek po ostatniej właściwości; niezamknięty nawias; komentarze wewnątrz JSON; nieprzetworzony znak nowej linii wewnątrz wartości ciągu; zduplikowany klucz w tym samym obiekcie.

Przepływ pracy wdrożenia

Określ główny obiekt i cel znaczników.
Sprawdź aktualne wymagania Schema.org i potrzebnego konsumenta danych.
Wybierz najdokładniejszy typ.
Wypełnij tylko wiarygodne właściwości obecne na stronie.
Wygeneruj JSON-LD.
Sprawdź kod w Schema Markup Validator.
Jeśli potrzebujesz obsługiwanego wyniku rozszerzonego Google, sprawdź w Rich Results Test.
Wstaw kod do wersji testowej strony.
Ponownie sprawdź opublikowany URL, a nie tylko wyizolowany fragment.
Skonfiguruj aktualizację wartości dynamicznych i ponowne sprawdzenia po zmianach szablonu.

Krótka lista kontrolna przed publikacją

wybrano typ rzeczywistego obiektu strony;
dane są zgodne z widoczną treścią;
brak zmyślonych ocen, opinii i właściwości;
URL są absolutne, dostępne i kanonicznie spójne;
daty podane w czytelnym formacie i ze strefą czasową, gdy jest potrzebna;
cena i waluta znajdują się w oddzielnych polach;
te same encje są połączone przez stabilny @id;
brak konfliktujących znaczników z innego modułu;
kod przeszedł odpowiednie walidacje;
opublikowany URL zawiera ten sam poprawny JSON-LD;
dane dynamiczne będą aktualizowane.

Częste pytania

Czy Schema.org gwarantuje rozszerzony fragment?

Nie. Prawidłowe znaczniki sprawiają, że strona jest gotowa do przetworzenia, ale wyszukiwarka samodzielnie decyduje, czy z nich skorzystać i jak wyświetlić wynik.

Czy trzeba dodawać Schema.org na każdej stronie?

Tylko tam, gdzie jest encja i przydatne, wiarygodne właściwości do jej opisania. Masowe wstawianie tego samego bloku bez powiązania z treścią tworzy błędy i sprzeczności.

Czy można zostawić właściwości, których użytkownik nie widzi?

Powiązania techniczne i identyfikatory mogą nie być wyświetlane jako oddzielny tekst, ale faktyczne informacje o produkcie, ocenie, pytaniach, wydarzeniu i innych obiektach muszą odpowiadać treści dostępnej dla użytkownika i zasadom konsumenta.

Gdzie umieścić kod – w `head` czy `body`?

JSON-LD może znajdować się w obu miejscach. Najważniejszy jest poprawny końcowy HTML, dostępność znaczników dla procesora i zgodność z bieżącą stroną.

Dlaczego Schema Markup Validator nie pokazuje błędu, a Google pokazuje?

Pierwsze narzędzie sprawdza słownik Schema.org i strukturę znaczników, a Google dodatkowo stosuje wymagania konkretnej funkcji wyszukiwania.

Czy warto obecnie oznaczać FAQPage?

Można, gdy strona rzeczywiście jest FAQ, a typ jest przydatny dla innych konsumentów danych. Ale dla większości stron nie należy liczyć na rozszerzony wynik FAQ od Google.

Czy HowTo jest potrzebne dla Google?

Google nie wyświetla już rozszerzonych wyników HowTo. Typ może pozostać przydatny jako opis semantyczny dla innych systemów, ale nie należy oczekiwać dawnego efektu wyszukiwania Google.

Powiązane narzędzia

Diffchecker; Procesor tekstu; Base64.

Materiały oficjalne

Ogólne zalecenia redakcyjne dla sekcji

1. Nie powielać tego samego bloku komercyjnego wewnątrz każdego przydatnego tekstu

Obecny blok o „kompleksowym audycie SEO, narzędziach do wzrostu widoczności w AI i automatyzacji” można pozostawić jako oddzielny wizualny CTA po głównym materiale. Nie należy wbudowywać go w strukturę artykułu między przydatnymi sekcjami: przerywa to scenariusz czytania i wygląda identycznie na wszystkich dziewięciu stronach. Lepiej użyć krótkiego kontekstowego linku odpowiadającego narzędziu. Na przykład:

po generatorze UTM — do raportów według kanałów i konwersji;
po kombinacji — do sprawdzania częstotliwości, grupowania i przypisywania zapytań do stron;
po Schema — do audytu danych strukturalnych;
po Diffchecker — do monitorowania zmian na stronach;
po usunięciu duplikatów — do importu semantyki lub URL do projektu.

2. Nie tworzyć identycznych sekcji „Zalety” i „Dla kogo” według szablonu

Ich treść prawie zawsze staje się powtórzeniami: „szybko”, „wygodnie”, „za darmo”, „dla marketerów i specjalistów”. Bardziej przydatne jest pozostawienie konkretnych scenariuszy, ograniczeń, przykładów i FAQ. Krótkie cechy, takie jak „za darmo”, „w przeglądarce”, „bez rejestracji”, są już wyświetlane obok narzędzia.

3. Uzgodnić obietnice z rzeczywistą implementacją

Przed publikacją deweloperzy powinni potwierdzić:

czy przetwarzanie odbywa się całkowicie w przeglądarce, czy dane są wysyłane na serwer;
jakie istnieją limity objętości tekstu i liczby wierszy;
czy oryginalne dane lub wyniki są przechowywane;
jaki algorytm i biblioteka są używane do wykrywania języka;
jak dokładnie Diffchecker porównuje słowa i wiersze;
czy usuwanie duplikatów rozróżnia wielkość liter i spacje oraz w jakiej kolejności stosowane są działania;
czy generator haseł korzysta z kryptograficznie bezpiecznego źródła losowości;
jakiego kodowania używa konwerter Base64;
czy obsługuje Base64url, czy tylko standardowy Base64.

Po potwierdzeniu szczegóły te można umieścić w krótkim bloku „Przetwarzanie i prywatność” na każdej stronie. Nie można obiecywać lokalnego przetwarzania i braku przechowywania tylko dlatego, że narzędzie działa wizualnie w przeglądarce.

4. Pokazywać ograniczenia obok funkcji, a nie chować ich na dole

Szczególnie ważne ostrzeżenia:

parametry UTM nie są umieszczane na linkach wewnętrznych;
Diffchecker nie sprawdza znaczenia ani faktycznej poprawności;
kombinator nie potwierdza popytu ani nie tworzy automatycznie struktury strony;
Base64 nie szyfruje danych;
nie należy bez sprawdzenia zamieniać całego URL na małe litery;
hasła nie można uznać za kryptograficznie bezpieczne bez sprawdzenia generatora;
prawidłowy Schema.org nie gwarantuje wyniku rozszerzonego.

5. Dodawać linki wewnętrzne zgodnie z następną akcją użytkownika

Zamiast ogólnej listy wszystkich narzędzi na końcu strony, umieść dwa lub trzy rzeczywiście powiązane linki. Nazwa linku powinna wyjaśniać kontynuację scenariusza: „Wyczyść uzyskaną listę”, „Porównaj dwie wersje”, „Usuń powtarzające się kombinacje”, „Sprawdź język tekstu”.

6. Nie oznaczać FAQ tylko w celu obiecywania rozszerzonego fragmentu

FAQ w tych tekstach jest przydatne dla użytkownika i może pozostać na stronie. Ale decyzję o dodaniu FAQPage należy podjąć osobno, biorąc pod uwagę zasady Schema.org i obecne ograniczenia wyszukiwarek. Dla zwykłych stron Google zazwyczaj nie wyświetla rozszerzonych wyników FAQ.

7. Zalecana kolejność wdrażania

Diffchecker, wykrywanie języka i UTM — obecnie mają najmniej przydatnego materiału.
Usuwanie duplikatów — pilnie poprawić radę o zamianie wszystkich URL na małe litery.
Base64 — zastąpić słowo „odszyfruj” przez „zdekoduj” i dodać Base64url.
Generator haseł — zaktualizować zalecenia dotyczące długości i sprawdzić implementację losowego generowania.
Schema.org — zastąpić obecny nadmiernie długi i powtarzalny tekst bardziej zwięzłym, ale technicznie precyzyjnym przewodnikiem.
Kombinator i procesor tekstu — pozostawić mocne części, dodać ograniczenia i praktyczną kolejność działań.

Potrzebujesz pełnego audytu SEO, narzędzi do zwiększania widoczności w AI i automatyzacji?

Wyszukiwarki się zmieniają: klasyczne pozycje już nie wystarczają; liczy się także widoczność strony w odpowiedziach AI, jakość treści, przewagi konkurencji i skuteczność reklam. Labrika analizuje stronę pod kątem ponad 400 czynników i daje dziesiątki narzędzi do wzrostu: audyt SEO, analizę AI, pisarza AI, pozycje w wyszukiwarce i AI, analizę kampanii PPC, konkurencji oraz monitoring zmian na stronie. Uruchom Labrikę i sprawdź, czy Twoja strona jest gotowa konkurować nie tylko w Google, ale także w nowych asystentach AI i wyszukiwarkach.

Zarejestruj się