Kiedy rozmawiamy z klientami FunkyMEDIA o AI, bardzo szybko dochodzimy do jednego wniosku: sztuczna inteligencja nie „czyta” internetu tak jak człowiek. Widzi strony jako zbiory bytów, relacji i atrybutów – produktów, firm, artykułów, lokalizacji, opinii. A jednym z najskuteczniejszych sposobów, żeby pomóc jej to wszystko uporządkować, są właśnie dane strukturalne (schema.org). Z perspektywy agencji SEO FunkyMEDIA schema to nie tylko sposób na dodatkowe gwiazdki w wynikach wyszukiwarki, ale przede wszystkim język, którym mówimy do Google i systemów AI: „to jest produkt”, „to jest recenzja”, „to jest FAQ”, „to jest poradnik krok po kroku”. W tym artykule pokazuję, jak FunkyMEDIA podchodzi do danych strukturalnych w kontekście AI, z konkretnymi liczbami i case studies z naszych projektów.
Dlaczego dane strukturalne są tak ważne w erze AI?
W klasycznym SEO dane strukturalne kojarzą się głównie z rich snippets: gwiazdki ocen, cena produktu, breadcrumbs, FAQ pod wynikiem. To wciąż bardzo ważne – bo wyższy CTR z wyników organicznych to często szybszy wzrost ruchu niż sama poprawa pozycji. Z perspektywy FunkyMEDIA widać jednak drugą, równie istotną warstwę: dane strukturalne pomagają wyszukiwarkom i modelom AI precyzyjniej zrozumieć, co jest czym na Twojej stronie. Jeżeli masz artykuł, który jest poradnikiem krok po kroku, i oznaczysz go jako HowTo, AI dostaje jasny sygnał, że tam znajduje się procedura. Jeśli strona jest produktem z ceną, stanem magazynowym, opiniami klientów – schema Product + Offer + AggregateRating pozwala wyszukiwarce „zobaczyć” to w sposób uporządkowany, a nie tylko jako przypadkowe liczby i teksty.
W FunkyMEDIA widzimy prostą zależność: tam, gdzie strona jest dobrze oznaczona danymi strukturalnymi, łatwiej o pojawienie się w rozbudowanych wynikach (rich results), AI Overview, karuzelach produktowych czy w odpowiedziach chatów AI. W jednym z projektów e-commerce po wdrożeniu kompleksowego schema dla produktów (o czym szerzej za chwilę) CTR na stronach produktowych wzrósł średnio o 40–60%, a liczba zapytań, z których przychodził ruch long-tail (pytania złożone, porównania, „jaki produkt do…”) zwiększyła się o ponad 30% w pół roku. To nie znaczy, że schema „magicznie” poprawiła rankingi, ale sprawiła, że algorytmy lepiej rozumiały strukturę oferty i chętniej prezentowały ją w formach, które użytkownicy chcą klikać – i które AI łatwiej może cytować lub wykorzystywać jako źródło.
Jak FunkyMEDIA zaczyna pracę z danymi strukturalnymi – audyt i inwentaryzacja
Pierwszy krok w każdym projekcie FunkyMEDIA związanym z danymi strukturalnymi jest audyt tego, co już istnieje. Wbrew pozorom wiele serwisów ma jakieś schema „z pudełka” – z motywu, wtyczki albo systemu sklepowego – ale bywa ono niekompletne, powielone lub wręcz sprzeczne z rzeczywistością. Dlatego zaczynamy od sprawdzenia, jakie typy treści ma klient (produkty, artykuły, usługi, FAQ, lokalizacje) oraz jakie typy schema są już używane (Article, Product, BreadcrumbList, Organization, FAQPage itd.). Robimy to zarówno ręcznie (przeglądając kod i testując wybrane URL-e w narzędziach testowych), jak i automatycznie, wykorzystując crawlery i skrypty, które wyciągają z serwisu znaczniki strukturalne.
Następnie zestawiamy to ze stanem faktycznym. Jeżeli sklep ma 3 000 produktów, a w sitemapie i w schemie „Product” pojawia się tylko 300, to znaczy, że brakuje oznaczenia na 90% oferty. Jeśli firma ma 5 lokalizacji stacjonarnych, ale nigdzie nie stosuje LocalBusiness ani danych o adresie, godzinach otwarcia czy numerach telefonów, to widzimy kolejną lukę. W jednym z naszych projektów B2B wyszło, że z 80 kluczowych artykułów eksperckich tylko 10 miało poprawnie wdrożone Article, a w dodatku część z nich była mylnie oznaczona jako NewsArticle, mimo że nie były to wiadomości, lecz wiecznie zielone poradniki. W efekcie modele AI miały utrudnione zadanie: nie było jasnego sygnału, które treści są eksperckie, a które tylko „aktualnościami”.
Mapowanie typów treści na typy schema – fundament strategii FunkyMEDIA
Kiedy FunkyMEDIA wie już, jakie treści posiada klient, przechodzi do mapowania typów stron na odpowiednie typy schema.org. To kluczowy moment, bo tutaj decydujemy, jakiej „klasy” będą nadane poszczególnym elementom serwisu w oczach wyszukiwarki i AI. W przypadku klasycznego e-commerce zazwyczaj kończy się na kilku podstawowych typach: Product, Offer, AggregateRating, BreadcrumbList, Organization, czasem FAQPage. W serwisie usługowym dochodzi LocalBusiness, Service, FAQPage, Article. W rozbudowanym portalu eksperckim: Article / BlogPosting, HowTo, FAQPage, BreadcrumbList, Organization, czasem Person (dla autorów).
Na tym etapie FunkyMEDIA tworzy tabelę odpowiadającą na pytanie: „Jaki typ strony = jaki typ schema + jakie pola wypełniamy?”. Przykład dla sklepu:
- strona produktu → Product (nazwa, opis, marka, SKU, kategoria) + Offer (cena, waluta, dostępność, warunki dostawy) + AggregateRating (średnia ocena, liczba opinii)
- strona kategorii → CollectionPage + BreadcrumbList + ewentualnie FAQPage (jeśli mamy sekcję FAQ)
- strona główna → WebSite + Organization
- strona „O nas” → rozwinięte Organization (logo, adres, social media, dane kontaktowe)
- artykuł blogowy → Article / BlogPosting (tytuł, opis, data publikacji, autor, obrazek) + FAQPage (jeśli są pytania i odpowiedzi).
Taka mapa pozwala FunkyMEDIA zapanować nad spójnością: wiemy, że np. każdy produkt w całym sklepie będzie miał określone pola, a nie tylko część oferty. Z perspektywy AI oznacza to, że dostaje ono uporządkowany, powtarzalny model danych – łatwiej więc analizować, uogólniać i wykorzystywać te treści.
Projektowanie JSON-LD – jak FunkyMEDIA buduje dane strukturalne w praktyce
Jako agencja FunkyMEDIA stawia na format JSON-LD umieszczany w <script type=”application/ld+json”> w kodzie strony. Jest to rozwiązanie rekomendowane przez Google, a przy tym najmniej inwazyjne – nie trzeba opakowywać każdego elementu HTML w mikroformaty, wystarczy wygenerować odpowiedni blok JSON-a z danymi. Na bazie tabeli mapującej tworzymy szablony schema dla poszczególnych typów stron. W przypadku produktów może to wyglądać tak:
- name → nazwa produktu z bazy,
- image → adres głównego zdjęcia,
- description → opis produktu,
- sku → symbol magazynowy,
- brand.name → marka,
- offers.price → cena bieżąca,
- offers.priceCurrency → waluta (PLN, EUR itd.),
- offers.availability → stan magazynowy (InStock, OutOfStock),
- aggregateRating.ratingValue → średnia ocena,
- aggregateRating.reviewCount → liczba opinii.
FunkyMEDIA bardzo pilnuje, żeby wszystkie te dane były spójne z tym, co widzi użytkownik. To nie jest miejsce na „podkręcanie” rzeczywistości – jeśli w schemie wpiszemy inną cenę niż na stronie, albo opinie, których naprawdę nie ma, ryzykujemy utratę zaufania algorytmów. Stąd zawsze dokładne testy: sprawdzamy, czy JSON-LD odzwierciedla aktualne dane, jak zachowuje się przy promocjach, wyprzedażach, braku dostępności produktu itd. W jednym ze sklepów obsługiwanych przez FunkyMEDIA, w którym ceny zmieniały się dynamicznie, musieliśmy zaprojektować aktualizację schema w czasie quasi-rzeczywistym – wcześniej zdarzało się, że schema pokazywało już nieaktualną cenę promocyjną jeszcze przez kilka godzin po zakończeniu kampanii, co powodowało ostrzeżenia w narzędziach Google.
Case study #1: Sklep internetowy – Product schema, AI i +52% CTR
Jeden z projektów FunkyMEDIA dotyczył średniej wielkości sklepu internetowego z branży wyposażenia domu – około 4 000 produktów, ruch organiczny na poziomie 35 000 sesji miesięcznie, sensowne pozycje na wiele fraz, ale bardzo przeciętny CTR (często 2–3% tam, gdzie konkurencja potrafiła mieć 4–6%). Sklep miał szczątkowe dane strukturalne – pojedyncze produkty oznaczone mikrodanymi, brak Offer, brak AggregateRating mimo aktywnego systemu ocen, brak uporządkowanego Organization i BreadcrumbList.
FunkyMEDIA przeprowadziło pełen audyt schema i zaprojektowało nową implementację w JSON-LD. W pierwszym etapie objęliśmy nią 800 najważniejszych produktów – te, które generowały ok. 60% przychodu. Po wdrożeniu Product+ Offer + AggregateRating oraz poprawnych breadcrumbs, w ciągu dwóch miesięcy Google zaczęło konsekwentnie wyświetlać rozbudowane wyniki z gwiazdkami, cenami i dostępnością dla większości tych produktów. W porównaniu 3-miesięcznych okresów przed i po wdrożeniu FunkyMEDIA odnotowało:
- średni CTR na stronach produktowych w grupie 800 produktów: wzrost z 3,1% do 4,7%, czyli o ok. 52%,
- liczba kliknięć z organicu na te produkty: wzrost z ok. 9 500 do 14 800 miesięcznie,
- ruch z zapytań long-tail (trzy i więcej słów, często w formie pytań): wzrost o ok. 34%.
Co ciekawe, widzieliśmy też zmianę w zachowaniu użytkowników: osoby wchodzące z wyników z rozbudowanym snippetem rzadziej natychmiast wracały do wyników. Prawdopodobnie dlatego, że snippet z ceną, dostępnością i opiniami lepiej „kwalifikował” użytkownika – klikali głównie ci, którym oferta faktycznie odpowiadała. Z punktu widzenia AI oznaczało to, że produkty tego sklepu stały się atrakcyjniejszym źródłem do cytowania w odpowiedziach dotyczących konkretnych modeli czy typów produktów, bo schemat danych był kompletny, a zachowanie użytkowników wskazywało wysoką trafność.
Case study #2: Portal poradnikowy – Article, HowTo, FAQPage i lepsza widoczność w odpowiedziach AI
Drugi projekt FunkyMEDIA dotyczył portalu poradnikowego w branży DIY i remontów. Serwis miał około 600 artykułów, ruch organiczny na poziomie 25 000 użytkowników miesięcznie i bardzo dużo treści typu „jak coś zrobić krok po kroku”. Problem? Brak spójnych danych strukturalnych – część artykułów miała jakieś Article z motywu, część była zupełnie „goła”, nigdzie nie wykorzystywano typów HowTo ani FAQPage, mimo że w tekście często pojawiały się sekcje pytaniowe i listy kroków.
FunkyMEDIA przeprowadziło segmentację treści: wytypowaliśmy 120 artykułów eksperckich, z których 40 miało wyraźny charakter „poradnika krok po kroku”. Dla wszystkich 120 wdrożyliśmy poprawne Article / BlogPosting (z tytułem, datą, autorem, obrazkiem, opisem), a dla 40 typowo instruktażowych również HowTo opisujące kolejne etapy, narzędzia, przybliżony czas realizacji itp. Dodatkowo na 50 najpopularniejszych artykułach dobudowaliśmy sekcje FAQ i opakowaliśmy je w FAQPage w JSON-LD.
Efekt po ok. 6 miesiącach od pełnego wdrożenia wyglądał następująco:
- ruch organiczny na całym serwisie: wzrost z 25 000 do ok. 34 000 użytkowników miesięcznie (+36%),
- liczba fraz w TOP10 związanych z instrukcjami „jak zrobić” (z dodatkiem słów typu „krok po kroku”, „samodzielnie”): wzrost z ok. 280 do 610,
- CTR na grupie artykułów z HowTo: wzrost średnio z 4,2% do 6,0%,
- udział wejść na długie zapytania pytaniowe (3+ słowa w formie pytania): wzrost o ok. 40%.
Równolegle FunkyMEDIA testowało, jak odpowiedzi chatów AI (w tym eksperymentalnych funkcji powiązanych z wyszukiwarką) reagują na takie treści. Przy pytaniach typu „jak samodzielnie położyć panele winylowe” czy „jak pomalować ścianę bez smug krok po kroku” widzieliśmy, że generowane odpowiedzi często kopiują strukturę kroków bardzo podobną do tej, którą zaprojektowaliśmy w HowTo, a niektóre fragmenty brzmiały jak parafrazy naszych oryginalnych akapitów. To dla FunkyMEDIA mocny sygnał, że dobrze zaprojektowane dane strukturalne nie tylko pomagają w SEO, ale realnie wpływają na to, które treści stają się „wzorcami” dla modeli językowych.
Dane strukturalne a E-E-A-T – jak FunkyMEDIA wzmacnia sygnały wiarygodności
W erze AI liczy się nie tylko to, co mówisz, ale też kim jesteś jako źródło. Google i modele AI zwracają coraz większą uwagę na sygnały E-E-A-T (Experience, Expertise, Authoritativeness, Trustworthiness). Dane strukturalne są jednym z narzędzi, które pomagają te sygnały uporządkować i podkreślić. W FunkyMEDIA dbamy o to, aby:
- firma była poprawnie opisana jako Organization lub LocalBusiness – z nazwą, logo, adresem, numerem telefonu, profilem w social media,
- artykuły eksperckie miały oznaczonych autorów (author jako Person z krótkim bio),
- strona miała jasne dane kontaktowe i elementy zaufania (np. odnośniki do polityki prywatności, regulaminu),
- tam, gdzie jest to zasadne, pojawiały się oznaczenia specjalistów (np. lekarzy, prawników) w powiązaniu z treściami, które tworzą lub weryfikują.
W jednym z projektów medycznych, w którym FunkyMEDIA wdrożyło rozbudowane Article z polami author, reviewedBy (lekarz weryfikujący treść) oraz MedicalWebPage, widzieliśmy po kilku miesiącach nie tylko wzrost widoczności na frazy informacyjne, ale też wyraźne „uspokojenie” w zakresie fluktuacji podczas aktualizacji algorytmów związanych z YMYL (Your Money Your Life). Z perspektywy AI takie oznaczenia mówią wprost: „to nie jest anonimowy blog, to treści przygotowane i weryfikowane przez konkretnych specjalistów”.
Typowe problemy ze schema, które FunkyMEDIA musi najpierw naprawić
Zanim dane strukturalne zaczną pomagać, często trzeba je… odgruzować. FunkyMEDIA regularnie trafia na kilka powtarzających się błędów:
- Sprzeczne schemy na jednej stronie – np. wtyczka dodaje Product z podstawowymi polami, motyw dodaje drugi Product o innej treści, a do tego ręcznie ktoś kiedyś wstawił jeszcze Article. AI dostaje wtedy sygnał: jedna strona jest produktem, artykułem i czymś jeszcze. W FunkyMEDIA porządkujemy to tak, aby na każdej stronie był logiczny zestaw typów schema, a nie chaos.
- Nieaktualne dane w schemie – ceny, dostępność, oceny, daty. Jeśli na stronie jest co innego niż w JSON-LD, może to zostać potraktowane jako wprowadzanie w błąd. W jednym ze sklepów FunkyMEDIA musiało zintegrować schema z systemem zarządzania cenami, bo wcześniej aktualizacje szły tylko w warstwie frontu, nie w danych strukturalnych.
- Nadmierne upiększanie rzeczywistości – wpisywanie ocen 5.0 przy braku realnych opinii, dopisywanie reviews, które nie istnieją. FunkyMEDIA tego nie robi i zawsze odradza takie praktyki. Krótkoterminowo może to wydawać się kuszące, ale długoterminowo psuje reputację domeny w oczach algorytmów – a to ostatnia rzecz, jakiej chcesz, jeśli liczysz na to, że AI będzie Cię cytować jako wiarygodne źródło.
- Wpychanie FAQPage tam, gdzie nie ma prawdziwego FAQ – Google wprost sugeruje, żeby nie stosować schema FAQ tam, gdzie treści nie są realnymi pytaniami i odpowiedziami. FunkyMEDIA zawsze najpierw projektuje prawdziwe, jakościowe FAQ (patrz nasz poprzedni artykuł), a dopiero potem opakowuje je w schema, nigdy odwrotnie.
Jak wygląda proces wdrożenia schema w FunkyMEDIA krok po kroku
W praktyce projekt danych strukturalnych z FunkyMEDIA wygląda zwykle tak:
- Audyt – sprawdzamy, co już jest, jakie są błędy, czego brakuje.
- Mapa typów treści i typów schema – ustalamy, które strony mają być czym oznaczone, i jakie pola będą wypełniane.
- Projekt JSON-LD – tworzymy szablony danych strukturalnych dla produktów, artykułów, usług, FAQ itd.
- Wdrożenie techniczne – we współpracy z deweloperem klienta albo przez nasz zespół (w zależności od technologii) wprowadzamy schema do CMS-a / szablonów.
- Testy i walidacja – używamy narzędzi typu Rich Results Test, walidatory schema.org, crawlery, żeby wychwycić błędy i ostrzeżenia.
- Monitoring – obserwujemy w Search Console raporty „Udoskonalenia” (Produkty, FAQ, HowTo, Breadcrumbs), sprawdzamy, ile adresów kwalifikuje się do rich results, jak zmienia się CTR i ruch.
- Rozwój i aktualizacje – wraz z rozwojem serwisu i zmianami w wyszukiwarkach FunkyMEDIA aktualizuje schemy, dodaje nowe typy (np. gdy wchodzi nowy format treści) i dba o spójność z realnymi danymi.
Dane strukturalne w rękach FunkyMEDIA jako most między Twoją stroną a AI
Dane strukturalne (schema) to nie jest „techniczny dodatek” tylko po to, żeby mieć ładną gwiazdkę w wynikach. Z perspektywy FunkyMEDIA to język, w którym komunikujesz się z wyszukiwarkami i modelami AI. Dzięki niemu Google i chaty AI lepiej rozumieją, co jest produktem, co artykułem, co poradnikiem krok po kroku, co jest pytaniem i odpowiedzią, a co danymi o Twojej firmie i ekspertach. Kiedy schema jest zaprojektowane mądrze, spójnie i zgodnie z rzeczywistością, widzimy wzrosty CTR, ruchu, widoczności na long-tail, lepsze rich results i większe zaufanie algorytmów. W połączeniu z dobrze zaprojektowanym contentem i topical authority staje się to solidnym fundamentem do tego, by Twoja strona była częściej wykorzystywana jako źródło w odpowiedziach AI.
