O Teu Site Está Pronto para Agentes de IA? Como Atingir o Nível 5 no Scanner da Cloudflare

O Abre-Olhos Técnico: Porque é que Sites “Modernos” Têm Nota 1/5 na Era dos Agentes

Durante os últimos quinze anos, as auditorias técnicas à web seguiram um guião previsível. Corrias o Google Lighthouse, validavas os Core Web Vitals, confirmavas o sitemap.xml, testavas os blocos JSON-LD da Schema.org e verificavas os cabeçalhos de segurança TLS. Se o teu site carregasse em menos de um segundo e passasse nos testes de usabilidade móvel, consideravas a tua infraestrutura exemplar.

Até que a Cloudflare lançou o Is It Agent Ready (isitagentready.com) — e, de um dia para o outro, a régua de avaliação da internet mudou.

Quando colocas o URL de quase qualquer multinacional da Fortune 500, grupo hoteleiro de luxo ou tecnológica em rápido crescimento no scanner de diagnóstico isitagentready.com, o resultado é quase invariavelmente o mesmo: Score: 1/5 (Basic Web Presence). Mesmo sites com pontuação 100/100 no Lighthouse falham entre 18 e 20 das 23 verificações técnicas do scanner.

Porquê? Porque durante três décadas construímos a web exclusivamente para olhos humanos a operar um navegador gráfico. Em 2026, uma fatia crescente do teu tráfego comercial de maior intenção já não é um humano a clicar em cinco menus de navegação. É um agente autónomo de IA — a operar dentro do ChatGPT, Claude, Perplexity, de um copiloto de compras empresariais ou de um assistente integrado no browser — a tentar descobrir as capacidades da tua empresa, verificar a tua identidade, ingerir a tua documentação e executar uma ação em nome de um decisor humano.

No nosso estúdio de engenharia Webxtek e em todo o ecossistema x078, auditámos e atualizámos recentemente dezenas de domínios em produção através das nossas áreas de integrações de IA, websites de alta performance e consultoria técnica, tanto em Cloudflare Workers/Pages como em infraestrutura dedicada HestiaCP Nginx/Apache. Neste artigo técnico, abro-te a arquitetura completa do que o isitagentready.com realmente testa, as armadilhas de protocolo que encontrámos em produção e como preparares o teu site para atingir o Nível 5 (Agent-Native).

Os 5 Níveis de Maturidade de Prontidão para Agentes

O scanner construído sobre a infraestrutura de desenvolvimento da Cloudflare não se limita a procurar palavras-chave; executa negociação de protocolos HTTP em tempo real, inspeção de registos DNS, validação de resumos criptográficos SHA-256 e análise estática de DOM/JavaScript ao longo de 23 especificações distintas:

Para alcançares o Nível 5 (5/5 Agent-Native), não podes tratar a otimização para IA como um exercício de copywriting. Tens de redesenhar a forma como a tua rede edge e o teu servidor de origem respondem a clientes HTTP não-humanos.

Pilar 1: Descoberta e Cabeçalhos HTTP Link na Edge (RFC 8288)

Quando um agente autónomo aterra em https://oteudominio.pt/, não deve ter de adivinhar vinte caminhos de URL diferentes para encontrar a tua documentação ou os teus esquemas de API. Segundo a norma IETF RFC 8288 Web Linking, a resposta HTTP da raiz do teu site deve anunciar diretamente as capacidades legíveis por máquina através do cabeçalho Link:

Link: </.well-known/mcp/server-card.json>; rel="service-desc", </.well-known/agent-skills/index.json>; rel="describedby", </.well-known/api-catalog>; rel="api-catalog", </llms.txt>; rel="service-doc"; type="text/markdown", </sitemap-index.xml>; rel="sitemap"
Vary: Accept

Em simultâneo, o <head> HTML da página de entrada tem de incluir a ligação para o manifesto Agentic Resource Discovery (ARD):

<link rel="ai-catalog" href="/.well-known/ai-catalog.json" />

A Armadilha de Produção em Arquiteturas Multilíngues

Em projetos Astro multilíngues onde a raiz / funciona como um seletor ou redirecionador de idioma para /pt/ ou /en/, é muito comum os programadores adicionarem <link rel="ai-catalog"> nos layouts principais de conteúdo, esquecendo o ficheiro autónomo src/pages/index.astro! Como o isitagentready.com inspeciona exatamente a resposta da raiz /, se omitires essa tag no ponto de entrada falhas de imediato a verificação HTML do catálogo ARD.

