Jak pozycjonować sklep pod AI — co działa, co jest mitem i jak to sprawdzić

Jak my to robimy — sklep gotowy na agentów AI w headless storefront

Wszystko, o czym piszemy wyżej, przerobiliśmy w praktyce przy migracji yrke.pl na nasz headless storefront. Punkty 1–4 dostaliśmy „w pakiecie" z architektury: strony sklepu są generowane jako gotowy, szybki HTML — bot AI widzi pełną treść kategorii i produktów bez wykonywania JavaScriptu, dane strukturalne i sitemap są częścią każdej publikacji, a robots.txt jest w całości pod naszą kontrolą i wprost wskazuje botom AI, gdzie znajdą zasoby sklepu.

Najlepiej widać to na opiniach o produktach. Zebrane oceny i recenzje renderujemy po stronie serwera — są częścią gotowego HTML karty produktu, więc crawler AI dostaje je w tym samym pobraniu co opis i cenę. W typowym sklepie opinie wstrzykuje dopiero widget zewnętrznego dostawcy, już po stronie przeglądarki: dla klienta wygląda identycznie, ale crawler, który JavaScriptu najczęściej nie wykonuje, w ogóle ich nie widzi. Co model zrobi z nimi dalej, to osobna sprawa — do maszyn najrzetelniej trafia ustrukturyzowana ocena (AggregateRating w schema.org, a u nas dodatkowo feed Product Ratings do Google), a treść samych recenzji jest dodatkowym kontekstem.

Nie zakładamy z góry, jak dokładnie który model zachowa się przy konkretnej stronie — tego nikt do końca nie wie i bywa różnie. Dlatego pilnujemy prostej zasady na całym sklepie: wartościowa treść nie może pojawiać się dopiero po uruchomieniu JavaScriptu. Co jest w gotowym HTML, bot zobaczy na pewno; co doczytuje się dopiero w przeglądarce — to już loteria.

Do tego dochodzi warstwa, której gotowe szablony sklepowe jeszcze nie mają — przygotowanie pod agentów. Przy każdej publikacji sklep generuje równolegle swoją „wersję dla maszyn": każda strona ma bliźniaczą wersję tekstową, którą agent dostaje automatycznie, gdy o nią poprosi; pełny katalog produktów i drzewo kategorii są dostępne jako pliki do pobrania, zawsze aktualne; a opublikowana „instrukcja obsługi sklepu" mówi agentowi wprost, co i jak może tu zrobić. Agent działający w przeglądarce klienta dostaje dodatkowo gotowe narzędzia do przeszukiwania oferty i poruszania się po sklepie.

Najważniejsza decyzja projektowa jest jednak inna: agenci nie mają dostępu do żadnych systemów sklepu. Nie logują się, nie autoryzują, nie dotykają API — czytają wyłącznie statyczne pliki opublikowane razem ze sklepem, tak jak każdy inny gość czyta strony. Sklep jest dla nich w pełni czytelny, a jednocześnie nie ma niczego, co mogliby zepsuć lub przeciążyć. Otwartość na agentów nie musi — i nie powinna — oznaczać otwartych drzwi do zaplecza.

Efekt w liczbach skanera Cloudflare: 21/100 → 64/100 i poziom „Agent-Integrated" — szczegóły i zrzuty ekranu w naszym case study migracji yrke.pl. Świadomie nie wdrażamy reszty punktów skanera: to standardy na etapie szkiców specyfikacji albo eksperymentalne protokoły płatności agentowych, bez zastosowania w polskim e-commerce. Pompowanie wyniku dla wyniku zostawiamy innym.

I dokładnie dlatego, że ten obszar zmienia się tak szybko, headless storefront traktujemy jak żywy produkt: gdy nowy standard agentowy się stabilizuje, wdrażamy go po naszej stronie — a sklepy działające na naszym headless dostają go przy kolejnej publikacji, bez żadnej pracy po swojej stronie. Tak jak nie musisz sam śledzić zmian w przeglądarkach, tak nie musisz śledzić standardów agentowych — to nasza działka.