Prontidão para agentes: como preparar o seu site para a Agentic Web

Porque é que a Agentic Web precisa da sua própria auditoria

Uma nova classe de visitantes chega agora à sua origem antes de qualquer pessoa: software que age. A Cloudflare mediu o tráfego de bots de IA em 4,2% de todos os pedidos HTML na sua rede em 2025 (Cloudflare Radar 2025 Year in Review, 2025). Essa fatia compra, reserva e inicia sessão. O Agent Protocol Readiness Checker audita se o seu site consegue servi-la.

Pontos-chave

• Os bots de IA já geram cerca de 4,2% dos pedidos HTML na rede da Cloudflare (Cloudflare Radar, 2025), e essa fatia continua a subir.
• Os agentes verificam os caminhos /.well-known/, a negociação de conteúdo e as chaves de autenticação de bots antes mesmo de analisarem o seu HTML.
• O verificador pontua cinco camadas: descoberta, acesso a conteúdo, identidade, capacidade e comércio.
• A maioria dos sites fica entre 10 e 30 na primeira passagem. Três correções dirigidas costumam levá-los a uma nota de aprovação.
• Comece pelas lacunas de maior peso: a negociação de Markdown e a descoberta de protocolos somam, em conjunto, 45% da pontuação.

Pense na ordem por que um agente moderno faz as coisas. Não abre a sua página inicial e começa a ler de cima a baixo como uma pessoa. Sonda. Coloca primeiro ao seu servidor algumas perguntas precisas: serve Markdown limpo, publica um manifesto de ferramentas, aceita pedidos assinados, consegue receber um pagamento? Só se essas sondagens falharem é que recorre à recolha de HTML em bruto, que é lenta e perde informação.

Esse comportamento de sondagem é a razão por que a prontidão para agentes é uma disciplina à parte. O SEO afina a forma como a Google o classifica. A Answer Engine Optimization afina a forma como os assistentes de conversa o citam. A prontidão para agentes afina algo diferente: se o software consegue, de todo, transacionar consigo. O verificador é uma auditoria de protocolos, não de conteúdo. Diz-lhe, camada a camada, onde é que um agente desiste.

O que mede o Agent Protocol Readiness Checker?

O verificador corre mais de 20 sondagens contra um URL e agrupa-as em cinco camadas pontuadas, ponderadas pelo impacto. A descoberta de protocolos e o comércio agêntico valem 25% da nota cada uma, a acessibilidade do conteúdo 20%, e a descobribilidade e o acesso de bots 15% cada. Cada sondagem devolve aprovado, aviso ou falha, com as provas brutas do servidor anexadas.

Figura 1: As cinco camadas que um agente avalia e quanto pesa cada uma na nota final.

O sentido das camadas é a sequência. Um agente que não consegue encontrar o seu robots.txt nunca chega à questão de saber se serve Markdown. Um agente que não consegue ler o seu conteúdo de forma limpa raramente se dá ao trabalho de verificar se publica ferramentas. As falhas propagam-se para baixo, por isso as camadas inferiores condicionam tudo o que está acima.

Cápsula de citação

O Agent Protocol Readiness Checker pontua cinco camadas ponderadas ao longo de mais de 20 sondagens: descobribilidade e acesso de bots a 15% cada, acessibilidade do conteúdo a 20%, e descoberta de protocolos e comércio agêntico a 25% cada. Cada sondagem devolve aprovado, aviso ou falha, com as provas brutas do servidor. Os bots de IA já geram 4,2% dos pedidos HTML (Cloudflare Radar, 2025).

Construímo-lo porque as ferramentas existentes respondem à pergunta errada. A maioria das auditorias pergunta «a Google vai classificar esta página». Precisávamos de uma que perguntasse «consegue um agente autónomo usar esta origem sem uma pessoa». Não é o mesmo site. Uma página pode classificar-se lindamente e continuar a ser um beco sem saída para um agente de reservas.

Como descobrem e leem os agentes o seu site?

A descoberta e o acesso a conteúdo são as duas primeiras camadas e decidem se um agente chega sequer a arrancar. Os agentes resolvem primeiro o robots.txt, depois leem os cabeçalhos de resposta Link em busca de indicações e, por fim, negoceiam o tipo de conteúdo. A maioria das origens pontua zero na negociação de Markdown, ainda que seja a correção com o melhor retorno por esforço para o tráfego mediado por IA.

