Web agent-ready — representações máquina: HTML, Markdown e chrome

Resumo do artigo

• Agentes e crawlers costumam ler DOM, árvore de acessibilidade ou Markdown — não a página "decorada" que um humano vê.
• Negociação de conteúdo (Accept: text/markdown) é um mecanismo HTTP padrão, implementado por várias plataformas — não invenção de um único fornecedor.
• Reduções de HTML para Markdown em casos publicados variam de ~20% a ~99%, mas são exemplos, não médias da web.
• Adoção de negociação de Markdown ainda é rara e nem todo agente pede por ela — meça no seu tráfego antes de investir.

O que um agente realmente lê

Um agente de navegador raramente “vê” a página como um humano vê. Segundo o web.dev, ferramentas de IA operam sobre representações de máquina — screenshot, HTML/DOM bruto e a árvore de acessibilidade — muitas vezes combinadas. A árvore de acessibilidade resume papéis, nomes e estados de cada elemento e ignora o ruído visual do CSS; por isso, o mesmo artigo recomenda HTML interativo semântico (button, a) em vez de div/span decorados, associações de label corretas e leiautes estáveis. [1]

O guia do Google Search Central para recursos de IA generativa reforça esse ponto: HTML semântico é boa prática para humanos e leitores de tela; validade perfeita de HTML não é exigida; e agentes de navegador podem usar screenshot, DOM e árvore de acessibilidade. A própria documentação chama a preparação para agentes de opcional — algo a fazer “se houver tempo extra”, não um requisito. [2]

Como servir uma representação máquina

O mecanismo de base é HTTP comum: content negotiation. O cliente envia um cabeçalho Accept indicando o formato preferido; o servidor escolhe a representação e sinaliza aos caches com Vary, segundo a documentação da MDN. [3] Sobre esse mecanismo, várias plataformas documentam padrões parecidos: a Vercel publica um guia para servir Markdown e HTML na mesma URL via Accept: text/markdown (rewrites + route handler); a Fastly descreve um serviço de borda que entrega HTML a navegadores e Markdown a crawlers de IA conhecidos ou a pedidos explícitos, sempre variando por Accept e User-Agent; e a Cloudflare documenta uma conversão equivalente em nível de zona, removendo cabeçalho, navegação, rodapé e scripts do corpo Markdown e preservando JSON-LD ao final do documento. [4] [5] [6]

Nenhuma dessas implementações é padrão único do setor — são a mesma ideia (content negotiation) aplicada por fornecedores diferentes. Publicar arquivos Markdown estáticos (como /index.md) ou um índice llms.txt é outra estratégia, usada por exemplo na própria documentação Cloudflare Docs for agents — mais simples de operar, mas com risco de o Markdown “descolar” do HTML canônico ao longo do tempo. [7]

Casos publicados: quanto isso pesa

Publishers relatam reduções expressivas de tamanho ao trocar HTML por Markdown — mas são estudos de caso, não uma média medida da web. A Cloudflare citou, em post de blog, um exemplo com cerca de 16.180 tokens em HTML contra 3.150 em Markdown (~80% menos) [8]; a Checkly mediu, na própria documentação, cerca de 615 KB / 180 mil tokens em HTML contra 2,3 KB / 478 tokens em Markdown (~99,6% menos) [9]; e a Fastly descreve, de forma qualitativa, artigos típicos comprimindo para 20–30% do tamanho do HTML original [5].

Negociação de Markdown só ajuda quem pede: a própria Checkly testou sete agentes de código e encontrou apenas três (Claude Code, Cursor e OpenCode) enviando Accept pedindo text/markdown — os outros quatro (Codex, Gemini CLI, GitHub Copilot e Windsurf) não priorizaram Markdown na amostra observada. [9] Um snapshot do Cloudflare Radar, citado no blog de Agent Readiness da própria empresa, mediu que a negociação de Accept: text/markdown passa em apenas 3,9% dos sites de alto tráfego escaneados — um retrato pontual de baixa adoção, não uma linha de base estável. [10]

