SEO para testes A/B na edge

TL;DR — Testes A/B na edge significam executar um teste dividido na sua CDN — a rede que fica na frente do site — em vez de no navegador ou no seu servidor. Um pequeno script na edge decide qual versão de uma página cada visitante recebe, antes de a página chegar até ele. Para SEO, isso é uma boa notícia: o Google vê HTML real, não uma troca feita por JavaScript. O ponto essencial é ter consistência — não deixe o Google ver uma versão diferente da dos usuários e não mantenha o teste ativo para sempre. Testar é permitido; mostrar ao Google algo diferente do que as pessoas veem é cloaking, contra as regras.

O que é teste A/B na edge

O teste A/B na edge atribui e modifica variantes na camada de entrega, em vez de exigir que a aplicação de origem renderize cada variação. Evidence for this claim Cloudflare Workers can execute code and modify requests or responses at the network edge. Scope: Cloudflare Workers; other edge platforms have different runtimes and controls. Confidence: high · Verified: 2026-07-14 Cloudflare: Workers overview O Google permite testes de sites, mas alerta contra cloaking e recomenda experimentos temporários e controlados.

Um teste A/B mostra a versão A de uma página para alguns visitantes e a versão B para outros, para que você meça qual tem melhor desempenho. O teste A/B na edge significa apenas que a escolha da versão acontece na sua CDN (Cloudflare, Akamai, Fastly ou uma ferramenta como Optimizely ou VWO executada na edge), e não no navegador do visitante ou no seu próprio servidor web.

Há três lugares onde um teste pode acontecer, e isso importa muito para SEO:

1. No cliente — JavaScript no navegador troca o conteúdo depois que a página carrega. É rápido de configurar, mas o Google pode nunca ver a alteração, pois nem sempre espera pelo JavaScript tardio.
2. No servidor de origem — seu servidor de aplicação cria a versão escolhida e a envia como HTML real.
3. Na edge — a CDN cria ou reescreve a versão escolhida como HTML real, antes que a solicitação sequer chegue ao servidor. O mesmo benefício de SEO do lado do servidor, além de ser mais rápido e não exigir um deploy de código.

Por que a edge é um lugar mais seguro para testar (para SEO)

A grande vantagem: como a edge envia HTML real, mecanismos de busca e usuários recebem o mesmo tipo de página. Isso contorna o maior problema dos testes no cliente, em que o Google pode não ver a versão testada.

A única regra: não mostre ao Google algo diferente das pessoas

O Google aceita perfeitamente testes A/B — diz isso na própria documentação. O que ele não aceita é cloaking: mostrar deliberadamente aos mecanismos de busca um conteúdo diferente do que você mostra a usuários reais para manipular rankings. O segredo de um teste seguro na edge é garantir que o Googlebot veja uma versão legítima e consistente da página — o mesmo tipo de página que qualquer usuário real poderia receber —, não uma “versão para bots” especial.

Duas coisas podem quebrar essa regra acidentalmente na edge:

• Cookies. A maioria dos testes na edge memoriza a versão atribuída ao visitante com um cookie. Em geral, o Googlebot não mantém cookies — portanto pode ser reatribuído aleatoriamente a uma versão diferente a cada visita. Isso não significa que você está tentando trapacear, mas ainda pode parecer desorganizado para o Google.
• Redirecionamentos para uma segunda URL. Se o teste envia visitantes para uma URL ligeiramente diferente (como ?variant=b), o Google pode tratá-la como uma página separada e indexar as duas.

As duas coisas têm correção, e a aba Avançado explica exatamente como — além de mostrar por quanto tempo você pode executar um teste com segurança e se “simplesmente dar aos bots a versão normal” é um atalho inteligente ou uma armadilha.

TL;DR — Os testes A/B na edge servem HTML de variantes ou redirecionam na camada do worker da CDN antes que a origem sequer veja a solicitação. Como os mecanismos recebem HTML real (não uma troca de JS no cliente), este é o lugar mais seguro para testar — mas há uma superfície de risco específica da edge. Separe dois padrões: reescritas de HTML na mesma URL (risco: o Googlebot em geral não mantém cookies, então o agrupamento por cookie pode mostrar uma nova variante aleatória a cada rastreamento) e redirecionamentos para uma URL de variante (risco: confusão de conteúdo duplicado/canonical). Correções: tornar determinístico o tráfego de bots/sem cookie, aplicar rel=canonical da variante de volta ao controle, usar 302, não 301, enquanto estiver ativo e desmontar o teste assim que houver um vencedor. A regra do Google é “testar é permitido, cloaking não” — cloaking trata de intenção e assimetria, não de “um bot ter visto a variante B uma vez”. Eu trataria o que é SEO na edge apenas brevemente aqui — o artigo geral de SEO na edge deste cluster é responsável pelo tour da plataforma; este artigo trata dos riscos específicos de testes.

O que realmente muda ao testar na edge

Um edge worker pode rotear ou transformar uma resposta perto do visitante, o que muda onde a atribuição acontece, mas não a lógica experimental subjacente. Evidence for this claim Cloudflare Workers can execute code and modify requests or responses at the network edge. Scope: Cloudflare Workers; other edge platforms have different runtimes and controls. Confidence: high · Verified: 2026-07-14 Cloudflare: Workers overview A segurança na busca depende de servir variantes legítimas do teste de forma consistente, não de direcionar conteúdo materialmente diferente aos rastreadores de busca.

