TL;DR: Agenci AI patrzą na Twoją stronę przez trzy soczewki (zrzuty ekranu, surowy DOM oraz drzewo dostępności), a większość witryn jest wobec wszystkich trzech nieumyślnie wroga. Poprawki pokrywają się z pracami nad dostępnością i Core Web Vitals, które i tak powinieneś już wykonywać. Poniżej znajdziesz listę priorytetów, 5-minutowy audyt i pętlę pomiarową, które możesz uruchomić od razu.
Kilka tygodni temu budowałem nasz „agent-ready” tool. Chodziło o to, by dać agentowi opartemu na Playwright prawdziwe strony klientów i obserwować, jak próbuje z nich korzystać. Wskazałem więc na naszą własną stronę główną, którą publikowałem już setki razy, i poprosiłem o znalezienie cennika.
Kliknął niewłaściwe CTA. Potem spróbował kliknąć przycisk, który wcale nie był przyciskiem (był to wystylizowany <div>, sklecony na szybko). W końcu się poddał i zapytał mnie, gdzie jest cennik.
Wiedziałem przecież, że nasza strona ma stany hover, które odsłaniają drugą nawigację. Człowiek rusza kursorem, menu się pojawia – problem rozwiązany. Agent pracował jednak na pojedynczym zrzucie ekranu stanu spoczynkowego. Nie miał kursora do poruszenia. Nawigacja widoczna wyłącznie po najechaniu dla niego po prostu nie istniała.
To był dzień, w którym przestałem myśleć o agentach AI jak o „mądrzejszych crawlerach”, a zacząłem postrzegać je jako nowy typ użytkownika z nietypowymi ograniczeniami. (Na marginesie: przez miesiące zakładałem, że działają jak Googlebot z dodatkowymi krokami. Przez pierwsze pół roku zeszłego roku myliłem się co do tego.) Poniżej znajdziesz to, czego nauczyłem się od tamtej pory, głównie psując rzeczy i obserwując reakcje agentów.
Agent AI, który ląduje na Twojej stronie głównej, nie „crawluje” pod indeks wyszukiwarki. Próbuje wykonać zadanie powierzone mu przez człowieka. Zarezerwuj lot. Porównaj plany. Dodaj produkt do koszyka. Ma minuty, nie godziny. A każde błędne kliknięcie kosztuje użytkownika pieniądze w tokenach inferencyjnych.
To zmienia problem projektowy. Bot wyszukiwarki może ponieść porażkę po cichu i nigdy się o tym nie dowiesz. Agent zawodzi na głos, przed płacącym użytkownikiem, i następnym razem ten użytkownik poprosi agenta, by Twoją stronę ominął. Silniki wyszukiwania oparte na AI zaczynają zachowywać się podobnie. Jeśli ich crawler nie potrafi z Twojej strony wyciągnąć pewnej odpowiedzi, odpowiedź trafi do tego, kogo można czysto zinterpretować. Kliknięcia, które dawniej zdobywałeś z SERP-a, zastępują cytaty z podsumowania AI – a o cytaty walczy się czytelnością, nie budżetem reklamowym.
Jeśli interesuje Cię dłuższe omówienie AI jako kanału odkrywania treści, filar ask engine optimization opisuje stronę wyszukiwawczą wprost. Ten artykuł dotyczy drugiej połowy: co dzieje się, gdy agent faktycznie próbuje używać Twojej strony.
Tego fragmentu chciałbym, aby ktoś mi rok temu wytłumaczył. Agenci nie widzą stron na jeden sposób. Są trzy, a główni dostawcy łączą je w różnych proporcjach.
„Agenci mogą przeglądać Twoją witrynę na 3 główne sposoby: zrzuty ekranu, surowy HTML i drzewo dostępności. Drzewo dostępności to natywny interfejs API przeglądarki, który destyluje DOM do tego, co najważniejsze: ról, nazw i stanów elementów interaktywnych. Dla agenta AI pełni funkcję mapy wysokiej wierności, ignorującej wizualny ‘szum’ CSS i skupiającej się na czystej użyteczności.”
— Kasper Kulikowski & Omkar More, web.dev: Build agent-friendly websites
Tak to wygląda u poszczególnych dostawców (stan na początek 2026 r.). Computer-use od Anthropica to wyłącznie zrzuty ekranu. Claude widzi obraz 1024×768, rozumuje w przestrzeni pikseli i mówi kontrolerowi, gdzie przesunąć mysz. Po stronie Anthropica nie ma wejścia DOM. Operator OpenAI (CUA) łączy zrzuty z danymi DOM i drzewa dostępności, choć we własnych materiałach OpenAI podkreśla pętlę screenshotów, a warstwowanie DOM wychodzi głównie z inżynierii odwrotnej. Projekt Mariner Google’a czyta piksele i podkład DOM. Frameworki oparte na Playwright, jak browser-use, preferują najpierw drzewo dostępności, a gdy to zawiedzie, wracają do zrzutów ekranu.
Ekonomia ma tu większe znaczenie niż architektura. Migawka drzewa dostępności typowej strony waży 2–5 KB. Zrzut ekranu tej samej strony to 100 KB lub więcej. To ok. 20–50× wyższy koszt per krok w tokenach. Agenci, którzy mogą czytać drzewo dostępności, mają silną motywację, by to robić. Strony, które generują czyste drzewo, są używane. Strony, które tego nie robią, kończą z drogimi zrzutami, większą liczbą nieudanych akcji i ostatecznie są pomijane.
Własne drzewo dostępności możesz zobaczyć już teraz. Otwórz Chrome DevTools, przejdź do zakładki Accessibility, zaznacz „Enable full accessibility tree”. To mniej więcej to, co pobierze agent taki jak browser-use. Chrome domyślnie ukrywa węzły ignorowane i beznazwowe „generic”, co jest przydatne, bo to właśnie z tymi elementami agenci mają problem.
Cytaty to nowe kliknięcia – przynajmniej w części zapytań. Według analizy Profound Wikipedia odpowiada za 47,9% udziału w top-10 źródeł ChatGPT, Reddit za 21% cytatów Google AI Overviews i 46,7% Perplexity. Wzorce zmieniają się ciągle (wg monitoringu Leapd udział Reddita w ChatGPT spadł z ok. 60% do 10% w sześć tygodni po pojedynczej zmianie parametru Google), ale kierunek jest stały: silniki AI nagradzają treści, które potrafią pewnie zparsować, a odrzucają resztę.
„Niektóre LLM-y, jak ChatGPT i Claude, nie wykonują JavaScriptu (w przeciwieństwie do Gemini), więc renderowanie po stronie serwera (SSR) jest krytyczne, aby istotne treści pojawiły się w ich odpowiedziach.”
— Aleyda Solis, AI Search: Where Are We & What Can We Do About It?
To jedno zdanie jest bardziej konkretne niż większość porad AI-SEO, które czytałem. Jeśli ważne treści renderujesz po stronie klienta, ChatGPT i Claude ich nie zobaczą. Gemini tak. Niezależnie, co o tym sądzisz, to weryfikowalny wymóg inżynierski, nie „vibes”. Nasz artykuł AI crawler playbook pokazuje głębiej, które crawlery uruchamiają JavaScript, a które nie.
Bądźmy szczerzy, czego nie wiemy. Nie ma publicznego badania wprost korelującego wyniki dostępności ze wskaźnikami cytowań AI. Mechanizm jest obroniony (drzewo dostępności to ta sama struktura, którą konsumują agenci i czytniki ekranu), ale empiryczne powiązanie nie zostało dowiedzione. Najmocniejsze dane poboczne pochodzą z podsumowania accessibility.works dla 10 000 witryn: zgodne z WCAG notowały 23% więcej ruchu organicznego i ranking dla 27% większej liczby słów kluczowych niż niezgodne. Metodologia jest słabo udokumentowana (brak poziomu WCAG, brak recenzji), więc traktuję to jako sugestię, nie fundament.
Zobaczysz mnóstwo list typu „8 rzeczy”. Lista jest naprawdę przydatna jako struktura porządkująca; przestaje być przydatna, gdy traktujesz wszystkie osiem jako równie ważne. Nie są. Oto porównanie.
| Sygnał | Co widzi agent, gdy zrobisz to dobrze | Co się psuje, gdy zrobisz źle | Wysiłek |
|---|---|---|---|
| Natywne elementy semantyczne | <button>, <a>, <h1> pojawiają się w drzewie a11y z rolami domyślnymi |
Wystylizowane przyciski z <div> znikają z drzewa a11y całkowicie |
Niski |
| Dostępne nazwy pól | "input, type=email, label='Adres e-mail'" | "input, type=text" (sam placeholder nie tworzy nazwy) | Niski |
| Widoczne cele interaktywne | Przyciski większe niż ~8 px² (empiryczny próg web.dev), najlepiej 24×24 CSS px (WCAG 2.5.8 AA) | Modele wizyjne filtrują małe cele; agenci klikowi nie trafiają | Niski |
| Stabilny układ (niski CLS) | Współrzędne kliknięcia lądują na właściwym elemencie | Obrazy lazy-load przesuwają stronę; agent klika zły przycisk | Średni |
| Treść renderowana po stronie serwera | ChatGPT i Claude widzą pełny HTML przy pierwszym pobraniu | Treść tylko po hydracji niewidoczna dla crawlerów bez JS | Średni-wysoki |
| Hierarchia nagłówków | Jedno <h1>, zagnieżdżone <h2>/<h3> z rolami nagłówków |
Nagłówki wizualne wystylizowane na <p>= brak outline’u dokumentu |
Niski |
| Brak „ghost overlays” / pułapek focusu | Zdarzenia kliknięcia trafiają we właściwy element | Przezroczyste warstwy pochłaniają kliknięcia; agent się gubi | Średni |
| Przewidywalne URL-e i formularze | Agent wznawia powigację; pola samoopisowe | SPA, które pochłania historię, myli zadania wieloetapowe | Średni |
Dwa sygnały dominują. Natywne elementy semantyczne i dostępne nazwy to fundament. Jeśli tu popełnisz błąd, reszta nie ma znaczenia. Spośród kilkuset stron, które przeszły przez nasz agent-ready check od premiery narzędzia, najczęstszą pojedynczą wpadką jest właśnie to: CTA zbudowane jako wystylizowany <div>, który znika z drzewa dostępności. Około połowa analizowanych homepagy ma przynajmniej jeden taki przypadek. Wspomniany próg 8 px² (web.dev) jest empiryczny, nie twardym limitem architektury; enkodery wizji w stylu CLIP używają faktycznie 14×14 lub 16×16-px patchy, więc traktuj to jako rozsądne minimum, nie magiczną liczbę.
Tego kroku nie widzę w innych materiałach o „agent-readiness”. Większość daje checklistę 8–30 rzeczy i zostawia Cię samemu. Oto co robię, gdy mam 5 minut między spotkaniami.
Minuta 1. Uruchom nasz darmowy agent-ready check. Narzędzie podaje Twoją stronę główną agentowi Playwright i raportuje takie rzeczy jak wystylizowany <div role="button"> bez tabindex, ukryte pole blokujące focus, czy CTA widoczne na zrzucie, ale niewidoczne w drzewie dostępności. To narzędzie, które Lida i ja wypuściliśmy po akcji „GPT nie widzi hover-ów” (nie zgadzaliśmy się co do terminu — ona chciała poczekać na czystsze dane, ja wypuściłem wersję roboczą). Jest darmowe i nie wymaga maila.
Minuta 2. Otwórz stronę w Chrome, DevTools → Accessibility → pełne drzewo. Szukaj węzłów z rolą „generic” bez nazwy. Każdy z nich to miejsce, gdzie agent musi zgadywać.
Minuta 3. Uruchom vibe-coded scanner na ten sam URL. To skaner jakości kodu, który budowaliśmy, aby wyłapywać wzorce, jakie domyślnie wypuszczają Cursor, Copilot i Lovable: <div onClick> jako przyciski, brak etykiet formularzy, nagłówki stylowane jak paragrafy. (Zbudowałem to, bo połowa audytowanych dziś stron jest generowana przez AI, a generatory wciąż nie znają semantycznego HTML.)
Minuta 4. Odpal raport Lighthouse. Zapisz wynik CLS. Powyżej 0,1 jest ryzykowne; powyżej 0,25 regularnie psuje kliknięcia agenta. Zanotuj też wynik dostępności, bo ten sam audyt łapie brak etykiet i problemy z kontrastem.
Minuta 5. Wybierz pojedynczy najgorszy problem z czterech raportów i zapisz. Jutro napraw tylko to. Nie próbuj ogarniać całej listy.
Pięć minut to realny budżet większości leadów marketingu. Masz więcej — super, kop głębiej. Nie masz — ta pętla wystarczy, by wyciągnąć największy problem, a to zwykle wszystko, czego potrzebujesz.
Trzy wzorce odpowiadają za większość awarii, które widzę. Pierwszy to wystylizowany <div> jako przycisk. Wygląda jak przycisk, ma stan hover, reaguje na klik, ale w drzewie dostępności przyciskiem nie jest.
„Nie używaj
<div>,<span>ani innych nieinteraktywnych elementów. Jeśli nie możesz przejść do niego tabulatorem, to prawdopodobnie fatalny pomysł.”— Adrian Roselli, Links, Buttons, Submits, and Divs, Oh Hell
Roselli pisał to w 2016 r., dekadę przed „agentami AI” w tym znaczeniu. Heurystyka „czy można dotrzeć tabem” idealnie mapuje się dziś na czytelność dla agenta: jeśli klawiatura nie dociera, drzewo dostępności go nie odsłoni, a agent Playwright go nie zobaczy. Rachunek za dekadę przycisków-divów właśnie przychodzi.
Drugi wzorzec to niestabilny układ. Doświadczyliśmy tego mocno przy migracji z .io na .com. Nowe obrazy lazy-load na .com przesuwały przycisk „Get started” o 40 px ok. 800 ms po renderze. Użytkownicy ledwo zauważyli. Agenci Playwright zidentyfikowali przycisk w pierwotnej pozycji, poczekali moment i kliknęli puste miejsce. To nie teoria: issue #6238 Playwright dokumentuje takie przypadki i wciąż jest otwarty. Wskaźnik Lighthouse CLS to proxy, któremu tu ufam. Powyżej 0,1 jest podejrzane.
Trzeci wzorzec to „ghost overlays”. Bannery cookies, które się nie zamykają, popupy GDPR z przezroczystym backdropem zostawionym po zamknięciu, widgety intercom z z-index: 9999 nad CTA. Każdy z nich przechwytuje klik, który agent chciał wysłać gdzie indziej. Web.dev opisuje je wprost, a nasz vibe-coded scanner je flaguje.
„Urządzenia te opierają się na drzewie dostępności — mechanizmie, dzięki któremu technologia wspomagająca może programistycznie czytać i interpretować interfejs — aby działać. Bazując na dobrze wspieranym, sprawdzonym znacznikowaniu treści, czynimy naszą pracę wszechstronną i odporną.”
— Eric Bailey, Truths about digital accessibility
Bailey pisał to w 2019 r., mając na myśli czytniki ekranu i technologię wspomagającą. Do mnie ciągle wraca fragment „mechanizm, którego używają komputery”. Zdefiniował drzewo dostępności jako interfejs programowy dla maszyn, nie tylko dla osób z niepełnosprawnościami. Pojawienie się agentów AI łączy trzy dotąd oddzielne zadania (dostępność, crawlability SEO i czytelność dla agentów) w jedno: dostarczyć czysty, maszynowo czytelny opis interfejsu.
Dłuższą wersję SEO-wej części tego zbiegu znajdziesz w naszym filarze accessibility-for-SEO. Krótko: te same poprawki (semantyczny HTML, dostępne nazwy, stabilny layout) ruszają trzy wskaźniki naraz.
Jeśli nie zrobisz nic innego z tego artykułu, zrób to w tej kolejności.
<div>/<span> na <button>. Największa dźwignia, najniższy koszt. Sama ta zmiana przenosi Cię z „niewidoczny” na „widoczny” w agentach stawiających na drzewo a11y (browser-use, Mariner, crawler-y Playwright).<label for> do każdego pola formularza. Placeholder to nie nazwa dostępna. Jeśli pole e-mail w formularzu nie ma etykiety, agent widzi nieopisany text-input, koniec.<h1> na stronę. <h2> dla sekcji. Nie styluj <p> jak nagłówka.
Widziałem zespoły spędzające dwa tygodnie na publikacji llms.txt, zanim naprawiły checkout-button w <div>. Kolejność odwrotna.
Wdrożyłeś poprawki. I co dalej?
Dla stabilności layoutu najtańszym, wiarygodnym pomiarem jest raport Lighthouse. Uruchom go przed i po na tym samym URL, obserwuj CLS, wynik dostępności i INP. (Gdy u siebie wymieniliśmy <div>-przyciski, wynik a11y Lighthouse skoczył o 14 pkt, CLS spadł z 0,18 do 0,04. To nie eksperyment kontrolowany, ale zmianę taką zrobisz w popołudnie.)
Dla samej czytelności przez agenta – ponownie uruchom agent-ready check. Narzędzie podaje score parseability i listę CTA, które agent znalazł lub zgubił. Patrzę na „CTAs successfully identified”: jeśli to nie 100%, agent wciąż zgaduje.
Dla cytatów AI (wyniku SEO, na którym Ci zależy) użyj naszego backlink checkera, by śledzić wzmianki w podsumowaniach AI. Cytaty ChatGPT, Perplexity i AI Overviews wyglądają jak backlinki, tylko z nowych źródeł. Jeśli poprawki działają, cytaty pojawią się w tygodniach, nie dniach. Metodologia audytu widoczności AI opisuje wolną pętlę pomiaru.
Chcę odnotować statystykę Wila Reynoldsa, którą Orbit Media cytuje: „0,8% ruchu, 10% leadów”. To prawdziwy, przydatny datapoint. Ale to liczba jednej firmy w konkretnym okresie, a sam Reynolds mówił, że to nie uniwersalny mnożnik. Traktuję to jako dowód, że ruch AI konwertuje ponad wagę, nie jako mnożnik do prognoz. Jeśli Twój ruch AI konwertuje 5× lepiej niż organiczny, masz coś. Jeśli nie, mnożnik Cię nie dotyczy.
WebMCP to specyfikacja, którą warto obserwować. Pozwala stronie zarejestrować narzędzia JavaScript, które agent AI może wywoływać bezpośrednio, zmieniając stronę w serwer Model Context Protocol. Chrome 146 Canary dodał ukrytą flagę, Edge 147 dołożył wsparcie w marcu 2026, a draft W3C Community Group opublikowano 23.04.2026.
Lubię ten pomysł. Jestem też realistą co do czasu. Samo repo zastrzega: „To nie jest standard W3C ani nawet na ścieżce standaryzacji”. Żaden duży dostawca LLM nie zadeklarował konsumpcji MCP. Według Cloudflare mniej niż 15 witryn globalnie używa MCP Server Cards. To historia na 2–5 lat.
„Przeglądarka webowa została zaprojektowana dla ludzi i deweloperów, nie dla agentów AI. Większość treści jest strukturyzowana pod wizualne spożycie, a dynamiczne elementy i złożone layouty opierają się prostemu parsowaniu.”
— Cobus Greyling, The Future of Web Browsing AI Agents
Greyling twierdzi, że checklisty „agent-friendly” (czyli ten artykuł) to obejście głębszego niedopasowania architektury, które prawdziwe standardy, jak WebMCP, próbują naprawić. Może mieć rację. Nie wiem, czy WebMCP wygra, czy llms.txt i NLWeb od Microsoftu, czy coś jeszcze nieznanego. Wiem, że piramida priorytetów to robota na teraz, zanim warstwa standardów się wyklaruje. Nasze spojrzenie na kierunek znajdziesz w agentic SEO workflows.
To witryna, którą agenci AI (Claude computer-use, OpenAI Operator, Project Mariner, crawlery Playwright) mogą niezawodnie odczytać i obsłużyć, podobnie jak ludzi. Kluczowe jest wyraźne ujawnienie elementów interaktywnych w drzewie dostępności, stabilny layout i serwer-rendering ważnej treści, by crawlery bez JS mogły ją odczytać.
Używają jednego lub kilku z trzech trybów wejścia: zrzutów ekranu, surowego HTML lub drzewa dostępności. Agenci tylko-screenshot (Anthropic) analizują piksele i gubią cele < 8 px². Agenci świadomi DOM (Mariner, Operator) warstwują dane o elementach. Agenci „a11y-tree-first” (browser-use, Playwright) dostają czystą mapę strukturalną, ale pomijają elementy nieeksponowane semantycznie.
Bing potwierdził, że schema pomaga Copilotowi zrozumieć treść. Google przyznał, że strukturalne dane dają przewagę w wynikach. Dowody na wzrost cytowań AI są mieszane: jedno badanie nie znalazło korelacji, inne pokazało 61,7% cytowań przy bogatym schemacie. Traktuj jako pomocne dla AI-search, nie gwarantowany mnożnik.
To proponowany format pliku (na wzór robots.txt), który mówi crawlerom AI, gdzie znaleźć ważne treści w czystej formie. Do października 2025 opublikowało go ponad 844 tys. witryn. Adopcja wysoka, konsumpcja niska: John Mueller i Gary Illyes mówili, że żaden duży system AI nie używa go operacyjnie. Warto opublikować, jeśli masz 10 wolnych minut; nie warto przed naprawą przycisków-divów.
Najszybsza droga to 5-minutowy audyt: agent-ready check, panel Accessibility w DevTools, raport Lighthouse i skaner vibe-coded. Te cztery kroki wyciągną największy problem. Napraw najgorszy punkt, zanim przejdziesz dalej.
Agenci AI czytają stronę przez zrzuty, DOM i drzewo dostępności, w różnych proporcjach zależnie od dostawcy. Większość poprawek to te same poprawki dostępności, które już powinieneś robić: semantyczne elementy, dostępne nazwy, stabilny layout, SSR ważnej treści. Warstwa standardów (WebMCP, llms.txt, NLWeb) jest realna, ale powolna; mało seksowne poprawki są pilne.
Uruchom nasz darmowy agent-readiness check, by sprawdzić, jak czytelna jest Twoja strona dla ChatGPT, Claude i Perplexity. Sprawdzisz, które CTA agent pominął, które przyciski zniknęły z drzewa dostępności i które przesunięcia layoutu zjadają kliknięcia. To narzędzie, którego życzyłbym sobie w dniu, gdy GPT nie zobaczył naszych efektów hover.
no credit card required
No related articles found.