Os sites aprenderam a se comunicar com navegadores e, em seguida, começaram a se comunicar com motores de busca. O Cloudflare acredita que agora os sites precisam aprender a se comunicar com agências de IA e oferece uma ferramenta para ajudar nisso. Esta é uma iniciativa ambiciosa, mas levanta mais perguntas do que soluções.

Destaques:

  • O Cloudflare lançou uma ferramenta gratuita chamada isitagentready.com, que avalia a compatibilidade dos sites com agências de IA em quatro dimensões: descobribilidade, conteúdo, controle de acesso e capacidades.
  • A web ainda não está pronta: apenas 4% dos 200.000 sites analisados informam suas preferências para uso de IA, e menos de 15 sites adotaram os últimos padrões, como Cartões de Servidor MCP ou Catálogos de API.
  • A iniciativa se baseia em um ecossistema de padrões em construção, o que expõe os primeiros adotantes ao risco de fragmentação ou obsolescência rápida.
  • O Cloudflare está em uma posição que determina a pontuação e oferece soluções para melhorá-la, o que levanta questionamentos.

Ferramenta de Avaliação para um Problema Real

O ponto de partida do Cloudflare é sólido. Quando uma agência de IA deseja acessar um site, ler a documentação, comprar um produto ou interagir com uma API, ela se depara com uma infraestrutura projetada para humanos: HTML denso, formulários, sessões, captchas. Como resultado, surgem agências lentas, custosas em termos de tokens e frequentemente errôneas.

O Cloudflare mediu a magnitude do problema ao escanear os 200.000 domínios mais visitados e, filtrando redirecionamentos, servidores de anúncios e serviços de túnel, focou em sites com os quais as agências poderiam interagir razoavelmente.

O resultado é impressionante: 78% dos sites têm um arquivo robots.txt, mas quase todos foram escritos para navegadores de motores de busca tradicionais, não para agências. Apenas 3,9% oferece conteúdo em formato Markdown quando solicitado. E novos padrões, como Cartões de Servidor MCP, estão disponíveis em menos de 15 sites em todo o conjunto de dados.

A solução promovida pelo Cloudflare, isitagentready.com, oferece uma pontuação estruturada em torno de quatro eixos.

  • Descobribilidade (discoverability) verifica a presença e a qualidade de robots.txt, sitemap.xml e Cabeçalhos de Link.
  • Conteúdo (content) avalia se o site oferece uma versão limpa em Markdown que atenda à solicitação de uma agência.
  • Controle de Acesso (bot access control) verifica se o site expressa preferências claras sobre o que as IAs podem fazer com seu conteúdo.
  • Por fim, capacidades testam a presença de padrões mais avançados, como Cartões de Servidor MCP, Catálogo de API ou descoberta OAuth, que permitam que as agências se autentiquem corretamente.

Padrões em Desenvolvimento e Adoção Quase Inexistente

Aqui, o entusiasmo do Cloudflare deve ser moderado. Muitos dos padrões destacados neste ponto estão em fase de rascunho no IETF ou são propostas informais sem garantia de aceitação geral. O Catálogo de API (RFC 9727), Cartões de Servidor MCP ou Web Bot Auth são novos padrões que ainda não alcançaram o status de RFC definitivo na data da publicação.

Essa situação não é exclusiva do Cloudflare: é a realidade de uma web em evolução. No entanto, isso exige uma honestidade que foi menosprezada no blog do Cloudflare. Considerando que um padrão adotado hoje pode ser reestruturado ou abandonado em dezoito meses, isso pode criar uma carga de trabalho que requer reintegração. Enquanto grandes players têm recursos para acompanhar essas evoluções, o mesmo pode não ser verdade para equipes menores ou desenvolvedores independentes.

O exemplo do llms.txt é notável. Proposto em setembro de 2024, este arquivo padronizado para apresentar um site a um LLM não está incluído por padrão na pontuação do Cloudflare, sendo apenas opcional. O motivo? O padrão ainda está em discussão. Essa é uma decisão cautelosa, mas também mostra que o Cloudflare ainda não sabe quais riscos deve assumir.

Discussão sobre Conteúdo em Markdown: Um Ganho Real Medido

Um dos aspectos mais concretos da iniciativa, e provavelmente o mais urgentemente útil, é a capacidade de um servidor responder em formato Markdown quando uma agência envia o cabeçalho Accept: text/markdown. O Cloudflare alega ter medido uma redução de até 80% no número de tokens necessários para ler uma página.

O contexto desse número é importante. O HTML de uma página de documentação técnica geralmente é muito pesado: navegação, menus, scripts, tags aninhadas... tudo isso gera ruído puro para um LLM. Um arquivo Markdown bem estruturado é a essência do conteúdo sem embalagem. O resultado direto é a redução do custo das chamadas de API para agências, diminuição da latência e aumento da probabilidade de que a agência obtenha o contexto completo sem interrupções.