O teste A/B na edge é um caso de uso de SEO na edge: você faz o agrupamento e a reescrita do HTML (ou o redirecionamento) em um worker da CDN — Cloudflare Workers, Akamai EdgeWorkers/EdgeKV, Fastly Compute ou as integrações edge/server-side da Optimizely e da VWO — antes de a solicitação chegar à origem. A SearchPilot descreve SEO na edge como “any SEO changes that are made after the HTML is created by your CMS or origin server before it is served to the user,” e destaca o ponto principal: “They appear to all users and googlebot as server side HTML changes, so there are no risks or downsides from an indexation point of view.” Essa é a vantagem de base — a edge é um lugar seguro para testar porque os mecanismos recebem HTML real, como no lado da origem.

Então por que este artigo existe se a edge é segura? Porque onde você testa é seguro; como você faz o agrupamento na edge é onde vivem as armadilhas específicas de SEO. Duas delas são quase exclusivas deste padrão, e artigos genéricos sobre “testes A/B e SEO” passam pelas duas sem explicar.

A posição real do Google: testar é permitido, cloaking não

Diga isso claramente, porque metade do medo em torno de testes de SEO é equivocada. O Google apoia explicitamente testes A/B e multivariados e publica boas práticas para eles. A linha que ele traça é o cloaking, que sua política de spam define como “presenting different content to users and search engines with the intent to manipulate search rankings and mislead users.” Observe a intenção de manipular e a assimetria entre usuários e mecanismos — não “um bot já viu uma variante”. A Optimizely parafraseia o mesmo ponto aos próprios clientes: “Google encourages constructive testing and does not view the ethical use of testing tools such as Optimize to constitute cloaking.”

A linha divisória prática que o Google fornece na documentação de testes é direta: “Don’t show one set of URLs to Googlebot, and a different set to humans.” Se o seu teste na edge respeita isso — todos, inclusive bots, são elegíveis para as mesmas variantes legítimas, servidas de forma consistente — você está do lado certo da política.

Os dois padrões de teste na edge (e seus riscos diferentes)

Mantenha os dois separados na sua cabeça, porque falham de formas diferentes e recebem correções diferentes.

Padrão 1 — HTML da mesma URL reescrito na edge

O worker mantém a URL igual (/product/123) e troca um título, um CTA ou um formato de exibição de preço — o HTML Rewriter reescreve a resposta durante o envio. Este é o modelo de “teste A/B com acesso direto na mesma URL” do Cloudflare Workers, que, como dizem os documentos, “Choose a group and set the cookie (50/50 split)” para um novo visitante.

O risco específico da edge: cookies. O Google afirma diretamente — “Googlebot generally doesn’t support cookies. This means it will only see the content version that’s accessible to users with browsers that don’t accept cookies.” Quase toda implementação na edge persiste o grupo em um cookie para manter um visitante humano no mesmo grupo (o exemplo EdgeKV da Akamai faz exatamente isso: “Client bucket selection will be persistent via a cookie value to ensure a client is locked to the same URL on subsequent visits”). Mas o Googlebot não carrega esse cookie, portanto a cada rastreamento pode entrar novamente no aleatorizador e cair em um grupo diferente do anterior. Isso não é cloaking enganoso — mas significa que o Google pode indexar uma versão flutuante e inconsistente da mesma URL ao longo do tempo. É o primo mais sutil e nativo da edge do problema clássico “mostramos deliberadamente algo diferente aos bots”, e é a coisa mais importante que este artigo precisa explicar.

Padrão 2 — um redirecionamento da edge para uma URL de variante

Aqui o worker redireciona /product/123 com 302 para uma URL distinta — /product/123?v=b ou /product/123-b. Agora você tem uma URL genuinamente diferente que os mecanismos podem descobrir e indexar por conta própria.

O risco específico da edge: conteúdo duplicado e confusão de canonical. Se o Google indexar a URL de variante como uma página própria, você dividiu os sinais e possivelmente criou uma duplicata.

Corrigindo o padrão 1: tornar os rastreadores determinísticos

A correção não é “detectar o bot e esconder o teste”. É não deixar que solicitações sem cookie recebam uma escolha aleatória. Agrupe humanos por cookie se quiser, mas, para qualquer solicitação sem cookie — inclusive a do Googlebot — resolva a variante de forma determinística: aplique hash à URL, fixe por uma chave estável ou simplesmente sirva o controle sempre. O ponto é que a mesma URL sempre produza a mesma variante para qualquer cliente sem cookie, para que o Google veja uma página estável a cada rastreamento, em vez de jogar uma moeda.

