Opisywanie treści witryny dla wyszukiwarek: wdrażanie i kontrola JSON-LD

JSON-LD opisuje treść strony w formie czytelnej maszynowo. Wynik rozszerzony to wynik wyszukiwania z dodatkowymi informacjami, na przykład ceną produktu lub oceną. Poprawny składniowo blok nie dowodzi jednak kwalifikacji do konkretnego wyniku rozszerzonego Google. Potrzebne są cztery kontrole: poprawność JSON, właściwe słownictwo, wymagania danej funkcji wyszukiwania i zgodność z widoczną stroną.

Błędy często pozostają niewidoczne w zwykłym widoku strony, ale narzędzia kontrolne potrafią wykryć wiele problemów. Z kolei brak wyniku rozszerzonego nie dowodzi błędu. Poprawne, kwalifikujące się znaczniki nadal nie gwarantują określonej prezentacji ani pozycji.

1. Format, słownictwo i funkcja wyszukiwania

@context określa interpretację krótkich nazw. W typowych znacznikach Schema.org zapis "@context": "https://schema.org" jest czytelnym standardowym rozwiązaniem. JSON-LD dopuszcza jednak także obiekty kontekstu i pełne identyfikatory. Możliwych jest zatem kilka technicznie poprawnych reprezentacji.

Nazwy typów zachowują pisownię z danego słownika: Article oznacza typ artykułu Schema.org, a article nie. Parser JSON sprawdza tylko formalną strukturę, na przykład przecinki i cudzysłowy, a nie prawdziwość opisanych informacji. Rozpoznanie znanego typu wymaga dodatkowej kontroli słownictwa. Powiązane obiekty mogą występować pod @graph lub w oddzielnych blokach skryptu.

Schema.org opisuje więcej właściwości, niż wykorzystują pojedyncze funkcje Google. Poprawny JSON, walidacja Schema.org i kwalifikacja do prezentacji Google są zatem różnymi wynikami. Aktualna dokumentacja wybranej funkcji określa pola wymagane i zalecane.

2. Wartości zgodne ze znaczeniem

Szablony powinny generować czas publikacji, bieżącą cenę i adres obrazu z właściwych wartości źródłowych. Zlokalizowany ciąg ceny nie jest odpowiednim wejściem liczbowym. Liczba miejsc po przecinku zależy od waluty i modelu cenowego; dwa miejsca pasują do przykładu EUR, a nie do każdej waluty.

3. Article bez wymyślonych pól obowiązkowych

Aktualna dokumentacja Google dla Article nie wymienia obowiązkowych właściwości. headline należy do zalecanych właściwości. Użyteczny zestaw danych powinien mimo to opisywać rzeczywisty tytuł, autora, czas publikacji i modyfikacji oraz reprezentatywne obrazy.

Poniższy przykład jest wyłącznie szablonem dla odpowiadającej strony artykułu. Domena, obrazy, profil autora i daty są przykładowe i muszą odpowiadać rzeczywistym widocznym informacjom. Szablon produktu w dalszej części należy do strony produktu; oba przykłady nie są dodatkowymi metadanymi tego tutorialu.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "@id": "https://www.example.com/blog/json-ld/#article",
  "headline": "JSON-LD: poprawne wartości i jasna walidacja",
  "image": [
    "https://www.example.com/images/json-ld-16x9.jpg",
    "https://www.example.com/images/json-ld-4x3.jpg",
    "https://www.example.com/images/json-ld-1x1.jpg"
  ],
  "author": {
    "@type": "Person",
    "name": "Lukas Wojcik",
    "url": "https://www.example.com/about/"
  },
  "datePublished": "2026-08-26T10:00:00+02:00",
  "dateModified": "2026-09-02T14:30:00+02:00",
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://www.example.com/blog/json-ld/"
  }
}
</script>

Google nie określa sztywnego limitu 110 znaków dla headline. Długie tytuły mogą zostać skrócone zależnie od prezentacji. Obiekty autora z Person lub Organization i odpowiednim adresem profilu ułatwiają identyfikację. Daty modyfikacji powinny odzwierciedlać rzeczywiste zmiany, zamiast aktualizować się przy każdym żądaniu. Czasy publikacji i modyfikacji muszą tworzyć logiczną chronologię.