Chrome, custo e tráfego de bots

O “chrome” da página — menu, rodapé, scripts, decoração — não tem valor semântico para um agente, mas consome tokens de contexto do lado dele e bytes de banda do lado de quem serve o site. Redes de borda relatam volume crescente de tráfego de bots de IA: a Fastly registrou crawlers de IA representando quase 80% do tráfego de bots de IA observado em sua análise de meados de 2025 (com Meta, Google e OpenAI como as maiores fatias), e tráfego de bot automatizado geral em 37% da atividade da própria rede no período; a Akamai relatou crescimento de aproximadamente 300% ano a ano na atividade de bots de IA na sua plataforma. [11] [12]

Reduzir o chrome pode, em tese, reduzir bytes por requisição de bot — mas isso é hipótese operacional, não retorno financeiro comprovado. Sem um estudo público de custo de origem/egress medido antes e depois de uma mudança de representação, o conselho prático é medir bytes, status e user-agent nos próprios logs antes de prometer economia.

llms.txt: índice ou vitrine

llms.txt funciona como um índice no estilo sitemap, pensado para ferramentas que já o consomem — é assim que a própria Cloudflare o descreve. [10] Mas o guia oficial do Google Search Central lista llms.txt e markup especial de IA entre os equívocos a evitar: não é requisito para aparecer em recursos de IA generativa no Search. [2] Um estudo da Ahrefs, analisando cerca de 137 mil domínios, encontrou que 28% publicavam um llms.txt válido, mas 97% desses arquivos não receberam nenhuma requisição no mês medido — e, dos que receberam tráfego, 96% das requisições vieram de bots, não de leitura editorial. [13]

Isso não prova que llms.txt seja inútil para sempre; prova que, hoje, publicá-lo raramente muda alguma coisa observável. Trate como conveniência opcional para ferramentas que já consomem o formato — não como entregável prioritário.

Incertezas

• Não há estudo público que isole o efeito de conformidade com acessibilidade (WCAG) no sucesso de tarefas de agentes, fora do argumento qualitativo do Google/web.dev.
• Não se sabe quais agentes e crawlers vão enviar Accept: text/markdown de forma estável — a amostra Checkly (3 de 7) é um retrato pontual.
• Não existem dados operacionais publicados sobre o custo real de manter uma árvore Markdown estática paralela ao HTML, incluindo risco de desalinhamento.
• Não existe um estudo de caso público medindo economia de banda ou origem em valores concretos, antes e depois de servir Markdown negociado para bots.

Referências

1. web.dev — Build agent-friendly websites. web.dev. Acesso em 07 ago. 2026.
2. Google Search Central — Optimizing your website for generative AI features on Google Search. Google. Acesso em 07 ago. 2026.
3. MDN — Content negotiation. MDN. Acesso em 07 ago. 2026.
4. Vercel — How to serve documentation for agents. Vercel. Acesso em 07 ago. 2026.
5. Fastly — Give AI Agents the Markdown They Actually Want. Fastly. Acesso em 07 ago. 2026.
6. Cloudflare — Markdown for Agents (docs). Cloudflare. Acesso em 07 ago. 2026.
7. Cloudflare — Docs for agents. Cloudflare. Acesso em 07 ago. 2026.
8. Cloudflare — Introducing Markdown for Agents. Cloudflare. Acesso em 07 ago. 2026.
9. Checkly — The Current State of Content Negotiation for AI Agents. Checkly. Acesso em 07 ago. 2026.
10. Cloudflare — Introducing the Agent Readiness score. Cloudflare. Acesso em 07 ago. 2026.
11. Fastly — New Fastly threat research reveals AI crawlers make up almost 80% of AI bot traffic. Fastly. Acesso em 07 ago. 2026.
12. Akamai — AI Bots Threaten Foundation of Web-Based Business Models. Akamai. Acesso em 07 ago. 2026.
13. Ahrefs — We Analyzed 137K Sites: 97% of llms.txt Files Never Get Read. Ahrefs. Acesso em 07 ago. 2026.