Agentes de IA veem seu site por três caminhos: 1) captura de tela interpretada por visão computacional (como o Computer Use da Anthropic; caro e sensível a layout); 2) HTML bruto (o DOM, com hierarquia e atributos); 3) árvore de acessibilidade (o resumo semântico com papéis, nomes e estados, derivado do HTML). Agentes modernos combinam os três, e a tendência do mercado é convergir para a árvore de acessibilidade. O que os faz desistir: div clicável sem nome acessível, input sem label, hierarquia de títulos quebrada, página que só existe via JavaScript e conteúdo crítico escondido em abas. Corrigir isso melhora agentes, leitores de tela e SEO ao mesmo tempo.
As 3 formas de percepção (e o híbrido que venceu)
Visão: o agente tira uma captura de tela e um modelo de visão computacional identifica botões, campos e textos por cor, tamanho e posição. É o caminho do Computer Use da Anthropic e do Project Mariner do Google (que atingiu 83,5% no benchmark WebVoyager). Funciona com qualquer site, mas custa caro em processamento e tokens, e quebra com mudanças visuais pequenas.
HTML bruto (DOM): o agente lê o código da página: hierarquia, atributos, estrutura. É rápido e barato, e a inferência é contextual (um botão dentro do card de um produto pertence àquele produto). O problema: um DOM inteiro estoura a janela de contexto dos modelos, exigindo poda e filtros.
Árvore de acessibilidade: o navegador deriva do HTML uma versão simplificada da página: só o que importa para interação, com papéis (botão, link, campo), nomes acessíveis e estados (expandido, desabilitado). É o mapa que os leitores de tela usam há décadas. O Playwright MCP da Microsoft já entrega aos agentes esse snapshot em vez de capturas; o navegador da Perplexity (Comet) descreve seu método como "snapshots de árvore de acessibilidade com visão seletiva".
O estado da arte é híbrido: DOM e árvore como caminho principal, visão para resolver ambiguidade. Nenhuma modalidade isolada fecha todas as lacunas semânticas, como mostra o teste clássico: um <div> estilizado como botão parece um botão na captura, mas não existe como botão na árvore.
O experimento que mede o custo do site ruim
Um estudo da UC Berkeley e Michigan (CHI 2026, com 158.325 eventos de uso real) mediu o Claude Sonnet 4.5 em 60 tarefas sob três condições, e os números expõem o tamanho do problema:
| Condição | Taxa de sucesso | Tempo médio |
|---|---|---|
| Interface padrão (mouse e tela normais) | 78,33% | ~325 s |
| Somente teclado | 41,67% | ~651 s |
| Viewport ampliado (zoom) | 28,33% | ~1.072 s |
Tradução: o mesmo agente, no mesmo site, cai de 78% para 28% de sucesso quando a interface muda. Cada lacuna de acessibilidade tem preço em tempo e em tarefa abandonada: as lacunas mapeadas foram de percepção (estados não declarados), cognição (manter o contexto entre etapas) e ação (atalhos e arrastar-e-soltar).
Os erros que travam agentes no meio da jornada
<div onclick>sem papel e sem nome: parece botão no visual, não existe como botão na árvore: o agente não reconhece como clicável.- Inputs sem
<label>e sem autocomplete: o agente não sabe o que digitar em cada campo, e o preenchimento automático morre. - Hierarquia de títulos quebrada: pular níveis de h1 a h6 confunde a leitura estrutural (para agente e para SEO).
- Página que só existe com JavaScript: o conteúdo renderizado só no cliente aparece como casca vazia (
<div id="root">) para robôs que não executam script, incluindo crawlers de IA como PerplexityBot e ClaudeBot. - Conteúdo crítico escondido em abas e acordeões: preços e especificações dentro de containers ocultos podem simplesmente não entrar no snapshot.
- Rotas falsas: links com
onClicksem URL real quebram a navegação e o compartilhamento. - ARIA mal usado: o paradoxo documentado pelo WebAIM: sites que usam ARIA tendem a ser menos acessíveis que os que usam HTML nativo, porque ARIA errado é pior que ARIA nenhum. E encher
aria-labelde palavra-chave é a nova forma de stuffing: os motores e os agentes percebem.
1) HTML nativo primeiro: <button>, <a href>, <select> no lugar de divs programados. 2) Label e autocomplete em todo input. 3) Conteúdo no HTML servido (renderização no servidor para páginas de conteúdo: o guia de site bloqueando a IA cobre o diagnóstico). 4) Landmarks corretos (<nav>, <main>, <footer>). 5) Hierarquia de títulos limpa. Só depois disso entre em ARIA para estados dinâmicos (aria-expanded, aria-controls).
Como testar o que os agentes veem
O melhor proxy é gratuito: abra seu site com um leitor de tela (VoiceOver no Mac, NVDA no Windows). Agentes e leitores de tela consomem a mesma árvore de acessibilidade: o que o leitor não anuncia, o agente não vê. O segundo passo é o navegador só de texto (Lynx), que mostra o parse sem o visual. E o terceiro é instrumentar: ferramentas como o Playwright MCP expõem exatamente o snapshot que agentes consomem. Se quiser a leitura rápida do lado de robôs de indexação e citação, rode o verificador de visibilidade em IA.
Agentes, acessibilidade e SEO: o mesmo conserto
A conclusão das três fontes que fundamentam este guia converge: tudo que torna um site operável por agentes melhora o site para humanos, para leitores de tela e para buscadores. Não é uma otimização nova na lista: é a volta aos fundamentos de HTML semântico, estados claros e conteúdo real no HTML, que o SEO técnico cobra desde sempre. A auditoria de SEO técnico da M&C cobre exatamente essa camada.