Salon kosmetyczny kontra Claude in Chrome — eksperyment, który nie wyszedł tak jak zakładaliśmy. I dlatego jest ciekawy.

przez Łukasz | maj 15, 2026

Mieliśmy prosty plan: dwie strony, identyczne wizualnie, jedna agent-ready, druga nie. Agent wchodzi na obie, na dobrej pobiera 10 plików bez problemu, na złej się gubi. Nagrywamy, pokazujemy klientom. Koniec teorii, zaczyna się dowód rzeczowy.

Nie wyszło. I to jest najciekawsza część tej historii.

Skąd pomysł

Problem z agent-readiness jest prosty: wszyscy kiwają głową, nikt nie rozumie. Mówisz „semantyczny HTML”, „czytelność dla agentów”, „struktura treści” — i widzisz w oczach rozmówcy uprzejme niezrozumienie. Słowa trafiają w próżnię, bo nie ma obrazu do którego można by je przyczepić.

Rozwiązanie znalazło się samo, gdy zacząłem pokazywać Claude in Chrome na żywo. Agent otwiera stronę, dostaje zadanie, działa — albo nie działa. Szczęki opadają. Żadnych slajdów, żadnych tłumaczeń. Jeden screen.

Potrzebowałem więc scenariusza do nagrania. Dwóch stron, które wyglądają tak samo, ale agent obsługuje jedną płynnie, a na drugiej się potyka.

Setup

Branża: salon kosmetyczny. Powszechna, prosta, zero branżowego żargonu.

Zadanie dla agenta: „Pobierz wszystkie instrukcje pielęgnacji po zabiegach.”

Liczba plików: 10 PDFów — po jednym dla każdego zabiegu (laminacja brwi, henna, przedłużanie rzęs, manicure hybrydowy, pedicure, depilacja, peeling, mezoterapia, lifting HIFU/RF, stylizacja brwi).

Dlaczego 10, nie jeden? Bo jeden plik to nie jest zadanie dla agenta. Dziesięć to już coś, co człowiek robi z irytacją przez kilka minut. Agent — jeśli strona mu na to pozwoli — powinien zrobić to w kilka sekund.

Strona dobra: semantyczny HTML, opisowe <a href="instrukcje/laminacja-brwi.pdf" download aria-label="Pobierz instrukcję pielęgnacji po laminacji brwi">, pliki z nazwami mówiącymi co zawierają.

Strona zła: ta sama wizualnie. Ale lista pobierania renderowana przez JavaScript (w surowym HTML tylko „Ładowanie…”), przyciski jako <button onclick="pobierzPlik(3)"> zamiast linków, pliki nazwane dokument_01.pdf przez dokument_10.pdf.

Co poszło nie tak — runda pierwsza

Pierwsza próba zwróciła 503 na obu stronach.

Przyczyna techniczna: WordPress na hostingu blokuje katalogi bez index.php. PDFy były w podkatalogach, serwer ich nie serwował.

Rozwiązanie: wbudowałem wszystkie PDFy jako base64 bezpośrednio w HTML. Dwa pliki standalone po ~300KB każdy, zero zewnętrznych zależności.

Co poszło nie tak — runda druga

Strony działają. Agent wchodzi na obie. Pobiera wszystkie pliki. Na obu. W tym samym czasie.

Pułapki z JS renderingiem i onclick nie zatrzymały Claude in Chrome.

Agent widział stronę już po wykonaniu JavaScriptu — lista była wyrenderowana. Przyciski onclick klikał bez problemu. Nazwy plików dokument_01.pdf nie były przeszkodą, bo agent widział etykiety na kartach („Laminacja brwi”, „Henna brwi” itd.) i wiedział, który przycisk jest który.

Innymi słowy: strona zła była za dobra.

Runda trzecia — iframe

Następna hipoteza: iframe jako pułapka. Agent widzi sekcję z pobieraniem, ale jej zawartość siedzi w <iframe srcdoc="...">— osobnym kontekście przeglądarki, do którego agent nie powinien mieć dostępu przez DOM strony głównej.

