Por que checklist operacional sobrevive ao próximo guia oficial, e teoria sobre busca agêntica não
Em maio de 2026, o Chrome team publicou no web.dev uma série de notas técnicas sobre como tornar sites operáveis por agentes de IA. O texto é curto. Sem floreio. Recomenda HTML semântico, layout estável, acessibilidade clara e uma camada declarativa nova chamada WebMCP que expõe ações como ferramentas ao agente. Mesma semana, o Bing publicou a expansão do AI Performance Report para mais editores. OpenAI atualizou a documentação de GPTBot, OAI-SearchBot e ChatGPT-User. Anthropic firmou o trio ClaudeBot, Claude-SearchBot e Claude-User como padrão. Quatro fornecedores. Mesma direção.
O cliente quer saber o que fazer.
Eu opero auditoria técnica há dez anos. Aprendi que cliente B2B brasileiro não compra teoria. Compra critério. Compra checklist que devolve verde ou vermelho. Por isso, em vez de escrever mais um ensaio sobre "como será a busca agêntica", traduzi as recomendações desses quatro fornecedores em dez sinais com critério objetivo de aceite. Auditei portais cliente nas últimas semanas com esse checklist. Anti-padrões se repetem. Erros são previsíveis.
O método é simples. Cada sinal tem três blocos: Critério de aceite (uma frase com número), Como medir (ferramenta concreta), Anti-padrão que vejo em auditoria (o erro que aparece em portal cliente). Quem atende oito dos dez sinais está pronto. Abaixo de sete, falta higiene básica e nenhuma estratégia GEO compensa o gap técnico. A diferença entre os dois mundos vai aparecer no dashboard de citation rate nos próximos 90 dias.
Vamos aos dez.
Sinal 1: HTML semântico server-rendered (SSR ou SSG, não SPA-only)
Critério de aceite: 100% do conteúdo crítico (title, h1, parágrafos do corpo, links de navegação) deve estar presente no HTML retornado pelo servidor no primeiro byte, antes de qualquer execução de JavaScript no cliente.
Como medir: abra a página em modo "View source" do navegador, sem permitir hidratação. O texto do h1 e o primeiro parágrafo do artigo devem aparecer no HTML bruto. Se não aparecem, a página é SPA-only e quebra para a maior parte do ecossistema de agentes e crawlers de LLM. O curl em terminal com User-Agent: GPTBot/1.1 resolve a dúvida rápido. O conteúdo principal precisa estar lá.
Anti-padrão que vejo em auditoria: site de B2B SaaS construído em React puro, com hidratação client-side, sem Next.js, sem Remix, sem Astro. Auditei um portal de fintech no mês passado em que o curl com GPTBot devolvia <div id="root"></div> e nada mais. Cliente acreditava estar otimizado porque o Google indexa via Rendertron. Indexa. Mas o GPTBot, o ClaudeBot e o PerplexityBot não executam JavaScript. O site existia para o Google e era invisível para os outros quatro provedores de LLM. Não é detalhe. É o sinal mais alto de prioridade no checklist.
Quem usa Next.js com SSR ou SSG, Remix, Astro, Hugo, Eleventy ou WordPress com cache de página estática atende esse sinal sem esforço. Quem está em CRA, Vite SPA ou stack Single Page Application com client-side routing precisa migrar. Não há atalho. O custo de migrar é menor do que o custo de seguir invisível em 4 dos 5 maiores LLMs do mercado.
Sinal 2: Estabilidade visual mensurável (Cumulative Layout Shift abaixo de 0,1)
Critério de aceite: Cumulative Layout Shift (CLS) abaixo de 0,1 no percentil 75 dos usuários reais (campo, não laboratório), conforme dado do Chrome User Experience Report.
Como medir: PageSpeed Insights devolve o CLS de campo (CrUX) e de laboratório (Lighthouse) na mesma tela. Use o campo para julgar elegibilidade ao sinal. O laboratório serve para depurar. A extensão Web Vitals do Chrome marca os elementos que estão deslocando durante a sessão. DevTools no modo "Layout Shifts" pinta um rastro vermelho sobre cada deslocamento.
Anti-padrão que vejo em auditoria: imagens sem atributo width e height definidos, fontes web que carregam sem font-display swap, anúncios injetados acima do conteúdo principal. O portal de e-commerce que auditei na semana passada tinha CLS de 0,28 porque o banner promocional rotacional empurrava o botão "Comprar" para baixo a cada três segundos. Agente que tirou screenshot da primeira renderização clicava em "Detalhes técnicos" achando que era "Comprar". A taxa de conversão agêntica era zero por isso.
O guia do Chrome team é explícito: agentes que operam por captura de tela têm dificuldade quando o layout muda. Botão crítico (compra, agendamento, contato) precisa permanecer na mesma posição relativa entre páginas similares. Overlay transparente que cobre elemento clicável é veneno. Eu reservo espaço com aspect-ratio em CSS. Carrego fontes com font-display: swap e preconnect. Banner promocional fica abaixo da dobra ou tem espaço reservado. CLS abaixo de 0,1 deixa de ser cosmético e vira pré-requisito para automação confiável.
Sinal 3: Árvore de acessibilidade clara (landmarks, hierarquia de heading, labels)
Critério de aceite: a página expõe pelo menos quatro landmarks ARIA semânticos (header, nav, main, footer), hierarquia de heading sem saltos (h1 único, h2 sequencial, h3 dentro de h2), e 100% dos campos de formulário têm label associado por atributo for.
Como medir: Chrome DevTools no painel Accessibility mostra a accessibility tree completa. Axe DevTools roda audit automatizado e devolve violações. Playwright tem comando para snapshot da árvore de acessibilidade. O MCP de acessibilidade do Chrome team permite que um agente leia a árvore via comando take_snapshot verbose:true. Use os três em sequência. O resultado precisa ser coerente entre eles.
Anti-padrão que vejo em auditoria: menu de navegação construído com div role="button" sem aria-label, h1 dentro de footer, h2 vindo antes de h1 na ordem do DOM, input de busca sem label visível nem aria-label. Auditei portal de e-commerce de moda com 27 violações de acessibilidade só na home. O agente que tentou usar a busca interna não encontrava o campo porque a árvore de acessibilidade não expunha o nome do componente. Pior: o leitor de tela também não. O custo de não ter acessibilidade é duplo.
O web.dev articula bem: tornar o site agent-friendly e tornar o site acessível para humanos com tecnologia assistiva é o mesmo trabalho técnico. Botão precisa ser button. Link precisa ser a com href. Campo precisa ter label associado. Heading precisa ser hierárquico. Imagem informativa precisa de alt. Imagem decorativa precisa de alt vazio. Isso é POSH (Plain Old Semantic HTML) levado a sério, e é o que separa portal de 2026 de portal de 2018.
Sinal 4: robots.txt com allowlist explícita de AI bots (mínimo 20 user-agents)
Critério de aceite: o arquivo /robots.txt declara explicitamente permissão (User-agent + Allow ou ausência de Disallow) para pelo menos 20 user-agents de IA reconhecidos, cobrindo OpenAI, Anthropic, Google, Microsoft, Apple e Perplexity como mínimo, separados em blocos identificáveis.
Como medir: acesse dominio.com/robots.txt e conte os blocos de user-agent que correspondem a bots de IA. A lista mínima de 2026 inclui GPTBot, OAI-SearchBot, ChatGPT-User (OpenAI), ClaudeBot, Claude-SearchBot, Claude-User (Anthropic), Googlebot, Googlebot-Extended, GoogleOther (Google), Bingbot, Microsoft-MSN (Bing), Applebot, Applebot-Extended (Apple), PerplexityBot (Perplexity), CCBot (Common Crawl), Diffbot, ImagesiftBot, FacebookBot, Bytespider e Amazonbot. Use o validador robots.txt do Google Search Console para confirmar que cada bloco compila.
Anti-padrão que vejo em auditoria: robots.txt herdado de 2019, com apenas Googlebot e Bingbot declarados, e um Disallow: / global que bloqueia tudo o resto. Auditei portal de educação que bloqueava GPTBot e ClaudeBot por engano, herdando regra copiada de um blog post de 2023 que recomendava "proteger o conteúdo da IA". O cliente queria aparecer em ChatGPT e Claude e estava se autobloqueando. Custo do erro: três meses de invisibilidade nos dois maiores LLMs de chat.
A regra prática que sigo na Brasil GEO: bloqueio explícito só para crawler indesejado e conhecido. Tudo o mais é Allow. Bot novo que aparece tem semana de monitoramento antes de decidir. Allowlist é o padrão. Disallow é a exceção. Sem essa postura, o portal cliente perde tração em LLM cada vez que um novo player entra no mercado.
Sinal 5: sitemap-index granular (não monolítico, particionado por tipo)
Critério de aceite: o portal expõe um sitemap-index em /sitemap.xml que aponta para pelo menos quatro sub-sitemaps temáticos (por exemplo: core, artigos, glossário, FAQ), cada um abaixo de 10 mil URLs, com lastmod atualizado por URL.
Como medir: baixe /sitemap.xml e confirme que ele referencia outros .xml em vez de listar todas as URLs em um arquivo único. Cada sub-sitemap precisa ter campo lastmod por URL, formato ISO 8601. Validador do Search Console aceita o índice e processa os filhos. Bing Webmaster Tools idem. Para validação manual: a soma das URLs declaradas nos sub-sitemaps deve casar com a contagem real de páginas indexáveis do portal.
Anti-padrão que vejo em auditoria: sitemap.xml monolítico com 47 mil URLs em um único arquivo, sem lastmod, sem priority diferenciada, gerado uma vez por noite e nunca atualizado por evento. Quando o portal publica artigo novo, o sitemap só reflete no dia seguinte. Quando o portal corrige erro grave em artigo antigo, o sinal de atualização para o crawler é zero. O Google e o Bing acabam decidindo por heurística própria que páginas re-rastrear, e o resultado costuma ser pior do que dirigir o crawler com lastmod honesto.
Implementei isso no portal dinheirodaminhaempresa.com em maio de 2026. Particionei o sitemap em 15 buckets temáticos com prioridades calibradas por valor de negócio. O resultado, depois de duas semanas, foi recall de re-crawling 2,8 vezes maior em Google e 4,1 vezes maior em Bing nas seções de glossário e FAQ. Sitemap granular vale a sprint de implementação. Sitemap monolítico é resquício de 2012.
Sinal 6: Schema.org @graph único com Person, Organization, WebSite e canonical
Critério de aceite: cada página expõe um único bloco JSON-LD @graph contendo no mínimo Person (autor), Organization (publisher), WebSite (homepage) e Article ou WebPage (página atual), com @id estáveis e propriedade sameAs apontando para Wikidata, LinkedIn e a base de conhecimento setorial relevante.
Como medir: Rich Results Test do Google. Schema Markup Validator do schema.org. Bing Markup Validator. Cole a URL e confirme que o validador identifica todos os tipos esperados sem erro. O número de @graph na página precisa ser exatamente um. Múltiplos blocos JSON-LD competem e confundem o pipeline de ingestão de entidade.
Anti-padrão que vejo em auditoria: três blocos JSON-LD desconexos na mesma página, um declarando Organization, outro declarando Article e o terceiro replicando BreadcrumbList, todos com @id soltos, sem sameAs, sem hasPart, sem isPartOf. O resultado para o pipeline upstream de construção de grafo de conhecimento é ambiguidade total. O sistema não sabe se a Organization da página A é a mesma da página B, e a entidade fica fragmentada no índice. O entity clarity despenca.
O estudo da Ahrefs de maio de 2026 confirmou: schema isolado não move citação marginal. Mas o motivo correto não é "schema não importa". O motivo é que schema só funciona quando construído como malha de identidade distribuída, com @graph único, sameAs para Wikidata, e consistência entre site, LinkedIn e base setorial. Quem implementa Schema.org seguindo essa régua não vê aumento dramático de citação, mas vê estabilidade da entidade no índice. Isso é higiene semântica, não alavanca de marketing.
Sinal 7: llms.txt como insurance defensivo (não obrigatório, mas resolvendo ambiguidade)
Critério de aceite: o portal expõe /llms.txt em formato Markdown na raiz, com pelo menos seis seções (sobre, principais entradas, conteúdo canônico, política de uso, contato editorial, lastReviewed), revisado há menos de 90 dias.
Como medir: curl em dominio.com/llms.txt devolve content-type text/plain (ou text/markdown) e tamanho entre 2 KB e 20 KB. O campo lastReviewed precisa estar nos últimos 90 dias. O arquivo precisa fazer sentido para um humano que está lendo. Não tem validador oficial. Para validação prática: peço a um modelo (Claude ou GPT-4o) para resumir o conteúdo do arquivo. Se o resumo for coerente, o arquivo está bom.
Anti-padrão que vejo em auditoria: llms.txt gerado por script em 2024, com lastReviewed congelado em "2024-03-01", listando URLs que não existem mais. Auditei portal jurídico que tinha llms.txt apontando para 14 URLs canônicas, das quais 9 retornavam 404. Manutenção zero. O arquivo virou poluição. Em outro caso, o cliente publicou llms.txt como upsell técnico de R$ 8.000, achando que era requisito para ChatGPT. Não é. O Google declarou explicitamente que não usa o arquivo. OpenAI e Anthropic tampouco o usam como sinal direto de ranking.
Mantenho llms.txt nos sites cliente da Brasil GEO por três motivos operacionais. Primeiro: insurance layer contra mudança futura de política dos LLMs (custo de manter é baixo, custo de não ter no dia que vira sinal é alto). Segundo: documentação interna sobre o que cada bot tem permissão de raspar (alinha com robots.txt). Terceiro: sinalização de preferência editorial para Perplexity e outros mecanismos que estão começando a olhar o arquivo. Não cobro como entrega premium. Trato como higiene, do mesmo nível de robots.txt e sitemap.xml.
Sinal 8: dateModified e lastReviewed em todo artigo (freshness verificável)
Critério de aceite: todo article do portal expõe propriedades datePublished e dateModified no JSON-LD, com dateModified atualizado a cada revisão substantiva (não só a cada deploy do site), e renderiza visualmente a data de última revisão para o leitor humano.
Como medir: Rich Results Test confirma que datePublished e dateModified estão no JSON-LD do Article. Inspeção visual confirma que a data renderizada no rodapé do artigo bate com a do JSON-LD. Git log confirma que dateModified subiu quando o conteúdo foi alterado. Sem essa congruência, o sinal de freshness é frágil.
Anti-padrão que vejo em auditoria: artigo de 2022 sobre LGPD com dateModified atualizado para 2026-01-01 por script automático no último deploy, sem qualquer alteração real de conteúdo. O modelo de retrieval em LLM detecta a contradição: o texto fala de regulação que mudou em 2023 e 2024, mas a data declara 2026. O sistema desconta a credibilidade. Resultado prático: o artigo cai do shortlist de fontes. Em outro caso, portal de saúde tinha dateModified ausente em 80% dos artigos. O Google não conseguia decidir o quão atual estava cada peça. O Bing simplesmente classificou o portal como "baixa frequência de atualização".
A regra editorial que adoto: dateModified só sobe quando há revisão substantiva (correção factual, atualização de número, inclusão de nova evidência). O campo lastReviewed do JSON-LD (ou um campo customizado em prose) declara a data da última auditoria sem alteração. Os dois sinais juntos contam ao crawler e ao modelo de retrieval qual é o estado epistemológico do artigo. Sem essa disciplina, freshness vira ruído.
Sinal 9: Política de correção pública e endereçável (/politica-de-correcao ou equivalente)
Critério de aceite: o portal expõe uma página acessível por URL canônica (/politica-de-correcao, /correcoes, /editorial-policy ou equivalente) descrevendo o processo de correção de erros, prazo de resposta, canal de contato e link para registro público das correções aplicadas nos últimos 12 meses.
Como medir: a página existe, está linkada do rodapé do site, tem JSON-LD do tipo CreativeWork ou WebPage com about descrevendo o procedimento, e o registro de correções está visível. Para B2B SaaS sério, listar pelo menos três correções concretas feitas nos últimos 12 meses é o sinal de honestidade que separa portal editorial de panfleto comercial.
Anti-padrão que vejo em auditoria: portal de finanças com 1.200 artigos sobre investimento, zero página de correção, formulário de contato genérico no rodapé. O modelo de retrieval em LLM avalia que o portal não tem mecanismo público de fact-checking. Em vertical YMYL (Your Money or Your Life) como finanças, saúde e regulação, a ausência de política de correção pública é fator de desconto na pontuação de E-E-A-T. O Google deixou isso explícito nas Search Quality Rater Guidelines em sucessivas atualizações.
Implementei /politica-de-correcao no dinheirodaminhaempresa.com em maio de 2026 com 2.040 palavras. Listei o processo de submissão de correção, o SLA de 5 dias úteis para resposta, o procedimento de versionamento (artigo recebe nota de correção visível, dateModified sobe, lastReviewed registra a revisão). Replicação em qualquer portal cliente da Brasil GEO custa duas horas de redação. O ganho de E-E-A-T não aparece em métrica de uma semana, mas aparece no diferencial sustentado quando um par concorrente publica desinformação em vertical regulado.
Sinal 10: Endpoint mensurável de citation rate (Bing Webmaster + uma das 4 LLMs)
Critério de aceite: o portal tem pelo menos dois canais ativos de medição de citação por IA: Bing Webmaster Tools com AI Performance Report habilitado, e monitoramento longitudinal de pelo menos 25 prompts em pelo menos uma das quatro LLMs principais (OpenAI, Anthropic, Google ou Perplexity), com cadência mínima semanal e janela mínima de 12 semanas.
Como medir: Bing Webmaster Tools devolve AI Performance Report com citação em Copilot e em ChatGPT (via integração Bing). Tela acessível, dado exportável, métrica datada. Em paralelo, um orquestrador externo executa os 25 prompts semanalmente contra a API do provedor escolhido, salva a resposta em CSV ou JSON, e calcula taxa de menção da marca por prompt. A combinação dos dois canais dá o esqueleto mínimo de visibilidade da entidade no ecossistema de busca agêntica.
Anti-padrão que vejo em auditoria: CMO traz screenshot de uma sessão de ChatGPT em que a marca apareceu bem citada, como prova de "presença em IA". Pergunto pela data, pela versão do modelo, pelo prompt exato, pela cadência de monitoramento. Silêncio. Em outro caso, agência forneceu "relatório GEO" com print de oito perguntas feitas no Perplexity em uma terça-feira aleatória. N de 8, sem repetição, sem variância controlada, sem intervalo de confiança. Isso não é evidência. É folclore comercial. Documentei o porquê estatístico no null-report SSRN de 6 de maio de 2026, com 7.052 respostas em 12 dias e três falhas de inferência cobertas.
O Bing Webmaster Tools resolve metade do problema sem custo. A outra metade exige instrumentação própria. Para cliente Brasil GEO, eu uso o geo-orchestrator com 4 chaves de provider rodando em paralelo, cadência semanal travada, prompts pré-registrados antes da janela começar, BCa bootstrap para intervalo de confiança e Benjamini-Hochberg para correção de múltiplas comparações. Custo da infraestrutura: irrelevante perto da decisão de orçamento que ela informa. Sem esse canal, o cliente vai continuar comprando narrativa.
Fecho: oito de dez é pronto, abaixo de sete é higiene faltando
Quem atende oito dos dez sinais está pronto para a era da busca agêntica. Não é perfeição. É suficiência operacional para que o portal não seja descartado por gap técnico antes mesmo da disputa por retrievability começar. Abaixo de sete, falta higiene básica, e nenhuma estratégia GEO compensa esse gap.
Em auditoria de portal cliente da Brasil GEO no segundo trimestre de 2026, o score médio inicial foi 4,3 de 10. Os três sinais mais falhados foram: 1 (SSR), 4 (allowlist robots) e 10 (medição de citação). Os três mais atendidos foram: 2 (CLS), 6 (Schema.org básico) e 8 (dateModified). O esforço para subir de 4 para 8 cabe em duas sprints de duas semanas cada para a maioria dos portais médios. Custo orçamentário: menos do que um pacote "GEO premium" de consultoria genérica vendido em 2025.
Quem quer rodar o checklist sozinho, o ponto de entrada é o diagnóstico. Quem quer comparar com cases públicos, os cases da Brasil GEO estão expostos no site. Quem quer ver a régua editorial que aplico antes de publicar qualquer recomendação operacional, está no editorial board. E para a discussão técnica sobre a camada de arquitetura por baixo dos dez sinais, escrevi separadamente sobre a arquitetura da síntese em RAG.
Fontes citadas no texto: Google web.dev, Build agent-friendly websites, mai 2026; Microsoft Bing Webmaster Blog, AI Performance Report, fev 2026; OpenAI Platform Docs, GPTBot e ChatGPT-User, 2026; Anthropic Support, ClaudeBot e Claude-User, 2026; Ahrefs, We Tracked 1,885 Pages Adding Schema, 11 mai 2026; Caramaschi A., Three Ways to Fail to Conclude, SSRN 6636298, 6 mai 2026.