Figura 2: A web humana devolve HTML renderizado. A Agentic Web devolve Markdown negociado em menos saltos.

Descobribilidade: os ficheiros que os agentes resolvem primeiro

Três ficheiros simples preparam o terreno. Um robots.txt válido segundo a RFC 9309, um sitemap para o qual o ficheiro robots aponta com uma linha Sitemap: e cabeçalhos de resposta Link na sua página inicial que sugiram recursos sob /.well-known/. Um agente que lê Link: </.well-known/mcp/server-card.json>; rel="mcp-server-card" obtém o passo seguinte de graça, sem nenhuma ida e volta adicional. Valide o ficheiro robots com o nosso Robots.txt Validator e inspecione o que a sua origem envia hoje com o HTTP Header Checker.

Acessibilidade do conteúdo: sirva Markdown a pedido

É aqui que a maioria dos sites falha, e é o mais barato de corrigir. A proposta da acceptmarkdown.com diz que, quando um cliente envia Accept: text/markdown, o seu servidor deve devolver o mesmo conteúdo em Markdown em vez de HTML. O verificador corre quatro sondagens aqui.

Primeira, confirma que o servidor respeita o cabeçalho e devolve Content-Type: text/markdown; charset=utf-8. Segunda, verifica se há Vary: Accept. Salte esse cabeçalho e uma CDN pode servir um corpo HTML em cache ao agente seguinte que pediu Markdown, contaminando a resposta para todos os clientes de IA por detrás dessa cache. Terceira, um tipo Accept não suportado deve devolver 406 Not Acceptable, e não um recurso silencioso ao HTML. Quarta, o servidor deve respeitar os q-values, de modo que text/markdown;q=1.0, text/html;q=0.1 devolva mesmo Markdown.

Nas nossas próprias auditorias, a primeira passagem típica pontua zero em quatro aqui, e um único worker de CDN que transforma HTML em Markdown a pedido corrige as quatro numa tarde. Depois disso, todos os agentes obtêm uma cópia limpa e tokenizada do seu conteúdo, em vez de lutarem com a estrutura de navegação. Para o lado da estrutura de conteúdo desta questão, o nosso AI Readiness Checker pontua a facilidade com que as suas páginas são analisadas.

Cápsula de citação

A negociação de conteúdo em Markdown segue a proposta da acceptmarkdown.com: quando um cliente envia Accept: text/markdown, o servidor devolve Markdown com Content-Type: text/markdown; charset=utf-8 e Vary: Accept. Saltar o Vary permite que uma CDN sirva HTML em cache a agentes que pedem Markdown, corrompendo as respostas para todos os clientes de IA por detrás dessa cache.

Como deve gerir o acesso e a identidade dos bots de IA?

O silêncio não é uma política. Um robots.txt por omissão que não nomeia nenhum agente de IA deixa cada crawler a adivinhar a sua intenção, e os palpites jogam contra si. A camada de acesso de bots premeia regras explícitas, uma política separada de sinais de conteúdo e um diretório público de chaves de Web Bot Auth, para que consiga distinguir um agente verdadeiro de um scraper que usa o nome dele.

O GPTBot defende bem a clareza. Comparando maio de 2024 com maio de 2025, a fatia do GPTBot no tráfego combinado de crawlers de IA e de pesquisa subiu de 2,2% para 7,7%, um aumento de 305% em pedidos brutos, fazendo-o passar do nono para o terceiro lugar (Cloudflare, 2025). Quando um agente cresce a este ritmo, uma regra genérica de «bloquear tudo» custa-lhe alcance a sério.

Nomeie os agentes no robots.txt

O verificador procura regras dirigidas aos crawlers que importam agora: GPTBot, ChatGPT-User, OAI-SearchBot, ClaudeBot, Google-Extended, PerplexityBot, Meta-ExternalAgent, Applebot-Extended, Bytespider, CCBot, Amazonbot e outros. Três ou mais agentes nomeados obtêm aprovação. Escrever User-agent: GPTBot e depois Allow: / é um compromisso público em que um motor de políticas pode confiar, o que é muito diferente de não dizer nada. Se quiser confirmar o comportamento dos crawlers nas várias versões, o nosso guia irmão sobre GPTBot vs ChatGPT-User vs ClaudeBot explica o que faz cada nome.

