Há anos o PageSpeed Insights avalia desempenho, acessibilidade, práticas recomendadas e SEO. Em 2026, um quinto item entrou discretamente nessa linha: Agentic Browsing. Ele responde a uma pergunta que as outras quatro categorias ignoram: um agente de IA consegue realmente trabalhar com esta página?
Este guia trata de colocar essa verificação para trabalhar no seu site: executá-la, entender o que cada auditoria realmente diz e sair com uma lista de correções.
O que você terá no final
Para quem é: profissionais de SEO, desenvolvedores e responsáveis por sites que querem saber como suas páginas se comportam quando um agente as percorre em vez de uma pessoa.
O que você terá no final: um resultado real de Agentic Browsing para o seu site, uma leitura auditoria por auditoria do que passa, falha ou não se aplica, e uma lista de correções priorizada.
Pré-requisitos: uma URL acessível publicamente, cerca de dez minutos para a primeira execução e acesso ao código se você pretende corrigir no mesmo dia.
Critério de conclusão: você consegue explicar a pontuação fracionária auditoria por auditoria e identificar quais falhas realmente impedem um agente de concluir uma tarefa na sua página.
De onde vem essa verificação e por que agora
A categoria Agentic Browsing não existia há um ano. A implantação aconteceu em três etapas, todas documentadas pelo Google:
- 7 de maio de 2026: o Lighthouse 13.3 adiciona a categoria à configuração padrão, tornando-a parte de uma execução comum.
- 22 de junho de 2026: o blog do Chrome for Developers anuncia a categoria no artigo sobre o kit de ferramentas para deixar seu site pronto para agentes, ao lado das DevTools para agentes e das orientações de WebMCP.
- 20 de julho de 2026: o Lighthouse 13.4.1 habilita a categoria no caminho da API do PageSpeed Insights e afirma que a versão deve chegar ao PageSpeed Insights em até duas semanas. Isso coloca a implantação pública no início de agosto de 2026.
Quando executei a verificação em 11 de setembro de 2026, o rodapé do relatório mostrava uma execução emulada com Lighthouse 13.4.1, e o Agentic Browsing aparecia bem ao lado de SEO. Ou seja, o recurso está no ar, não restrito a um canal experimental. E também está explicitamente inacabado: a descrição da categoria no relatório diz sem rodeios que ela ainda está em desenvolvimento e sujeita a mudanças.
Uma observação prática antes de começar: o PSI executa a categoria por você, do lado do Google. Para as verificações no nível da página não é preciso Chrome 150 nem origin trial. As exigências de versão valem para a execução local no Chrome DevTools.
Execute a verificação no seu próprio site
- Abra pagespeed.web.dev e cole a URL. Rode primeiro no celular e depois repita no desktop, porque as duas execuções de laboratório são pontuadas separadamente.
- Espere os dados de laboratório terminarem. Os dados de campo no topo vêm do Chrome UX Report e carregam rápido. A execução do Lighthouse logo abaixo demora mais, e é onde ficam as categorias.
- Encontre a linha de pontuações. Você verá desempenho, acessibilidade, práticas recomendadas, SEO e, em seguida, Agentic Browsing como uma fração em vez de uma nota de 0 a 100.
- Expanda a categoria. A lista de auditorias se agrupa em Agent Accessibility, WebMCP e os habituais blocos de aprovadas e não aplicáveis.
- Abra cada auditoria que falhou. Cada linha se expande e mostra a regra, o elemento ou o arquivo específico por trás da falha, que é exatamente o que você precisa para abrir um chamado de correção.
A quinta categoria fica na mesma linha das notas que os times de SEO conferem todos os dias. Capturada no PageSpeed Insights em 11 de setembro de 2026.
Verificação de qualidade: confirme a versão do Lighthouse nos detalhes da execução antes de comparar resultados com um colega. O PSI atualiza o Lighthouse no próprio ritmo, e a categoria continua mudando entre versões.
Se falhar: o PSI às vezes devolve um tempo esgotado de RPC em páginas pesadas. Aconteceu comigo em um site grande no meio da pesquisa. Tente de novo ou teste a página no Lighthouse local.
Leia corretamente a pontuação fracionária
O Agentic Browsing não tem pontuação ponderada de 0 a 100, e isso é intencional. A documentação do Lighthouse explica que os padrões da web agêntica ainda estão surgindo, por isso o foco está em sinais acionáveis, não em um ranking.
A aritmética que realmente importa é esta:
Exibição | O que significa |
|---|---|
3/3 | Todas as verificações pontuadas passaram. As não aplicáveis ficam de fora. |
1/3 | Uma passou, duas falharam. O denominador inclui apenas auditorias que passam ou falham. |
0/3 | Nada do que é pontuado passou ainda. Comum na primeira execução em uma página pesada e cheia de anúncios. |
Sem fração | Todas as auditorias eram não aplicáveis ou a categoria não rodou. Confira os detalhes da execução. |
A armadilha é ler 1/3 como “33 por cento pronto para agentes”. Não é porcentagem de nada. É uma contagem: das três verificações que podiam ser pontuadas naquela página, uma passou, e as auditorias que não se aplicavam ficaram totalmente fora da conta. No relatório que capturei, seis auditorias rodaram, três eram não aplicáveis e as três restantes produziram o 1/3.
As pontuações também mudam entre execuções na mesma página. O Lighthouse aponta três causas: registro dinâmico de ferramentas (ferramentas WebMCP registradas via JavaScript podem ser capturadas ou perdidas dependendo do momento), mudanças no DOM que reformulam a árvore de acessibilidade e mudanças de layout causadas por anúncios, imagens sem dimensões ou conteúdo injetado. Se o seu número oscila, geralmente é por isso.
Percorra as seis auditorias
A versão atual do PSI executa seis auditorias. Vem mais uma por aí: o branch de desenvolvimento do Lighthouse já adiciona uma verificação de ai-catalog.json (Agent Resource Discovery) dentro de um novo grupo Agent Discoverability, então trate esta lista como dependente da versão.
Auditoria | O que verifica | O que significa “não aplicável” |
|---|---|---|
A árvore de acessibilidade está incorreta | Um subconjunto de regras de acessibilidade com foco em agentes: nomes e rótulos programáticos, estrutura ARIA válida e elementos que continuam interativos mesmo ocultos da árvore | Nunca; essa sempre pontua |
llms.txt não segue as recomendações | Se | O arquivo retornou 404. A ausência de llms.txt é tratada como opcional, não como falha |
Mudança de layout acumulada | A estabilidade visual, para que agentes que agem pela posição dos elementos não cliquem na coisa errada durante um deslocamento | Nunca; essa sempre pontua |
Ferramentas WebMCP registradas | Se a página registra ferramentas WebMCP pela API declarativa ou imperativa | Nenhuma ferramenta WebMCP foi detectada |
Cobertura de formulários WebMCP | Formulários declarativos sem anotações de ferramentas | Igual ao acima |
Validade dos esquemas WebMCP | Se as ferramentas registradas publicam esquemas de entrada e saída válidos | Igual ao acima |
Visão expandida da categoria: duas falhas, uma aprovação e três verificações não aplicáveis. A lista de falhas é a lista de tarefas mais curta.
As três auditorias WebMCP aparecerem como “não aplicável” é normal em 2026. O WebMCP é um padrão proposto, em origin trial e prévia inicial, com duas APIs: uma declarativa, que anota formulários HTML comuns, e uma imperativa, que registra ferramentas a partir de JavaScript. A maioria dos sites ainda não implementa nenhuma delas, então a maioria dos relatórios mostra três círculos cinza ali. Cinza não é vermelho. Não trate isso como falha.
Corrija o que a verificação sinaliza
Quatro temas de correção cobrem as seis auditorias. As três linhas de WebMCP só exigem atenção se você realmente entrega ferramentas para agentes.
Torne a árvore de acessibilidade legível para agentes
Os agentes usam a árvore de acessibilidade como mapa principal da sua página. Ela lista papéis, nomes e estados. Um botão sem nome acessível é um beco sem saída para eles e também para quem usa leitores de tela.
O que fazer: percorra as regras que falharam na auditoria expandida. Os suspeitos de sempre são botões só com ícone, campos de formulário sem rótulo, links cujo texto é apenas “clique aqui”, combinações inválidas de papéis ARIA e IDs duplicados referenciados por ARIA. Prefira HTML semântico, adicione atributos for aos rótulos e dê a widgets personalizados um papel e um tabindex explícitos quando um elemento nativo não for possível.
Resultado esperado: a auditoria vira aprovada e sua pontuação comum de acessibilidade costuma subir junto, porque a versão do Agentic Browsing é um subconjunto focado das mesmas verificações.
Se travar: quando a lista de correções chega a centenas de elementos, não persiga um por um. Corrija o componente compartilhado, como o botão só com ícone no cabeçalho, e rode de novo. Um componente costuma limpar dezenas de linhas.
Publique um llms.txt que sobrevive à checagem de formato
Aqui há uma armadilha que pega gente cuidadosa. A auditoria não verifica apenas se /llms.txt existe. Ela checa o conteúdo do arquivo, e um arquivo que lista URLs cruas falha, porque a checagem procura links no formato Markdown.
O que fazer: crie /llms.txt no domínio raiz, com um título H1 e links Markdown de verdade:
# Nome da empresa
Descrição curta do que o site cobre e de como ele deve ser usado.
## Páginas principais
- [Visão geral do produto](https://example.com/product)
- [Preços](https://example.com/pricing)
- [Documentação](https://example.com/docs)Resultado esperado: a auditoria fica verde. Um 404, por outro lado, aparece como não aplicável, o que é aceitável hoje. Uma resposta da série 500 ou um erro de busca é falha real e exige correção no servidor.
Verificação de qualidade: busque o seu próprio /llms.txt no terminal e conte os links. Se eles aparecerem como https://example.com/pricing sem colchetes, a auditoria vai falhar mesmo com o arquivo publicado e legível para humanos.
Uma ressalva honesta: o Google Search não usa o llms.txt. O próprio guia de otimização para IA do Google diz que o arquivo “não prejudicará nem ajudará a visibilidade ou o ranqueamento do seu site no Google Search, já que o Google Search os ignora”. Escreva para as ferramentas de agentes que leem essa convenção, não para ranqueamento.
Estabilize o layout para que os agentes possam mirar
Mudanças de layout importam mais do que antes. Um agente que localiza um botão e depois clica nas coordenadas dele vai errar se um anúncio, um banner ou uma imagem de carregamento tardio empurrar esse botão 200 pixels para baixo entre esses dois momentos.
O que fazer: defina largura e altura explícitas (ou aspect-ratio) em imagens e incorporações, reserve espaço fixo para os espaços de anúncio e os banners de consentimento, evite inserir conteúdo acima do conteúdo existente depois do carregamento e anime com transform em vez de propriedades que disparam recálculo de layout.
Resultado esperado: mudança de layout acumulada abaixo de 0,1 na execução de laboratório, o mesmo limite usado pelas Core Web Vitals.
Verificação de qualidade: a seção de desempenho do relatório traz a caixa de causas da mudança de layout e nomeia os elementos exatos. Comece por ali em vez de adivinhar.
Decida sobre o WebMCP mais tarde
As três auditorias WebMCP só pontuam se o seu site registrar ferramentas. Se você tem um fluxo de reserva, checkout, formulário de suporte ou qualquer tarefa estruturada que um agente poderia concluir, o WebMCP vale um protótipo: ele diz ao agente exatamente qual ferramenta chamar em vez de obrigá-lo a adivinhar pelo DOM. O Chrome oferece o recurso atrás de um origin trial e de uma flag de teste local, então é uma opção real, não um exercício mental.
Se você não tem nenhuma tarefa que valha automatizar, deixe o WebMCP em paz. Três círculos cinza não têm nada de errado. A única coisa a não fazer é registrar uma ferramenta decorativa só para a fração parecer melhor. A categoria é um sinal de prontidão, e enganá-la tira o sentido dela.
Verifique a correção
Rode a mesma URL no PSI de novo e compare três coisas, não uma: a fração, o status específico de cada auditoria e o tipo de dispositivo. Uma correção pode mexer na fração sem resolver o que você queria, e celular e desktop produzem resultados de laboratório separados.
Para iterar mais rápido, rode o Lighthouse localmente em vez de esperar o PSI. A categoria está no Lighthouse 13.3 e posteriores, então uma instalação local já a inclui. Se você quiser a versão do painel do DevTools, a documentação do Google observa que testar a categoria exige Chrome 150 ou superior, e as auditorias de WebMCP exigem também o registro no origin trial.
Mantenha um registro curto de antes e depois. Uma linha com data, como “2026-09-11: celular 1/3, falha na árvore de acessibilidade e no llms.txt”, basta. Ela mostra se uma regressão posterior é real ou apenas oscilação entre execuções.
O que esta verificação não é
Três coisas que ela não faz, porque a confusão é generalizada:
- Não é fator de ranqueamento. O anúncio do Chrome descreve a categoria como informativa e fora de benchmarks. O ranqueamento no Google Search não é afetado pela sua fração de Agentic Browsing.
- Não é uma pontuação de visibilidade em IA. Ela mede se um agente consegue operar sua página e não diz nada sobre o ChatGPT ou o Perplexity citarem você em uma resposta.
- Não é um veredito de aprovado ou reprovado sobre o seu site. Uma fração baixa em uma página de marketing simples costuma significar que havia pouco a pontuar, não que os agentes estejam bloqueados.
A leitura que ajuda: esta categoria verifica se o seu site se sustenta quando o visitante não é humano. Tudo o que ela premia vale a pena de qualquer forma: HTML semântico, layouts estáveis, controles rotulados. O próprio guia do Google sobre sites amigáveis a agentes fecha com a mesma ideia: o que deixa um site pronto para agentes também o deixa melhor para pessoas.
Mantenha na sua rotina de revisão
Prontidão para agentes é uma dessas áreas em que a plataforma anda mais rápido que a checklist. Dois hábitos mantêm você atualizado sem virar um projeto:
- Rode a verificação de novo depois de qualquer mudança em template, navegação, formulário ou checkout. São essas edições que movem a árvore de acessibilidade e a estabilidade de layout.
- Acompanhe a fração por template, não por URL. Dez páginas de produto com a mesma pontuação são um problema de template, e uma correção resolve todas as dez.
A verificação do PSI é deliberadamente estreita: seis auditorias, uma página por vez. Se você quer o quadro mais amplo, incluindo se as regras de robots, os cartões de servidor MCP, a descoberta OAuth e os sinais de comércio para agentes estão no lugar, a Auspia mantém uma verificação gratuita de Agent Readiness que escaneia uma URL segundo esses padrões de protocolo e mostra uma tabela comparativa.
Perguntas frequentes
A pontuação de Agentic Browsing afeta o ranqueamento no Google? Não. O Google descreve a categoria como informativa, e ela não faz parte dos sistemas de ranqueamento da busca. Trate-a como uma verificação de prontidão para agentes, não como pontuação de SEO.
Por que minha fração mudou entre duas execuções na mesma página? Registro dinâmico de ferramentas, mudanças no DOM que alteram a árvore de acessibilidade e mudanças de layout tardias causam variação entre execuções. Teste de novo e compare a lista de auditorias, não apenas a fração.
Por que as três auditorias WebMCP aparecem como não aplicáveis? Porque sua página não registra ferramentas WebMCP. Esse é o estado esperado na maioria dos sites em 2026 e não é uma falha.
Um llms.txt ausente é problema? Para esta auditoria, não. Um 404 é tratado como não aplicável. Um arquivo que existe mas está mal formatado falha, então, se você publicar um, publique corretamente.
Posso rodar isso em CI? Sim, assim que a categoria estiver na sua versão do Lighthouse. As auditorias são determinísticas por concepção, e é isso que as torna adequadas para checagens de pipeline. Lembre-se de que as partes de WebMCP dependem de suporte do navegador e de inscrição no origin trial, então espere vê-las como não aplicáveis na maioria dos ambientes de CI.
Preciso do Chrome 150 para usar isso? Não. O PageSpeed Insights executa do lado do servidor. A exigência do Chrome 150 vale para rodar a categoria localmente no DevTools.
Autora: Alice Monroe, analista de ferramentas de AI SEO na Auspia, onde cobre mais de 150 ferramentas. Escreve sobre SEO e ferramentas de busca com IA, sobre quais verificações valem o seu tempo e sobre como encaixá-las na rotina de trabalho.
