Navegação agêntica no Lighthouse: como preparar sites para agentes de IA

Por Alisson Lima 29 de julho de 2026 11 minutos de leitura

Agentes de IA precisam compreender interfaces e executar ações. Veja como o Lighthouse avalia acessibilidade, CLS, llms.txt e WebMCP.

Imagem com fundo roxo e texto: Agentic Browsers, llms.txt, webmcp, lighthouse

Agentes de IA podem fazer mais do que resumir uma página ou responder perguntas sobre ela. Em alguns contextos, precisam reconhecer a estrutura de uma interface, encontrar uma ação, preencher um campo e concluir um fluxo com segurança.

Para esse cenário, o Chrome adicionou ao Lighthouse uma categoria experimental chamada Navegação Agêntica (Agentic Browsing). Ela reúne auditorias que ajudam a verificar se uma página oferece sinais estruturais úteis para interação por máquinas.

Não se trata de uma nova métrica de SEO, nem de uma forma de prever se um site aparecerá em respostas de IA. Também não certifica que qualquer agente conseguirá concluir qualquer tarefa. O objetivo é mais específico: observar fundamentos técnicos que tornam uma interface mais compreensível e confiável.

Como as peças se encaixam

Antes de falar em llms.txt e WebMCP, vale separar seus papéis:

HTML semântico e acessibilidade: dão significado a links, botões, campos e estados. São fundamentos de uma boa experiência web.
Estabilidade visual (CLS): evita que elementos mudem de lugar durante uma interação. Também é uma boa prática essencial.
llms.txt: oferece um resumo editorial e links relevantes do site. É opcional.
WebMCP: expõe ações estruturadas da página para agentes. Também é opcional.
Navegação agêntica no Lighthouse: audita alguns desses sinais. A categoria é experimental.

Em outras palavras: llms.txt ajuda um agente a se situar no site; WebMCP pode ajudá-lo a executar uma ação específica; HTML semântico e um layout estável tornam a interface existente mais utilizável. A auditoria do Lighthouse observa esses fundamentos, mas não exige que todos estejam presentes em todos os projetos.

O que muda quando um agente navega por uma interface?

Um crawler tradicional (programa automatizado que percorre páginas e links para coletar conteúdo) extrai informações para indexação. Ele não precisa necessariamente distinguir um botão de confirmação de uma ação destrutiva, nem preencher um formulário.

Um agente que executa tarefas enfrenta outro problema. Ele pode precisar encontrar um botão, diferenciar um link de uma ação que gera cobrança, manter contexto enquanto a tela muda e recuperar-se de um erro ou cancelamento.

Por isso, a qualidade da interface importa. Estrutura semântica, nomes claros, fluxos por teclado e estabilidade visual já ajudam pessoas usuárias e tecnologias assistivas. Esses mesmos sinais também oferecem uma base mais previsível para sistemas automatizados.

O que a auditoria de navegação agêntica avalia?

A categoria é experimental e não usa a pontuação tradicional de 0 a 100 do Lighthouse. O relatório mostra uma proporção de verificações aprovadas, estados de aprovação ou reprovação e sinais informativos.

As auditorias se concentram em quatro frentes:

Descoberta de conteúdo, incluindo llms.txt.
Acessibilidade útil para interação.
Estabilidade visual medida por Cumulative Layout Shift (CLS).
Integração com WebMCP, quando o site declara ferramentas para agentes.

As regras das auditorias são determinísticas, mas o resultado ainda pode variar em situações como registros dinâmicos de ferramentas ou mudanças relevantes na árvore de acessibilidade durante o carregamento.

Comece pela base: HTML semântico e acessibilidade

A árvore de acessibilidade representa a interface por meio de funções, nomes, estados e relações entre elementos. Ela permite que leitores de tela compreendam uma página sem depender apenas da aparência visual e é um dos sinais estruturais mais úteis para agentes.

Um link com texto claro, um botão nomeado corretamente e um formulário com rótulos associados oferecem mais contexto do que elementos genéricos manipulados apenas com JavaScript.

Boas práticas essenciais:

Usar elementos nativos como button, a, nav, main e form.
Manter hierarquia lógica de títulos, de h1 a h6.
Escrever nomes claros para links e botões.
Associar cada label ao respectivo campo.
Preferir HTML nativo antes de adicionar ARIA.
Garantir o funcionamento por teclado nos fluxos importantes.

html

<nav aria-label="Navegação principal">
  <a href="/projetos">Ver projetos</a>
  <a href="/contato">Entrar em contato</a>
</nav>

O exemplo é simples, mas comunica explicitamente o que cada elemento faz. Essa clareza beneficia diferentes formas de navegação.

Evite mudanças inesperadas de layout

O CLS mede quanto os elementos se movem inesperadamente durante o carregamento. Imagens sem dimensões definidas, banners inseridos tarde, fontes que alteram o tamanho do texto e conteúdo assíncrono sem espaço reservado são causas comuns de instabilidade.

Para uma pessoa, isso pode causar um clique acidental. Para um agente que identificou um elemento antes de a página terminar de carregar, a mudança de posição pode tornar a interação pouco confiável.

Algumas medidas práticas:

Declarar largura e altura de imagens.
Reservar espaço para conteúdo carregado depois.
Evitar inserir avisos e banners acima de conteúdo já renderizado.
Usar placeholders próximos ao tamanho final.
Revisar fontes e animações que mudem tamanho ou posição.

html

<img src="/assets/capa.webp"
     alt="Interface de um sistema web"
     width="1200" height="630">

Use llms.txt como complemento

O arquivo llms.txt é uma convenção emergente para oferecer um resumo legível por máquina sobre a finalidade de um site e suas principais URLs. Quando utilizado, deve ficar na raiz do domínio, como em https://exemplo.com/llms.txt.