Separe treino de recuperação com Content Signals

A proposta Content Signals da Cloudflare acrescenta três diretivas dentro do robots.txt: search, ai-input e ai-train. Permitem-lhe autorizar respostas fundamentadas, para que a sua marca continue a aparecer nas citações de IA, ao mesmo tempo que recusa o treino de modelos. O verificador aprova com qualquer diretiva Content-Signal: isolada. Bloquear o GPTBot por completo é um golpe rude que elimina citações e treino em conjunto. A nossa análise sobre o que bloqueia a visibilidade de IA no robots.txt cobre os bloqueios em excesso mais comuns.

Verifique os agentes com Web Bot Auth

O Web Bot Auth permite que os agentes assinem pedidos com um par de chaves Ed25519, publicando a chave pública como um JWKS em /.well-known/http-message-signature-directory. Está a passar rapidamente de proposta a produção: a AWS WAF anunciou suporte para Web Bot Auth em novembro de 2025 (AWS, 2025), com a Cloudflare, a Anthropic e a OpenAI por detrás do trabalho subjacente do IETF. O verificador sonda esse diretório e confirma que devolve JSON. Sem ele, não consegue provar que um agente legítimo não é um falsário, e os agentes verificados obtêm limites de débito mais baixos e acesso mais amplo.

Que protocolos permitem aos agentes usar o seu site como uma ferramenta?

A descoberta de protocolos é o coração do verificador e a sua camada mais pesada, a 25%. Olha para os endpoints /.well-known/ e as anotações na página que transformam o seu site de um documento numa ferramenta invocável. A âncora aqui é o Model Context Protocol, que a Anthropic tornou código aberto a 25 de novembro de 2024 (Anthropic, 2024) e que a OpenAI e a Google adotaram em menos de um ano.

MCP Server Card

Um MCP Server Card em /.well-known/mcp/server-card.json anuncia o nome do seu servidor, as capacidades, o transporte e o modelo de autenticação. O verificador sonda esse caminho e recorre a /.well-known/mcp.json. Se o seu produto tiver qualquer API, um Server Card é a mudança que faz o seu site passar de «recolham-no» a «invoquem-no». Um agente que encontra um card deixa de analisar HTML e começa a chamar funções, o que é mais barato para si e mais rápido para o utilizador.

WebMCP para agentes no navegador

O MCP pressupõe um mundo de servidor para servidor, mas hoje muita da atividade de agentes acontece dentro de um separador do navegador, e o WebMCP preenche essa lacuna. Em vez de um URL /.well-known/, anota diretamente os elementos <form> com atributos de ferramenta ou declara ferramentas através de uma etiqueta <meta name="webmcp">, expondo ações invocáveis a um agente que já está na página. A proposta surgiu como um esforço conjunto da Google e da Microsoft em 2025 e foi aceite por um Community Group da W3C, com o Chrome a disponibilizar uma pré-visualização inicial, por isso encare os números de versão exatos como alvos em movimento. O verificador procura na sua página inicial qualquer um dos padrões. A lição prática: se as suas conversões acontecem na página, o MCP do lado do servidor por si só deixa os agentes presos nos seus formulários.

API Catalog e descoberta OAuth

Mais duas superfícies de descoberta completam a camada. A RFC 9727 define /.well-known/api-catalog como um ponteiro application/linkset+json para todas as APIs que expõe. Muitas origens recebem aviso aqui porque servem o caminho com application/json em vez disso, uma correção de um único cabeçalho. Depois há a descoberta OAuth: os metadados da RFC 8414 em /.well-known/oauth-authorization-server indicam a um agente como iniciar um fluxo de autenticação, e os metadados da RFC 9728 em /.well-known/oauth-protected-resource indicam-lhe, num 401, que emissor e âmbitos usar. Sem descoberta OAuth, nenhum agente consegue automatizar uma ação com sessão iniciada no seu site.

Cápsula de citação

