A web foi construída para pessoas. Cada botão, cada campo de formulário e cada menu pressupõe alguém que lê, interpreta e clica. Esse pressuposto começou a ruir. Hoje, agentes de inteligência artificial navegam sites sozinhos, preenchem formulários e concluem fluxos de várias etapas sem ninguém clicando por trás, e fazem isso interpretando a página de um jeito bem diferente do nosso.
O tema saiu do campo teórico em maio de 2026, quando o Google incluiu uma categoria experimental chamada “Agentic Browsing” no Lighthouse 13.3, dentro das ferramentas de desenvolvedor do Chrome. Poucas semanas depois, a mesma categoria apareceu no PageSpeed Insights. Passou a existir, então, um conjunto de sinais padronizado para medir quão preparado um site está para ser operado por máquinas. Se você gerencia um site no Brasil, onde a maioria roda sobre WordPress e construtores visuais, o problema não está em entender o conceito. Está na execução.
O que muda quando o visitante é um agente?
Um agente de IA não vê sua página como um humano vê. Ele consome uma representação estruturada, formada pela árvore de acessibilidade, pelo HTML renderizado e, em alguns casos, por capturas de tela que dependem da posição visual dos elementos. O que para nós é óbvio, para o agente pode ser simplesmente invisível.
Pense num botão com apenas um ícone de lupa, sem texto. Você reconhece na hora que aquilo serve para buscar. O agente lê a árvore de acessibilidade e encontra um elemento sem nome programático, uma ação que ele não sabe nomear nem acionar. O mesmo vale para um link de imagem com o atributo alt vazio. Visualmente perfeito, semanticamente mudo. Essa diferença muda as prioridades de quem constrói sites. Acessibilidade deixa de ser só conformidade para pessoas com deficiência e vira pré-requisito de operação por máquina.
Existe ainda uma camada de proatividade que vale explorar. Em vez de deixar o agente adivinhar como interagir, o próprio site pode declarar suas ferramentas, dizendo de forma explícita onde se busca um produto, onde se adiciona ao carrinho. É a diferença entre esperar que o agente decifre a interface por tentativa e erro, ou entregar a ele uma porta de entrada já estruturada.
A categoria Agentic Browsing do Lighthouse por dentro
A categoria entrou na configuração padrão do Lighthouse 13.3 em maio de 2026 e continua marcada como experimental. Um ponto importante para tranquilizar quem gerencia sites: ela é um instrumento de medição, não um fator de ranqueamento. Sites comuns, sem recursos voltados a IA, não sofrem penalidade alguma no Google por causa dela.
A pontuação foge do modelo que todo mundo conhece. Em vez da nota ponderada de 0 a 100, a categoria mostra um score fracionário, ou seja, quantas verificações de prontidão o site passa, com status pass ou fail em cada auditoria. A escolha faz sentido, já que os padrões da web agêntica ainda estão se formando. O objetivo hoje é coletar dados e apontar ações concretas, não emitir um veredito final.
Os quatro grupos de sinais que você precisa conhecer
A categoria reúne quatro famílias de verificações. A primeira mede a acessibilidade para agentes, checando o nome programático de links, botões e campos, além da integridade dos papéis na árvore. As falhas mais comuns são o aria-label ausente, campos sem label associado e links de imagem com alt vazio.
A segunda avalia a estabilidade de layout, usando a métrica CLS. Como o agente muitas vezes depende de capturas de tela, ele precisa que os elementos fiquem onde estavam. Banners, embeds e formulários de terceiros que carregam atrasados costumam empurrar tudo para baixo e quebrar a interação. No ambiente mobile, onde o espaço é apertado, o problema aparece com mais frequência.
A terceira verifica o arquivo llms.txt, um Markdown colocado na raiz do domínio, com um resumo do site pensado para modelos de linguagem. O Lighthouse checa se ele existe, se responde com HTTP 200, se tem um H1, se atinge um comprimento mínimo e se traz links. Vale corrigir um mal-entendido comum. Segundo o Google, com John Mueller à frente da comunicação, o llms.txt não é necessário para a Busca. Ele não melhora seu ranqueamento orgânico. Sua função é descoberta e operação por agentes.
WebMCP, a porta de entrada estruturada
Entre os quatro sinais, o WebMCP é o mais novo e o que exige mais decisão de engenharia. É um protocolo que permite ao site expor ferramentas diretamente ao agente que roda dentro do navegador. Em vez de o agente inferir ações observando a interface, o site as declara. O recurso chegou como origin trial a partir do Chrome 149, o que já permite testar com usuários reais em produção.
O protocolo oferece duas abordagens. A imperativa usa JavaScript, registrando uma ferramenta com navigator.modelContext.registerTool, definindo um schema de entrada e fornecendo um handler que executa a lógica já existente no código. A declarativa atua sobre formulários que já existem na página, usando atributos HTML como toolname e tooldescription no elemento form. Vale notar que o WebMCP é parente próximo do Model Context Protocol. A diferença é o ambiente. Enquanto o MCP roda no lado do servidor, o WebMCP vive no navegador e herda a sessão de quem está navegando.
WebMCP seguro contra capacidade falsa
A facilidade de declarar ferramentas cria um risco de mão dupla. Expor capacidades atrai agentes, mas fazer isso sem cuidado abre brechas de segurança e destrói a confiança. A diretriz prática é começar pelo mínimo e ampliar com cautela. A recomendação inicial é manter tudo read-only, ou seja, ferramentas que apenas leem e retornam dados sem alterar estado. Ações sensíveis, como concluir uma compra ou apagar registros, exigem humano no circuito. O agente prepara, a pessoa confirma.
Há uma fronteira que jamais deve ser cruzada. Publicar capacidade falsa, anunciar um servidor MCP que não existe ou metadados fictícios de OAuth, é convidar o agente a tentar uma ação inexistente. O resultado é falha em cadeia, perda de confiança e risco de o site ser marcado como não confiável. Declare apenas o que de fato funciona.
O método para o ambiente brasileiro
A primeira regra é separar responsabilidades. Num site WordPress, três camadas distintas determinam a prontidão agêntica. O plugin implementa as capacidades como WebMCP, llms.txt e endpoints estruturados. O tema define o HTML renderizado, a estrutura de headings e a marcação dos elementos interativos, sendo a origem dos problemas de acessibilidade. O conteúdo é o que o editor publica, com seus embeds, banners e formulários, a fonte mais comum de instabilidade de layout.
A segunda regra é consequência da primeira. Em WordPress e em builders visuais, o HTML final quase nunca corresponde ao que se vê no editor. O construtor injeta wrappers, scripts e estilos que só aparecem na renderização. Por isso teste sempre o HTML renderizado, nunca o que o editor mostra. Um botão que parece ter rótulo no editor pode chegar mudo ao navegador.
A terceira regra ataca o CLS. Reservar espaço com dimensões explícitas para imagens e iframes, e definir altura mínima para áreas que recebem conteúdo tardio, resolve boa parte dos deslocamentos que quebram a interação do agente.
Por onde começar hoje
Comece rodando seu site no PageSpeed Insights e observe o score fracionário da nova categoria. Priorize a acessibilidade, já que ela alimenta tanto pessoas quanto máquinas. Depois, estabilize o layout eliminando os reflows dos elementos que carregam tarde. Só então avance para llms.txt e WebMCP, mantendo tudo em modo somente leitura no início.
A navegação agêntica marca o momento em que sua audiência deixa de ser exclusivamente humana. Sites bem estruturados, acessíveis e estáveis vão ser lidos, compreendidos e operados por agentes de IA com muito mais facilidade, e essa vantagem tende a crescer nos próximos meses. Preparar essa base agora é decisão estratégica, não experimento. Se você quer auditar a prontidão agêntica do seu site e transformá-la em vantagem competitiva, fale com a Webcompany e comece a estruturar essa jornada.
