Dane strukturalne to jedno z niewielu zadań SEO, w których model językowy naprawdę oszczędza czas. Składnia JSON-LD jest sztywna, typy ze słownika schema.org są dobrze opisane, a wynik da się sprawdzić automatycznie. Problem jest jeden: model, któremu brakuje danych, chętnie je dopisuje. Poniżej osiem szablonów promptów, z których każdy zawiera zakaz zmyślania pól i kończy się krokiem walidacji.
Dlaczego JSON-LD to dobre zadanie dla modelu
Generowanie znaczników to praca polegająca na przepisaniu faktów ze strony do ustalonego formatu. Model nie musi niczego wymyślać, wystarczy, że dopasuje treść do właściwości typu i zachowa poprawny zapis JSON. To zadanie odwrotne do pisania tekstów, gdzie swoboda modelu bywa wadą (piszemy o tym w artykule kiedy nie warto pisać z AI). Tutaj ramy są ciasne, więc łatwo ocenić, czy wynik jest dobry.
Druga zaleta: format jest niezależny od HTML. Blok JSON-LD wstawia się w jednym miejscu strony, bez ingerencji w szablon, co odróżnia go od mikrodanych. Szczegółowe porównanie obu podejść znajdziesz w tekście JSON-LD vs microdata.
Prompt bazowy i zasada braku zmyślonych pól
Każdy z ośmiu szablonów zaczyna się od tego samego bloku instrukcji. Warto trzymać go w bibliotece promptów jako osobny fragment i doklejać na początku:
Jesteś generatorem danych strukturalnych JSON-LD zgodnych ze schema.org.
Zasady:
1. Używaj wyłącznie faktów podanych w sekcji DANE. Nie dopisuj niczego.
2. Jeśli właściwość jest wymagana, a brak danych, wpisz wartość "BRAK_DANYCH".
3. Nie twórz adresów URL, dat, cen, ocen ani nazw, których nie ma w DANYCH.
4. Zwróć tylko kod w bloku script type="application/ld+json", bez komentarza.
5. Pod kodem wypisz listę pól oznaczonych BRAK_DANYCH.
DANE:
[wklej treść strony lub listę faktów]Kluczowy jest punkt drugi. Znacznik BRAK_DANYCH sprawia, że luka staje się widoczna, zamiast zostać zapełniona prawdopodobnie brzmiącą wartością. Model bez tej instrukcji potrafi podać fikcyjny numer telefonu, ocenę 4,8 z 127 recenzji albo datę publikacji z kosmosu. Takie dane w znacznikach są gorsze niż ich brak, bo Google traktuje niezgodność z treścią strony jako naruszenie wytycznych.
Dwie praktyczne uwagi do pracy z blokiem bazowym. Po pierwsze, jedna rozmowa to jedna podstrona: przy kilku stronach naraz model zaczyna mieszać fakty między nimi. Po drugie, jeśli narzędzie pozwala ustawić temperaturę, ustaw ją nisko (0–0,3). Przy przepisywaniu faktów kreatywność nie jest potrzebna, a niższa temperatura zmniejsza ryzyko, że model dopowie brakujące wartości.
Szablony: Article, Product, FAQPage, Organization
1. Article. Do bloku bazowego dodaj: „Typ: Article. Pola: headline, author (Person z name i url), datePublished, dateModified, image, publisher (Organization z logo). headline maksymalnie 110 znaków, skopiuj dosłownie z tytułu strony”. Autor powinien wskazywać na istniejącą stronę profilu, bo to ona buduje wiarygodność treści.
2. Product. „Typ: Product. Pola: name, image, description, sku, gtin13 jeśli podany, brand, offers (Offer z price, priceCurrency, availability, url). Nie dodawaj aggregateRating ani review, jeśli w DANYCH nie ma ocen”. To ostatnie zdanie jest ważne: modele mają silną skłonność do dodawania ocen do produktów.
3. FAQPage. „Typ: FAQPage. Każde pytanie i odpowiedź przepisz dosłownie z treści. Nie skracaj, nie parafrazuj, nie dodawaj pytań”. Treść odpowiedzi w znaczniku musi być identyczna z widoczną na stronie.
4. Organization. „Typ: Organization. Pola: name, url, logo, sameAs (tylko adresy profili wymienione w DANYCH), contactPoint jeśli podano telefon lub e-mail”. Lista sameAs jest najczęstszym miejscem halucynacji: model dopisuje profile, które według niego „powinny istnieć”.
Szablony: Person, BreadcrumbList, HowTo, LocalBusiness
5. Person. „Typ: Person. Pola: name, jobTitle, worksFor, url, image, sameAs, knowsAbout (maksymalnie pięć tematów, tylko te wymienione w biogramie)”. Ten szablon przydaje się przy stronach autorów.
6. BreadcrumbList. „Typ: BreadcrumbList. Na podstawie podanego adresu URL i nazw kategorii utwórz ListItem z position, name i item. Pozycja 1 to strona główna. Nie zmieniaj struktury adresów”. Tu model sprawdza się bez zarzutu, bo cała informacja jest w adresie.
7. HowTo. „Typ: HowTo. Pola: name, step (HowToStep z name i text, w kolejności z treści), totalTime w formacie ISO 8601 tylko jeśli podano czas”. Google nie wyświetla już wyników rozszerzonych HowTo, ale znacznik nadal porządkuje informację dla innych systemów, w tym wyszukiwarek AI.
8. LocalBusiness. „Typ: najbardziej szczegółowy podtyp LocalBusiness pasujący do opisu. Pola: name, address (PostalAddress), telephone, openingHoursSpecification, geo tylko jeśli podano współrzędne”. Zakaz zgadywania współrzędnych jest konieczny, bo model wygeneruje je na podstawie nazwy miasta.
Jeśli przygotowujesz znaczniki dla wielu stron jednocześnie, te szablony dobrze łączą się z arkuszem, w którym każdy wiersz to zestaw danych jednej podstrony. Taki schemat opisujemy w poradniku o stronach programmatic z arkusza Google.
Walidacja wyniku przed wdrożeniem
Wygenerowany kod przechodzi przez trzy kontrole, zawsze w tej kolejności:
- Kontrola składni. Parser JSON (choćby w konsoli przeglądarki) odrzuci brakujące przecinki i niezamknięte nawiasy.
- Kontrola zgodności ze słownikiem. Schema Markup Validator pokazuje nieistniejące właściwości i błędne typy wartości.
- Kontrola kwalifikacji do wyników rozszerzonych. Test wyników z elementami rozszerzonymi Google wskaże brakujące pola wymagane dla danego typu. Wymagania opisuje dokumentacja Google Search Central.
Czwarta kontrola jest ręczna i najważniejsza: porównanie każdej wartości z treścią strony. Pomaga tu drugi prompt, uruchomiony w osobnej rozmowie: „Oto kod JSON-LD i treść strony. Wypisz każdą wartość z kodu, której nie da się znaleźć dosłownie w treści”. Model weryfikujący, który nie widział procesu generowania, łatwiej wychwytuje dopisane fakty.
Wstawianie znaczników w WordPressie
Jeśli strona korzysta z RankMath lub Yoast, wtyczka generuje już Article, BreadcrumbList i Organization. Dokładanie własnego bloku tego samego typu tworzy duplikaty, więc ręczne JSON-LD warto ograniczyć do typów, których wtyczka nie obsługuje, lub wyłączyć dany schemat w jej ustawieniach. Kod wstawia się w bloku HTML w edytorze albo w polu niestandardowego schematu wtyczki.
Dla całych typów treści lepiej sprawdza się wstawianie przez szablon motywu lub krótki fragment kodu w functions.php. Krok po kroku pokazujemy to w tutorialu schema w WordPressie. Po wdrożeniu sprawdź stronę narzędziem do inspekcji adresu URL w Search Console, by zobaczyć, czy Google odczytał znaczniki z wyrenderowanej wersji.
Najczęstsze błędy w wygenerowanym kodzie
- Zmyślone oceny i recenzje. aggregateRating bez źródła w treści to najpoważniejszy błąd, grożący działaniem ręcznym.
- Daty w złym formacie. Model pisze „21 października 2026” zamiast ISO 8601 (2026-10-21). Dodaj format do promptu.
- Względne adresy URL. W polach url, image i item potrzebne są adresy bezwzględne z protokołem.
- Cudzysłowy typograficzne. Polskie „ ” zamiast prostych cudzysłowów psują składnię. Zdarza się to po kopiowaniu przez edytory tekstu.
- Pola spoza słownika. Model wymyśla właściwości o sensownie brzmiących nazwach, których schema.org nie zna.
- Nieusunięte znaczniki BRAK_DANYCH. Przed wdrożeniem uzupełnij je albo usuń całe pole.
FAQ
Czy model AI może sam pobrać dane ze strony do JSON-LD?
Może, jeśli ma dostęp do przeglądania stron, ale bezpieczniej jest wkleić treść ręcznie. Wtedy wiadomo dokładnie, na jakich danych pracował model, i łatwiej sprawdzić, czy niczego nie dopisał.
Który typ schematu najczęściej zawiera zmyślone dane?
Product i LocalBusiness. W pierwszym model dodaje oceny i recenzje, w drugim współrzędne geograficzne, godziny otwarcia i numery telefonów. Oba szablony powinny zawierać wyraźny zakaz dodawania tych pól bez źródła.
Czy ręczny JSON-LD koliduje z RankMath?
Tak, jeśli dublujesz typ, który wtyczka już generuje, np. Article. Własny kod dodawaj dla typów nieobsługiwanych albo wyłącz odpowiedni schemat w ustawieniach wtyczki dla danego wpisu.
Czy poprawny JSON-LD gwarantuje wynik rozszerzony w Google?
Nie. Poprawne znaczniki są warunkiem koniecznym, ale Google sam decyduje, czy wyświetli wynik rozszerzony. Część typów, jak HowTo, w ogóle nie jest już prezentowana w ten sposób.
Ile kosztuje weryfikacja wygenerowanego kodu?
Narzędzia walidacyjne są darmowe. Największym kosztem jest ręczne porównanie wartości z treścią strony, które przy jednej podstronie zajmuje kilka minut, a przy setkach wymaga półautomatycznego porównania w arkuszu.