O Cloudflare documenta um mecanismo útil: “Enable Passthrough to allow direct access to control and test routes.” O Passthrough permite que qualquer pessoa — bots, QA e stakeholders — alcance consistentemente /control/* ou /test/*, em vez de ser aleatorizada novamente a cada solicitação sem cookie. Esta é a alavanca documentada oficialmente para dar aos rastreadores uma variante consistente sem inventar um caminho exclusivo para bots.

O modelo da SearchPilot evita isso por completo ao dividir em outro nível: “When doing SEO A/B testing, there is only one version of the page. We are not showing different versions of the same page to users or Google. This isn’t cloaking and doesn’t create any duplicate versions of the same page.” Eles dividem páginas de forma determinística (uma dada página sempre mostra a mesma variante a todos), em vez de dividir usuários aleatoriamente — a filosofia de agrupamento oposta ao exemplo 50/50 por cookie do Cloudflare, e um perfil de risco de SEO genuinamente diferente, embora os dois sejam chamados de “teste A/B na edge”. Como dizem: “There is only one Googlebot. You also can’t make two versions of a single page because it would cause problems like duplicate content.”

Corrigindo o padrão 2: disciplina de canonical + redirecionamento

Quando o teste vive em sua própria URL, três regras da documentação de testes do Google se aplicam diretamente:

• Aplique canonical da variante de volta ao controle. Google: “you can use the rel=“canonical” link attribute on all of your alternate URLs to indicate that the original URL is the preferred version.” Toda URL de variante aponta sua canonical para a URL de controle.
• Use 302, não 301, enquanto o teste estiver ativo. Google: “use a 302 (temporary) redirect, not a 301 (permanent) redirect.” Um 302 informa ao Google que a mudança é temporária e que a original deve continuar indexada; um 301 diz que é permanente. Guarde o 301 para depois de escolher um vencedor e assumir o resultado.
• Desmonte quando terminar. Google: “Once you’ve concluded the test, update your site with the desired content variation(s) and remove all elements of the test as soon as possible… we may interpret this as an attempt to deceive search engines and take action accordingly.”

Uma ressalva honesta sobre canonical: é uma dica, não uma diretiva. Se o conteúdo da variante diferir substancialmente do controle, o Google pode ignorar sua canonical e indexar as duas — exatamente por isso o padrão 2 é mais arriscado que uma reescrita na mesma URL e mudanças estruturais grandes são melhor tratadas como divisão de páginas do que como uma URL de variante por usuário.

Orçamento de rastreamento: o problema da multiplicação multivariada

Um único teste A/B adiciona um estado extra que um rastreador pode ver. Um teste multivariado multiplica os estados: três variáveis independentes com duas variantes cada podem produzir até oito combinações distintas que um rastreador teoricamente encontraria se o agrupamento não fosse persistente e determinístico por URL. O agrupamento não determinístico transforma uma URL em uma nuvem mutável de estados, e cada estado rastreável distinto consome orçamento de rastreamento. Esse ângulo de permutações compostas praticamente não aparece na maioria dos textos sobre testes e SEO, e é por isso que um agrupamento determinístico e persistente importa para eficiência de rastreamento, não apenas para cloaking. (A orientação do Google “Crawling December” de 2024 sobre CDNs e crawl budget é a leitura de contexto certa; o artigo geral de SEO na edge deste cluster aponta para ela.)

“Simplesmente sirva aos bots a variante de controle” — atalho ou armadilha?

Esta ideia exige cuidado, porque é um conselho meio certo. Servir aos rastreadores uma versão de controle estável é aceitável — até bom — se esse controle for genuinamente a versão que você teria satisfação em entregar sempre a qualquer usuário e em deixar o Google indexar. A segurança vem da consistência e legitimidade, não da detecção de bots.

Isso vira cloaking no momento em que o “caminho de bot” existe especificamente para mostrar aos mecanismos uma realidade diferente da que usuários reais recebem — essa é a frase literal do Google: “Don’t show one set of URLs to Googlebot, and a different set to humans”. Portanto, o enquadramento correto é: sirva aos rastreadores a mesma variante determinística que você aceitaria que qualquer usuário sempre visse — não um caminho especial exclusivo para bots, criado para escapar da fiscalização. Usar detecção de UA para “excluir bots do teste” só é seguro porque você padronizou uma versão verdadeira; não é seguro como técnica geral.

Por quanto tempo você pode executar um teste na edge?

O Google não dá um número de dias. Ele alerta contra deixar elementos de teste no lugar por tanto tempo que o “teste” se torne silenciosamente o estado permanente do site sem que você jamais declare um vencedor — é a frase “remove all elements of the test as soon as possible” novamente. John Mueller, do Google, já falou sobre isso: executar continuamente novos experimentos, um após o outro, é aceitável, mas um único teste deixado indefinidamente até virar a página permanente de fato começa a parecer que não é mais um teste. (Os comentários de Mueller aqui são retransmitidos por cobertura do setor de um Google Webmaster Central Hangout, não por um documento oficial do Google — trate a redação como paráfrase.) Mueller também observou que executar um teste A/B durante uma migração de site confunde os sinais de redirecionamento necessários para o Google reconhecer a migração corretamente; evite sobrepor os dois.

A Optimizely, ao reapresentar o Google aos clientes, oferece uma regra prática: “If you are running an experiment for an unnecessarily long time, Google may interpret this as an attempt to deceive search engines and take action accordingly.” E, sobre publicar um vencedor, a Optimizely estima que um redirecionamento 301 carrega “a small loss of link equity (around 10%)” — esse é um número da Optimizely e uma regra prática, não um número confirmado pelo Google; trate-o como tal.

A orientação do Bing é mais limitada — use a do Google como padrão

O Bing não tem uma página dedicada a testes A/B na edge/CDN tão detalhada quanto a do Google. O que ele tem: um padrão geral de cloaking que depende de conteúdo materialmente equivalente — “as long as you make a good faith effort to return the same content to all visitors, with the only difference being the content is rendered on the server for bots and on the client for real users, this is acceptable and not considered cloaking” (Tradução: “desde que você faça um esforço de boa-fé para devolver o mesmo conteúdo a todos os visitantes, com a única diferença de que o conteúdo é renderizado no servidor para bots e no cliente para usuários reais, isso é aceitável e não é considerado cloaking.”) — e uma observação de que, para “significant structural changes, we recommend hosting each version on separate URLs, or split URL testing,” (Tradução: “se você estiver criando mudanças estruturais significativas, recomendamos hospedar cada versão em URLs separadas ou fazer testes com divisão por URL.”), com IndexNow para que URLs de variantes sejam vistas rapidamente. Como o padrão do Bing é compatível com o do Google, aplique as regras de canonical/302/duração do Google como padrão conservador para os dois mecanismos.

Onde isso se encaixa

Este é o complemento específico de testes do artigo geral sobre SEO na edge deste cluster — aquele é responsável pelo tour da plataforma (quais workers existem, o que mais você pode fazer na edge); este trata apenas do risco de testes divididos. A mecânica de canonical e conteúdo duplicado do padrão 2 usa as mesmas ideias das análises aprofundadas de canonicalização e conteúdo duplicado, e o ângulo de crawl-budget se conecta ao material sobre rastreamento e orçamento de rastreamento — tudo em outras partes do site.

Resumo de IA

Uma síntese da versão Avançada:

• Os testes A/B na edge executam testes divididos na camada de workers da CDN (Cloudflare Workers, Akamai EdgeWorkers, Fastly Compute, edge da Optimizely/VWO), para que HTML de variantes ou redirecionamentos sejam servidos antes da origem. Os mecanismos recebem HTML real, portanto é um lugar seguro para testar — muito mais seguro que testes com troca de JS no cliente.
• Posição do Google: testar é permitido; cloaking não. Cloaking é definido pela intenção de manipular e pela assimetria entre usuários e bots — não pelo fato de “a bot ever saw variant B.” (Tradução: “um bot ter visto a variante B.”)
• Dois padrões, dois riscos. (1) Reescrita de HTML na mesma URL: o Googlebot geralmente não mantém cookies, então o agrupamento por cookie pode reatribuí-lo a uma variante diferente a cada rastreamento → conteúdo indexado inconsistente. (2) Redirecionamento para uma URL de variante: confusão de conteúdo duplicado/canonical.
• Correções. Torne o tráfego de bots/sem cookie determinístico (sempre a mesma variante por URL; o “passthrough” do Cloudflare é um modelo). Faça rel=canonical de toda URL de variante de volta para o controle. Use um 302, não 301, enquanto estiver ativa. Remova o teste assim que tiver um vencedor.
• Divisão por página versus por usuário. A divisão determinística por página no estilo SearchPilot evita completamente o problema dos cookies; o agrupamento aleatório por cookie por usuário (exemplos do Cloudflare/Akamai) precisa do fallback determinístico.
• Orçamento de rastreamento se multiplica com testes multivariados — muitas variáveis independentes multiplicam os estados rastreáveis se o agrupamento não for persistente/determinístico.
• “Serve bots the control” (Tradução: “sirva aos bots o controle”) é seguro apenas se esse controle for genuinamente o que você quer indexar — a segurança vem da consistência e da legitimidade, não da detecção de bots.
• Duração: não há limite fixo, mas não deixe o teste se tornar o estado permanente; evite executar testes durante uma migração. A orientação do Bing é mais limitada — use a do Google como padrão.

Qual padrão de teste na edge você está executando — e qual é a correção?

A maioria dos problemas de SEO em testes na edge se resume a duas perguntas: o teste muda a URL e a variante do crawler é determinística? Siga este fluxo para encontrar a correção aplicável.

Documentação oficial

Orientações de fonte primária dos mecanismos de busca e dos fornecedores de plataformas.

Google

• Práticas recomendadas para testes A/B na busca — a orientação sobre canonical/302/duração/cookies em que todo este artigo se baseia.
• Políticas de spam — Cloaking — a definição de cloaking (intenção de manipular + assimetria).

Bing / Microsoft

• Teste A/B para melhorar o desempenho nos mecanismos de busca com IndexNow e Microsoft Clarity — a observação (limitada) do Bing sobre testes A/B; URLs separadas para mudanças estruturais, IndexNow para que sejam vistas.
• Série bingbot: JavaScript, renderização dinâmica e cloaking. Oh, meu Deus! — o padrão de cloaking do Bing de conteúdo equivalente em boa-fé e materialmente.

Fornecedores de CDN / plataformas de testes

• Cloudflare Workers — teste A/B com acesso direto na mesma URL — o exemplo de cookie 50/50 e o padrão “passthrough” para acesso consistente à variante.
• Akamai — criando um teste A/B com EdgeWorkers e EdgeKV — agrupamento na edge bloqueado por cookie (observe: a documentação não trata de SEO/bots).
• Optimizely — testes A/B e otimização para mecanismos de busca — orientação do fornecedor que repete as regras do Google para seus próprios clientes.

Citações da fonte

Declarações registradas do Google, do Bing e dos fornecedores de plataformas. Cada link do Google/Bing/Cloudflare é um deep link que salta para o trecho citado na página de origem.

Google — práticas recomendadas para testes A/B

• “Don’t show one set of URLs to Googlebot, and a different set to humans.” (Tradução: “não mostre um conjunto de URLs ao Googlebot e um conjunto diferente aos humanos.”) Salte para a citação
• “Googlebot generally doesn’t support cookies. This means it will only see the content version that’s accessible to users with browsers that don’t accept cookies.” (Tradução: “o Googlebot geralmente não oferece suporte a cookies. Isso significa que ele verá apenas a versão do conteúdo acessível a usuários com navegadores que não aceitam cookies.”) — a citação central para testes na edge. Salte para a citação
• “you can use the rel=“canonical” link attribute on all of your alternate URLs to indicate that the original URL is the preferred version.” (Tradução: “você pode usar o atributo de link rel=“canonical” em todas as URLs alternativas para indicar que a URL original é a versão preferencial.”) Salte para a citação
• “use a 302 (temporary) redirect, not a 301 (permanent) redirect.” (Tradução: “use um redirecionamento 302 (temporário), não um redirecionamento 301 (permanente).”) Salte para a citação
• “Once you’ve concluded the test, update your site with the desired content variation(s) and remove all elements of the test as soon as possible… we may interpret this as an attempt to deceive search engines and take action accordingly.” (Tradução: “assim que concluir o teste, atualize seu site com a(s) variação(ões) de conteúdo desejada(s) e remova todos os elementos do teste o mais rápido possível… podemos interpretar isso como uma tentativa de enganar os mecanismos de busca e agir de acordo.”) Salte para a citação

Google — cloaking (política de spam)

• “Cloaking refers to the practice of presenting different content to users and search engines with the intent to manipulate search rankings and mislead users.” (Tradução: “cloaking é a prática de apresentar conteúdo diferente a usuários e mecanismos de busca com a intenção de manipular rankings de busca e induzir usuários ao erro.”) Salte para a citação

Bing / Microsoft

• “as long as you make a good faith effort to return the same content to all visitors, with the only difference being the content is rendered on the server for bots and on the client for real users, this is acceptable and not considered cloaking.” (Tradução: “desde que você faça um esforço de boa-fé para devolver o mesmo conteúdo a todos os visitantes, com a única diferença de que o conteúdo é renderizado no servidor para bots e no cliente para usuários reais, isso é aceitável e não é considerado cloaking.”) Salte para a citação
• “If you’re creating significant structural changes, we recommend hosting each version on separate URLs, or split URL testing.” (Tradução: “se você estiver criando mudanças estruturais significativas, recomendamos hospedar cada versão em URLs separadas ou fazer testes com divisão por URL.”) Salte para a citação

Cloudflare Workers — o exemplo de mesma URL

• “Enable Passthrough to allow direct access to control and test routes.” (Tradução: “ative o Passthrough para permitir acesso direto às rotas de controle e de teste.”) — a forma documentada de dar aos crawlers (e ao QA e às partes interessadas) uma variante consistente em vez de um sorteio aleatório por cookie. Salte para a citação

Akamai — o exemplo EdgeKV

• “Client bucket selection will be persistent via a cookie value to ensure a client is locked to the same URL on subsequent visits.” (Tradução: “a seleção do bucket do cliente será persistente por meio de um valor de cookie para garantir que o cliente fique preso à mesma URL em visitas subsequentes.”) (A documentação da Akamai é puramente de engenharia de conversão — vale observar que não contém nenhum enquadramento de SEO, bot ou crawler; a lente de SEO precisa ser trazida por você.)

Optimizely — orientação do fornecedor para seus clientes

• “Google encourages constructive testing and does not view the ethical use of testing tools such as Optimize to constitute cloaking.” (Tradução: “o Google incentiva testes construtivos e não considera que o uso ético de ferramentas de teste como o Optimize constitua cloaking.”)
• “If Google determines that the variation of your page is substantially different from the original in scope and content, then they may construe this change as cloaking.” (Tradução: “se o Google determinar que a variação da sua página é substancialmente diferente da original em escopo e conteúdo, ele poderá interpretar essa mudança como cloaking.”) (Estas são afirmações da Optimizely para seus próprios clientes, repetindo a leitura que o fornecedor faz da política do Google — trate-as como orientação de fornecedor, não como autoridade independente. A frequentemente citada “perda de cerca de 10% do valor dos links em um 301” também é uma regra prática da Optimizely, não um número confirmado pelo Google.)

SearchPilot — metodologia de divisão por página

• “When doing SEO A/B testing, there is only one version of the page. We are not showing different versions of the same page to users or Google. This isn’t cloaking and doesn’t create any duplicate versions of the same page.” (Tradução: “ao fazer testes A/B de SEO, existe apenas uma versão da página. Não mostramos versões diferentes da mesma página a usuários ou ao Google. Isso não é cloaking e não cria versões duplicadas da mesma página.”) (A SearchPilot é um fornecedor de testes server-side/na edge descrevendo sua própria abordagem de divisão por página; a citação aparece aqui como contraste metodológico com o agrupamento aleatório por cookie.)

Checklist de SEO para testes A/B na edge

Execute esta lista antes de publicar um teste na edge que toque em páginas indexadas:

• Você sabe qual padrão está executando: reescrita de HTML na mesma URL ou redirecionamento para uma URL de variante.
• Solicitações sem cookie são determinísticas. O Googlebot (que geralmente não mantém cookies) sempre resolve para a mesma variante por URL — não para um novo sorteio aleatório.
• Se for uma URL de variante, toda variante carrega uma rel=canonical apontando para a URL de controle.
• O redirecionamento durante o teste é um 302, não um 301. (301 apenas para o vencedor, depois do teste.)
• A variante que os crawlers veem é uma versão legítima e representativa que você teria satisfação em indexar — não um caminho exclusivo para bots criado para esconder o experimento.
• Você não usa detecção de UA para mostrar aos bots algo diferente dos usuários reais e escapar da fiscalização.
• Em um teste multivariado, o agrupamento é persistente/determinístico por URL para não multiplicar estados rastreáveis.
• Existe um fim definido: um momento de escolher o vencedor e um plano para remover prontamente toda a estrutura do teste (nenhum teste permanece como página permanente de fato).
• O teste não se sobrepõe a uma migração de site (isso confunde os sinais de redirecionamento).
• As regras de WAF / bots da CDN não bloqueiam nem desviam silenciosamente o Googlebot antes de o worker do teste ser executado.
• Você verificou na Inspeção de URL / nos logs qual variante o Googlebot realmente recebe.

Modelos mentais

1. Testar é permitido; cloaking não. O Google incentiva testes A/B e multivariados. O risco não está no teste, mas no tratamento assimétrico de bots e usuários (com intenção de manipular) ou em deixar o teste rodando até se tornar efetivamente o site permanente. Ancore cada decisão nisso.

2. Dois padrões, duas correções.

• Reescrita de HTML na mesma URL → o risco é rastreamento inconsistente (agrupamento por cookie + Googlebot sem cookies). Correção: variante determinística para tráfego sem cookie.
• Redirecionamento para URL de variante → o risco é conteúdo duplicado / confusão de canonical. Correção: canonical para o controle + 302 enquanto ativo.

3. Consistência e legitimidade, não detecção de bots, são o que mantém você seguro. Servir um controle estável aos crawlers é aceitável apenas porque ele é uma versão legítima que você indexaria de qualquer maneira. A segurança vem da consistência, não do ato de detectar um bot. Um caminho exclusivo para bots criado para esconder conteúdo é a definição de cloaking.

4. Divisão por página versus por usuário. A divisão determinística por página (uma variante por página, igual para todos) evita completamente o problema dos cookies. O agrupamento aleatório por cookie por usuário precisa de um fallback determinístico para crawlers. Ambos são chamados de “teste A/B na edge”, mas têm perfis de risco muito diferentes.

5. Estado rastreável = orçamento de rastreamento. Cada estado distinto em que uma URL pode ser rastreada custa orçamento. Um teste A/B adiciona um estado; um teste multivariado os multiplica, a menos que o agrupamento seja persistente e determinístico por URL.

6. Cliente < origem server-side ≈ edge (para visibilidade de SEO). Trocas de JS no cliente podem não ser vistas pelos mecanismos de busca. Origem server-side e edge servem HTML real — a edge apenas o faz mais rápido e antes da origem, ao custo das armadilhas de cookies/redirecionamentos descritas acima.

Testes A/B na edge — folha de consulta

Os dois padrões

Regras de redirecionamento durante o teste

“Serve bots the control” — safe or not? (Tradução: “sirva aos bots o controle — seguro ou não?”)

• Seguro: o controle é genuinamente representativo e é o que você indexaria de qualquer maneira; o ponto é a consistência.
• Não é seguro: um caminho exclusivo para bots criado para mostrar aos mecanismos uma realidade diferente da dos usuários → cloaking.

Fatos rápidos

• O Googlebot geralmente não mantém cookies → o agrupamento apenas por cookie não é confiável para bots.
• Canonical é uma dica, não uma diretiva → variantes estruturais grandes podem fazer ambas as URLs serem indexadas.
• Não há limite fixo de duração, mas não deixe um teste se tornar o estado permanente; não o execute durante uma migração.
• O Bing não tem uma página dedicada a testes A/B na edge — use as regras do Google como padrão.
• A “~10% link-equity loss on a 301” (Tradução: “perda de cerca de 10% do valor dos links em um 301”) da Optimizely é uma regra prática do fornecedor, não um número do Google.

Mitos e erros de testes na edge a evitar

As armadilhas que aparecem com mais frequência — várias são mitos repetidos à exaustão que vale corrigir:

• “Testing is inherently risky / against the rules.” (Tradução: “testar é inerentemente arriscado / contra as regras.”) Não. O Google incentiva testes A/B e multivariados construtivos. O risco está na implementação, não no ato de testar.
• “If I exclude bots from the test entirely, I’m safe.” (Tradução: “se eu excluir completamente os bots do teste, estou seguro.”) Apenas parcialmente. Servir um controle estável aos bots é aceitável se esse controle for genuinamente a versão que você indexaria. Criá-lo como “bot-detection to dodge scrutiny,” (Tradução: “detecção de bots para escapar da fiscalização”) é cloaking clássico — mostrar aos mecanismos uma realidade diferente da que os usuários reais recebem.
• “Cookie bucketing is fine — that’s how ad-tech always does A/B tests.” (Tradução: “o agrupamento por cookie é aceitável — é assim que a ad tech sempre faz testes A/B.”) Não para SEO. O Google afirma que o Googlebot geralmente não mantém cookies, então uma lógica somente por cookie feita para humanos se comporta de modo imprevisível para crawlers sem um fallback determinístico.
• “A 301 to the winner is basically the same as a 302 during the test.” (Tradução: “um 301 para o vencedor é basicamente igual a um 302 durante o teste.”) Não. 302 diz temporário (continue indexando o original); 301 diz permanente. Use 301 somente depois de assumir o vencedor.
• “A canonical tag guarantees Google won’t index my variant URL.” (Tradução: “uma tag canonical garante que o Google não indexará minha URL de variante.”) Não. Canonical é uma dica. Se o conteúdo da variante diferir substancialmente do controle, o Google pode ignorá-la e indexar ambas — por isso grandes mudanças estruturais pertencem a uma divisão por página, não a uma URL de variante por usuário.
• “Edge, origin server-side, and client-side testing carry the same SEO risk.” (Tradução: “testes na edge, na origem server-side e no cliente têm o mesmo risco de SEO.”) Não. Trocas de JS no cliente podem não ser vistas pelos mecanismos; edge/origem servem HTML real. E a edge acrescenta riscos próprios (bots sem cookies, redirecionamentos para URLs de variantes, cache da CDN e interações com WAF) que o teste simples no cliente não tem.
• “An edge test running for months is fine as long as it’s ‘still testing.’” (Tradução: “um teste na edge rodando há meses é aceitável se ainda estiver ‘testando’.”) Arriscado. Um teste deixado até se tornar a página permanente de fato — sem declarar um vencedor — é exatamente o que o Google alerta que pode parecer uma tentativa de enganar. Conclua-o, escolha um vencedor e remova a estrutura.
• “The CDN vendor’s A/B testing docs cover the SEO angle.” (Tradução: “a documentação do fornecedor de CDN sobre testes A/B cobre o ângulo de SEO.”) Geralmente não — o exemplo oficial EdgeKV da Akamai, por exemplo, não tem enquadramento de SEO, bot ou crawler. A lente de SEO é algo que você traz; a documentação da plataforma não traz.

Veja qual variante um crawler realmente recebe

O objetivo é fazer uma solicitação sem cookie (como o Googlebot geralmente se comporta) resolver para uma variante consistente. Veja como verificar o que sua edge está servindo quando não há cookie.

Buscar como cliente sem cookie (shell / curl)

# No cookie sent — this is closest to how Googlebot hits you.
# Run it a few times: the variant should be the SAME every time (deterministic),
# not a fresh 50/50 roll.
for i in 1 2 3; do
  curl -s -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
    https://example.com/product/123 | grep -o 'data-variant="[^"]*"'
done

# Show the response headers too — look for Set-Cookie (bucketing),
# Vary, and any redirect (302 good / 301 bad while testing).
curl -sI -A "Googlebot" https://example.com/product/123

Identificar um redirecionamento para URL de variante e seu status (shell)

# -L follows redirects; -w prints the chain of status codes.
# A live test should show 302, never 301.
curl -sIL -o /dev/null \
  -w "%{http_code} -> %{redirect_url}\n" \
  https://example.com/product/123

Verificar a variante servida + canonical no console do DevTools (compatível com bookmarklet)

Cole no console do navegador na página em teste — ou salve como bookmarklet (javascript: + o corpo) para verificar qualquer página com um clique:

// What variant am I seeing, and does the page canonical to the control?
(() => {
  const variant = document.querySelector('[data-variant]')?.dataset.variant
    ?? 'no data-variant attr found';
  const canonical = document.querySelector('link[rel="canonical"]')?.href
    ?? 'no canonical';
  const hasCookie = /(?:^|; )ab_bucket=/.test(document.cookie);
  console.log({ url: location.href, variant, canonical, hasCookie });
})();

Confirmar agrupamento determinístico (regex nos logs da edge)

Se o worker registra o bucket atribuído a cada solicitação, isto extrai as solicitações sem cookie e seus buckets para confirmar que a mesma URL sempre mapeia para a mesma variante:

# Match log lines with no ab_bucket cookie, capture URL + assigned variant.
# Group by URL: every URL should show ONE variant, not a mix.
grep -vE 'ab_bucket=' edge.log \
  | grep -oE '"(GET|HEAD) [^"]+".*variant=[AB]' \
  | sort | uniq -c | sort -rn

Se alguma URL mostrar tanto variant=A quanto variant=B para solicitações sem cookie, o agrupamento não é determinístico para crawlers — corrija isso antes que o Googlebot indexe um alvo em movimento.

Ferramentas para executar e verificar testes na edge

• Cloudflare Workers — reescritas HTML com HTML Rewriter na mesma URL e o padrão documentado de “passthrough” para acesso consistente ao controle/teste.
• Akamai EdgeWorkers + EdgeKV — agrupamento na edge com atribuição bloqueada por cookie (traga suas próprias proteções de SEO; a documentação não as fornece).
• Fastly Compute — computação na edge para os mesmos padrões de reescrita/redirecionamento.
• Optimizely / VWO (integrações edge / server-side) — plataformas comerciais de experimentação que podem executar na edge, não apenas no cliente.
• SearchPilot — testes A/B de SEO server-side/na edge baseados em divisão determinística por página (uma variante por página para todos), evitando o problema dos cookies.
• Google Search Console — Inspeção de URL — verifique como o Googlebot realmente rastreou e renderizou a URL em teste e qual variante ele viu.
• Análise de arquivos de log do servidor — a fonte definitiva para saber qual variante crawlers reais receberam, com que frequência e se as solicitações sem cookie chegam de forma consistente.
• curl / console do DevTools — verificações manuais rápidas da variante sem cookie, da canonical e do status do redirecionamento (consulte a aba Scripts).
• IndexNow — protocolo de envio do Bing/Yandex para que URLs de variantes sejam vistas rapidamente quando você faz testes com divisão por URL (o caminho recomendado pelo Bing para mudanças estruturais).

Auditar o agrupamento na edge quanto ao determinismo para crawlers

Review this edge A/B test implementation. First classify it as:
A. Same-URL HTML rewriting, or
B. Redirect to a separate variant URL.

Then trace assignment for: a normal first visit, a returning visitor with a cookie,
Googlebot without a cookie across repeated crawls, and a request whose cache key is reused.
Return:
1. Every source of randomness or unstable assignment
2. Whether the same URL can show a crawler different indexable versions over time
3. Whether cache keys mix control and variant responses
4. For redirected variants, the redirect status and canonical relationship
5. User-agent branches that show bots content users cannot receive
6. A deterministic replacement and a repeat-request test plan
7. The cleanup required when the test ends

Do not assume crawlers retain cookies. Do not call a test safe merely because bots receive
the control; verify that control is genuinely available to users and is the intended
indexable version. Do not invent CDN settings or experiment data.

Worker/middleware code, routes, cache configuration, and test design:
[PASTE INPUT]

Revisar um teste proposto com URL de variante

Check this edge redirect test for temporary-test hygiene. Verify that the variant URL
canonicalizes to the control, the redirect is temporary, internal links and sitemaps do
not multiply the test URLs, crawler assignment is stable, and an end date/winner-removal
plan exists. Return pass/fail per condition and the smallest safe correction.

Inputs:
[PASTE REDIRECT RULES, HEAD OUTPUT, CANONICALS, AND TEST WINDOW]

Recursos que valem seu tempo

Meus textos relacionados

• Guia para iniciantes de SEO técnico — onde testes e rastreabilidade se encaixam no panorama maior, incluindo a linha de cloaking que um teste na edge não pode cruzar.

Minhas palestras

• How Search Works (SlideShare) — meu percurso por rastreamento, renderização, indexação e ranking; contexto útil para entender por que o rastreamento sem cookies se comporta assim. (Meu aviso permanente se aplica: “esta é a minha compreensão dos sistemas… não será 100% completa ou precisa.”)

De outras fontes do setor

• Práticas recomendadas para testes A/B na busca (Google Search Central) — a documentação autoritativa: canonical, 302, duração e a questão de cookies/Googlebot.
• Cloudflare Workers — teste A/B com acesso direto na mesma URL — o exemplo de cookie 50/50 e o padrão de “passthrough” para acesso consistente à variante.
• Criando um teste A/B com EdgeWorkers e EdgeKV (Akamai) — agrupamento na edge bloqueado por cookie (observe: sem enquadramento de SEO na documentação).
• Testes A/B e otimização para mecanismos de busca (Optimizely) — orientação do fornecedor que repete as regras do Google; origem da regra prática de “perda de cerca de 10% do valor dos links em 301”.
• O que é teste A/B de SEO? (SearchPilot) — metodologia de divisão por página versus por usuário e por que “existe apenas um Googlebot”.
• SEO e testes de SEO na edge (SearchPilot) — por que mudanças na edge aparecem para usuários e Googlebot como mudanças HTML server-side.
• Teste A/B para melhorar o desempenho nos mecanismos de busca com IndexNow e Microsoft Clarity (Bing Webmaster Blog) — observação do Bing sobre testes A/B e orientação do IndexNow.

Teste seu conhecimento: SEO para testes A/B na edge

Cinco perguntas rápidas sobre executar testes divididos na edge sem criar problemas de SEO. Escolha uma resposta para cada uma e depois confira.

Registro de alterações