Cloudflare

Seu site está pronto para agentes de IA? O check da Cloudflare na prática

Como o isitagentready.com pontua descoberta, conteúdo, bots e APIs, o que implementar de verdade (robots.txt, llms.txt, Markdown, MCP) e o que pular só para inflar nota.

Assistir ao vídeo original no YouTube
Thumbnail do vídeo: Seu Site Está Pronto para Agentes de IA? Check Cloudflare

Antes de lançar um site feito com inteligência artificial, eu quero saber como um agente lê a página. Não basta o layout abrir no meu navegador. robots.txt, llms.txt, Markdown, MCP, metadados e a forma como o bot entra no domínio passam a fazer parte do mesmo checklist. A Cloudflare publicou o isitagentready.com exatamente para isso: você cola o domínio, recebe uma nota e um diagnóstico. No vídeo eu rodei o check num site novo de preços de API — calculadora e tabela comparativa, no ar havia uma semana — e depois no site principal, para ver o que a nota estava medindo de verdade.

Abra o isitagentready.com, rode o scan e trate a nota como um PageSpeed de agentes: descoberta, conteúdo, acesso de bots e capacidades (MCP, catálogo de API, autenticação). Copie o pacote de melhorias, mande a IA aplicar só o que cabe na stack e recuse item que existe só para subir score — OAuth e Web Bot Auth, por exemplo, não fazem sentido em site público só de leitura. Na gravação o site novo saiu de 29 para 71 depois de links no header, catálogo MCP e um DNS opcional via Wrangler.

Ferramenta
isitagentready.com — scan público da Cloudflare
O que costuma faltar
robots.txt, llms.txt, Markdown, MCP, catálogo de API
O que não forçar
OAuth, Web Bot Auth e e-commerce quando o site não tem isso

O que o check Agent-Ready mede no seu domínio

O site da Cloudflare pede a URL e varre o domínio como um agente faria. A nota que eu mostrei no vídeo se parece com um PageSpeed: não é um ranking de busca, é um diagnóstico de descoberta, conteúdo, bots e APIs. Área de e-commerce veio vazia no meu caso. O check não deveria punir um site que não vende produto; aquela fatia simplesmente não se aplica. O relatório chega em inglês, item a item, com o que falta e o que já passou.

A documentação oficial do Agent Readiness confirma quatro eixos. Descoberta: robots.txt, sitemap.xml e Link headers (RFC 8288). Conteúdo: Markdown para agentes — o servidor responder text/markdown quando o pedido traz Accept: text/markdown. Controle de bots: Content Signals, regras de crawler de IA no robots.txt e Web Bot Auth. Capacidades: Agent Skills, catálogo de API (RFC 9727), descoberta de OAuth, MCP Server Card e WebMCP. Padrões de comércio (x402 e afins) são checados à parte e, no texto da Cloudflare, ainda não entram na nota.

O scan padrão da Cloudflare, no anúncio, foca a negociação Markdown e não exige llms.txt. Dá para incluir o llms.txt no perfil do scan. Eu trato os dois como trabalho real: o arquivo na raiz é a lista de leitura do site; a negociação Markdown é o formato em que cada página chega no contexto do agente. Sem isso, o bot paga o HTML inteiro — navegação, script, div — para extrair um título.

Scan: MCP, Markdown e o que o bot realmente consegue ler

O meu site de preços de API ainda não estava redondo para agente. O check também olha se o domínio se presta a MCP, a Markdown, a skill de agente. MCP é o protocolo para o modelo falar com ferramenta e dado externo: se você tem API pública, o caminho maduro é um Server Card em .well-known descrevendo ferramenta, transporte e autenticação, mais um catálogo em /.well-known/api-catalog. Markdown é o formato curto. robots.txt continua sendo a porta: regra de crawl e ponte para o sitemap. llms.txt, no padrão llmstxt.org, é um Markdown na raiz com o que o site é e quais URLs importam, escrito para modelo, não para crawler de mapa XML.

