Modelo de Teste Dividido de SEO

Planeie e execute testes A/B de SEO em títulos, templates e alterações on-page para comprovar o impacto orgânico com evidências, não com suposições.

A maioria das alterações de SEO entra no ar por palpite e ninguém consegue dizer se ajudaram, prejudicaram ou não fizeram nada. Este modelo guia-o pelo teste de grupos de páginas (buckets), feito para a pesquisa, em que dividimos páginas semelhantes num grupo de teste e num grupo de controlo e comparamos o desempenho orgânico. Use-o para escrever uma hipótese limpa, controlar a sazonalidade e as atualizações de algoritmo, medir com a Search Console e implementar vencedores ou reverter perdedores com um registo documentado.

6 variações prontas para usar

Escolher uma Hipótese e o Tipo de Teste

Transforme uma ideia vaga («títulos novos vão ajudar») numa única hipótese falsificável ligada a uma métrica.

Comece com uma hipótese clara

Escreva-a como uma única frase que possa provar ou refutar. Evite testar cinco coisas ao mesmo tempo, ou não vai saber o que fez a diferença.

Hipótese: [Se alterarmos X neste grupo de páginas, então a métrica orgânica Y vai melhorar, porque Z.]

Tipos comuns de teste de SEO

Reescrita da tag title & meta description (melhor para a taxa de cliques)
Alterações ao template da página (layout, links internos, schema)
Adições ao conteúdo on-page (introduções, FAQ, cabeçalhos)
Ajustes de indexação / técnicos (canónicos, dados estruturados)

Escolha a métrica que corresponde à alteração: os títulos afetam a taxa de cliques & os cliques; o conteúdo e os links afetam as impressões & a posição.

Métrica principal: [Cliques / CTR / Posição média]
Métrica de proteção (não pode cair): [ex. conversões]

Escolher Teste vs. Controlo (Teste de Grupos/Buckets de Páginas)

Divida URLs semelhantes num bucket de teste e num bucket de controlo, uma vez que não pode dividir os utilizadores da pesquisa por cookies.

Porquê não um teste A/B normal?

Em SEO não pode mostrar ao Googlebot duas versões de um mesmo URL, por isso a divisão por cookies ao nível do utilizador não funciona. Em vez disso, testa ao nível do grupo de páginas: altera um bucket de páginas, deixa um bucket equivalente inalterado e compara o desempenho orgânico ao longo do tempo.

Construa dois buckets comparáveis

Escolha um conjunto de páginas semelhantes (mesmo template e intenção, ex. páginas de produto ou de categoria).
Atribua aleatoriamente cada página a teste ou controlo para que tráfego, idade e tema fiquem equilibrados.
Confirme que ambos os buckets têm páginas e cliques suficientes para produzir um sinal, não ruído.

Template de página em teste: [Páginas de categoria]
Páginas no bucket de teste: [n.º de URLs]
Páginas no bucket de controlo: [n.º de URLs]

Mantenha a única diferença entre os buckets como sendo a alteração que está a testar. Nunca sirva ao Googlebot conteúdo diferente do que serve aos utilizadores.

Configurar o Acompanhamento e o Cronograma

Defina quanto tempo o teste corre e exatamente que dados vai extrair antes de alterar seja o que for.

Fixe primeiro o plano de medição

Decida a fonte de dados e o cronograma antes do lançamento para não poder mudar as regras a meio.

Fonte de dados: Search Console (cliques, impressões, CTR, posição média), filtrada pelos conjuntos de URLs de teste e de controlo.
Período prévio: capture uma linha de base limpa para ambos os buckets, idealmente um ciclo de negócio completo.
Período de teste: suficientemente longo para o Google voltar a rastrear, reordenar e acumular cliques, muitas vezes várias semanas.

Registe a linha de base

Janela da linha de base: [datas]
Cliques da linha de base do bucket de teste: [n.º]
Cliques da linha de base do bucket de controlo: [n.º]
Data de lançamento prevista: [data]
Data de fim prevista: [data]

Marque a data de lançamento para alinhar os dados de antes e depois e identificar o momento exato em que a alteração produziu efeito após o novo rastreio.

