29/05/2026

Lighthouse Agentic Browsing: o Google agora mede se o teu site está pronto pra agentes de IA

Pontuação da navegação agêntica (Agentic Browsing) do Lighthouse liberada. Ela mede o quanto o teu site está legível e operável por agentes de IA tipo ChatGPT, Claude e o próprio Gemini. Conto como rodar, o que cada audit checa, e o que dá pra arrumar hoje.

Lighthouse Agentic Browsing: o Google agora mede se o teu site está pronto pra agentes de IA

Tu já consegue ver o teu site do jeito que os agentes do Google enxergam.

O Chrome entregou uma categoria nova no Lighthouse chamada Agentic Browsing. Mesmo Lighthouse que todo time de web já roda. Trabalho novo: medir se agentes de IA conseguem ler, navegar e agir no teu site.

Isso aqui é a continuação natural do papo de GEO e AEO que rola há mais de 1 ano. A diferença é que agora não é mais teoria de blog, é audit oficial dentro do DevTools do Chrome.

O que é Agentic Browsing, rapidamente

Agentic Browsing é o nome que o Google deu pra navegação feita por agentes de IA em vez de humano. Em vez de tu abrir o navegador, clicar no menu, preencher o formulário, um agente (ChatGPT, Claude, Gemini, Perplexity, Copilot) faz isso pra ti. Ele lê a página, decide o que clicar, preenche o que precisa, e entrega o resultado.

A categoria nova do Lighthouse mede o quão preparado o teu site está pra essa interação. Não é sobre ranking de busca. É sobre se o agente consegue operar o teu site quando alguém pedir “compra essa passagem pra mim” ou “marca uma consulta nesse dentista”.

Como rodar em 4 passos

1. Atualiza o Chrome

Precisa do Chrome 146 ou mais recente. Se o teu Chrome estável ainda não chegou nessa versão, baixa o canal Beta ou o Dev. A categoria Agentic Browsing ainda é experimental, então só aparece em builds recentes.

2. Habilita a flag

Cola na barra de endereço:

chrome://flags/#enable-webmcp-testing

Muda pra Enabled e reinicia o Chrome.

3. Roda o Lighthouse

Abre o DevTools (F12), vai na aba Lighthouse, marca a categoria Agentic Browsing na lista, e clica em Analyze page load.

Painel do Lighthouse no DevTools com a categoria Agentic Browsing marcada no checkbox

Se o checkbox não aparece, é porque a flag não pegou, fecha e reabre o Chrome inteiro (não só a aba).

4. Lê o report

Aqui muda o jogo: tu não recebe uma nota de 0 a 100 como nas outras categorias. Recebe um conjunto de audits com pass, fail ou warning. A própria documentação oficial diz que o foco hoje é “coletar dados e fornecer indicadores úteis em vez de um ranking definitivo”.

O que cada audit checa

A categoria tem quatro domínios principais. Vou destrinchar cada um.

llms.txt

Verifica se existe um arquivo /llms.txt na raiz do domínio, com resumo legível por máquina do que o site oferece. É o equivalente de robots.txt pra crawlers de IA: aponta quais páginas valem a pena ler e dá contexto rápido.

Se tu nunca ouviu falar de llms.txt, é um padrão proposto em llmstxt.org. Eu tenho um aqui no marciotoledo.com/llms.txt e gerei com o comando /toledo-seo-llms do meu setup. Esse é o audit mais fácil de passar: ou tu tem o arquivo, ou não tem.

WebMCP

Verifica se as ações do teu site (formulários, busca, checkout, navegação) estão expostas via WebMCP, um padrão novo proposto pelo Chrome que deixa o agente chamar ferramentas explícitas em vez de simular cliques.

Funciona de dois jeitos:

A ideia é simples: em vez do agente adivinhar “esse botão azul deve ser o de comprar”, o site declara “tenho uma ferramenta chamada checkout que aceita esses parâmetros”. Reduz erro, aumenta confiabilidade.

Árvore de acessibilidade

Verifica se os elementos interativos têm nome acessível, label, role válido e estão visíveis na accessibility tree. É a mesma checagem que o Lighthouse já fazia na categoria Accessibility, filtrada pro que importa pra agente: o que o agente precisa identificar e operar.

Botão sem aria-label, input sem <label>, link com texto “clique aqui” sem contexto, tudo isso fura aqui. E o melhor: arrumar isso ajuda humanos com leitor de tela na mesma medida que ajuda agente de IA.