O Cloudflare explica que testou seu site de documentação (developers.cloudflare.com) e direcionou uma agência (através do Kimi-k2.5 OpenCode) para vários sites técnicos. O resultado: 31% menos consumo de tokens e respostas corretas 66% mais rápidas em comparação com outros sites não otimizados. Esses números devem ser tratados com cautela, pois derivam de condições de teste internas não auditadas. No entanto, a ordem de grandeza é consistente com o que se sabe sobre a excessiva estrutura do HTML.

Implementação Técnica no Cloudflare Docs: Prática e Repetível

A parte mais instrutiva do artigo é como o Cloudflare reestruturou sua própria documentação. A abordagem é interessante porque supera um problema real: entre as sete ferramentas testadas em fevereiro de 2026, apenas três (Claude Code, OpenCode e Cursor) enviam automaticamente o cabeçalho Accept: text/markdown. Para as outras, uma alternativa é necessária.

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

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

Resultado: Qualquer agência pode acessar a versão Markdown de qualquer página adicionando /index.md à URL, sem a necessidade de gerenciar um cabeçalho especial.

Outra decisão notável: em vez de um único grande arquivo llms.txt (a documentação do Cloudflare contém mais de 5.000 páginas), cada diretório de primeiro nível tem seu próprio arquivo, e o arquivo raiz aponta para esses subdiretórios. Isso evita o loop grep descrito no artigo: uma agência que se depara com um arquivo muito longo começa a perder o foco, faz buscas por palavras-chave, aumenta as chamadas e diminui a qualidade das respostas.

A granularidade também foi cuidadosamente considerada: cerca de 450 páginas contendo apenas listas de links (páginas de diretório) foram excluídas do llms.txt, pois já não acrescentam valor semântico para um LLM para as subpáginas listadas individualmente.

Um Jogador que Avalia e Vende Preparação de Pontuação

A posição do Cloudflare requer um exame cuidadoso. A empresa publica a pontuação de referência para a preparação de agências, integra essa pontuação ao Navegador de URL, oferece modelos prontos para corrigir cada ponto de falha... e vende produtos (Workers, Rules, Access) para implementar essas correções. O isitagentready.com também é oferecido pelo Cloudflare e hospeda um servidor MCP.

Isso não é necessariamente problemático: o Google fez o mesmo com o Lighthouse e o Core Web Vitals e se tornou um provedor que fornece tanto critérios de avaliação quanto ferramentas para melhorar o desempenho (via Google Cloud, Firebase, etc.). No entanto, isso significa que os critérios da pontuação podem evoluir tanto de acordo com os interesses comerciais da empresa quanto com as reais necessidades das agências. Um padrão apoiado por uma única empresa, mesmo que de boa fé, pode influenciar as diretrizes.

Além disso, é notável que o Cloudflare esteja ativamente promovendo padrões relacionados a pagamentos de agências (x402, Protocolo de Comércio Universal); alguns desses padrões incluem parceiros diretos como Coinbase. Esses padrões ainda não estão incluídos na pontuação, mas a presença deles na ferramenta já sinaliza uma direção.

Coisas que os Desenvolvedores Podem Fazer Hoje

Apesar dessas reservas, muitas ações oferecem um retorno claro e imediato, independentemente da evolução dos padrões:

  • Oferecer Markdown sob demanda é tecnicamente simples, reduz custos para consumidores de API e melhora a qualidade das respostas para agências. Essa é uma prioridade.
  • Modificar o robots.txt para agências de IA (por exemplo, adicionando diretrizes para navegadores como GPTBot, ClaudeBot, CCBot) é uma boa prática e sem custo, esclarecendo direitos de acesso.
  • Para sites com muito conteúdo, configurar o llms.txt por seção é uma boa prática de documentação para agências e pessoas que desejam entender rapidamente a arquitetura de um site.

Por outro lado, implementar Cartões de Servidor MCP ou Catálogos de API para um site que ainda não possui uma API pública ou um caso de uso claro para agências é equivalente a construir uma sala de espera sem visitantes.

Adoção como Indicador de Mercado, Não como Obrigação

O verdadeiro valor da iniciativa do Cloudflare reside, talvez, nos dados do conjunto Radar: um conjunto de dados que rastreia semanalmente a adoção de cada padrão nos 200.000 sites mais visitados, segmentado por categorias de domínio. Esses dados permitirão medir se os padrões realmente trazem benefícios ou se a maioria dos sites permanece passiva, esperando que as agências se adaptem a eles, como já fazem há trinta anos com o HTML.

A resposta a essa questão dirá muito sobre a dinâmica de poder entre editores de sites e desenvolvedores de agências. À medida que as agências adquirirem habilidades robustas de análise de HTML, a pressão sobre os sites para se adaptarem diminuirá. Por outro lado, se os custos e os prazos do consumo de HTML não otimizado se tornarem uma vantagem competitiva mensurável para sites que se adaptam, a adoção aumentará naturalmente.