Cloudflare avalia o seu site na era dos agentes de IA com o Score Agent Readiness

Os sites aprenderam a falar com os navegadores e depois com os motores de busca. A Cloudflare considera que agora eles devem aprender a falar com agentes de IA e lança uma ferramenta para ajudar nisso. Uma iniciativa ambiciosa, mas que levanta tantas questões quanto resolve.

Uma ferramenta de avaliação para um problema real

O ponto de partida da Cloudflare é sólido. Quando um agente de IA como Claude, Cursor ou OpenCode tenta aceder a um site para ler documentação, comprar um produto ou interagir com uma API, depara-se com uma infraestrutura pensada para humanos: HTML denso, formulários, sessões de navegação, captchas. O resultado são agentes lentos, caros em tokens e muitas vezes imprecisos.

Para medir a dimensão do problema, a Cloudflare escaneou os 200 000 domínios mais visitados da web, filtrando os redirecionadores, servidores publicitários e serviços de túnel para se concentrar nos sites com os quais os agentes poderiam razoavelmente interagir.

O balanço é revelador: 78% dos sites têm um ficheiro robots.txt, mas a quase totalidade foi escrita para os crawlers dos motores de busca tradicionais, não para agentes. Apenas 3,9% dos sites servem conteúdo em Markdown quando solicitados. E padrões emergentes como os Cartões de servidor MCP estão presentes em menos de 15 sites em todo o conjunto de dados.

Revelada pela Cloudflare, a solução isitagentready.com propõe então uma pontuação estruturada em torno de quatro eixos.

• A descobribilidade (discoverability) verifica a presença e a qualidade do robots.txt, de um sitemap.xml, e dos Link Headers.
• O conteúdo (content) avalia se o site sabe servir uma versão Markdown limpa a pedido de um agente.
• O controlo de acesso (bot access control) verifica se o site expressa preferências claras sobre o que as IA podem fazer com o seu conteúdo.
• Por fim, as capacidades testam a presença de padrões mais avançados como MCP Server Cards, API Catalog, ou a descoberta OAuth para que os agentes possam autenticar-se corretamente.

Normas ainda incipientes e uma adoção quase nula

É aqui que o entusiasmo da Cloudflare deve ser atenuado. Vários dos padrões destacados nesta pontuação estão ou em redação na IETF, ou são propostas informais sem garantia de adoção generalizada. O API Catalog (RFC 9727), as MCP Server Cards ou o Web Bot Auth são padrões recentes, alguns dos quais ainda não tinham alcançado o estatuto de RFC definitiva no momento da publicação.

Esta situação não é exclusiva da Cloudflare: é a realidade de uma web em fase de evolução. Mas isso exige uma honestidade que o post no blog da Cloudflare adotar hoje um standard que será reformulado ou abandonado em dezoito meses é potencialmente envolver‑se num trabalho de integração que terá de ser refeito. Os grandes intervenientes, que têm recursos para acompanhar essas evoluções, beneficiarão disso. As equipas reduzidas ou os desenvolvedores independentes, menos.

O caso do llms.txt é ilustrativo. Proposto em setembro de 2024, este ficheiro padronizado para apresentar um site a um LLM não está incluído por defeito na pontuação da Cloudflare, apenas como opção. A razão? O padrão ainda é objeto de debate. É uma decisão prudente, mas que indica que mesmo a Cloudflare ainda não sabe exatamente em que apostas apostar.

A negociação de conteúdo em Markdown: um ganho real e mensurável

Um dos aspetos mais concretos da iniciativa, e provavelmente o mais imediatamente útil, diz respeito a a capacidade de um servidor responder em Markdown quando um agente envia um header Accept: text/markdownA Cloudflare afirma ter medido até 80% de redução no número de tokens necessários para ler uma página, em comparação com a sua versão HTML.

Este número merece ser contextualizado. O HTML de uma página de documentação técnica é frequentemente muito prolixo: navegação, menus, scripts, etiquetas aninhadas… tudo isso representa ruído puro para um LLM. Um ficheiro Markdown bem estruturado, é a essência do conteúdo sem a embalagem. A consequência direta é uma redução do custo das chamadas de API para os agentes, uma redução da latência e uma maior probabilidade de que o agente disponha do contexto completo sem o truncar.

Para ilustrar, a Cloudflare explica ter testado o seu próprio site de documentação (developers.cloudflare.com) apontando um agente (Kimi-k2.5 via OpenCode) para vários sites técnicos. Resultado: 31% menos tokens consumidos e respostas corretas 66% mais rápidas do que com outros sites não otimizados. Estes números devem ser tomados com precaução, pois resultam de condições de teste internas não auditadas. Mas a ordem de grandeza é coerente com o que se sabe sobre o excesso estrutural do HTML.

A implementação técnica no Cloudflare Docs: pragmática e reprodutível