Wynik: agent poradził sobie i z tym.

Claude in Chrome wchodzi do iframe. Widzi zawartość. Klika przyciski.

 

 

Co z tego wynika

Kilka rzeczy, które warto zapamiętać.

Po pierwsze: Claude in Chrome jest lepszy niż zakładałem. JS rendering, onclick, bezsensowne nazwy plików, iframe — żadna z tych przeszkód go nie zatrzymała, jeśli etykiety tekstowe na stronie były czytelne. Agent nie czyta kodu — czyta wyrenderowaną stronę tak jak ją widzi człowiek, i działa na tym co widzi.

Po drugie: pułapki które działają na agentów to nie te same co pułapki które działają na crawlery. Googlebot nie wykonuje JavaScriptu (albo robi to z opóźnieniem). Claude in Chrome wykonuje JavaScript, widzi efekt, działa na efekcie. To inna klasa narzędzia.

Po trzecie: prawdziwa bariera dla agenta to brak kontekstu, nie brak technicznego dostępu. Gdyby karty w wersji złej nie miały czytelnych tytułów zabiegów — tylko „Produkt 1”, „Produkt 2” — agent nie wiedziałby co pobiera. Gdyby sama strona nie informowała że w ogóle są jakieś instrukcje do pobrania — agent by ich nie szukał. Semantyka to nie tylko poprawny HTML. To czy strona w ogóle komunikuje co na niej jest i po co.

Po czwarte: dobry eksperyment to też taki który nie potwierdza hipotezy. Założyłem, że iframe i onclick wystarczą. Nie wystarczyły. To jest użyteczna informacja — i uczciwa. Nie znam nikogo kto w Polsce pokazał to na żywo i opowiedział co naprawdę się stało.

Co by rzeczywiście zatrzymało agenta

Na podstawie eksperymentu i dalszych testów — trzy rzeczy, które faktycznie sprawiają problem:

Brak kontekstu dla akcji. Strona nie mówi że ma pliki do pobrania. Linki są, ale schowane za nawigacją bez opisu, za zakładkami bez etykiet, za modalnymi oknami otwieranymi jednym przyciskiem „więcej”.

Wymagana interakcja z formularzem przed dostępem do treści. „Podaj swoje imię i datę wizyty, żebyśmy mogli wysłać Ci właściwą instrukcję” — agent musi zrozumieć stan formularza, wypełnić go, poczekać na odpowiedź. To już inna skala trudności niż kliknięcie przycisku.

Treść wyłącznie w obrazkach lub PDF bez warstwy tekstowej. Agent widzi obrazek, nie widzi tekstu. Skany dokumentów bez OCR są dla niego czarne skrzynki. Chociaż zaskakująco i z tym sobie potrafi poradzić wykonując zrzuty ekranu strony na której operuje.

Live demo

Obie strony są dostępne do testowania na żywo. Możesz wejść, odpalić Claude in Chrome i sprawdzić sam.

Strona agent-ready: https://studio.ifox.pl/demo/dobra.html
Strona bez agent-readiness: https://studio.ifox.pl/demo/zla.html

Jeden wniosek na koniec

Agent-readiness nie polega na tym żeby zablokować złym agentom dostęp do danych. Polega na tym żeby dobry agent — działający w imieniu Twojego klienta — mógł tę stronę obsłużyć sprawnie i bezbłędnie. Oczywiście tylko tam gdzie chcemy, żeby agent mógł działać.

Jeśli Twoja strona jest zbudowana tak, że agent się na niej gubi, tracisz klientów których agent obsługuje. Nie widać tego w Google Analytics. Widać to dopiero wtedy, gdy ktoś pokazuje Ci na żywo jak agent radzi sobie — albo nie radzi — z tym co zbudowałeś.

To właśnie pokazuje ten eksperyment. Nawet jeśli nie wyszedł aż tak spektakularnie jak zakładałem.