Adicionalmente, se o teu domínio publicar registos DNS segundo o draft IETF DNS-AID (draft-ietf-dnsop-svcb-dns-aid) (_index._agents, _a2a._agents, _mcp._agents), tem em atenção que os resolvers validadores exigem que a zona tenha DNSSEC ativo (AD=true) com o registo DS publicado no TLD superior.

Pilar 2: Negociação de Conteúdo Accept: text/markdown

Esta é a melhoria técnica com maior impacto direto em Generative Engine Optimization (GEO).

Uma página empresarial típica pesa entre 80 KB e 350 KB de HTML bruto — repleta de ícones <svg>, classes utilitárias de CSS, mega-menus repetidos, banners de cookies e scripts de hidratação. Alimentar HTML bruto a um LLM desperdiça milhares de tokens em estrutura visual irrelevante.

A especificação llms.txt (llmstxt.org) resolveu parte do problema ao padronizar /llms.txt e /llms-full.txt como mapas em Markdown limpo. Contudo, o isitagentready.com vai mais longe: envia um pedido HTTP GET / à tua página principal com o cabeçalho:

Accept: text/markdown, text/html;q=0.9

Se o teu servidor continuar a devolver Content-Type: text/html, reprovas imediatamente no teste de Conteúdo.

Para passares, o teu worker na edge (em Cloudflare Workers/Pages) ou o teu servidor web de origem (Apache .htaccess / Nginx) tem de inspecionar o cabeçalho Accept. Quando text/markdown é pedido, deve servir dinamicamente a versão Markdown canónica (/llms-full.txt ou o Markdown da rota) acompanhada por três cabeçalhos obrigatórios:

1. Content-Type: text/markdown; charset=utf-8
2. Vary: Accept (garantindo que a CDN nunca entrega Markdown em cache a um utilizador humano no Chrome, nem HTML em cache a um agente de IA)
3. x-markdown-tokens: <estimativa_de_tokens> (permitindo ao agente calcular o orçamento da janela de contexto antes de processar o corpo da resposta)

Em Cloudflare Workers Static Assets, ficheiros estáticos puros não conseguem fazer branching pelo cabeçalho Accept. Resolvemos isto na x078.com ligando um entrypoint leve src/worker.mjs com run_worker_first = true no wrangler.toml, que interseta pedidos Accept: text/markdown na edge da Cloudflare em menos de 0.4ms e devolve o /llms-full.txt com telemetria exata de tokens.

Pilar 3: Controlo de Bots, Content-Signal e a Armadilha da Cache de 10 Anos no Nginx

No /robots.txt, as configurações clássicas de SEO limitam-se a User-agent: * e Sitemap:. Para atingires o Nível 5 de prontidão para agentes, o teu /robots.txt deve declarar permissões explícitas para os crawlers de IA (OAI-SearchBot, ChatGPT-User, PerplexityBot, Claude-SearchBot, Google-Extended, GPTBot, ClaudeBot) e definir sinais de utilização de conteúdo através da diretiva Content-Signal:

User-agent: *
Allow: /
Content-Signal: ai-train=yes, search=yes, ai-input=yes

Sitemap: https://x078.com/sitemap-index.xml
Agentmap: https://x078.com/.well-known/ai-catalog.json

O Bug da Cache de 10 Anos em .txt no HestiaCP / Nginx

Ontem, ao corrigirmos vários servidores de clientes, detetámos um problema subtil de infraestrutura que fazia com que o isitagentready.com continuasse a falhar mesmo depois de o /robots.txt estar atualizado no disco.

Muitos blocos location predefinidos do Nginx para ficheiros estáticos incluem \.(css|js|txt|ico|...)$ com expires max; (Cache-Control: max-age=315360000). Quando a Cloudflare está à frente desse servidor, faz cache do /robots.txt e do /llms.txt na edge durante 10 anos! Quando atualizas o /robots.txt para adicionar o Content-Signal, o scanner continua a receber a versão antiga em cache (CF-Cache-Status: HIT).

A correção definitiva exige dois passos:

• Remover |txt| das regras de cache imutável do Nginx e forçar Cache-Control: no-cache, no-store, must-revalidate em /robots.txt, /llms.txt, /llms-full.txt e /auth.md.
• Publicar um diretório JWKS de Web Bot Auth em /.well-known/http-message-signatures-directory para verificação de assinaturas HTTP (RFC 9421).

