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.

Najlepszy schemat na start Article, WebPage i BreadcrumbList dla większości stron poradnikowych.
Najlepszy proces Generuj schemat z tych samych metadanych, które tworzą tytuł, opis, kanoniczny URL i Open Graph.
Najlepsza weryfikacja rzeczywistości Znaczniki FAQPage i WebSite mogą opisywać treść, ale nie buduj strategii wokół przestarzałych wyświetleń Google.

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.

Ważne: Dane strukturalne powinny wspierać stronę, a nie zastępować użyteczną treść. Jeśli strona jest uboga, myląca, przestarzała lub wprowadzająca w błąd, schemat nie poprawi wyniku w wyszukiwarce.

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.

01

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.

02

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.

03

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.

04

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.

05

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.

06

Uczyń obrazy indeksowalnymi

Używaj absolutnych URL obrazów, odpowiednich wymiarów i plików nieblokowanych przez roboty, uwierzytelnianie lub leniwe ładowanie.

07

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.

08

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.

HTMLPrzykład JSON-LD dla artykułu
<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>
C#Wzorzec pomocnika C#
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>");
}
Praktyczna zasada: Używaj stabilnych URL dla url i @id. Stosuj ten sam kanoniczny URL wszędzie. Jeśli ta sama strona jest pod wieloma URL w różnych językach, generuj metadane specyficzne dla języka i zachowaj spójność hreflang/kanonicznego ustawienia.

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 rozszerzonych

Sł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 schematu

Typowe 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

Powyższe wskazówki opierają się na oficjalnej dokumentacji Google Search Central i schema.org, przekształconej w praktyczną listę kontrolną JSON-LD.

01 Wprowadzenie do danych strukturalnych Google developers.google.com 02 Zasady danych strukturalnych Google developers.google.com 03 Dane strukturalne Google Article developers.google.com 04 Dane strukturalne Google Breadcrumb developers.google.com 05 Dane strukturalne Google FAQ developers.google.com 06 Aktualizacja pola wyszukiwania linków witryny Google developers.google.com 07 Pierwsze kroki ze schema.org schema.org 08 Test wyników rozszerzonych Google search.google.com 09 Walidator oznaczeń schematu validator.schema.org

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.