Executar o Teste (Evitar Fatores de Confusão)

Mantenha a experiência limpa para que um fator externo não seja confundido com o seu resultado.

Aplique a alteração apenas ao bucket de teste

Aplique a alteração a todas as páginas do bucket de teste de uma só vez e congele o bucket de controlo. Depois deixe ambos em paz.

Atenção aos fatores de confusão

Não faça outras alterações a nenhum dos buckets a meio do teste (novos links, redesenhos, preços).
Acompanhe as atualizações de algoritmo e os core updates; anote os que ocorram durante a janela.
Vigie o rastreio & a indexação para que a alteração esteja mesmo no ar e seja vista pelo Google.
Evite picos sazonais a atingir apenas um bucket (ex. uma promoção nas páginas de teste).

Alteração no ar (rastreio confirmado): [data]
Eventos externos registados: [atualizações, notícias, campanhas]

Resista a espreitar e a terminar mais cedo num bom dia. Parar assim que os resultados parecem favoráveis inflaciona os falsos positivos. Deixe o período planeado terminar para que ambos os buckets vivam as mesmas condições externas.

Analisar os Resultados (Significância, Sazonalidade)

Compare teste e controlo de forma justa e decida se o ganho é real ou ruído.

Compare os buckets, não apenas o antes e o depois

Os números brutos de antes e depois são enganadores porque o tráfego varia sazonalmente. O bucket de controlo absorve essas oscilações partilhadas, por isso compare a variação relativa do bucket de teste com a do bucket de controlo nas mesmas datas.

Calcule a variação de cada bucket, da linha de base ao período de teste.
Subtraia a variação do controlo para isolar o efeito da sua edição.
Verifique se a diferença é grande e consistente o suficiente para ser um sinal real, e não ruído de semana para semana.

Verificações de sanidade

Sazonalidade: ambos os buckets moveram-se juntos, exceto pela sua alteração?
Atualizações de algoritmo: uma atualização explicaria a oscilação?
Tamanho da amostra: páginas e cliques suficientes para confiar no resultado?

Variação do bucket de teste: [%]
Variação do bucket de controlo: [%]
Efeito líquido: [+/- %]
Veredito: [Vitória / Derrota / Sem efeito]

Implementar ou Reverter e Documentar

Aja sobre o resultado e capture o aprendizado para que o próximo teste comece mais inteligente.

Decida, depois aja

Vitória clara: implemente a alteração no bucket de controlo e noutras páginas equivalentes.
Derrota clara: reverta o bucket de teste para a versão original.
Sem efeito: reverta ou mantenha por outras razões (UX, acessibilidade), mas não reivindique um ganho de SEO.

Documente cada teste

Um teste que não consegue voltar a encontrar é um teste que vai repetir. Registe-o num local partilhado para que a equipa construa uma biblioteca de evidências.

Nome do teste: [título]
Hipótese: [enunciado]
Resultado: [vitória / derrota / neutro]
Decisão: [implementar / reverter]
O que aprendemos: [insight]
Ideia do próximo teste: [seguimento]

Trate os resultados como evidência para este site, não como lei universal. Volte a testar as vitórias importantes mais tarde, porque o Google muda e o que resultou uma vez pode esmorecer.

Como usar este modelo

Escreva uma hipótese falsificável e escolha uma única métrica principal (cliques, CTR ou posição média) mais uma métrica de proteção que não pode cair.
Escolha um conjunto de páginas semelhantes no mesmo template e depois divida-as aleatoriamente num bucket de teste e num bucket de controlo equivalente, de tamanho e tráfego comparáveis.
Confirme que ambos os buckets têm páginas e cliques suficientes para detetar um sinal real; buckets pequenos produzem ruído em que não pode confiar.
Extraia uma linha de base limpa da Search Console para ambos os buckets ao longo de uma janela representativa antes de alterar seja o que for.
Aplique a alteração apenas ao bucket de teste, congele o bucket de controlo e confirme que o Google voltou a rastrear as páginas de teste.
Mantenha ambos os buckets estáveis durante todo o período planeado, registe quaisquer atualizações de algoritmo ou campanhas e resista a parar mais cedo.
Compare a variação do bucket de teste com a variação do bucket de controlo nas mesmas datas para isolar o efeito real e descartar a sazonalidade.
Implemente as vitórias em páginas equivalentes, reverta os perdedores e documente a hipótese, o resultado, a decisão e o aprendizado para o próximo teste.