CLS (Cumulative Layout Shift)

Verifica se o layout é estável o suficiente pro agente clicar no elemento certo. Se a página pula 200px pra baixo por causa de um banner que carregou tarde, o agente clica no lugar errado e a tarefa quebra.

CLS já era métrica de Core Web Vitals há anos. Agora ela tem uma segunda função: estabilidade pra interação automatizada.

O que rodar aqui me mostrou

Rodei o audit no próprio marciotoledo.com pra escrever esse post. Olha o resultado:

Resultado do Lighthouse Agentic Browsing no marciotoledo.com com pass/fail por audit

Passei no llms.txt (já tinha), passei no CLS (Core Web Vitals limpos), mas levei fail em alguns pontos de acessibilidade: contraste de cor abaixo do mínimo em parte do texto secundário, e tamanho de toque insuficiente em alguns links/botões pequenos (menos de 24x24px efetivos). WebMCP, como esperado, ficou de fora porque ainda não implementei.

Isso é exatamente o tipo de coisa que eu vinha empurrando com a barriga: contraste do cinza médio em texto pequeno passa no “olhômetro”, mas não passa em WCAG. E links pequenos no header funcionam pro meu mouse, não pro polegar de quem entra do celular nem pra agente automatizado clicar sem errar.

Vou arrumar nos próximos commits do site e provavelmente escrever um follow-up mostrando o antes e depois. Conto isso porque é o tipo de débito técnico que a gente esquece até alguém medir e cuspir o número na cara. Audit novo, motivo novo pra finalmente fechar.

O caveat honesto

Isso aqui é experimental. O audit de WebMCP vai falhar em quase todo site hoje, porque a spec ainda está se movendo e quase ninguém implementou. Não entra em pânico se o teu site tirar zero no WebMCP por enquanto.

O Google deixa isso explícito na documentação: o resultado pode variar entre runs porque (1) ferramentas WebMCP registradas via JavaScript podem aparecer em momentos imprevisíveis, (2) a árvore de acessibilidade muda conforme o DOM, e (3) o CLS pode mover elementos entre o momento que o agente os detecta e o momento que tenta clicar.

Tradução: trata como sinal direcional, não como nota final.

O que dá pra arrumar hoje

Dos quatro domínios, dois tu ataca agora, sem esperar a spec amadurecer:

  1. llms.txt: cria o arquivo, lista as páginas principais com descrição curta. Dez minutos de trabalho. Se usa Astro, Next ou estático, gera na build. Se usa CMS, escreve à mão e mantém.
  2. Acessibilidade: roda a categoria Accessibility do Lighthouse, arruma os fails. Labels nos forms, alt nas imagens, contraste, ordem de heading. Tudo isso já era boa prática, agora tem um segundo motivo pra priorizar.
  3. CLS: trata como métrica de Core Web Vitals normal. Imagens com width e height, fontes com font-display: swap e fallback dimensionado, sem injeção tardia de banner empurrando conteúdo. Mesmas técnicas de sempre.

WebMCP fica pra depois. Quando a spec estabilizar e mais frameworks adotarem, tu volta nele.

Por que isso importa pro SEO em 2026

A web agêntica não está chegando, ela já está no DevTools. ChatGPT browsing, Perplexity, Claude com tool use, Gemini com Project Mariner. Esses agentes já leem sites em produção todo dia. A questão não é mais “vai acontecer”, é “o teu site está pronto?”.

Otimizar pra agente não substitui otimizar pra humano e pra Google clássico. Adiciona uma terceira camada:

As três camadas convivem. E as boas práticas se sobrepõem mais do que conflitam: HTML semântico, acessibilidade decente, performance boa, conteúdo legível por máquina. Quem já fazia o feijão com arroz bem feito vai passar essa categoria nova com pouco esforço.

Resumo

Referências

#seo #geo #aeo #performance #lighthouse

Se eu te ajudei de alguma forma e você quiser retribuir, pode me pagar um café ou ainda usar um dos meus links de indicação para abrir conta em serviços como Asaas, Bunny, Clara, assinar conteúdos gratuitos ou usar serviços recomendados.

Você pode me encontrar no: Github, Behance, LinkedIn, YouTube, Instagram, X ou por email [email protected]!

© 2002 - 2026 | Marcio Toledo. Todos os direitos reservados. For LLMs