Dane strukturalne (Schema.org)

Dane strukturalne to dodatkowy, maszynowo czytelny opis tego, co już znajduje się na stronie. Zwykle zapisuje się je jako JSON-LD, czyli fragment danych w kodzie HTML. Zamiast zostawiać systemowi sam tekst „Audyt AI, 60 minut, 297 zł”, można opisać, że strona dotyczy usługi, kto ją oferuje, jaka jest cena i gdzie prowadzi oferta. Słownik Schema.org dostarcza wspólnych typów i właściwości, takich jak Organization, Person, Service, Article, Event czy FAQPage. Dzięki temu wyszukiwarka nie musi zgadywać, czy fragment strony jest nazwą firmy, datą wydarzenia czy odpowiedzią na pytanie.

To nie jest to samo co dobre copy, SEO title ani zwykłe metatagi. Treść odpowiada na potrzebę człowieka, a dane strukturalne opisują tę treść w ustalonym formacie. Obie warstwy muszą mówić prawdę i być ze sobą zgodne. Google wyraźnie zaznacza, że poprawny markup nie gwarantuje wyświetlenia rich result. Nie jest też prostym przełącznikiem widoczności w odpowiedziach generatywnych. Nadal liczą się użyteczność strony, dostępność dla crawlera, wiarygodne źródła i faktyczna jakość odpowiedzi. Schema pomaga interpretacji, lecz nie naprawi oferty, której nie da się zrozumieć bez niej.

Dla solopreneura najlepszym punktem startu są strony, na których podajesz jednoznaczne fakty: strona główna z Organization i Person, usługa z Service oraz Offer, artykuł z Article, wydarzenie z Event, a widoczna sekcja pytań z FAQPage. Wybieraj tylko typ, który opisuje realną zawartość. Jeśli na stronie nie ma prawdziwych pytań i odpowiedzi, nie wstawiaj FAQPage dla pozoru. Jeśli konsultacja nie ma publicznie ustalonej ceny, nie wymyślaj pola price. Taki markup rozjeżdża się z treścią, zawodzi odbiorcę i może zostać zignorowany.

Praktyczny przykład: ekspert publikuje stronę warsztatu o budowie systemu AI. W treści jasno podaje tytuł, opis, datę, godzinę, format online, prowadzącego oraz link do zapisu. JSON-LD Event może powtórzyć dokładnie te dane w odpowiednich polach. Na osobnej stronie usługi warto opisać nazwę, zakres, cenę i URL zakupu jako Service oraz Offer. W artykule poradnikowym Article pomaga wskazać nagłówek, autora, datę publikacji i obraz. Najpierw piszesz pełną, widoczną stronę dla człowieka. Dopiero potem dodajesz opis danych, który odzwierciedla tę stronę.

Najczęstszy błąd to traktowanie danych strukturalnych jak generatora obietnic. Nie oznaczaj ocen, recenzji, cen, dostępności ani FAQ, jeśli ich nie pokazujesz użytkownikowi albo nie potrafisz ich potwierdzić. Nie kopiuj też losowo obszernego JSON-LD z generatora. Jeden błędny typ, nieaktualna data wydarzenia lub stara cena potrafią zbudować sprzeczność między kodem a ofertą. Przy zmianie usługi sprawdzaj jednocześnie copy, CTA, metadane i markup. Dane strukturalne są częścią utrzymania strony, a nie zadaniem wykonanym raz przy wdrożeniu.

W kontekście AEO i GEO ich rola jest pomocnicza, ale konkretna. Uporządkowane informacje ułatwiają maszynie połączenie strony z encją, autorem, usługą oraz pytaniem, na które strona odpowiada. Nie zastępują cytowalnej treści: potrzebujesz krótkiej odpowiedzi blisko pytania, wyjaśnienia, przykładów i źródeł tam, gdzie temat tego wymaga. Dla encyklopedii AI sensowny zestaw to widoczny artykuł, prawdziwy autor, aktualna data, wewnętrzne linki do pojęć oraz zgodne dane Article i FAQPage. To zwiększa klarowność, nie daje jednak uczciwej podstawy do obietnicy „AI na pewno nas poleci”.

Wdrożenie warto zakończyć walidacją i kontrolą renderowanego HTML. Schema.org udostępnia własny validator, a Google ma Rich Results Test dla typów obsługiwanych w wynikach rozszerzonych. Narzędzie może potwierdzić składnię, lecz nie odpowie za prawdziwość lub sens biznesowy informacji. Po publikacji otwórz stronę jako użytkownik, porównaj ją z JSON-LD i sprawdź, czy zmiana ceny, daty albo autora została zaktualizowana w obu miejscach. Taka prosta checklista chroni przed markowaniem danych, które kiedyś były prawdziwe, ale dziś wprowadzają w błąd.