Google zaleca kilka pasujących obrazów artykułu w wysokiej rozdzielczości i proporcjach 16:9, 4:3 oraz 1:1. Trzy przykładowe adresy wymagają rzeczywiście istniejących wariantów. Logo lub czysto dekoracyjny symbol nie zastępuje obrazu przedstawiającego treść artykułu.

4. FAQPage pozostaje typem słownika

Od 7 maja 2026 roku Google nie pokazuje wyników rozszerzonych FAQ. Wcześniejsze ograniczenie do znanych witryn urzędowych i zdrowotnych nie opisuje już aktualnego stanu. W czerwcu 2026 roku usunięto dokumentację tej funkcji Google. Typ FAQPage w Schema.org istnieje niezależnie.

Znaczniki pytań i odpowiedzi mogą służyć wyszukiwaniu wewnętrznemu lub aplikacji zaprojektowanej do przetwarzania takiego formatu. Nie wynika z tego gwarantowana korzyść w asystentach AI lub innych wyszukiwarkach. Aplikacja musi faktycznie obsługiwać format.

Zgodność z dostępną treścią strony nie dotyczy wyłącznie FAQ. Dane artykułów, produktów i ocen również nie mogą zawierać zmyślonych lub mylących informacji. Działająca rozwijana odpowiedź różni się od odpowiedzi istniejącej tylko w JSON. Naruszenia mogą prowadzić do działań. Nie każdy błąd wyświetlania automatycznie skutkuje działaniem ręcznym.

5. Fragmenty produktowe i oferty sprzedawców

Dla fragmentu produktowego Google dokumentacja wymaga name i co najmniej jednej właściwości spośród review, aggregateRating lub offers. Blok oferty nie jest zatem konieczny dla każdego fragmentu produktowego. Prezentacje ofert sprzedawców mają osobne wymagania; niewielki przykład nie spełnia automatycznie wszystkich funkcji zakupowych.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "@id": "https://www.example.com/switch/#product",
  "name": "Kompaktowy switch PoE, 8 portów",
  "image": [
    "https://www.example.com/images/switch.png"
  ],
  "brand": {
    "@type": "Brand",
    "name": "Example"
  },
  "offers": {
    "@type": "Offer",
    "price": "149.00",
    "priceCurrency": "EUR",
    "availability": "https://schema.org/InStock",
    "url": "https://www.example.com/switch/"
  }
}
</script>

Przykład opisuje widoczną ofertę za 149,00 EUR. priceCurrency używa trzyliterowego kodu ISO 4217. Pełny adres Schema.org jest jednoznaczny dla availability, ale Google obsługuje też krótkie formy, takie jak InStock, w przypadku fragmentów produktowych. Obie formy muszą odpowiadać rzeczywistej dostępności produktu.

Dodatkowe oceny wymagają prawdziwych informacji zgodnych ze stroną. AggregateRating potrzebuje ratingValue, odpowiedniej liczby w ratingCount lub reviewCount oraz innej skali ocen, gdy ma zastosowanie. Gwiazdki nie mogą być wymyślane tylko po to, aby usunąć ostrzeżenie testu.

6. Walidacja jako część utrzymania szablonu

1. Kontrola składni JSON: podwójne cudzysłowy, właściwe przecinki i kodowanie znaków.
2. Kontrola typów i właściwości w walidatorze Schema.org. To nie potwierdza kwalifikacji do prezentacji Google.
3. Rich Results Test dla aktualnie obsługiwanych funkcji wyszukiwania, z rozróżnieniem błędów i zaleceń.
4. Sprawdzenie dostarczonej lub wyrenderowanej strony, obrazów, rzeczywistej treści i dostępności. Search Console oraz dostępne raporty ulepszeń pomagają po publikacji.

Przejście kilku testów nadal nie gwarantuje wyświetlenia. Testy automatyczne nie rozpoznają też każdej zmyślonej oceny lub mylącej ceny. Ponowna kontrola próbki stron należy do utrzymania po zmianie motywu, wtyczki lub źródła danych.