Jest pewna niejasność, która towarzyszy rozmowom o danych strukturalnych od dekady. Niejasność polega na tym, że dane strukturalne brzmią jak coś technicznego — jak zestaw dodatkowych tagów, które wrzuca się do kodu, żeby Google pokazał obok wyniku wyszukiwania gwiazdki albo cenę. Niby wiadomo, że to ważne, ale w praktyce wielu ludzi ich nie wdraża, a jeśli wdraża, to dlatego, że wtyczka SEO robi to za nich.
W erze agentów AI to myślenie przestaje wystarczać. Bo dane strukturalne przestają być dodatkiem do SEO — zaczynają być jedynym sposobem, w jaki maszyna czytająca twoją stronę może powiedzieć czym twoja oferta jest, a nie tylko o czym jest. Różnica wydaje się subtelna, ale jest fundamentalna, i w tym wpisie spróbuję pokazać dlaczego.
Przypomnę tło. W manifeście tej serii wprowadziłem sześć filarów agent-readiness. W wpisie o czytelności pokazałem filar pierwszy — czy agent widzi twoją stronę. Ten wpis dotyczy filaru drugiego — czy agent rozumie, co widzi. Bo widzieć a rozumieć to dwie zupełnie różne rzeczy, i druga wymaga innego typu pracy niż pierwsza.
Tekst opowiada
Zacznijmy od przykładu. Wyobraź sobie stronę produktu — ekspres do kawy, cena 2490 zł, opis: „profesjonalny ekspres ciśnieniowy z młynkiem żarnowym i automatycznym spienianiem mleka, idealny do domu i małego biura, dostępny w kolorze czarnym i srebrnym”. Strona ma ładne zdjęcia, szczegółową specyfikację, zakładkę z recenzjami klientów, informację o dostawie w 24 godziny.
Dla człowieka to jest komplet informacji. Wchodzisz, patrzysz, rozumiesz, kupujesz. Agent czytający tę stronę widzi dokładnie ten sam tekst — ale co z niego wyciągnie, zależy od tego, jak ten tekst jest ułożony.
Scenariusz pierwszy: tekst jest ułożony jak narracja. Długi akapit opisujący produkt, gdzieś w środku zdanie „cena: 2490 zł”. Specyfikacja w formie listy punktowej. Opis dostawy w zupełnie innej sekcji, stylizowany na banner. Agent to wszystko czyta, ale musi wnioskować. „2490 zł” — to cena? Tak, bo pasuje kontekstowo. „Czarny i srebrny” — to warianty? Prawdopodobnie. „24 godziny” — to czas dostawy czy godziny otwarcia sklepu? Zależy, co jest dookoła.
Scenariusz drugi: strona ma te same informacje, ale dodatkowo ma JSON-LD w głowie strony, który mówi wprost: "@type": "Product", "name": "Nazwa modelu", "offers": { "@type": "Offer", "price": "2490.00", "priceCurrency": "PLN", "availability": "InStock" }, "color": ["czarny", "srebrny"], "shippingDetails": { "deliveryTime": { "businessDays": 1 } }.
Teraz agent nie musi nic wnioskować. Ma wprost powiedziane: „to jest produkt, nazywa się tak, kosztuje dwa tysiące czterysta dziewięćdziesiąt, waluta PLN, jest dostępny, kolory te i te, dostawa jeden dzień roboczy”. Zero zgadywania. Zero domysłów.
Różnica w tym, co agent wie o produkcie, jest w tych dwóch scenariuszach radykalna. W pierwszym — agent ma intuicję opartą na kontekście, która często jest trafna, ale czasem się myli. W drugim — agent ma fakty.
To jest sedno różnicy między tekstem a danymi. Tekst opowiada o rzeczy. Dane twierdzą, że rzecz jest taka a taka.Opowieść wymaga interpretacji. Twierdzenie nie wymaga — jest samoopisowe. Dla człowieka opowieść jest ciekawsza, bogatsza, bardziej perswazyjna. Dla agenta twierdzenie jest szybsze, pewniejsze, operacyjne.
Nie znaczy to, że tekst jest zbędny — przeciwnie, to w nim siedzi wartość narracyjna i perswazyjna, która decyduje, czy człowiek kliknie „dodaj do koszyka”. Znaczy to tylko, że agent patrzy na coś innego. I jeśli nie dasz agentowi twierdzeń, dostanie tylko opowieść — z której będzie zgadywał. A jeśli zgadnie źle, zarekomenduje konkurenta albo poda twojemu użytkownikowi nieaktualną cenę.
Schema.org jako wspólny język twierdzeń
Żeby dane były twierdzeniami, musi istnieć wspólny język, w którym da się je wypowiadać. Ten język to schema.org — projekt wspólny Google, Microsoftu, Yahoo i Yandeksu, zapoczątkowany w 2011 roku, dziś utrzymywany przez społeczność. Zawiera setki typów („co to jest” — produkt, artykuł, osoba, wydarzenie, przepis, kurs, usługa) i tysiące właściwości („jakie ma cechy” — nazwa, cena, data, autor, oceny).
JSON-LD jest formatem, w którym te twierdzenia się zapisuje. Wygląda jak zwykły JSON, z tą różnicą, że zaczyna się od pola "@context": "https://schema.org", które mówi „używam słownictwa schema.org”, i "@type", które mówi „to jest ten typ rzeczy”. Reszta to właściwości.
Przykład najbardziej podstawowy — firma:
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "WebFlux",
"url": "https://webflux.pl",
"logo": "https://webflux.pl/logo.png",
"sameAs": [
"https://twitter.com/webfluxpl",
"https://linkedin.com/company/webflux"
]
}
Pięć linii, które agentowi mówią pięć twierdzeń. To jest firma. Nazywa się tak. Ma taki adres. Ma takie logo. Jest tą samą organizacją, co te profile społecznościowe. Bez tego agent może coś z tego wywnioskować z treści strony, ale nie musi, i nie ma pewności. Z tym — ma.
Ta sama mechanika działa dla wszystkich typów, które na twojej stronie mają sens. Produkt, artykuł, przepis, wydarzenie, usługa, lokalna firma, kurs, oferta pracy, film, wystawa, FAQ. Za każdym razem ta sama zasada: wyrażasz w ustrukturyzowanej formie to, co na stronie i tak jest w formie tekstu. Nie dodajesz nowej treści. Duplikujesz ją w języku, który maszyna rozumie jednoznacznie.
Kluczowe słowo tutaj to „duplikujesz”. Bo to prowadzi do pierwszego wielkiego problemu danych strukturalnych — kiedy tekst i dane mówią co innego.
Kiedy tekst i dane się rozjeżdżają
Najczęstszy błąd we wdrożeniach JSON-LD na polskich stronach nie polega na tym, że JSON-LD nie ma. Polega na tym, że JSON-LD jest, ale nie zgadza się z tym, co widać na stronie.
Przykład pierwszy — produkt ma na stronie cenę 2490 zł, a w JSON-LD (bo ktoś wprowadził kiedyś w innej wtyczce albo zapomniał zaktualizować) ma 2290 zł. Człowiek widzi jedno, agent widzi drugie. Kiedy ktoś zapyta swojego agenta „ile kosztuje ten ekspres”, usłyszy 2290. Wejdzie na stronę i zobaczy 2490. Poczuje się oszukany. W coraz bardziej autonomicznych scenariuszach zakupowych — a takie rozwija dziś UCP i podobne protokoły — pojawia się też realne ryzyko rozbieżności między tym, co agent „wie” o cenie, a tym, co faktycznie pokazuje się w koszyku.
Przykład drugi — firma deklaruje w JSON-LD godziny otwarcia 9–17 w dni robocze, ale na stronie kontaktowej widać „pon-pt 8–18″. Agent, który planuje wizytę klienta o 7:30, powie „nie, zamknięte”, choć w rzeczywistości byłoby otwarte. Firma traci klienta.
Przykład trzeci — artykuł ma w JSON-LD "datePublished": "2023-04-15", bo tak został wrzucony pierwotnie, ale został istotnie zaktualizowany miesiąc temu i dziś ma nową treść, nowe liczby, nowe rekomendacje. Agent cytujący ten artykuł w odpowiedzi na zapytanie użytkownika poda go jako źródło sprzed dwóch lat — podczas gdy w rzeczywistości jest świeży. Czytelnik, widząc datę 2023, nie klika, bo wydaje mu się nieaktualny. Ruch przepada.
Agent zazwyczaj ufa danym strukturalnym bardziej niż widocznej treści. Logika jest prosta: dane strukturalne są jednoznaczne, widoczna treść wymaga interpretacji. Jeśli oba źródła są spójne, nie ma problemu. Jeśli się różnią, agent idzie za danymi. Oznacza to, że rozbieżność między tekstem a JSON-LD jest gorsza niż brak JSON-LD — bo agent dostaje pewną, ale błędną informację, zamiast niepewnej, ale trafnej.
Pisałem już o tym pośrednio w kontekście semantyki HTML, w tekście semantyczny HTML a SEO, AI i dostępność — i ta sama zasada dotyczy warstwy wyżej. Maszyny wierzą strukturze. Jeśli struktura kłamie, maszyna przekazuje kłamstwo dalej.
Puste pola, nadmierne typy i inne sposoby psucia dobrych intencji
Druga rodzina problemów z danymi strukturalnymi to sytuacje, w których JSON-LD formalnie jest, ale jego jakość psuje jego użyteczność. Trzy najczęstsze wzorce warto rozpoznać.
Puste albo ogólnikowe pola. JSON-LD z "description": "Zapraszamy do naszego sklepu" albo "name": "Produkt" to jest marnotrawstwo. Agent dostaje pole, sprawdza zawartość i widzi, że nic z niej nie wynika. To gorzej niż brak pola — bo agent może uznać, że to jest najbardziej opisowa informacja, jaką dysponujesz, i tak ją przekaże użytkownikowi. Jeśli pole ma istnieć, musi zawierać treść, która coś dla agenta znaczy.
Nadmierne typowanie. Pojawia się, kiedy ktoś w JSON-LD deklaruje produkt jako jednocześnie Product, Thing, Organization i LocalBusiness. Brzmi „więcej informacji to lepiej”, w praktyce to oznacza „nie wiemy, czym ta rzecz jest”. Dla agenta niejednoznaczność typu to sygnał, że danych nie warto ufać. Wybierz jeden typ, który najlepiej pasuje, i dopracuj jego właściwości, zamiast rozlewać się po wielu typach.
Ukryte pola bez odpowiednika na stronie. Wtyczki SEO czasem automatycznie generują JSON-LD z pól, które były wypełnione w panelu, ale nie są pokazane użytkownikowi na stronie. Na przykład oceny produktu, które są w bazie danych, ale na stronie produktu ich nie widać. To narusza zasady schema.org (które wymagają, żeby dane strukturalne odpowiadały widocznej treści) i — co ważniejsze — stwarza dokładnie tę rozbieżność tekst-dane, o której była mowa wyżej. Google publicznie karze takie praktyki usuwając rich snippets, a agent po prostu dostaje informację, której użytkownik nie może zweryfikować — co podważa zaufanie do całej strony.
Reguła, która z tego wynika, jest prosta: JSON-LD ma być lustrem widocznej treści, nie jej uzupełnieniem. Wszystko, co jest w danych strukturalnych, powinno być też widoczne na stronie. Wszystko, co jest na stronie i ma znaczenie, warto przenieść do danych strukturalnych. Rozbieżność w którąkolwiek stronę to problem.
Co agent robi z danymi, których nie dałeś
Ostatnia warstwa tego filaru jest ta, o której mówi się najmniej, a jest jedną z najważniejszych. Chodzi o to, co agent robi, kiedy na twojej stronie nie ma danych strukturalnych.
Stara odpowiedź brzmiała: agent wyciąga co może z tekstu, robi heurystyki, daje sobie radę. W erze ChatGPT z funkcją zakupów, w erze Copilot Checkout, w erze UCP, nowa odpowiedź brzmi trochę inaczej.
Agent, który dostaje dwa źródła informacji o podobnym produkcie — jedno z kompletnym, spójnym JSON-LD, drugie bez — ma dobre powody, żeby wybrać pierwsze. Nie dlatego, że pierwsze jest lepsze merytorycznie. Dlatego, że z pierwszego agent może działać od razu, a z drugiego musi najpierw zgadnąć. Działanie z pewnością jest szybsze i bezpieczniejsze niż działanie z domysłem. W świecie, który stopniowo przesuwa się w kierunku zakupów i decyzji podejmowanych przez agentów, strony bez danych strukturalnych mogą zacząć wypadać z procesów, w których użytkownik nie klika, tylko mówi „załatw to za mnie”. Nie dlatego, że ich treść jest gorsza — tylko dlatego, że agent ma do nich mniej zaufania.
To nie jest nowa mechanika. Google już od lat pokazuje rich snippets tylko tam, gdzie są dane strukturalne — i strony bez nich wyglądają na SERP-ie uboższo, co zwykle przekłada się na niższą klikalność. Ta sama dynamika może przenosić się teraz na warstwę agentów. Różnica jest taka, że agent nie tylko pokazuje wyniki — on w nich działa. Więc koszt braku danych strukturalnych w świecie agentów to nie tylko kwestia prezentacji, ale też tego, z czym agent w ogóle jest w stanie pracować, kiedy użytkownik nie klika, tylko mówi „załatw to za mnie”.
Dlatego dane strukturalne, które pięć lat temu były sposobem na ładniejsze wyniki w Google, dziś są warunkiem istnienia w procesie decyzyjnym agenta. To nie przesada — to po prostu przesunięcie funkcji tej warstwy ze „pomocy w prezentacji” do „kryterium kwalifikacji”.
Co dalej
Następny wpis w serii Agent-ready Divi pokaże praktyczną stronę tego filaru — jak dodawać JSON-LD w WordPressie i Divi 5, które wtyczki naprawdę warto, gdzie Woo załatwia sprawę automatycznie a gdzie trzeba dopisać ręcznie, jak walidować. Będzie też osobny wpis o typach schema.org, które mają największe znaczenie dla polskich stron — bo nie wszystko jest Product, i nie wszystko jest Article.
Zasada, która wraca we wszystkich filarach agent-readiness, wraca też tutaj. Agent nie wymyślił nowej dyscypliny. Dane strukturalne były ważne dla SEO od dekady. Różnica polega na tym, że przestały być dodatkiem, a zaczęły być fundamentem. Różnica polega też na tym, że rozbieżność między tym, co agent widzi, a tym, co na stronie widzi człowiek, jest dziś bardziej kosztowna niż kiedykolwiek — bo agent nie pyta użytkownika, czy informacja się zgadza. Po prostu jej używa.
To jest drugi z sześciu filarów. W następnych wpisach schodzimy do warstwy sygnałów dla agentów — llms.txt, robots.txt dla AI-botów, .well-known, pierwsze standardy discovery. Bo dane strukturalne mówią agentowi czym jest treść. Sygnały mówią mu gdzie tej treści szukać i co wolno z nią robić. I to jest już zupełnie nowa warstwa, której pięć lat temu jeszcze nie było.