Na Cloudflare, se a zona está no plano que libera, existe o interruptor Markdown for Agents no painel (AI Crawl Control). Com ele ligado, um Accept: text/markdown na borda converte o HTML em Markdown, tira chrome da página e devolve frontmatter e, quando existe, JSON-LD no fim. A docs da Cloudflare mede até 80% menos tokens em alguns artigos. Quem não usa essa flag ainda pode servir .md próprio ou um index.md por rota — o check olha o comportamento, não a marca da hospedagem. O scan funciona em Worker, em servidor clássico e, em tese, até em WordPress; eu não conheço um plugin único que cubra MCP, llms.txt e negociação Markdown de uma vez.

  1. Abra https://isitagentready.com/ e cole o domínio publicado, não o localhost.
  2. Leia a nota por eixo (descoberta, conteúdo, bots, capacidades) antes de sair corrigindo tudo.
  3. Ignore e-commerce, OAuth e catálogo de API se o produto não tem essas peças.
  4. Confira na origem se existe robots.txt, sitemap.xml, llms.txt e resposta text/markdown.
  5. Só então copie o pacote de melhorias do botão de pontuação — é mais completo do que um print solto.

Como mandar a IA corrigir: print versus o pacote completo

Eu comecei do jeito preguiçoso: print de cada falha e “corrige isso”. Funciona em item isolado. Perde o contexto do relatório. Alguns avisos nem têm conserto na sua stack — catálogo de API num site que não tem API, autenticação num site sem login. Sem dizer isso, a IA tenta implementar o universo. O botão de melhorar a pontuação no isitagentready.com copia o pacote inteiro de correções, com os arquivos de skill em Markdown apontando onde mexer. Isso substitui a dança do print.

O pedido que eu fiz por voz, na prática, foi: use o relatório da Cloudflare, veja o que dá para corrigir neste repositório, suba descoberta, conteúdo e o que for API, não quebre o que já funciona, e anote num Markdown o que não deve ser apagado. Eu tinha tirado 29. Pedi cautela porque o site público de tabela de preço não precisa parecer um painel autenticado. Tempo, nessa corrida, some quando a pessoa fica lendo cada bullet em inglês em vez de deixar a ferramenta gerar a lista e a IA aplicar o que couber.

O que implementar de verdade — e o que pular para não inflar score

Enquanto a IA trabalhava no site novo, eu rodei o check no site principal. Tinha ficado em 79%. Uma atualização anterior tinha deixado um furo de descoberta ligado a DNS; a nota não é eterna. A própria plataforma mostra a auditoria: cada critério, o que passou, o que falhou. Serve para validar o que a IA disse que fez.

No site novo, depois da primeira leva, a descoberta subiu, o conteúdo melhorou, entraram links no header e um catálogo MCP que antes era zero. Autenticação (OAuth) ficou de fora de propósito: site público, API só de leitura, não ia colocar login só para ter score. Web Bot Auth caiu no mesmo saco — assinar requisição de bot faz sentido quando o seu serviço também sai pela internet como agente, não quando você só publica tabela. A Cloudflare, no texto do Agent Readiness, diz a mesma coisa sobre Web Bot Auth: site que só serve conteúdo e não dispara pedido para os outros não precisa disso agora.

O DNS extra era opcional. Pouco retorno imediato, dá para fazer depois no painel. Como o projeto já tinha Wrangler e o token da conta tinha permissão de DNS, eu mandei criar o registro. No checkup seguinte a nota foi para 71%. Não foi mágica de “otimizador”: foram arquivos e cabeçalhos que o agente usa de fato. Vale repetir o scan depois de cada deploy. Uma mudança de rota, de header ou de domínio derruba descoberta sem ninguém perceber.

  • Fazer: robots.txt com sitemap, regras para crawler de IA e, se quiser, Content-Signal (ai-input, search, ai-train).
  • Fazer: llms.txt na raiz com o mapa curto do site e links para as páginas em Markdown.
  • Fazer: responder Accept: text/markdown (flag Markdown for Agents na Cloudflare, ou conversão na origem).
  • Fazer, se houver API pública: catálogo em /.well-known/api-catalog e MCP Server Card.
  • Fazer: Link headers apontando esses recursos, para o agente achar sem parsear HTML.
  • Pular: OAuth e fluxo de login em site sem área autenticada.
  • Pular: Web Bot Auth se você não opera bots que chamam outros sites.
  • Pular: x402 e checkout de agente se não há venda.