O Model Context Protocol, tornado código aberto pela Anthropic a 25 de novembro de 2024 (Anthropic, 2024), permite que os agentes descubram ferramentas invocáveis através de um MCP Server Card em /.well-known/mcp/server-card.json. Em cerca de um ano, a OpenAI e a Google adotaram-no, tornando o MCP a camada de descoberta de facto que o Agent Protocol Readiness Checker sonda primeiro.

Consegue um agente pagar-lhe mesmo?

O comércio agêntico é a camada mais recente e está empatada como a mais pesada, a 25%. A questão é direta: quando um agente quer comprar-lhe algo para o seu utilizador, que aspeto tem essa transação? A Adobe Analytics constatou que as visitas a sites de retalho dos EUA vindas de fontes de IA generativa subiram 1.200% entre julho de 2024 e fevereiro de 2025 (Adobe, 2025). As referências já chegam. O checkout tem de estar pronto.

As apostas só sobem a partir daqui. A Gartner prevê que os agentes de IA intermedeiem mais de 15 biliões de dólares em despesa B2B até 2028 (Gartner, via Digital Commerce 360, 2025). Uma pontuação de aprovação no comércio não exige suporte a todos os padrões. Exige pelo menos um, porque «um agente consegue pagar-lhe» é uma capacidade com quatro protocolos a disputar a sua posse.

x402: o caminho de menor compromisso

O x402 ressuscita o estado HTTP 402, «Payment Required», com um cabeçalho de oferta legível por máquina que lista preço, moeda e endpoint de liquidação. O agente recebe o 402, assina um pagamento, volta a submeter e obtém o recurso. A adoção é real: o protocolo x402 da Coinbase ultrapassou os 100 milhões de transações acumuladas na rede Base no início de 2026 (Crypto Briefing, 2026), com os valores on-chain fornecidos pelo próprio projeto e não por um auditor neutro. Escolhe um endpoint pago, devolve um 402 com os termos e está no ar.

ACP: checkout completo para retalho

O Agentic Commerce Protocol é a superfície mais completa. A Stripe e a OpenAI lançaram o ACP em paralelo com o Instant Checkout no ChatGPT a 29 de setembro de 2025 (Stripe Newsroom, 2025), começando com vendedores da Etsy nos EUA e mais de um milhão de comerciantes Shopify, incluindo a Glossier, a Vuori, a Spanx e a SKIMS. O ACP vive em /.well-known/agentic-commerce e descreve catálogo, preços, impostos, envio e devoluções. Se vende bens e quer que o ChatGPT transacione diretamente, é esta a via.

UCP e MPP: mais leves e mais gerais

Duas opções em fase mais inicial completam a camada, e o verificador trata-as como emergentes e não como padrões assentes. O UCP apoia-se no OAuth: declara âmbitos de comércio como ucp:scopes:checkout_session dentro dos seus metadados OAuth, por isso, se já emite tokens, está a meio caminho. O MPP, anunciado em /.well-known/machine-payments, é o mais geral, descrevendo que carris máquina-a-máquina aceita, de stablecoins a transferências bancárias e medição por token. Nenhum tem o respaldo documentado, de fonte primária, que o MCP, o ACP e o x402 trazem, por isso defina-os a partir da sua própria especificação e observe como se consolidam.

Como ler a pontuação e corrigir as lacunas?

O verificador junta as cinco camadas numa nota ponderada de A a F. Pontuações acima de 85 valem um A, 70 a 84 um B, e as notas mais baixas caem a pique de propósito: um site na faixa do D não anuncia ferramentas, não serve Markdown nem aceita pagamentos de agentes, por isso, para o tráfego orientado por agentes, lê-se como um domínio estacionado. Nas nossas auditorias, a maioria dos sites começa entre 10 e 30.

Camada	Peso
Descobribilidade	15%
Acessibilidade do conteúdo	20%
Controlo de acesso de bots	15%
Descoberta de protocolos	25%
Comércio agêntico	25%

Esse ponto de partida baixo é esperado e é trabalhável. A ferramenta destaca as seis correções de maior alavancagem, e resolver três delas costuma mover um site de F para C dentro de um dia.

Uma ordem prática para corrigir as coisas

