Testes A/B de SEO
Como executar experimentos de SEO controlados — testando separadamente title tags, meta descriptions, dados estruturados e alterações na página — usando abordagens de séries temporais ou URL dividida para medir o impacto causal.
Idiomas
O teste A/B de SEO mede se uma alteração realmente moveu a busca orgânica — não se você acha que moveu. Você não pode testar SEO da mesma forma que testa uma landing page para conversões, porque existe apenas um Googlebot: os mecanismos de busca indexam uma versão de uma URL e não há como dividir as buscas por uma consulta 50/50. Então você randomiza no nível da página. Dois métodos reais: teste de URL dividida/holdout (dividir aleatoriamente um grande grupo de páginas de modelo semelhante em controle e variante, comparar o tráfego orgânico) e teste de séries temporais/impacto causal (prever o que as páginas variantes teriam feito sem a alteração, usando um grupo de controle como linha de base). Title tags, meta descriptions, dados estruturados, links internos e conteúdo são testáveis; backlinks não são. Você precisa de páginas e tráfego suficientes para superar o ruído (o piso prático do SearchPilot é centenas de páginas do mesmo modelo e ~30 mil sessões orgânicas/mês), os testes geralmente duram de 2 a 6 semanas, e você não interrompe cedo uma tendência de aparência boa. Mantenha-se em conformidade com o Google: canonicize as URLs variantes, use 302 em vez de 301 se redirecionar, sem cloaking, e encerre o teste quando terminar.
Evidence for this claim CausalImpact estimates an intervention's causal effect from a Bayesian structural time-series counterfactual under stated assumptions. Scope: Original methodology; validity depends on controls, stable relationships, and experimental design. Confidence: high · Verified: Brodersen et al.: Inferring causal impact using Bayesian structural time-series models Evidence for this claim Search experiments must avoid showing materially different content to Googlebot and users in ways that constitute cloaking; temporary tests should preserve normal crawlability and canonical intent. Scope: Current Google spam and testing constraints, not a universal test-duration prescription. Confidence: high · Verified: Google Search Central: Website testing and Google SearchTL;DR — O teste A/B de SEO é como você prova que uma mudança de SEO funcionou em vez de adivinhar. Você não pode testar SEO da mesma forma que os profissionais de marketing testam uma landing page — existe apenas um Google, e ele vê uma versão da sua página. Então, em vez de dividir pessoas em dois grupos, você divide páginas: altere algumas páginas, deixe outras semelhantes intactas, e compare o desempenho de cada grupo na busca. Isso mostra se a mudança causou a diferença ou se foi apenas sazonalidade ou sorte.
O que é teste A/B de SEO
Quando você altera uma tag de título ou adiciona conteúdo a uma página, o tráfego aumenta ou diminui — mas por quê? Talvez sua mudança tenha funcionado. Talvez tenha sido um aumento sazonal. Talvez o Google tenha lançado uma atualização naquela semana. Sem uma forma de separar sua mudança de tudo o mais que está acontecendo, você está adivinhando.
O teste A/B de SEO (também chamado de teste de divisão de SEO) é como você para de adivinhar. Você faz uma mudança em algumas das suas páginas, mantém um conjunto semelhante de páginas inalterado como comparação e mede a diferença no tráfego de busca orgânica entre os dois grupos. Se as páginas alteradas ficarem à frente das inalteradas, sua mudança provavelmente causou isso.
Por que você não pode testar SEO como um teste A/B normal
Se você já ouviu falar de teste A/B antes, provavelmente é do tipo de marketing: mostre metade dos seus visitantes um botão vermelho e metade um botão verde, e veja qual recebe mais cliques. Isso funciona porque um site pode mostrar duas versões diferentes da mesma página para duas pessoas diferentes ao mesmo tempo.
Os mecanismos de busca não funcionam assim. Existe basicamente um Googlebot, e ele vê uma versão da sua página. Você não pode mostrar “versão A” para metade das pessoas que pesquisam uma palavra-chave e “versão B” para a outra metade — o Google decide quem ranqueia, não você, e ele indexa apenas uma versão. Mostrar conteúdo diferente ao Google do que aos visitantes reais é chamado de cloaking, e é contra as regras.
Então, o teste de SEO faz a próxima melhor coisa: em vez de dividir pessoas, ele divide páginas.
Como funciona na prática
Você precisa de um conjunto de páginas semelhantes — pense em todas as suas páginas de produto, ou todos os seus posts de blog, que usam o mesmo modelo. Então:
- Divida-as em dois grupos aleatoriamente: um grupo de controle (permanece o mesmo) e um grupo de variante (recebe sua mudança).
- Faça a mudança apenas no grupo de variante.
- Aguarde algumas semanas e compare o tráfego de busca orgânica entre os dois grupos.
Como ambos os grupos passam pelo mesmo clima — a mesma estação, as mesmas atualizações do Google — qualquer coisa que mova ambos os grupos juntos não é sua mudança. Apenas a diferença entre eles é.
O que você pode e não pode testar
Você pode testar os elementos on-page: tags de título, meta descrições, cabeçalhos, dados estruturados, links internos e conteúdo. Você geralmente não pode testar de forma confiável backlinks dessa forma — você não pode distribuir links para exatamente metade das suas páginas em um cronograma da mesma forma que pode alterar uma tag de título.
Quer a versão para profissionais — as duas metodologias reais, quanto tráfego você precisa, por quanto tempo executar e como ficar do lado certo das regras do Google? Mude para a aba Avançado.
Evidence for this claim CausalImpact estimates an intervention's causal effect from a Bayesian structural time-series counterfactual under stated assumptions. Scope: Original methodology; validity depends on controls, stable relationships, and experimental design. Confidence: high · Verified: Brodersen et al.: Inferring causal impact using Bayesian structural time-series models Evidence for this claim Search experiments must avoid showing materially different content to Googlebot and users in ways that constitute cloaking; temporary tests should preserve normal crawlability and canonical intent. Scope: Current Google spam and testing constraints, not a universal test-duration prescription. Confidence: high · Verified: Google Search Central: Website testing and Google SearchTL;DR — O teste A/B clássico randomizado não se aplica ao SEO orgânico porque existe apenas um Googlebot — os mecanismos de busca indexam uma versão de uma URL e não conseguem dividir as buscas de uma consulta 50/50. Então você randomiza no nível da página. Duas metodologias: split-URL/holdout (dividir aleatoriamente um grande grupo de páginas com o mesmo template em controle e variante, comparar sessões orgânicas) e séries temporais/causal-impact (prever o contrafactual com um grupo de controle como linha de base, conforme a própria pesquisa CausalImpact do Google). Testável: títulos, metas, dados estruturados, links internos, conteúdo, layout. Não é confiavelmente testável: backlinks, atualizações de algoritmo, qualquer coisa em todo o site. Você precisa de páginas comparáveis suficientes, observações e histórico pré-teste para estimar a variância; não há um piso universal de tráfego ou duração. Trate isso como um quase-experimento, não um RCT limpo — grupos de páginas não são totalmente independentes, pois templates compartilhados, links internos e concorrência na SERP podem permitir que uma mudança no grupo variante vaze para o grupo de controle. Predefina a regra de parada em vez de encerrar com base em uma tendência de aparência favorável. Mantenha a conformidade: canônize as variantes, use 302 e não 301, sem cloaking, desmonte o teste quando terminar.
Por que o teste A/B no estilo CRO não funciona para a busca orgânica
A razão pela qual o teste de SEO precisa de sua própria metodologia é que aquilo que você está testando não é um humano. Como Craig Bradford, da SearchPilot, diz, “The ‘user’ we are testing for is Googlebot, not human users. That means it’s not possible, for instance, to show 10,000 ‘Googlebots’ control and variant pages randomly. There is only one Googlebot.” (tradução) «O ‘usuário’ para o qual testamos é o Googlebot, não usuários humanos. Isso significa que não é possível, por exemplo, mostrar 10 000 ‘Googlebots’ em páginas de controle e variante aleatoriamente. Existe apenas um Googlebot.»
Existem duas razões estruturais pelas quais o teste A/B randomizado no nível do visitante — o tipo que a otimização da taxa de conversão usa — não pode ser aplicado à busca orgânica:
- Os mecanismos de busca indexam e ranqueiam uma versão de uma URL. Um servidor web pode colocar metade dos seus visitantes no balde A e metade no balde B por cookie, em tempo real. O Googlebot rastreia e indexa uma versão servida. Não há mecanismo para ele manter duas versões concorrentes da mesma URL e ranqueá-las uma contra a outra.
- Não há atribuição aleatória por consulta. Você não pode mostrar conteúdo variante para “metade das buscas por [palavra-chave]” da mesma forma que uma plataforma de anúncios mostra criativos variantes para metade das impressões. O Google decide quais páginas ranqueiam para uma consulta; você não consegue dividir esse tráfego.
A solução em ambas as metodologias reais é a mesma: randomizar no nível da página, não no nível do visitante ou da consulta. Você trata um grande grupo de páginas semelhantes como sua população e divide as páginas em controle e variante.
Isso também significa que hábitos seguros para CRO não são automaticamente seguros para SEO. Ferramentas de teste A/B em JavaScript no lado do cliente que trocam conteúdo após o carregamento são boas para humanos, mas arriscadas para rastreadores — a SearchPilot alerta que usar JavaScript para testes de SEO “can cause significant problems or even invalidate the results” (tradução) «pode causar problemas significativos ou até invalidar os resultados». Se você vai testar SEO, faça isso no lado do servidor (ou no lado da borda), para que o rastreador veja a variante no HTML inicial.
As duas metodologias reais
A maioria dos guias agrupa tudo sob “teste A/B de SEO”. Vale a pena separar as duas abordagens distintas, porque elas respondem a perguntas ligeiramente diferentes.
1. Teste split-URL / grupo de páginas (holdout)
Pegue um grande conjunto de páginas com template — todas as páginas de produto, todas as páginas de categoria, todos os posts de blog — e atribua-as aleatoriamente a um grupo de controle e a um grupo de variante. O grupo de variante recebe a mudança; o grupo de controle não. Durante a janela do teste, você compara o tráfego orgânico (sessões/cliques) entre os dois grupos.
Ambos os grupos experimentam as mesmas condições externas, então sazonalidade e atualizações de algoritmo que afetam a todos aparecem como movimento paralelo em ambos os grupos e não são atribuídas erroneamente à sua mudança. O que você está medindo é a divergência entre os grupos depois que a mudança entra no ar.
O problema é o poder estatístico: você precisa de páginas suficientes e tráfego suficiente por página para detectar um efeito real acima do ruído do dia a dia que essas páginas já apresentam.
Vale a pena nomear honestamente: grupos de páginas não são observações totalmente independentes como visitantes individuais em um teste A/B de site. Páginas no mesmo site frequentemente compartilham modelos, links internos e competem entre si nos mesmos SERPs — uma mudança no grupo de variantes pode alterar a equidade de links internos ou canibalizar cliques de maneiras que também afetam o grupo de controle. Essa é uma limitação real, não uma nota de rodapé: é por isso que isso é um quase-experimento, não um ensaio clínico randomizado limpo. Quanto menos independentes forem suas páginas, mais conservador você deve ser antes de chamar um resultado de significativo.
2. Teste de séries temporais / impacto causal
Em vez de (ou além de) manter um grupo de controle ao vivo, você aplica a mudança e então prevê qual teria sido o tráfego das páginas variantes sem ela — o contrafactual — usando um grupo de controle de páginas semelhantes e não afetadas para construir essa previsão. A lacuna entre a previsão e o que realmente aconteceu é o impacto estimado.
O motor estatístico por trás disso é a modelagem bayesiana de séries temporais estruturais, que vem diretamente da pesquisa do Google: Brodersen, Gallusser, Koehler, Remy e Scott, “Inferring Causal Impact Using Bayesian Structural Time-Series Models” (The Annals of Applied Statistics, 2015), lançado como o pacote R de código aberto CausalImpact (pré-print aqui). Quase toda ferramenta de teste de SEO que afirma ter um método “bayesiano” ou “impacto causal” se baseia neste artigo, mesmo quando não o cita. Vale a pena saber de onde o método realmente vem.
Ferramentas neste espaço
O cenário muda, então verifique o status atual antes de se comprometer, mas os principais players:
- SearchPilot — a plataforma mais associada a testes A/B rigorosos de SEO. Ela cresceu a partir da ODN (Optimisation Delivery Network) da Distilled; a Distilled foi adquirida pela Brainlabs em 2020 e o produto de testes foi desmembrado como SearchPilot. Ela executa testes na borda, então as variantes são servidas no HTML que o rastreador vê.
- SEOTesting.com — uma ferramenta de teste mais leve, orientada pelo Search Console, com forte foco em significância estatística.
- seoClarity — sua suíte empresarial inclui um módulo de teste A/B de SEO.
Uma coisa para não presumir: o Google Search Console não oferece um recurso de experimentos de SEO ao vivo e de propósito geral hoje. Havia ferramentas de experimento ligadas à era AMP, mas elas foram efetivamente incorporadas ao relatório geral de Page Experience. Não recorra a “GSC Experiments” como se fosse uma ferramenta atual de teste A/B — não é.
No lado do Bing, a Microsoft enquadra o teste de URL dividida como a abordagem certa para mudanças estruturais e posiciona o IndexNow para obter novas URLs de variantes rastreadas rapidamente e o Microsoft Clarity como o companheiro do lado da UX para a medição do lado do ranqueamento.
Quanto tráfego e quantas páginas você precisa
Não há um número universal, e qualquer guia que lhe dê um está simplificando demais. O tamanho da amostra que você precisa é determinado por três coisas:
- Quanta variação natural as páginas já apresentam — páginas mais ruidosas precisam de mais dados.
- Qual o tamanho do efeito que você está tentando detectar — efeitos menores precisam de muito mais dados.
- Quantas páginas você pode colocar em cada grupo — mais páginas, mais sinal.
Para um piso prático, a SearchPilot diz que eles “geralmente trabalham com sites com pelo menos centenas de páginas no mesmo template e pelo menos 30.000 sessões orgânicas por mês para o grupo de páginas que você quer testar.” O guia de testes da Ahrefs coloca o limite confortável em “dezenas ou centenas de milhares de visitas orgânicas por mês.” Sites menores podem testar, mas precisarão de um efeito muito maior para alcançar significância — o que geralmente significa que as pequenas vitórias se perdem no ruído e apenas grandes mudanças são registradas.
Observe a métrica aqui: sessões orgânicas/cliques para o grupo de páginas, não rankings. O argumento da SearchPilot para isso é prático — o rastreamento de posições não consegue cobrir toda a cauda de consultas para as quais uma página ranqueia, e os dados de posição do Search Console são muito esparsos e médios para serem uma métrica de teste rigorosa. O tráfego para o grupo é o sinal mais completo.
Quanto tempo rodar um teste
Janelas comuns rodam 2–6 semanas. O piso é definido por duas coisas: o Google precisa recrawlear as páginas variantes e reavaliá-las, e você precisa acumular tráfego suficiente em cada grupo para alcançar significância.
O pecado cardinal é parar cedo. Movimento positivo precoce é muito frequentemente ruído, e se você encerrar o teste no momento em que parece bom, você vai publicar falsos positivos. Ryan Jones, da SEOTesting.com, é direto sobre isso — “Nunca encerre um teste cedo só porque você vê bons resultados!” — e recomenda manter um nível de confiança de 95% (p < 0,05) como padrão. Um teste com poder insuficiente deve rodar por mais tempo ou ser abandonado, não declarado vencedor.
Controlando sazonalidade e atualizações de algoritmo
É exatamente para isso que o grupo de controle e o modelo de previsão servem. Se um pico sazonal ou uma atualização principal atingir, atinge tanto o seu controle quanto os grupos variantes, e você vê isso como movimento paralelo — não é atribuído erroneamente à sua mudança.
Onde isso quebra é má distribuição em grupos. O próprio exemplo ilustrativo da SearchPilot: se você colocar todas as páginas “gato” de um site no grupo variante logo antes do Dia Internacional do Gato, um pico sazonal externo real será mal interpretado como uma vitória do teste. A solução é atribuição aleatória em grupos, para que tanto o controle quanto a variante contenham uma mistura representativa de páginas e nenhum deles fique exclusivamente exposto a uma força externa.
O que você pode — e não pode — testar de forma confiável
Testável:
- Tags de título e meta descrições
- Estrutura de H1/cabeçalhos
- Dados estruturados (tipo de schema ou presença)
- Padrões de links internos
- Conteúdo on-page (profundidade, posicionamento, blocos de “conteúdo SEO” em páginas de categoria)
- Layout da página e estrutura de UI — até redesenho completo de landing pages no nível avançado
Não é confiavelmente testável desta forma:
- Backlinks. Este é o exemplo claro. Você não pode atribuir aleatoriamente e uniformemente links de entrada para metade de um grupo de páginas enquanto os retém da outra metade — aquisição de links não é um tratamento que você pode dosar em um cronograma ou padronizar entre páginas. Sites de terceiros linkam quando linkam. Como Liam Blackledge, da Gorilla Marketing, coloca, construir links para metade das suas páginas de produto e não para a outra metade não é um experimento controlado. Links são avaliados com análise antes/depois ou correlacional, não com teste de divisão verdadeiro.
- Atualizações de algoritmo e mudanças em todo o site. Por definição, atingem todos, então não há um grupo de controle verdadeiro para comparar.
- Qualquer coisa que não possa ser isolada nas páginas variantes sem vazar para o grupo de controle.
Permanecendo em conformidade enquanto você testa
O Google sanciona explicitamente esse tipo de teste — ele tem um documento inteiro sobre isso — desde que você siga as regras de higiene:
- Canonicalize as URLs das variantes para a original. O Google recomenda
rel="canonical"em vez denoindexpara variantes de teste, porque isso agrupa as variações e mantém a original indexada como canônica. (Se você quiser os detalhes mais profundos de como a seleção canônica funciona, esse é um tópico à parte.) - Use 302, não 301, se você estiver redirecionando. O Google é explícito: “If you’re running a test that redirects users from the original URL to a variation URL, use a 302 (temporary) redirect, not a 301 (permanent) redirect.” (tradução) «Se você estiver executando um teste que redireciona usuários da URL original para uma URL de variação, use um redirecionamento 302 (temporário), não um 301 (permanente).»
- Não faça cloaking. “Don’t show one set of URLs to Googlebot, and a different set to humans.” (tradução) «Não mostre um conjunto de URLs para o Googlebot e um conjunto diferente para humanos.»
- Encerre o teste quando ele terminar. O Google avisa que “If we discover a site running an experiment for an unnecessarily long time, we may interpret this as an attempt to deceive search engines and take action accordingly.” (tradução) «Se descobrirmos um site executando um experimento por um tempo desnecessariamente longo, podemos interpretar isso como uma tentativa de enganar os mecanismos de busca e tomar as medidas cabíveis.»
E para acabar com um mito persistente: não existe “penalidade por conteúdo duplicado” para variantes de teste devidamente canonicalizadas. O risco real é cloaking, não duplicação. O Google entende variações intencionais de teste pelo que elas são.
Onde isso se encaixa
O teste A/B de SEO é uma disciplina de medição que compensa mais em escala, por isso vive no kit de ferramentas empresariais junto com os problemas de relatórios e atribuição que você enfrenta quando tem milhares de páginas modeladas. É a resposta honesta para “essa mudança funcionou?” — e em sites grandes, respostas honestas valem muito.
Use SEO testing to make portfolio decisions under uncertainty, not to manufacture certainty: predefine the hypothesis, control, duration, and rollout rule before results arrive.
- Search experiments randomize comparable pages because search engines cannot be split like website visitors.
- Seasonality, algorithm changes, and regression to the mean can make simple before-and-after comparisons misleading.
- A documented stopping rule reduces pressure to ship a favorable-looking result early.
Controlled evidence helps teams scale changes that improve organic performance and avoid rolling weak ideas across a large template inventory.
Risco se ignorado: The organization attributes normal volatility to its changes and scales decisions that have not demonstrated incremental value.
Pergunte à sua equipe: Was the success threshold and rollout rule written before the test, and is the control group comparable enough to support the decision?
Resumo de IA
Uma visão condensada da versão Avançada:
- Por que o teste A/B estilo CRO falha para SEO. Existe um único Googlebot; os mecanismos de busca indexam uma versão de uma URL e não conseguem dividir as buscas de uma consulta 50/50. Então você randomiza no nível da página, não no nível do visitante ou da consulta.
- Duas metodologias. Split-URL/holdout (dividir aleatoriamente páginas do mesmo modelo em controle e variante, comparar sessões orgânicas) e séries temporais/impacto causal (prever o contrafactual usando um grupo de controle como linha de base — a própria pesquisa CausalImpact do Google, Brodersen et al. 2015).
- É um quase-experimento, não um RCT limpo. Grupos de páginas não são totalmente independentes — modelos compartilhados, links internos e concorrência na SERP podem permitir que uma mudança no grupo variante vaze para o grupo de controle. Seja mais conservador sobre a significância quanto menos independentes forem suas páginas.
- Ferramentas. SearchPilot (cresceu a partir do ODN da Distilled, separado após a aquisição da Brainlabs em 2020), SEOTesting.com, módulo da seoClarity. O GSC não tem um recurso de experimentos ao vivo de propósito geral (isso era da era AMP). O Bing endossa teste split-URL + IndexNow + Clarity.
- Tamanho da amostra. Não há um número universal — determinado pela variância do grupo de páginas, tamanho do efeito e tamanho do grupo. O mínimo da SearchPilot: centenas de páginas do mesmo modelo + ~30 mil+ sessões orgânicas por mês. A métrica são sessões orgânicas para o grupo, não ranqueamentos.
- Duração. Geralmente de 2 a 6 semanas. Nunca pare cedo em uma tendência de aparência boa — o movimento inicial geralmente é ruído. Mantenha 95% de confiança (p < 0,05).
- Sazonalidade/atualizações. O grupo de controle lida com elas — forças externas atingem ambos os grupos como movimento paralelo. O modo de falha é uma má divisão em grupos; corrija com atribuição aleatória.
- Testável: títulos, metas, cabeçalhos, dados estruturados, links internos, conteúdo, layout. Não testável: backlinks (não é possível dosar a aquisição de links uniformemente), atualizações de algoritmo, mudanças em todo o site.
- Conformidade (Google): canonalize as variantes, use 302 e não 301 se redirecionar, sem cloaking, encerre o teste prontamente. Não há penalidade por conteúdo duplicado para variantes canonalizadas.
Documentação oficial
Orientação de fonte primária que rege o teste de SEO.
- Práticas recomendadas de teste A/B para pesquisa — Documento oficial do Google sobre como executar testes sem prejudicar a pesquisa: canônico, 302 e não 301, sem cloaking e não execute testes para sempre.
- Inferindo impacto causal usando modelos bayesianos de séries temporais estruturais — Brodersen et al. (Google, 2015), a pesquisa e o pacote
CausalImpactpor trás do teste de SEO de séries temporais. Pré-impressão. - Consolidar URLs duplicadas (canonicalização) — como funciona o
rel="canonical", o que é importante para canonalizar variantes de teste.
Bing / Microsoft
- Teste A/B para melhor desempenho no mecanismo de busca com IndexNow e Microsoft Clarity — Endosso do Bing ao teste split-URL para mudanças estruturais, além de IndexNow e Clarity como complementos.
Citações da fonte
Declarações registradas. Cada link do Google é um link profundo que salta para a passagem citada na página de origem.
Google — práticas recomendadas de teste A/B
- “Don’t show one set of URLs to Googlebot, and a different set to humans. This is called cloaking, and is against our spam policies, whether you’re running a test or not.” (tradução) «Não mostre um conjunto de URLs para o Googlebot e um conjunto diferente para humanos. Isso é chamado de cloaking e viola nossas políticas de spam, esteja você executando um teste ou não.» Ir para a citação
- “If you’re running a test that redirects users from the original URL to a variation URL, use a 302 (temporary) redirect, not a 301 (permanent) redirect.” (tradução) «Se você estiver executando um teste que redireciona usuários da URL original para uma URL de variação, use um redirecionamento 302 (temporário), não um 301 (permanente).» Ir para a citação
- “If we discover a site running an experiment for an unnecessarily long time, we may interpret this as an attempt to deceive search engines and take action accordingly.” (tradução) «Se descobrirmos um site executando um experimento por um tempo desnecessariamente longo, podemos interpretar isso como uma tentativa de enganar os mecanismos de busca e tomar as devidas providências.» Ir para a citação
Craig Bradford, SearchPilot — por que não existe teste de SEO no nível do visitante
- “The ‘user’ we are testing for is Googlebot, not human users. That means it’s not possible, for instance, to show 10,000 ‘Googlebots’ control and variant pages randomly. There is only one Googlebot.” (tradução) «O “usuário” para o qual estamos testando é o Googlebot, não usuários humanos. Isso significa que não é possível, por exemplo, mostrar 10.000 páginas de controle e variação de “Googlebots” aleatoriamente. Existe apenas um Googlebot.» Ir para a citação
- Sobre o mínimo prático: “at least hundreds of pages on the same template and at least 30,000 organic sessions per month to the group of pages you want to test on.” (tradução) «pelo menos centenas de páginas no mesmo modelo e pelo menos 30.000 sessões orgânicas por mês para o grupo de páginas em que você deseja testar.» Ir para a citação
Você deve executar um teste A/B de SEO — e qual tipo?
Um caminho rápido pela decisão.
1. Você tem um grande grupo de páginas semelhantes e com modelo definido? (por exemplo, centenas de páginas de produto, páginas de categoria ou posts de blog que compartilham um modelo)
- Não → o teste dividido de SEO provavelmente ainda não é para você. Você não consegue isolar uma alteração em um grupo de variação limpo. Considere um antes/depois cuidadoso com um conjunto de controle correspondente, mas trate o resultado como direcional, não como prova.
- Sim → continue.
2. Essas páginas recebem tráfego orgânico significativo? (piso prático do SearchPilot: ~30 mil+ sessões orgânicas/mês para o grupo de teste; confortável é de dezenas a centenas de milhares)
- Não / muito baixo → você ainda pode testar, mas apenas efeitos grandes serão registrados. Espere janelas longas e não interprete demais resultados pequenos.
- Sim → continue.
3. O que você está tentando testar?
- Title tags, metas, dados estruturados, links internos, conteúdo, layout → testável. Continue.
- Backlinks, uma alteração em todo o site ou uma atualização de algoritmo → não é confiavelmente testável via teste dividido. Use análise antes/depois ou correlacional e seja honesto sobre o fator de confusão.
4. Qual metodologia?
- Você pode manter um grupo de controle ao vivo de páginas → execute um teste de URL dividida / grupo de páginas (holdout): divida aleatoriamente em controle e variação, compare sessões orgânicas.
- Você não pode manter páginas de fora (a alteração precisa ir para todos os lugares), mas você tem páginas semelhantes não afetadas para modelar → execute um teste de série temporal / impacto causal: preveja o contrafactual e meça a lacuna.
5. Antes de lançar o teste:
- Atribuição aleatória em grupos (sem buckets temáticos antes de um pico sazonal).
- Sirva a variante no servidor/edge, não via JS no cliente.
- Canonicalize as variantes; use 302, não 301, se redirecionar; sem cloaking.
- Comprometa-se com uma duração (geralmente 2–6 semanas) e um nível de significância antes, e não pare cedo em uma tendência promissora.
Erros comuns em testes de SEO
Tratar como um teste de CRO. Executar uma ferramenta de A/B em JavaScript no cliente e assumir que é seguro para SEO porque é seguro para humanos. Mudanças de flicker de conteúdo e carregamento tardio podem ser perdidas ou mal indexadas por crawlers. Sirva as variantes no servidor ou na edge.
Bucketing temático. Colocar todas as suas páginas de “gatos” no grupo de variantes logo antes do Dia Internacional do Gato (exemplo do próprio SearchPilot). Um pico sazonal real então parece uma vitória do teste. Atribua páginas a grupos aleatoriamente para que ambos os grupos tenham uma mistura representativa.
Parar o teste cedo. Declarar um vencedor no momento em que a tendência parece boa. Movimento inicial geralmente é ruído. Comprometa-se com uma duração e um nível de significância antes e mantenha-os.
Julgar por posições. Usar posições de rank tracker ou posição média do Search Console como métrica principal. O rank tracking não cobre toda a cauda de consultas e os dados de posição do GSC são muito esparsos e médios. Meça sessões/cliques orgânicos para o grupo de páginas em vez disso.
Testar algo que você não pode isolar. Tentar “testar backlinks em split” ou atribuir uma mudança de site inteiro/técnica a um grupo de variantes. Se o tratamento vazar para o grupo de controle (ou atingir todos), não há comparação limpa.
Deixar o teste rodando para sempre. O Google avisa explicitamente que experimentos deixados no ar por um tempo desnecessariamente longo podem ser lidos como uma tentativa de enganar. Desmonte o teste e lance o vencedor (ou reverta) assim que tiver sua resposta.
Assumir que o GSC tem um recurso de experimentos. A ferramenta de experimentos que existia era da era AMP. Não monte um plano de testes em torno de um recurso do GSC que não é oferecido atualmente para testes gerais de SEO.
Checklist de configuração de teste A/B de SEO
Passe por isso antes de lançar um teste:
- Você tem um grande grupo de páginas semelhantes, com o mesmo template para testar.
- O grupo de páginas recebe tráfego orgânico suficiente para detectar o efeito que você se importa (mínimo ~30k+ sessões/mês; mais se o efeito for pequeno).
- A mudança é testável (título, meta, heading, dados estruturados, links internos, conteúdo, layout) — não backlinks ou um fator de site inteiro/algoritmo.
- As páginas são atribuídas aleatoriamente a controle e variante — sem buckets temáticos.
- A variante é servida no servidor ou na edge, não via JS no cliente.
- As URLs das variantes são canonicalizadas para a original.
- Quaisquer redirecionamentos são 302, não 301.
- Sem cloaking — Googlebot e humanos veem conteúdo correspondente para cada versão servida.
- Você escolheu a metodologia certa (holdout de URL dividida vs. série temporal/impacto causal) para saber se você pode manter um grupo de controle ao vivo.
- A métrica é sessões/cliques orgânicos para o grupo de páginas, não posições de rank.
- Duração e nível de significância comprometidos antes (tipicamente 2–6 semanas, 95% de confiança) — e um plano para não parar cedo.
- Um plano para desmontar o teste prontamente após a conclusão e lançar ou reverter.
Ferramentas para teste A/B de SEO
- SearchPilot — a plataforma mais associada a testes A/B rigorosos de SEO; executa testes na borda para que as variantes apareçam no HTML visível ao rastreador. Cresceu a partir do ODN da Distilled.
- SEOTesting.com — uma ferramenta de teste mais leve, orientada pelo Search Console, com forte foco em significância estatística.
- seoClarity — suíte de SEO empresarial com um módulo de testes A/B.
CausalImpact— pacote R de código aberto do Google para inferência causal bayesiana com séries temporais estruturais; o método por trás de testes de SEO baseados em séries temporais se você quiser criar sua própria análise.- Google Search Console + Bing Webmaster Tools — para monitoramento de indexação/tráfego durante um teste. Observe que o GSC não possui um recurso geral de experimentos atualmente.
- IndexNow — para fazer com que URLs de variantes sejam rastreadas novamente rapidamente no lado do Bing durante testes iterativos.
- Microsoft Clarity — mapas de calor e gravações de sessão como complemento do lado da UX para a medição do lado do ranqueamento.
Estruturas para projetar um teste de SEO
A estrutura tratamento-controle-resultado
Defina cada teste em três linhas antes de discutir ferramentas:
- Tratamento: a única mudança isolada aplicada às páginas variantes.
- Controle: páginas semelhantes que permanecem inalteradas e compartilham a mesma sazonalidade e condições externas de busca.
- Resultado: cliques orgânicos ou sessões para o grupo de páginas em uma janela pré-definida.
Se o tratamento vazar para o grupo de controle, os grupos não forem comparáveis ou o resultado mudar depois que os resultados aparecerem, o teste não pode sustentar a alegação causal.
A estrutura contrafactual
Todo resultado deve responder: o que provavelmente teria acontecido sem a mudança? Um teste de holdout observa essa comparação por meio de páginas inalteradas. Um teste de série temporal modela isso usando páginas semelhantes não afetadas e o comportamento pré-teste. Um gráfico de antes/depois sem um contrafactual confiável é uma observação, não uma prova.
A estrutura de poder antes do lançamento
O poder estatístico é um requisito de projeto, não um resultado que você negocia depois. Estime se a quantidade de páginas, o tráfego, a variância natural e o efeito esperado podem produzir um sinal detectável. Se não, teste um grupo maior, mire em uma mudança maior, estenda a janela planejada ou rotule o resultado como direcional.
A estrutura de decisão antes dos dados
Escreva as regras de decisão de lançamento antes do início do teste:
- a métrica primária,
- a janela mínima de execução,
- a regra de significância ou intervalo de credibilidade,
- o efeito prático que vale a pena publicar,
- e a ação para resultados positivos, negativos e inconclusivos.
O pré-compromisso impede que uma tendência inicial promissora reescreva o experimento.
Folha de dicas de testes A/B de SEO
| Decisão | Use esta regra |
|---|---|
| Unidade de atribuição | Divida páginas semelhantes, não visitantes ou consultas |
| Método de holdout | Grupos aleatórios de páginas de controle e variantes; compare o tráfego orgânico |
| Método de série temporal | Preveja o contrafactual sem mudança a partir de páginas não afetadas |
| Resultado primário | Cliques orgânicos ou sessões para o grupo de páginas testado |
| Mudanças comuns testáveis | Títulos, metas, cabeçalhos, dados estruturados, links internos, conteúdo, layout |
| Candidatos ruins para testes A/B | Backlinks, atualizações de algoritmo e mudanças que afetam todo o site |
| Entrega | No lado do servidor ou da borda para que os rastreadores recebam a variante em HTML |
| URLs de variantes | Canonicalize para a original; use 302 se redirecionar |
| Janela típica | Pré-comprometa uma janela; muitos testes duram de 2 a 6 semanas |
| Regra de parada | Não pare cedo porque a tendência parece positiva |
| Estado final | Publique ou reverta e remova o experimento imediatamente |
Verificação rápida de validade
- Páginas com o mesmo modelo existem em volume suficiente.
- A atribuição é aleatória, não agrupada por tópico ou temporada.
- Uma alteração muda; todo o resto permanece estável.
- As páginas de controle não são afetadas pela alteração.
- A métrica e a regra de decisão foram escolhidas antes do lançamento.
- Googlebot e usuários não veem conteúdos diferentes.
- A conclusão distingue inconclusivo de sem efeito.
Prompts para planejar e revisar experimentos de SEO
Teste a resistência de um design de experimento
Cole um conjunto de páginas proposto, a alteração, a métrica e a janela de execução. Espere uma crítica do design, não uma previsão do vencedor.
Review this proposed SEO A/B test for causal validity. Identify the treatment,
assignment unit, control, primary outcome, expected recrawl lag, likely confounders,
spillover risks, seasonality risks, compliance issues, and reasons the test may be
underpowered. Recommend changes to randomization and measurement. Do not invent a
minimum sample size or effect estimate when the supplied data cannot support one.
[PASTE TEST DESIGN AND PAGE-GROUP DATA]Interprete um teste concluído sem exagerar
Cole as regras pré-definidas e o resumo do resultado. Espere uma decisão estruturada com a incerteza mantida.
Evaluate this completed SEO test against its precommitted decision rules. Return:
result (positive, negative, or inconclusive), estimated practical effect, statistical
uncertainty, control-vs-variant behavior, evidence of seasonality or algorithm-update
confounding, whether the run window was honored, and the recommended action (ship,
revert, or retest). Do not convert correlation into causation or treat an
inconclusive result as proof of no effect.
[PASTE PRECOMMITTED RULES, TIME SERIES, AND RESULT SUMMARY] Teste-se: teste A/B de SEO
Cinco perguntas sobre como o teste dividido de SEO realmente funciona. Escolha uma resposta para cada uma e depois confira.
Recursos que valem seu tempo
Meus escritos relacionados
- SEO Testing: A Simple (But Complete) Guide — o guia da Ahrefs sobre teste de SEO (da minha época lá), que posiciona o teste A/B/dividido como o mais seguro dos métodos de teste e define as expectativas de tráfego e duração.
- Enterprise SEO Strategies For Maximum Growth — o contexto de escala onde o teste de SEO mais compensa, já que depende de grandes conjuntos de páginas modeladas.
- The Beginner’s Guide to Technical SEO — a base técnica (canonicalização, redirecionamentos, rastreamento) sobre a qual as regras de conformidade aqui se apoiam.
De toda a indústria
- A/B Testing Best Practices for Search — Google Search Central — as regras oficiais: canônico, 302 não 301, sem cloaking, não execute testes para sempre.
- What is SEO A/B testing? — SearchPilot (Craig Bradford) — o explicador mais autoritativo da prática, da equipe que constrói as ferramentas.
- Inferring Causal Impact Using Bayesian Structural Time-Series Models — Brodersen et al., Google — o artigo de pesquisa e o pacote
CausalImpactpor trás do teste de SEO de séries temporais. - Statistical Significance in SEO Testing — SEOTesting.com (Ryan Jones) — o caso para uma barra de confiança de 95% e não parar os testes cedo.
- A/B Test for Better Search Engine Performance with IndexNow and Microsoft Clarity — Bing Webmaster Blog — a visão do Bing: teste de URL dividida para mudanças estruturais, além de IndexNow e Clarity.
- What You Can and Can’t A/B Test for SEO — Gorilla Marketing (Liam Blackledge) — uma explicação clara de por que backlinks e fatores de todo o site ficam fora do teste dividido.
- SEO A/B Testing Guide — VWO — uma perspectiva de fornecedor de CRO com exemplos reais de estudos de caso de aumento orgânico.
Registro de alterações
Atualizado em 19 de jul. de 2026.
Resumo editorial e detalhes registrados da alteração.Detalhes da alteração
- Avançado
As notas detalhadas sobre as alterações estão disponíveis atualmente em inglês.
- Resumo de IA
As notas detalhadas sobre as alterações estão disponíveis atualmente em inglês.
Não é possível fazer a comparação completa — nenhum instantâneo anterior foi arquivado para esta revisão.
Atualizado em 16 de jul. de 2026.
Resumo editorial e detalhes registrados da alteração.Detalhes da alteração
- Para decisores
As notas detalhadas sobre as alterações estão disponíveis atualmente em inglês.
Não é possível fazer a comparação completa — nenhum instantâneo anterior foi arquivado para esta revisão.