O Teste A/B Afeta Como a IA Cita o seu Site?
Teste A/B e citação por IA: por que o teste client-side é invisível pro crawler, o que muda no server-side e como testar GEO sem enganar a si mesmo.
📚 Este artigo faz parte do guia GEO em 2026: a Busca por IA Mudando CRO e SEO.
Na configuração mais comum, um teste A/B não afeta como a IA cita o seu site, porque a IA nem enxerga o teste: quase toda ferramenta de CRO troca o conteúdo via JavaScript no navegador, e nenhum dos grandes crawlers de IA executa JavaScript. Isso muda quando o teste é server-side, e aí valem as mesmas regras de sempre contra cloaking. Este guia, parte do guia de GEO em 2026, cobre o que a evidência de log de servidor mostra sobre os crawlers de IA, a diferença prática entre testar no cliente e no servidor, os quatro cuidados técnicos que a documentação do Google exige de qualquer teste, e o problema que quase ninguém trata com honestidade: o segmento de tráfego vindo de IA quase nunca tem volume para fechar amostra, então ele não pode ser a métrica que decide o seu teste.
O que os crawlers de IA realmente conseguem ler
A pergunta de fundo tem uma resposta técnica, não filosófica: para uma IA citar a sua página, algum crawler precisa ter lido aquele conteúdo. E o que esses crawlers leem é bem mais limitado do que se imagina.
Um estudo da Vercel em parceria com a MERJ, publicado em dezembro de 2024 a partir de logs reais de servidor da rede da Vercel, mediu o comportamento dos principais crawlers de IA. O achado central: nenhum dos grandes crawlers de IA renderiza JavaScript. O GPTBot, da OpenAI, baixou arquivos JavaScript em 11,50% das requisições, e o crawler da Anthropic em 23,84%, mas nenhum dos dois executa esses arquivos (Vercel, The rise of the AI crawler). O AppleBot é a exceção relevante: ele renderiza JavaScript através de um crawler baseado em navegador, parecido com o Googlebot.
O volume ajuda a dimensionar o assunto: no período analisado, o GPTBot fez 569 milhões de requisições na rede da Vercel e o crawler da Anthropic 370 milhões, contra 4,5 bilhões do Googlebot. Ou seja, os crawlers de IA já são um tráfego relevante, mas ainda uma fração do Googlebot, e enxergam menos.
Client-side x server-side: a diferença que decide tudo
Toda a resposta prática desta pergunta cabe nessa distinção.
Num teste client-side, o servidor entrega o mesmo HTML para todo mundo e um script reescreve a página no navegador do visitante. É o formato padrão de praticamente toda ferramenta de CRO por snippet, incluindo a Donnu. Como o crawler de IA não executa esse script, ele lê exatamente o HTML original: o controle. A variação, para ele, não existe.
Num teste server-side, o servidor decide qual versão montar antes de responder à requisição. O crawler recebe HTML de verdade, e esse HTML pode ser o da variação. É aqui que um teste passa a poder mudar o que uma IA lê e eventualmente cita.
Essa distinção é a mesma que separa os dois modelos no guia de teste A/B client-side x server-side, só que lida por outra lente: não a de latência ou de flicker, mas a de quem consegue ler o quê.
| Cenário | O crawler de IA vê | Risco de cloaking | O que fazer |
|---|---|---|---|
| Teste client-side por snippet (padrão de CRO) | Sempre o controle | Nenhum, o HTML é igual pra todos | Nada além do normal; a variação simplesmente não existe pra ele |
| Teste server-side com sorteio aleatório | Controle ou variação, conforme o sorteio | Nenhum, o sorteio não olha quem pediu | Manter o sorteio independente de user-agent e IP |
| Teste server-side que força o robô no controle | Sempre o controle, por decisão baseada no robô | Alto, é a definição de cloaking | Não fazer; remover a exceção por user-agent |
| Split URL com URLs de variação indexáveis | A URL que sortear | Baixo, se bem configurado | rel="canonical" pra URL original e redirecionamento 302 |
Os quatro cuidados técnicos que a documentação do Google exige
Quando o teste toca o que é servido (server-side ou split URL), a documentação oficial do Google sobre teste em site é curta e direta (Google Search Central, A/B testing best practices for Search):
- Nunca faça cloaking. A regra é “não mostre um conjunto de URLs pro Googlebot e outro pras pessoas”. Isso vale se a decisão for tomada por lógica de servidor, por robots.txt ou por qualquer outro meio. Um teste com sorteio aleatório de verdade não viola isso, porque ele não olha quem está pedindo a página.
- Use
rel="canonical"nas URLs de variação. Se o teste usa URLs diferentes, cada URL alternativa deve apontar por canonical para a URL original. O Google recomenda isso em vez denoindex, porque reflete melhor a intenção: você não quer que a página deixe de ser indexada, quer que as versões sejam entendidas como variações agrupadas sob a original. - Use redirecionamento 302, nunca 301. O 302 (temporário) diz que a URL original deve continuar no índice. O 301 (permanente) sinaliza que a original foi substituída, o que é exatamente o oposto do que um teste temporário significa.
- Encerre o teste assim que ele acabar. Terminado o experimento, atualize o site com a variação escolhida e remova os elementos do teste. Um teste que fica no ar indefinidamente pode ser interpretado como tentativa de enganar mecanismos de busca.
Vale um quinto ponto, que a mesma documentação registra e que quase ninguém lembra: o Googlebot geralmente não suporta cookies. Um teste controlado por cookie tende a mostrar pra ele apenas a versão que uma pessoa sem cookies veria, normalmente o controle. Não é um problema, é uma consequência a conhecer antes de tentar explicar por que a variação “não apareceu no índice”.
A consequência que quase ninguém tira: o teste não expõe a melhoria
Aqui está a parte contraintuitiva. Se você roda um teste client-side, a IA continua lendo o controle durante todo o experimento. Isso é confortável no curto prazo (nada do que você testa pode “confundir” um mecanismo generativo), mas tem um custo prático: a variação vencedora só passa a existir para sistemas de IA quando ela é promovida a conteúdo servido de verdade, no HTML da página.
Isso reordena o trabalho de forma útil. O teste A/B prova que a mudança converte melhor com pessoas. A implementação definitiva no HTML é o passo que também a expõe a crawlers e mecanismos generativos. Tratar as duas coisas como um evento só, “vou testar e ver se a IA cita mais”, é confundir dois processos que acontecem em tempos diferentes e com mecanismos diferentes.
O problema de amostra: o tráfego de IA é pequeno demais para decidir
Suponha que você queira ir além e testar se uma mudança de estrutura de conteúdo (a matéria do guia de GEO) melhora a conversão de quem chega vindo de um assistente. A intenção é boa, mas a conta quase nunca fecha.
Um site com 12.000 visitas por semana, das quais 320 vêm de assistentes de IA, com uma taxa de conversão base de 2,6%, querendo detectar uma melhora relativa de 20% (levando a taxa para cerca de 3,1%), a 95% de confiança e 80% de poder, precisa de:
Cálculo por aproximação normal de duas proporções, 2 variações (50/50). Mexa nos campos e veja o impacto ao vivo.
Ajustando a calculadora acima para taxa base 2,6, efeito mínimo detectável 20 (relativo) e 12.000 visitantes por semana, o resultado é 16.128 visitas por variação (32.256 no total), o que leva cerca de 19 dias rodando no site inteiro. Agora repita a conta com os mesmos 16.128 por variação, mas alimentados só pelas 320 visitas semanais vindas de IA: seriam cerca de 706 dias, quase dois anos, para um único teste. Nesse prazo, o próprio comportamento dos assistentes já teria mudado várias vezes.
Dá para inverter a pergunta e perguntar o que o segmento de IA consegue detectar no prazo que você aceita esperar. Com 320 visitas por semana ao longo de 8 semanas, você acumula 1.280 visitas por variação. Nesse tamanho, sobre uma base de 2,6%, o menor efeito detectável é de aproximadamente 67,8% relativos (taxa alvo de cerca de 4,36%). Ou seja, só uma diferença enorme apareceria, e diferenças enormes de conversão raramente existem numa mudança de estrutura de conteúdo.
Amostra por variação: -. Cálculo por aproximação normal de duas proporções, split igualitário entre as variações. Mexa nos campos e veja o menor efeito que o seu tráfego consegue provar.
Ajuste a calculadora acima para taxa base 2,6, 320 visitantes por semana, 8 semanas e 2 variações para reproduzir esse número. A leitura prática: o segmento de IA é uma leitura secundária, nunca a métrica de decisão. Rode o teste no site inteiro, decida por ele, e olhe o segmento de IA como contexto direcional, sabendo que ele não tem poder estatístico para sustentar uma decisão sozinho. É a mesma disciplina descrita no guia completo de otimização de conversão: quando o volume não banca a precisão, mude o que você promete medir, não o rigor.
Como medir citação por IA de verdade (fora do teste A/B)
Se citação não pode ser métrica primária de um teste A/B, ela ainda precisa ser acompanhada de alguma forma. Quatro sinais, nenhum deles suficiente sozinho:
| Sinal | O que mostra | O que ele NÃO prova |
|---|---|---|
| Acessos de crawlers de IA nos logs do servidor | Que a sua página está sendo lida por esses sistemas | Que ela foi citada em alguma resposta |
| Tráfego de referência de assistentes no analytics | Que alguém clicou a partir de uma resposta gerada | O volume total de citações, já que boa parte não gera clique |
| Checagem manual periódica em consultas-alvo | Se a sua página aparece citada hoje, naquela consulta específica | Estabilidade, porque a resposta muda entre execuções |
| Evolução de buscas por marca | Se a exposição em respostas está gerando lembrança | Causalidade direta com qualquer mudança específica |
O ponto honesto: nenhum desses quatro tem a granularidade e o volume que um teste A/B exige. Eles compõem um painel de acompanhamento, não um experimento.
Os erros mais comuns nessa interseção
| Erro | Sinal de alerta | Correção |
|---|---|---|
| Esconder o teste do robô por user-agent | “Configurei para o Googlebot sempre ver o controle” | Isso é cloaking pela definição do Google; deixe o sorteio aleatório e independente de quem pede |
| Usar 301 no split URL | O redirecionamento do teste é permanente | Troque para 302; o 301 diz que a URL original foi substituída |
| Esperar que o teste client-side mude a citação | “Testei três meses e a IA não cita a versão nova” | Ela nunca leu a versão nova; só o HTML servido conta |
| Decidir o teste pelo segmento de IA | “No tráfego de IA a variação B ganhou” | Confira a amostra desse recorte; quase sempre falta poder estatístico |
| Deixar o teste no ar indefinidamente | O experimento roda há meses sem decisão | A própria documentação do Google pede que se encerre e se remova o teste ao fim |
| Tratar citação como métrica de conversão | O painel mistura citação com receita | Citação é sinal de exposição; conversão é o que o teste A/B decide |
Faça isso automático na Donnu
Você acabou de ver que a pergunta do título tem uma resposta técnica e não uma resposta de opinião: depende de onde a variação é decidida, e o teste A/B por snippet, o formato mais comum, é invisível para os crawlers que alimentam sistemas generativos. O que a Donnu resolve é o outro lado da conta, o lado que realmente decide: dimensionar a amostra certa antes de rodar, medir a conversão de pessoas de verdade no site inteiro e devolver um veredito honesto, em vez de deixar você declarar vencedor num recorte de tráfego pequeno demais para sustentar qualquer conclusão.
Comece um teste grátis de 14 dias e leve esse rigor para as suas mudanças de conteúdo. Para a base completa do assunto, veja o guia de GEO em 2026.
Referências
- Vercel e MERJ. The rise of the AI crawler. Análise de logs de servidor publicada em 17 de dezembro de 2024. vercel.com/blog/the-rise-of-the-ai-crawler.
- Google Search Central. A/B testing best practices for Search. developers.google.com/search/docs/crawling-indexing/website-testing.
- Aggarwal, P., Murahari, V., Rajpurohit, T., Kalyan, A., Narasimhan, K., Deshpande, A. GEO: Generative Engine Optimization. ACM SIGKDD 2024. arxiv.org/abs/2311.09735.
Leia também:
Perguntas frequentes
- Rodar teste A/B prejudica a chance do meu site ser citado por uma IA?
- Na configuração mais comum, não, porque a IA nem enxerga o teste. Um teste A/B client-side (o formato padrão de quase toda ferramenta de CRO) troca o conteúdo via JavaScript no navegador, e nenhum dos grandes crawlers de IA executa JavaScript. Segundo o estudo da Vercel com dados de servidor de dezembro de 2024, GPTBot e o crawler da Anthropic baixam arquivos JavaScript (11,50% e 23,84% das requisições, respectivamente) mas não os executam. O que eles indexam é o HTML original, ou seja, o controle. Testes server-side são outra história, e é neles que valem os cuidados deste guia.
- Qual a diferença entre teste client-side e server-side pra um crawler de IA?
- No client-side, o servidor entrega o mesmo HTML pra todo mundo e o JavaScript reescreve a página depois, já no navegador. Como o crawler de IA não roda esse JavaScript, ele lê exatamente o HTML original, o controle. No server-side, o servidor decide qual variação entregar antes de responder, então o crawler pode receber a variação em vez do controle. É só nesse segundo caso que o teste tem alguma chance de mudar o que uma IA lê e eventualmente cita.
- Teste A/B server-side conta como cloaking?
- Não, desde que a decisão de variação seja aleatória e independente de quem está pedindo a página. A documentação do Google sobre teste em site é explícita: o problema é mostrar um conjunto de URLs pro robô e outro pra pessoas. Se o seu servidor sorteia a variação sem olhar para o user-agent ou o IP do visitante, ele não está discriminando robô de gente, e por isso não é cloaking. O risco aparece quando alguém tenta "proteger o SEO" forçando o robô a sempre ver o controle, o que é exatamente a definição do problema.
- Dá para fazer um teste A/B só no tráfego que vem de assistentes de IA?
- Quase nunca com rigor estatístico, porque esse segmento costuma ser pequeno demais. No exemplo trabalhado deste guia, um site com 12.000 visitas por semana e 320 delas vindas de assistentes precisaria de 16.128 visitas por variação para detectar uma melhora relativa de 20% sobre uma taxa base de 2,6%. No site inteiro isso leva 19 dias; só no segmento de IA levaria cerca de 706 dias. A saída honesta é rodar o teste no site inteiro e acompanhar o segmento de IA como leitura secundária, nunca como métrica de decisão.
- Quais cuidados técnicos um teste A/B precisa ter para não atrapalhar busca e citação?
- A documentação do Google lista quatro: não fazer cloaking (nunca decidir a variação pelo user-agent), usar rel="canonical" nas URLs de variação apontando para a URL original quando o teste usa URLs diferentes, usar redirecionamento 302 (temporário) e nunca 301 (permanente), e encerrar o experimento assim que ele terminar, removendo os elementos de teste. Vale lembrar também que o Googlebot geralmente não suporta cookies, então um teste controlado por cookie tende a mostrar pra ele só a versão de quem não aceita cookies.
- Se a IA só lê o controle, meu teste vencedor nunca melhora a chance de citação?
- Enquanto o teste está rodando em client-side, correto: o crawler continua vendo o HTML original. A melhoria só passa a existir para sistemas de IA quando a variação vencedora é promovida a conteúdo servido de verdade, no HTML da página. Isso muda a ordem prática do trabalho: use o teste A/B para provar que a mudança converte melhor com pessoas, e trate a implementação definitiva no HTML como o passo que também a expõe a crawlers e mecanismos generativos.
- Como medir se uma mudança melhorou a minha citação por IA?
- Nenhuma métrica isolada resolve, e é honesto dizer que a medição ainda é imperfeita. O conjunto mais útil combina quatro sinais: acessos de crawlers de IA nos logs do servidor, tráfego de referência vindo de assistentes generativos no analytics, checagens periódicas e manuais de citação em consultas-alvo, e a evolução de buscas por marca. Nenhum deles isoladamente prova causalidade, e nenhum deles tem volume suficiente para virar métrica primária de um teste A/B.