Trabalhe as camadas por ordem de dependência, para que cada correção desbloqueie a seguinte.

1. Publique um robots.txt válido com regras User-agent: explícitas para GPTBot, ClaudeBot, Google-Extended e PerplexityBot, mais uma linha Sitemap:. Valide-o com o Robots.txt Validator.
2. Adicione a negociação de conteúdo em Markdown na borda da sua CDN: respeite Accept: text/markdown, defina Vary: Accept, devolva 406 para tipos não suportados.
3. Publique um llms.txt na sua raiz a apontar para as páginas que mais quer que os agentes citem. Gere-o e valide-o com o LLMs.txt Generator + Validator e veja a nossa perspetiva sobre se precisa de llms.txt.
4. Exponha um MCP Server Card mínimo em /.well-known/mcp/server-card.json para que os agentes consigam descobrir as suas ferramentas.
5. Adicione uma diretiva Content Signals ao robots.txt para publicar uma política real de treino versus recuperação.
6. Publique um JWKS de Web Bot Auth para que os agentes verificados consigam assinar pedidos.

Nos sites que passámos pelo verificador, essa sequência corresponde a cerca de dois dias-engenheiro de trabalho numa pilha de CDN e autenticação normal, e move de forma fiável uma origem de F para B. Para confirmar que as suas regras de robots deixam mesmo os crawlers passar, combine isto com o nosso guia sobre como verificar se os crawlers de IA conseguem aceder ao seu site.

FAQ

A prontidão para agentes é diferente de SEO e AEO?

Sim. O SEO afina o posicionamento na pesquisa, e a Answer Engine Optimization afina a forma como os assistentes de conversa o citam. A prontidão para agentes afina se o software consegue, de todo, transacionar com a sua origem: descobrir ferramentas, negociar conteúdo, iniciar sessão e pagar. Uma página pode posicionar-se bem e continuar a ser um beco sem saída para um agente de reservas autónomo.

Que correção dá o retorno mais rápido?

A negociação de conteúdo em Markdown. A maioria dos sites pontua zero em quatro nela, mas um único worker de CDN que respeite Accept: text/markdown, defina Vary: Accept e devolva 406 para tipos não suportados corrige as quatro sondagens numa tarde. A acessibilidade do conteúdo vale 20% da nota, por isso o retorno por hora é elevado.

Preciso de suportar todos os protocolos de comércio?

Não. A camada de comércio agêntico aprova com qualquer padrão isolado, porque «um agente consegue pagar-lhe» é uma capacidade com quatro protocolos a disputar a sua posse. Escolha o que lhe encaixa: x402 para endpoints pagos de baixo compromisso, ACP para checkout de retalho completo, UCP se já emite tokens OAuth.

A que ritmo está mesmo a crescer o tráfego de agentes?

Depressa. Os bots de IA chegaram a 4,2% dos pedidos HTML na rede da Cloudflare em 2025 (Cloudflare Radar, 2025), a fatia de crawling do GPTBot subiu 305% em pedidos brutos de um ano para o outro (Cloudflare, 2025), e as visitas de retalho vindas de fontes de IA generativa subiram 1.200% em oito meses (Adobe, 2025).

Estas verificações vão manter-se iguais para o ano?

Não, e isso não é problema. O MCP vai formalizar a negociação de capacidades, os detalhes de versão do WebMCP ainda estão a mudar, e os protocolos de comércio vão consolidar-se. Acrescentamos sondagens à medida que os padrões assentam e retiramo-las quando se tornam o comportamento por omissão. A forma do problema mantém-se: exponha o que o seu site sabe fazer, de forma clara, nos primeiros pedidos.

O que fazer a seguir

Corra o Agent Protocol Readiness Checker contra a sua página inicial, corrija as três principais recomendações e volte a correr para ver como os agentes passam a tratar a sua origem de forma diferente. As sondagens são gratuitas, correm no navegador e devolvem as provas brutas do servidor por detrás de cada veredito.

A partir daí, dois guias irmãos aprofundam o tema. Leia como verificar se os crawlers de IA conseguem aceder ao seu site para confirmar que as suas regras de robots fazem o que pensa, e o guia completo de Answer Engine Optimization para tornar digno de citação o conteúdo a que esses agentes chegam.