A parte talvez mais instrutiva do artigo é aquela que descreve como a Cloudflare reorganizou a sua própria documentaçãoA abordagem é interessante porque contorna um problema real: em fevereiro de 2026, apenas três ferramentas entre sete testadas (Claude Code, OpenCode e Cursor) enviam automaticamente o header Accept: text/markdownPara as outras, é necessária uma alternativa.

A solução escolhida combina duas regras da Cloudflare:

• Uma reescrita de URL que transforma uma solicitação para /r2/get-started/index.md em solicitação para /r2/get-started/,
• E uma transformação de cabeçalho que adiciona automaticamente Accept: text/markdown a essas solicitações reescritas.

Resultado qualquer agente pode aceder à versão Markdown de qualquer página simplesmente adicionando /index.md à URL, sem ter de gerir um header especial.

Outra decisão notável: em vez de um único ficheiro llms.txt gigante (a documentação da Cloudflare tem mais de 5 000 páginas), cada diretório de primeiro nível tem o seu próprio ficheiro, e o ficheiro raiz aponta para esses subdiretórios. Isso evita o “grep loop” descrito no artigo: um agente confrontado com um ficheiro demasiado longo para caber na sua janela de contexto começa a procurar por palavras-chave, perde a visão geral, multiplica as chamadas e degrada a qualidade das suas respostas.

A granularidade também foi cuidadosamente trabalhada cerca de 450 páginas que são apenas listas de links (páginas de diretório) foram excluídas do llms.txtjá que não acrescentam nenhum valor semântico a um LLM cujas páginas filhas já estão listadas individualmente.

Um interveniente que avalia e que vende a preparação para as avaliações

A posição da Cloudflare merece um exame atento. A empresa publica a pontuação de referência para o “agent readiness”, integra essa pontuação no seu URL Scanner, oferece prompts prontos para uso para corrigir cada ponto de falha… e vende os produtos (Workers, Rules, Access) que permitem implementar essas correções. O isitagentready.com é ele próprio servido pela Cloudflare e expõe um servidor MCP.

Isso não é necessariamente problemático: O Google fez o mesmo com o Lighthouse e os Core Web Vitals, tornando-se ao mesmo tempo juiz do desempenho e fornecedor de ferramentas para melhorá-lo (via Google Cloud, Firebase, etc.). Mas isso significa que os critérios da pontuação podem evoluir de acordo com os interesses comerciais da empresa tanto quanto com as necessidades reais dos agentes. Um padrão promovido por uma única empresa, mesmo com boas intenções, continua a ser um padrão cujas orientações podem ser influenciadas.

Também é notável que a Cloudflare promove ativamente padrões relacionados a pagamentos agênticos (x402, Universal Commerce Protocol), alguns dos quais envolvem parceiros diretos como a Coinbase. Esses padrões ainda não contam para a pontuação, mas a sua presença na ferramenta já indica uma direção.

O que os desenvolvedores podem fazer concretamente hoje

Apesar dessas reservas, várias ações têm um retorno sobre o investimento claro e imediato, independentemente da evolução dos padrões:

• Servir Markdown sob demanda é tecnicamente simples, reduz os custos para os consumidores da API e melhora a qualidade das respostas dos agentes. É a prioridade.
• Aprimorar o robots.txt para os agentes de IA (adicionando diretrizes para crawlers como GPTBot, ClaudeBot, CCBot, etc.) é uma boa prática que não custa nada e esclarece os direitos de acesso.
• Estruturar um llms.txt por seção para sites com muito conteúdo é uma boa prática documental que beneficia tanto os agentes quanto as pessoas que procuram entender rapidamente a arquitetura de um site.

Em contrapartida, implementar MCP Server Cards ou API Catalogs para um site que ainda não tem uma API pública ou um caso de uso de agente claramente definido equivaleria a construir uma sala de espera antes de ter visitantes.

A adoção como indicador de mercado, não como obrigação

O verdadeiro valor da iniciativa da Cloudflare talvez esteja no dataset Radar que ela introduz: um acompanhamento semanal da adoção de cada padrão pelos 200 000 sites mais visitados, segmentado por categoria de domínio. Esse tipo de dado permitirá medir se os padrões realmente “vencem”, ou se a maioria dos sites permanece passiva aguardando que os agentes se adaptem a eles, como já se adaptam ao HTML há trinta anos.

A resposta a essa questão dirá muito sobre a dinâmica de poder entre os editores de sites e os desenvolvedores de agentes. Se os agentes mais populares acabarem por integrar capacidades de parsing de HTML suficientemente robustas, a pressão sobre os sites para se adaptarem diminuirá. Se, pelo contrário, os custos e prazos ligados ao consumo de HTML não otimizado se tornarem uma vantagem concorrencial mensurável para os sites que se adaptam, a adoção ocorrerá naturalmente.

O artigo “Cloudflare avalia o seu site na era dos agentes de IA com o Score Agent Readiness” foi publicado no site Abundância.