Praktyczny przewodnik po danych strukturalnych
Praktyczny przewodnik po JSON-LD Schema Markup dla SEO
JSON-LD pomaga wyszukiwarkom zrozumieć, czym jest strona, kto ją opublikował, jak pasuje do witryny i które fakty warto wykorzystać w obsługiwanych funkcjach wyszukiwania.
Celem nie jest dodanie każdego możliwego typu schematu, lecz dokładnych danych strukturalnych zgodnych z widoczną stroną, łatwych do walidacji i aktualizowanych przy zmianach treści.
Przydatna krótka wersja
Używaj JSON-LD, gdy możesz opisać stronę uczciwymi, widocznymi faktami: tytułem, opisem, autorem, datą publikacji, okruszkami, danymi produktu, wideo lub jasną treścią pytań i odpowiedzi. Nie dodawaj schematu, by obiecywać funkcje, których Google już nie pokazuje, ani oznaczać treści niewidocznej dla użytkowników.
Spis treści
Co właściwie robi JSON-LD
JSON-LD to maszynowo czytelny blok danych strukturalnych. Zwykle znajduje się w tagu skryptu w head lub body i opisuje byty za pomocą słownictwa schema.org. Wyszukiwarki traktują go jako warstwę wyjaśniającą nad widoczną treścią.
Jasność parsera
Znaczenie
Przekształca fakty ze strony w nazwane byty i właściwości, takie jak Article, author, datePublished, BreadcrumbList czy SoftwareApplication.
Funkcja wyszukiwania
Kwalifikowalność
Może uczynić stronę kwalifikującą się do wyników rozszerzonych, ale Google decyduje, co pokazać na podstawie jakości, polityki, zapytania i dostępności funkcji.
Graf witryny
Spójność
Daje Twojemu CMS lub aplikacji Blazor jedno miejsce na uporządkowane ponowne użycie kanonicznego URL, języka, tytułu, dat, obrazów i danych wydawcy.
To nie skrót
Limit
Nie naprawia słabej treści, fałszywych recenzji, ukrytych odpowiedzi FAQ, przestarzałych dat ani stron niezgodnych z danymi strukturalnymi.
Wybierz schemat według funkcji strony
Najprostszy sposób, by uniknąć spamerskich lub duplikujących się danych, to zapytać, co strona chce osiągnąć. Dodaj najmniejszy zestaw schematów dokładnie opisujący tę funkcję.
Zawartość
Article / BlogPosting
- Użyj do
- Poradniki, tutoriale, recenzje, posty informacyjne i długie wyjaśnienia.
- Dodaj, gdy
- Strona ma wyraźny nagłówek, autora lub wydawcę, datę publikacji, modyfikacji, kanoniczny URL i obraz.
- Unikaj, gdy
- Strona to głównie interfejs narzędzia, lista produktów, strona kategorii lub uboga strona docelowa.
Nawigacja
BreadcrumbList
- Użyj do
- Prawie każda strona poza stroną główną.
- Dodaj, gdy
- Użytkownicy mogą zrozumieć, gdzie strona znajduje się w hierarchii witryny.
- Unikaj, gdy
- Ścieżka okruszków nie zgadza się z linkami wewnętrznymi, kanonicznymi URL lub widoczną nawigacją.
Tożsamość witryny
WebPage / WebSite / Organization
- Użyj do
- Strona główna, huby, strony o nas i tam, gdzie ważna jest tożsamość wydawcy.
- Dodaj, gdy
- Chcesz stabilnego grafu podmiotów łączącego stronę, witrynę, wydawcę i język.
- Unikaj, gdy
- Dodajesz znacznik WebSite tylko, by uzyskać stare pole wyszukiwania linków witryny.
Produkt lub aplikacja
Product / SoftwareApplication
- Użyj do
- Narzędzia, aplikacje, strony SaaS, rozszerzenia, oprogramowanie do pobrania lub prawdziwe strony produktów.
- Dodaj, gdy
- Widoczna treść strony zawiera nazwę, opis, system operacyjny lub kategorię, cenę, oferty i oceny, gdy je oznaczysz.
- Unikaj, gdy
- Oceny, cena, dostępność lub recenzje nie są widoczne dla użytkowników na stronie.
Pytania
FAQPage
- Użyj do
- Widoczne sekcje pytań i odpowiedzi, które naprawdę pomagają użytkownikom zrozumieć temat.
- Dodaj, gdy
- Treść pytań i odpowiedzi jest przydatna na stronie, nawet jeśli Google nie wyświetla rozszerzonych wyników FAQ.
- Unikaj, gdy
- Dodajesz ogólne pytania i odpowiedzi tylko po to, by zająć miejsce w wynikach lub powtarzać tę samą odpowiedź na wielu stronach.
Media
VideoObject / ImageObject
- Użyj do
- Strony z ważnym osadzonym wideo, tutorialem lub indeksowalnym obrazem.
- Dodaj, gdy
- Media są centralnym elementem strony i mają tytuł, opis, miniaturę, datę przesłania oraz stabilny URL.
- Unikaj, gdy
- Media są dekoracyjne, ukryte, zablokowane lub nieistotne dla głównego celu strony.
Lista kontrolna wdrożenia zapobiegająca większości błędów
Dobry JSON-LD jest nudny w najlepszym znaczeniu: spójny, generowany z zaufanych pól, łatwy do walidacji i trudny do pominięcia przy zmianach strony.
Wybierz jeden główny podmiot strony
Określ, czy strona to głównie artykuł, produkt, aplikacja, wideo, FAQ, kolekcja czy strona ogólna. Schemat pomocniczy powinien wspierać główny podmiot.
Dopasuj do widocznej treści
Każde oznaczenie powinno być widoczne lub wyraźnie wywnioskowane na stronie: tytuł, autor, daty, cena, ocena, pytania i odpowiedzi, okruszki i obrazy.
Używaj stabilnych wartości @id
Nadaj ważnym elementom stabilne ID, np. kanoniczny URL plus #article, #webpage, #organization lub #faq. To pomaga parserom łączyć elementy grafu.
Generuj z wspólnych metadanych
Wykorzystaj te same pola źródłowe, które tworzą tytuły, meta opisy, kanoniczne URL, obrazy Open Graph, tagi językowe i daty ostatniej modyfikacji.
Utrzymuj daty wiarygodne
Zmieniaj dateModified tylko przy istotnych zmianach treści. Nie odświeżaj dat automatycznie, by wyglądały na nowsze w wynikach.
Uczyń obrazy indeksowalnymi
Używaj absolutnych URL obrazów, odpowiednich wymiarów i plików nieblokowanych przez roboty, uwierzytelnianie lub leniwe ładowanie.
Renderuj wcześnie
W Blazor i innych aplikacjach JavaScript preferuj prerenderowany lub renderowany po stronie serwera JSON-LD, aby roboty widziały go w początkowej odpowiedzi HTML.
Weryfikuj i monitoruj
Przeprowadź test wyników rozszerzonych przed publikacją, sprawdź składnię w walidatorze schematu i monitoruj Search Console po indeksacji.
Czysty wzorzec JSON-LD dla stron Blazor
W Blazor najbezpieczniej budować schemat z metadanych strony podczas inicjalizacji lub prerenderingu, serializować raz i renderować skrypt application/ld+json widoczny dla robotów w początkowym HTML.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"@id": "https://example.com/en/json-ld-schema-guide/#article",
"headline": "JSON-LD Schema Markup Guide for Practical SEO",
"description": "A practical guide to choosing, generating, and validating structured data.",
"image": "https://example.com/images/json-ld-guide.png",
"datePublished": "2026-03-28T10:00:00+00:00",
"dateModified": "2026-05-31T10:00:00+00:00",
"author": {
"@type": "Organization",
"name": "Example Publisher"
},
"publisher": {
"@type": "Organization",
"name": "Example Publisher",
"logo": {
"@type": "ImageObject",
"url": "https://example.com/logo.png"
}
},
"mainEntityOfPage": {
"@type": "WebPage",
"@id": "https://example.com/en/json-ld-schema-guide/"
}
}
</script>private MarkupString BuildJsonLd(PageMetaData meta)
{
var pageUrl = BuildPageUrl(meta);
var schema = new Dictionary<string, object?>
{
["@context"] = "https://schema.org",
["@type"] = "Article",
["@id"] = $"{pageUrl}#article",
["headline"] = meta.Title,
["description"] = meta.Description,
["url"] = pageUrl,
["datePublished"] = meta.Published?.ToString("O"),
["dateModified"] = meta.Modified?.ToString("O"),
["inLanguage"] = CS.Culture
};
var json = JsonSerializer.Serialize(schema, new JsonSerializerOptions
{
DefaultIgnoreCondition = JsonIgnoreCondition.WhenWritingNull
});
return new MarkupString($"<script type=\"application/ld+json\">{json}</script>");
}Weryfikuj JSON-LD przed użyciem
Weryfikacja ma dwa zadania. Walidator schematu sprawdza, czy słownictwo i składnia JSON-LD są poprawne. Test wyników rozszerzonych Google sprawdza, czy Google uznaje stronę za kwalifikującą się do obsługiwanych typów wyników rozszerzonych.
Kwalifikowalność Google
Test wyników rozszerzonych
Sprawdza, czy Google może odczytać stronę i czy wykryte dane strukturalne kwalifikują się do obsługiwanych wyników rozszerzonych.
Otwórz test wyników rozszerzonychSłownictwo
Walidator oznaczeń schematu
Sprawdza strukturę schema.org i składnię JSON-LD, w tym typy, właściwości, zagnieżdżone elementy i błędny JSON.
Otwórz walidator schematuPo publikacji
Search Console
Używaj raportów Inspekcji URL i Ulepszeń, by wykrywać problemy z indeksowaniem i danymi strukturalnymi po przetworzeniu strony przez Google.
Przeczytaj dokumentację danych strukturalnych GoogleTypowe błędy JSON-LD obniżające zaufanie
Większość problemów ze schematem to nie złożone błędy techniczne, lecz rozbieżności między znacznikiem a tym, co użytkownik lub robot może zweryfikować na stronie.
Oznaczanie ukrytej lub brakującej treści
Jeśli użytkownicy nie widzą odpowiedzi, recenzji, oferty, obrazu lub autora, nie umieszczaj tego w danych strukturalnych. To najszybszy sposób na utratę zaufania.
Dodawanie FAQPage do wszystkiego
Schemat FAQ może opisywać widoczne pytania i odpowiedzi, ale nie powinien być kopiowany na każdą stronę. Używaj go tylko, gdy Q&A poprawia stronę.
Sprzeczne duplikaty skryptów
Wiele bloków Article z różnymi nagłówkami, datami lub URL-ami utrudnia interpretację strony. Jeden jasny graf jest lepszy niż trzy częściowe.
Błędny kanoniczny lub @id
URL-e schematu powinny odpowiadać kanonicznej stronie, URL kultury i konfiguracji hreflang. Mieszane języki powodują duplikaty i zamieszanie w podmiotach.
Fałszywa świeżość
Nie zmieniaj dateModified przy edycjach szablonu, śledzeniu zmian lub aktualizacjach schematu. Używaj daty tylko dla rzeczywistych zmian treści.
Późne renderowanie tylko po stronie klienta
Jeśli JSON-LD pojawia się dopiero po opóźnionym renderowaniu klienta, roboty mogą go nie zauważyć. Lepiej stosować renderowanie po stronie serwera lub prerendering dla ważnych stron.
Praktyczne schematy według typu strony
Rzadko potrzebujesz ogromnego grafu. Te kombinacje obejmują strony, które większość małych witryn, blogów, narzędzi i projektów recenzji faktycznie publikuje.
Artykuł poradnikowy
Article + BreadcrumbList + WebPage
- Używaj Article dla nagłówka, autora, wydawcy, obrazu, dat i nazw sekcji.
- Używaj BreadcrumbList dla widocznej ścieżki witryny.
- Używaj odniesień WebPage lub @id, by połączyć stronę i podmiot artykułu.
Strona narzędzia
SoftwareApplication + WebPage + BreadcrumbList
- Używaj SoftwareApplication tylko jeśli strona dotyczy prawdziwej aplikacji lub narzędzia.
- Uwzględniaj system operacyjny, kategorię, cenę lub ofertę tylko gdy są widoczne.
- Unikaj znaczników recenzji lub ocen, jeśli strona nie pokazuje prawdziwych danych.
Strona recenzji
Recenzja / Produkt tylko gdy strona to obsługuje
- Oznaczaj recenzowany element, autora, datę i ocenę tylko, gdy są wyraźnie widoczne na stronie.
- Zachowaj przejrzystość linków afiliacyjnych i kontekstu komercyjnego.
- Używaj tej samej oceny w schemacie i widocznej treści.
Strona z pytaniami
FAQPage tylko dla przydatnych, widocznych pytań i odpowiedzi
- Każda odpowiedź powinna być pomocna sama w sobie, nie tylko wariantem słowa kluczowego.
- Nie ukrywaj odpowiedzi za zablokowanym interfejsem, do którego nie mają dostępu roboty.
- Nie oczekuj, że FAQ będzie główną korzyścią SEO.
Sprawdzone źródła
Źródła badań do tego przewodnika
Powyższe wskazówki opierają się na oficjalnej dokumentacji Google Search Central i schema.org, przekształconej w praktyczną listę kontrolną JSON-LD.
Najczęstsze pytania
Czy JSON-LD jest czynnikiem rankingowym?
JSON-LD nie jest magicznym przełącznikiem rankingowym. Pomaga wyszukiwarkom zrozumieć kwalifikującą się treść i wspiera wyniki rozszerzone, ale ranking zależy od jakości, trafności, indeksowalności, linków i innych sygnałów.
Gdzie umieścić JSON-LD na stronie?
Tag skryptu w sekcji head jest najłatwiejszy do zarządzania, ale Google może też odczytać JSON-LD w body. Ważne, by znacznik był w renderowanej stronie i odpowiadał widocznej treści.
Czy nadal używać schematu FAQPage?
Używaj FAQPage tylko gdy strona ma naprawdę przydatne, widoczne pytania i odpowiedzi. Nie licz na dodatkową przestrzeń w wynikach Google, bo wyświetlanie FAQ zostało mocno ograniczone i wycofane dla większości stron.
Czy jedna strona może mieć wiele bloków JSON-LD?
Tak. Zwykła strona artykułu może mieć dane Article, BreadcrumbList i WebPage. Zachowaj spójność bloków, unikaj duplikatów i konfliktów oraz używaj stabilnych wartości @id do łączenia elementów.
Czy JSON-LD jest lepszy od Microdata?
W większości nowoczesnych stron tak. Google obsługuje JSON-LD, Microdata i RDFa, ale JSON-LD jest łatwiejszy w utrzymaniu, bo nie wymaga atrybutów schematu w szablonach HTML.
Jak często weryfikować dane strukturalne?
Weryfikuj po każdej zmianie szablonów, pól metadanych, pomocników schematu, URL, routingu językowego, generowania obrazów, danych recenzji lub sekcji FAQ. Sprawdzaj też Search Console po indeksacji ważnych stron.