Cloudflare ocenia twoją stronę w erze agentów AI za pomocą Score Agent Readiness

Strony internetowe nauczyły się komunikować z przeglądarkami, a potem z wyszukiwarkami. Cloudflare uważa, że teraz powinny nauczyć się rozmawiać z agentami AI i uruchomił narzędzie, które ma w tym pomóc. Ambitna inicjatywa, która jednak rodzi tyle samo pytań, ile rozwiązuje problemów.

Narzędzie oceniające dla realnego problemu

Punkt wyjścia Cloudflare jest solidny. Gdy agent AI, taki jak Claude, Cursor czy OpenCode, próbuje uzyskać dostęp do strony, by przeczytać dokumentację, kupić produkt lub skorzystać z API, napotyka infrastrukturę zaprojektowaną dla ludzi: gęsty HTML, formularze, sesje przeglądania, captcha. W efekcie agenty działają wolno, kosztują dużo tokenów i często popełniają błędy.

Aby ocenić skalę problemu, Cloudflare przeskanował 200 000 najczęściej odwiedzanych domen w sieci, odfiltrowując przekierowania, serwery reklamowe i usługi tunelowania, by skupić się na stronach, z którymi agenty mogłyby rozsądnie wchodzić w interakcje.

Wynik jest wymowny: 78% stron ma plik robots.txt, ale niemal wszystkie zostały napisane z myślą o tradycyjnych crawlerach wyszukiwarek, a nie o agentach. Tylko 3,9% stron serwuje zawartość w Markdownie, gdy o to poproszono. A standardy wschodzące, takie jak Karty serwerów MCP są obecne na mniej niż 15 stronach w całym zbiorze danych.

Rozwiązanie ujawnione przez Cloudflare isitagentready.com proponuje wtedy wynik ustrukturyzowany wokół czterech osi.

• Ta odkrywalność (discoverability) sprawdza obecność i jakość robots.txt, jednego sitemap.xml, oraz nagłówków Link.
• To treść (content) ocenia, czy strona potrafi serwować czystą wersję Markdown na żądanie agenta.
• To kontrola dostępu (bot access control) sprawdza, czy strona wyraża jasne preferencje dotyczące tego, co SI mogą robić z jej treścią.
• Na koniec, możliwości sprawdzają obecność bardziej zaawansowanych standardów, takich jak MCP Server Cards, API Catalog lub odkrywanie OAuth, aby agenci mogli się poprawnie uwierzytelnić.

Standardy wciąż niedojrzałe i niemal zerowa adopcja

Tutaj należy ostudzić entuzjazm wobec Cloudflare. Wiele ze standardów podkreślanych w tym wyniku jest albo w trakcie opracowywania w IETF, albo to nieformalne propozycje bez gwarancji szerokiego przyjęcia. API Catalog (RFC 9727), Karty serwerów MCP czy Web Bot Auth to niedawne standardy, z których niektóre nie osiągnęły jeszcze statusu ostatecznego RFC w chwili publikacji.

Ta sytuacja nie dotyczy wyłącznie Cloudflare: to rzeczywistość ewoluującego internetu. Ale wymaga uczciwości, której wpis na blogu Cloudflare mają tendencję do bagatelizowania. Przyjęcie dziś standardu, który zostanie przerobiony lub porzucony za osiemnaście miesięcy, to potencjalnie zaangażowanie się w prace integracyjne, które trzeba będzie powtórzyć. Wielcy gracze, którzy mają zasoby, by nadążać za tymi zmianami, na tym skorzystają. Małe zespoły czy niezależni deweloperzy — mniej.

Przypadek llms.txt jest ilustracyjny. Zaproponowany we wrześniu 2024 r., ten ustandaryzowany plik do przedstawienia strony modelowi LLM nie jest domyślnie uwzględniony w ocenie Cloudflare, a jedynie jako opcja. Jaki jest powód? Standard wciąż budzi kontrowersje. To ostrożna decyzja, ale sygnalizuje, że nawet Cloudflare nie wie jeszcze dokładnie, na co postawić.

Negocjacja treści w Markdown: realny, mierzalny zysk

Jednym z najbardziej konkretnych aspektów tej inicjatywy, i prawdopodobnie najbardziej bezpośrednio użytecznym, dotyczy zdolność serwera do odpowiedzi w Markdown, gdy agent wysyła nagłówek Accept: text/markdown. Cloudflare twierdzi, że zmierzył do 80% redukcji liczby wymaganych tokenów aby przeczytać stronę, w porównaniu z jej wersją HTML.

Ta liczba wymaga kontekstu. HTML strony dokumentacji technicznej jest często bardzo rozmowny: nawigacja, menu, skrypty, zagnieżdżone tagi… to wszystko stanowi czysty szum dla modelu LLM. Dobrze ustrukturyzowany plik Markdown, to istota treści bez otoczki. Bezpośrednim skutkiem jest obniżenie kosztów wywołań API przez agentów, zmniejszenie opóźnień oraz większe prawdopodobieństwo, że agent będzie miał pełny kontekst bez jego ucinania.

Dla zobrazowania, Cloudflare wyjaśnia, że przetestował własną stronę dokumentacji (developers.cloudflare.com), kierując agenta (Kimi-k2.5 przez OpenCode) na kilka stron technicznych. Wynik: o 31% mniej zużytych tokenów i odpowiedzi poprawne o 66% szybsze niż w przypadku innych, nieoptymalizowanych stron. Te liczby należy traktować ostrożnie, ponieważ pochodzą z wewnętrznych, nieaudytowanych warunków testowych. Jednak rząd wielkości jest spójny z tym, co wiadomo o strukturalnym nadmiarze HTML.