Ele pode ajudar um agente a entender mais rapidamente a estrutura geral de um site. Ainda assim, não substitui HTML semântico, sitemap.xml, robots.txt, dados estruturados ou conteúdo bem organizado.

Também é importante destacar que o llms.txt é opcional e não faz milagre. Ele não garante indexação, não obriga agentes a consumirem seu conteúdo e não é um fator oficial de ranking do Google.

markdown

# Nome do site

Resumo objetivo sobre a finalidade do site.

## Páginas principais

- [Produtos](https://exemplo.com/produtos): catálogo e detalhes.
- [Documentação](https://exemplo.com/docs): guias técnicos.

O objetivo é facilitar a descoberta das páginas mais importantes, não duplicar o sitemap inteiro.

Onde o WebMCP entra?

WebMCP é uma tecnologia web experimental para que uma página exponha ferramentas estruturadas a agentes executados no navegador. Em vez de depender exclusivamente de cliques, leitura do DOM e interpretação visual, o site pode declarar uma ação com nome, descrição, parâmetros e resultado esperado.

Ele não é uma versão mais avançada de llms.txt:

llms.txt descreve o site e suas páginas.
WebMCP descreve ações que um agente pode executar naquela página.

Pode fazer sentido para agendamento, consulta de disponibilidade, busca em catálogo, formulários com várias etapas, checkout e áreas autenticadas com fluxos previsíveis.

Um blog, uma landing page ou um site institucional geralmente não precisa expor ferramentas adicionais. WebMCP deve responder a um caso de uso real, e não existir apenas para melhorar uma auditoria.

Exemplo: expondo uma busca de catálogo

Neste exemplo, a página registra uma ferramenta chamada search_catalog. Um agente compatível pode descobrir a ação, saber quais parâmetros ela aceita e executá-la sem percorrer visualmente todo o catálogo.

javascript

async function registerCatalogTool() {
  if (!('modelContext' in document)) return;

  await document.modelContext.registerTool({
    name: 'search_catalog',
    description: 'Busca produtos pelo termo informado.',
    inputSchema: {
      type: 'object',
      properties: {
        query: { type: 'string', description: 'Termo de busca.' },
      },
      required: ['query'],
      additionalProperties: false,
    },
    execute: async ({ query }) => {
      if (typeof query !== 'string' || !query.trim()) {
        throw new Error('Informe um termo de busca válido.');
      }

      return JSON.stringify(await searchCatalog(query.trim()));
    },
  });
}

registerCatalogTool().catch(console.error);

O schema ajuda o agente a formar a chamada corretamente, mas não substitui validação. A função searchCatalog e a API que ela usa precisam validar permissões, regras de negócio e dados sensíveis no servidor.

Para testar a categoria de navegação agêntica, é necessário Chrome 150 ou superior. As auditorias específicas de WebMCP também exigem participação no origin trial correspondente.

Segurança ao expor ações para agentes

Tornar uma ação compreensível para um agente não deve torná-la executável sem controles. Isso é especialmente importante em áreas autenticadas, operações financeiras, alterações de dados ou ações difíceis de desfazer.

Ao expor ações para agentes, considere:

Exigir confirmação explícita antes de ações destrutivas, irreversíveis ou que gerem cobrança.
Aplicar autenticação forte e autorização de menor privilégio.
Delimitar claramente escopo e parâmetros aceitos.
Validar dados e permissões no servidor.
Proteger fluxos contra CSRF, abuso e automação indevida.
Tratar conteúdo não confiável como dado, reduzindo riscos de prompt injection.
Manter registros de auditoria, limites de uso e meios de revisão ou reversão.
Testar sucesso, erro, expiração de sessão, confirmação, cancelamento e recuperação.

Uma boa pontuação no Lighthouse não mede esses controles nem comprova que um agente compreenderá regras de negócio, permissões ou exceções de um fluxo real.

O que essa auditoria não resolve

A navegação agêntica do Lighthouse não garante melhor posição no Google, citação por assistentes de IA ou sucesso de ponta a ponta em qualquer agente. Ela também não substitui SEO técnico, performance, testes de usabilidade, testes de fluxo ou revisão de segurança.

O valor está em apontar fundamentos verificáveis de clareza estrutural, acessibilidade e estabilidade.

Checklist de implementação

A página usa HTML semântico e elementos nativos quando possível?
Links, botões e campos têm nomes claros?
Fluxos importantes funcionam por teclado?
Elementos interativos aparecem na árvore de acessibilidade?
O CLS está sob controle?
Existe um llms.txt conciso na raiz do domínio, quando fizer sentido?
WebMCP foi considerado apenas para uma ação concreta?
Ações sensíveis exigem confirmação, autorização e validação no servidor?
Cenários de erro, cancelamento e recuperação foram testados?
Há registros e limites para investigar ou conter ações automatizadas?

Conclusão

Preparar um site para navegação agêntica não depende de um truque ou de uma única tecnologia. O ponto de partida é boa engenharia web: semântica correta, acessibilidade consistente, layout estável, conteúdo claro e fluxos bem definidos.

llms.txt pode melhorar a descoberta de conteúdo. WebMCP pode ser útil para produtos com ações complexas e previsíveis. Nenhum deles substitui os fundamentos — e nenhum deve ser adotado apenas para obter uma auditoria positiva.

Como a categoria do Lighthouse e o próprio WebMCP ainda são experimentais, a abordagem prudente é aplicar primeiro as práticas que já beneficiam todas as pessoas usuárias e adicionar integrações específicas para agentes apenas quando houver um caso de uso concreto e controles compatíveis com o risco da operação.