Pilar 4: MCP, A2A, Agent Skills, Descoberta OAuth e WebMCP

A maior categoria do benchmark isitagentready.com (API, Auth, MCP & Skill Discovery) avalia se um agente autónomo consegue compreender programaticamente as tuas ferramentas, competências (skills) e políticas de autenticação sem intervenção humana.

Mesmo num website institucional ou de serviços 100% público, o Nível 5 exige uma malha coerente de manifestos .well-known:

1. Catálogo de API (/.well-known/api-catalog — RFC 9727)

Servido obrigatoriamente com Content-Type: application/linkset+json, este manifesto mapeia o endpoint principal de informação para agentes (/api/agent-info) para a respetiva documentação (service-doc $\rightarrow$ /llms-full.txt), descrição técnica (service-desc $\rightarrow$ /.well-known/mcp/server-card.json) e endpoint de estado (status $\rightarrow$ /api/health.json).

2. MCP Server Card (/.well-known/mcp/server-card.json — SEP-1649) e A2A Agent Card (/.well-known/agent-card.json)

Alinhados com o ecossistema Model Context Protocol (modelcontextprotocol.io) e com o protocolo Agent-to-Agent (A2A), estes dois ficheiros declaram a identidade da tua organização, os endpoints de transporte (streamable-http / http-json), os formatos de entrada e saída suportados (text/plain, text/markdown, application/json) e as competências do domínio.

3. Índice de Descoberta de Agent Skills (/.well-known/agent-skills/index.json)

Seguindo a norma Agent Skills Discovery RFC v0.2.0 (agentskills.io), o teu site publica um ficheiro estruturado SKILL.md (em /.well-known/agent-skills/site-guide/SKILL.md) acompanhado por um index.json que contém o resumo criptográfico exato sha256:<hex> desse ficheiro SKILL.md.

Nota Crítica de Engenharia: Força sempre quebras de linha LF (\n) no .gitattributes para o SKILL.md! Se o Git no Windows converter o ficheiro para CRLF antes do deploy, o hash SHA-256 muda e a validação de integridade do scanner falha!

4. auth.md e Descoberta OAuth 2.0 / OIDC (RFC 9728 e RFC 8414)

Os agentes precisam de uma forma determinística de saber como se autenticar — ou de confirmar que o acesso anónimo (read:public) é permitido. Ao publicares /auth.md em conjunto com /.well-known/oauth-protected-resource, /.well-known/oauth-authorization-server e metadados OpenID Connect (openid.net) (/.well-known/openid-configuration) com o bloco agent_auth, os agentes descobrem de imediato a política de acesso público sem erros 401/403. (Dica prática: Nunca envolvas os URLs em backticks de Markdown dentro do /auth.md — vários parsers de expressões regulares capturam acidentalmente o carácter %60 no final do URL ao testar os endpoints!)

5. WebMCP no Browser (document.modelContext.registerTool)

Por fim, para agentes executados diretamente no contexto do navegador do utilizador (em linha com os grupos de trabalho de agentes web do W3C (w3.org)), expor uma ferramenta imperativa via document.modelContext.registerTool({ name: 'get_business_info', ... }) e anotar os formulários <form> com toolname e tooldescription transforma qualquer página numa superfície interativa para agentes.

Testa o Teu Próprio Domínio Hoje

A transição do SEO tradicional para a Engenharia Agent-Native está a acontecer ainda mais depressa do que a transição para o mobile em 2012. Os motores de resposta de IA e os agentes autónomos de compras já privilegiam domínios que negoceiam Markdown limpo, declaram políticas Content-Signal explícitas e publicam manifestos .well-known verificáveis.

Podes testar a https://x078.com — ou o domínio da tua própria empresa — agora mesmo em https://isitagentready.com/. E se a tua infraestrutura ainda estiver retida no Nível 1 (Basic Web Presence), na nossa equipa de engenharia já automatizámos toda a stack de Nível 5 (Agent-Native) tanto para plataformas estáticas na edge como para sistemas empresariais à medida.

Na prática, aplicas exatamente estes padrões operacionais em setores exigentes como ia como serviço e modelos locais e cibersegurança b2b e inteligência corporativa. Quando alinhas a tua estrutura através de automação ai para workflows reais de negócio e websites de alta performance, transformas boas práticas técnicas numa vantagem competitiva real e mensurável para o teu negócio.