DNS, Wrangler e quando a nota deixa de ser o objetivo

O token com permissão de DNS permitiu gravar o registro opcional direto pelo Wrangler, sem clicar no painel. Depois disso, espera-se a propagação. Não tem o que “otimizar” além do que o check ainda aponta com causa real. Blog e site institucional também se beneficiam: agente que acha o llms.txt e recebe Markdown gasta menos contexto para citar a página certa. Loja, SaaS e API pública ganham mais, porque aí MCP, catálogo e — se existir conta — OAuth deixam de ser teatro.

A nota alta não é o produto. O produto é o agente conseguir descobrir o mapa, ler o conteúdo sem HTML inflado e, se for o caso, chamar a API sem adivinhar endpoint. Se um item do relatório pede autenticação que o seu serviço não tem, documente a recusa. Score comprado com OAuth fantasma é a versão nova de meta tag vazia.

Na sequência

  1. Publique o domínio em HTTPS e rode o isitagentready.com na URL real.
  2. Garanta robots.txt e sitemap.xml acessíveis na raiz.
  3. Publique um llms.txt curto, com descrição e links para o conteúdo em Markdown.
  4. Teste um pedido com cabeçalho Accept: text/markdown e veja se a resposta não é o HTML completo.
  5. Se houver API pública, exponha catálogo e, se couber, MCP Server Card em .well-known.
  6. Recuse OAuth, Web Bot Auth e e-commerce no relatório quando o produto não tem essas funções.
  7. Rode o scan de novo depois do deploy e depois de mexer em DNS ou header.

Onde isso quebra

Implementar OAuth ou Web Bot Auth só para a barra de pontuação subir.

Mandar print solto para a IA sem dizer quais eixos não se aplicam à stack.

Esquecer llms.txt e Markdown e achar que um robots.txt genérico resolve leitura por agente.

Não repetir o check depois de um deploy: a nota de 79% no site principal já tinha recuado num furo de descoberta.

Perguntas frequentes

O isitagentready.com só funciona em site na Cloudflare?

Não. O scan pede o domínio público. Hospedar na Cloudflare facilita ligar Markdown for Agents e gravar DNS com Wrangler, mas robots.txt, llms.txt, MCP e catálogo de API são arquivos e cabeçalhos da origem.

llms.txt é obrigatório para a nota?

No anúncio da Cloudflare o scan padrão prioriza a negociação Markdown e deixa o llms.txt como opção do perfil. Continua sendo o mapa que o modelo lê primeiro; eu publicaria mesmo que a nota não cobrasse.

O que é a negociação Markdown na prática?

O agente envia Accept: text/markdown. O servidor — ou a borda da Cloudflare, com Markdown for Agents ligado — devolve text/markdown em vez do HTML. Menos token, menos chrome, mais conteúdo.

Preciso de MCP num blog?

Em geral não. MCP e catálogo de API importam quando existe ferramenta ou dado que o agente deve chamar. Blog ganha mais com llms.txt, sitemap, Link headers e Markdown.

Por que a nota do site novo foi 29 e depois 71?

Na primeira passada faltava descoberta e conteúdo útil para agente, e não havia catálogo MCP. Depois dos links no header, do catálogo e de um DNS opcional via Wrangler, a nota subiu. OAuth ficou de fora de propósito.

Markdown for Agents é gratuito em qualquer plano Cloudflare?

A documentação oficial descreve o recurso em beta sem custo extra para planos Pro, Business, Enterprise e clientes de SSL for SaaS. Confira o painel da zona; plano Free pode não ter o interruptor.

A leitura por agente não substitui a entrega da página para gente de verdade: confira renderização e o HTML público. Com o domínio respondendo, feche a porta em proteção de site feito com IA na Cloudflare.