Dicas profissionais

Teste uma variável de cada vez. Se alterar títulos e templates em conjunto, um resultado não lhe diz nada sobre qual deles funcionou.
Compare sempre contra um bucket de controlo, nunca com números brutos de antes e depois. O controlo absorve oscilações sazonais e atualizações de algoritmo que, de outra forma, o enganariam.
Dê tempo ao Google para voltar a rastrear e reordenar antes de ler os resultados, e confirme que a alteração está mesmo indexada e não apenas publicada.
Nunca faça cloaking nem sirva ao Googlebot conteúdo diferente do dos utilizadores reais para correr um teste. Ambos os buckets têm de mostrar conteúdo idêntico a bots e visitantes.

Perguntas frequentes

Porque não posso correr um teste A/B normal para SEO como faço para a taxa de conversão?

As ferramentas de CRO dividem visitantes humanos por cookies e mostram a cada pessoa uma versão diferente do mesmo URL. Não pode fazer isso com o Google, porque um URL tem de servir uma só versão ao rastreador, e mostrar ao bot algo diferente dos utilizadores é cloaking. Em vez disso, os testes de SEO funcionam ao nível do grupo de páginas: divide páginas semelhantes num bucket de teste e num bucket de controlo e compara o seu desempenho orgânico ao longo do tempo.

De quantas páginas preciso para correr um teste dividido de SEO fiável?

Não há um número fixo, mas precisa de páginas suficientes e cliques suficientes por bucket para que o resultado seja um sinal e não ruído. Um punhado de páginas com pouco tráfego vai oscilar descontroladamente de semana para semana e não lhe diz nada. Testes em grandes conjuntos de páginas semelhantes (pense em templates de categoria ou de produto com tráfego orgânico estável) dão leituras mais limpas do que testes em algumas páginas avulsas.

Quanto tempo deve durar um teste de SEO?

O suficiente para o Google voltar a rastrear e reordenar as páginas de teste e para ambos os buckets acumularem cliques significativos, o que muitas vezes significa várias semanas. Correr o teste, idealmente, ao longo de um ciclo de negócio completo ajuda a nivelar os padrões de dias úteis e fins de semana. Evite terminar o teste cedo só porque os resultados parecem bons num dia, já que parar num pico favorável inflaciona os falsos positivos.

Como separo a minha alteração da sazonalidade ou de uma atualização de algoritmo?

É exatamente para isso que serve o bucket de controlo. A sazonalidade e os core updates tendem a mover páginas semelhantes em conjunto, por isso, se ambos os buckets sobem e descem a par, esses são efeitos partilhados. O que lhe interessa é quanto o bucket de teste variou para além do bucket de controlo nas mesmas datas. Registe sempre quaisquer atualizações de algoritmo durante a janela para as poder descartar.

O que meço, e de onde vêm os dados?

A Google Search Console é a fonte principal: cliques, impressões, taxa de cliques e posição média, filtrados pelos URLs exatos de cada bucket. Faça corresponder a métrica à alteração. Os testes de title e meta description movem sobretudo a taxa de cliques e os cliques, enquanto o conteúdo, os links internos e as alterações de template aparecem mais nas impressões e na posição média.

O que devo fazer quando um teste vence, perde ou não mostra efeito?

Implemente uma vitória clara no bucket de controlo e noutras páginas equivalentes. Reverta um perdedor claro para o original. Se não houver efeito mensurável, reverta ou mantenha a alteração por outras razões, como usabilidade, mas não reivindique um ganho de SEO que não consegue provar. Em todos os casos, documente a hipótese, o resultado, a decisão e o aprendizado para que a equipa construa uma biblioteca de evidências em vez de repetir suposições.