Wdrożenie techniczne na Cloudflare Docs: pragmatyczne i powtarzalne

Najbardziej pouczająca część wpisu to być może ta, która opisuje jak Cloudflare przerobił własną dokumentacjęPodejście jest interesujące, ponieważ omija realny problem: w lutym 2026 tylko trzy z siedmiu testowanych narzędzi (Claude Code, OpenCode i Cursor) automatycznie wysyłają nagłówek Accept: text/markdownDla pozostałych potrzebna jest alternatywa.

Przyjęte rozwiązanie łączy dwie reguły Cloudflare:

• Przepisywanie URL, które przekształca zapytanie do /r2/get-started/index.md w zapytanie do /r2/get-started/,
• I transformacja nagłówka, która automatycznie dodaje Accept: text/markdown do tych przepisanych żądań.

Wynik : dowolny agent może uzyskać dostęp do wersji Markdown dowolnej strony po prostu dodając /index.md do URL, bez konieczności obsługi specjalnego nagłówka.

Inna znacząca decyzja: zamiast jednego llms.txt ogromnego pliku (dokumentacja Cloudflare zawiera ponad 5 000 stron), każdy katalog pierwszego poziomu ma własny plik, a plik główny wskazuje na te podkatalogi. Pozwala to uniknąć opisanego w artykule „pętli grep”: agent napotykający plik zbyt długi, by zmieścić się w jego oknie kontekstu, zaczyna wyszukiwać według słów kluczowych, traci ogólny obraz, mnoży wywołania i pogarsza jakość swoich odpowiedzi.

Zadbano także o granulację : około 450 stron będących jedynie listami linków (strony katalogów) zostało wyłączonych z llms.txt, ponieważ nie wnoszą żadnej wartości semantycznej dla modelu LLM, którego strony podrzędne są już wymienione indywidualnie.

Podmiot, który przyznaje oceny i sprzedaje przygotowanie do nich

Pozycja Cloudflare zasługuje na uważne przeanalizowanie. Firma publikuje referencyjny wynik dla „agent readiness”, integruje ten wynik w swoim URL Scannerze, oferuje gotowe prompt’y do poprawy każdego punktu awarii… i sprzedaje produkty (Workers, Rules, Access), które pozwalają wdrożyć te poprawki. isitagentready.com sam jest obsługiwany przez Cloudflare i udostępnia serwer MCP.

To niekoniecznie jest problematyczne: Google postąpił podobnie z Lighthouse i Core Web Vitals, stając się jednocześnie sędzią wydajności i dostawcą narzędzi do jej poprawy (poprzez Google Cloud, Firebase itp.). Jednak oznacza to, że kryteria wyniku mogą ewoluować pod wpływem interesów komercyjnych firmy równie mocno, co pod wpływem realnych potrzeb agentów. Standard promowany przez jedną firmę, nawet z dobrymi intencjami, pozostaje standardem, którego kierunki mogą być wypaczone.

Warto też zauważyć, że Cloudflare aktywnie promuje standardy związane z płatnościami agentowymi (x402, Universal Commerce Protocol), które w niektórych przypadkach angażują bezpośrednich partnerów, takich jak Coinbase. Te standardy nie są jeszcze wliczone do wyniku, ale ich obecność w narzędziu już wskazuje kierunek.

Co deweloperzy mogą dziś zrobić konkretnie

Mimo tych zastrzeżeń, kilka działań ma jasny i natychmiastowy zwrot z inwestycji, niezależnie od ewolucji standardów:

• Serwowanie Markdown na żądanie jest technicznie proste, obniża koszty dla klientów API i poprawia jakość odpowiedzi agentów. To priorytet.
• Dbać o robots.txt dla agentów AI (dodając dyrektywy dla crawlerów takich jak GPTBot, ClaudeBot, CCBot, itp.) to dobra praktyka, która nic nie kosztuje i wyjaśnia prawa dostępu.
• Strukturyzować llms.txt podział na sekcje dla stron z dużą ilością treści to dobra praktyka dokumentacyjna, korzystna zarówno dla agentów, jak i dla osób chcących szybko zrozumieć architekturę strony.

Natomiast wdrożenie MCP Server Cards czy API Catalogs dla strony, która nie ma jeszcze publicznego API ani jasno określonego przypadku użycia agenta, byłoby jak budowanie poczekalni przed pojawieniem się odwiedzających.

Adopcja jako wskaźnik rynkowy, nie jako obowiązek

Prawdziwa wartość inicjatywy Cloudflare może leżeć w Radar zbioru danych który wprowadza: cotygodniowe monitorowanie adopcji każdego standardu przez 200 000 najczęściej odwiedzanych stron, segmentowane według kategorii domeny. Tego typu dane pozwolą zmierzyć, czy standardy rzeczywiście „zwyciężają”, czy też większość stron pozostaje pasywna, czekając, aż agenci dostosują się do nich, tak jak od trzydziestu lat dostosowują się do HTML.

Odpowiedź na to pytanie powie wiele o dynamice sił między wydawcami stron a twórcami agentów. Jeśli najpopularniejsze agenty w końcu zintegrują wystarczająco solidne możliwości parsowania HTML, presja na strony, by się dostosowały, zmaleje. Jeśli przeciwnie, koszty i opóźnienia związane z konsumowaniem nieoptymalnego HTML staną się mierzalną przewagą konkurencyjną dla stron, które się dostosują, adopcja nastąpi naturalnie.

Artykuł „Cloudflare ocenia twoją stronę w erze agentów AI za pomocą Score Agent Readiness” został opublikowany na stronie Abondance.