Experiências de SEO + GEO com o Claude Code e um grupo de controlo

O que faz o ciclo de experiências de SEO

As experiências de SEO só dizem alguma coisa quando as páginas alteradas se movem mais do que um grupo de páginas em que ninguém tocou. É por essa regra que passam as correções de SEO do nosso site. O Claude Code escreve a ficha da experiência antes de tocar numa página, altera um grupo tratado escolhido aleatoriamente, deixa intacto um grupo de controlo equivalente, e um script compara os dois ao dia 15 e ao dia 31. O ConvOps gere tudo como tarefas agendadas com fluxos de trabalho, e uma pessoa faz o merge de cada alteração. É um dos ciclos com que gerimos a nossa empresa.

Uma experiência de SEO pré-registada é uma alteração de páginas cuja hipótese, métrica, grupos de páginas e regra de refutação ficam registados em commit antes de a alteração ser publicada, e nunca são editados depois. Uma família de páginas é uma página mais as suas variantes de idioma (en, es, de). As famílias são a unidade que o ciclo atribui ao grupo tratado ou ao de controlo.

Todos os ecrãs e números abaixo usam dados de exemplo da Tidewell, uma aplicação fictícia de faturação em tidewell.example.com.

Como funciona o ciclo: a investigação mensal e a estratégia aprovada por uma pessoa alimentam um planeador semanal que cria tarefas de experiências, um pulso diário acorda as que chegaram ao prazo, tudo lê e escreve num único repositório de registo central, e uma pessoa faz o merge de cada alteração antes de ser publicada.

Quatro agendamentos movem o ciclo: um pulso diário, um planeador semanal e a investigação e a estratégia mensais.

Quatro agendamentos movem o ciclo: um pulso diário, um planeador semanal, a investigação mensal e a estratégia mensal, cada um com a sua regra e aquilo que faz.

Porque o construímos: uma página é ruído, e os agentes inventam números

A maioria dos testes de SEO em sites pequenos engana: uma página oscila um terço sem que nada tenha mudado. As atualizações do Google, a sazonalidade, o momento do rastreio e as quebras gerais do site movem uma página por si só. Um gráfico de antes e depois de uma única página não distingue uma correção de uma semana calma.

A resposta é um grupo de controlo do mesmo site, atribuído aleatoriamente no mesmo momento. Os dois grupos enfrentam as mesmas condições, por isso a diferença entre eles é o efeito. As orientações de testes da Google dizem que o tempo de que um teste fiável precisa depende do tráfego do site (Google Search Central, 2025(abre num novo separador)). Este ciclo nunca altera um URL nem acrescenta um redirecionamento, e um site pequeno tem 28 dias medidos mais um prolongamento.

Uma página oscila um terço de semana para semana sem que nada mude, enquanto os grupos tratado e de controlo se movem em conjunto durante uma quebra geral do site, por isso o que se mede é a diferença entre eles.

O segundo problema é o agente. Peça a um agente que «verifique os dados» e ele calcula rácios, compara-os com referências que inventou e recomenda alterações. O nosso fez exatamente isso. Por isso, um script calcula todas as métricas e vereditos, e o Claude Code executa os passos e lê os resultados.

Se quer um ciclo agendado como este, com passos, portões e aprovações humanas, veja como o ConvOps o executa(abre num novo separador).

Como funciona: quatro agendamentos, cinco fluxos de trabalho

Um ciclo de experiências só é tão honesto quanto o seu relógio, por isso aqui nada fica à espera de que alguém se lembre.

O planeador só usa um memorando de estratégia cuja tarefa de aprovação esteja concluída. Sem isso, mantém as predefinições. Um memorando orienta semanas de experiências, por isso é uma pessoa que o assina.

Um pool é o conjunto de famílias em que uma métrica é mensurável: acessos de crawlers de IA, impressões no Google, posição ou taxa de cliques. Um braço é um tipo de correção aplicado a um grupo de famílias de páginas. Uma vaga é o conjunto de braços iniciados ao mesmo tempo numa segunda-feira, que partilham um grupo de controlo.

Cada braço é uma tarefa própria com um fluxo de trabalho de 10 passos, um grafo de passos e portões, a forma que descrevemos em O que é a engenharia de grafos (graph engineering)?.

Cada merge espera por uma pessoa, o portão humano descrito em Construir sistemas de IA com human in the loop.

O fluxo de trabalho da experiência como um grafo: registar, implementar e rever, um passo de publicação que exige aprovação humana, depois a entrada em produção (dia 0), Intercalar (dia 15) e Final (dia 31), com os resultados dos portões a saltar para Reversão ou Agir antes de Aprender.

Entre avaliações, a tarefa fica parada até ao seu prazo e o pulso diário acorda-a.

O nosso ciclo de website com autorreparação usa o mesmo padrão para o QA do site: um varrimento semanal regista bugs, e cada bug tem a sua própria execução de reparação, que só fecha depois de uma nova verificação.

Uma execução, passo a passo (dados de exemplo)

Eis uma execução completa da Tidewell, do planeador de segunda-feira ao veredito do dia 31.

Segunda-feira: o planeador abre uma vaga

O relatório do planeador semanal: famílias elegíveis e capacidade de braços por pool, os tipos de correção sorteados para cada vaga, a atribuição com semente e quatro tarefas de experiência deixadas para o pulso seguinte despachar.

O planeador conta as famílias elegíveis e a capacidade de braços por pool (legenda 1). A capacidade é o número de famílias elegíveis dividido por 15, arredondado para baixo, menos um: as 68 famílias do pool de IA da Tidewell permitem 3 braços. O pool do Google está limitado a 1 braço, e cada pool tem uma única vaga ativa de cada vez.

Um pool só recebe uma vaga quando a sua linha de base A/A histórica está ok. Essa linha de base volta a correr dados passados com divisões fictícias e conta quantas vezes o ruído, sozinho, parece uma vitória (2,1 % no exemplo). Um pool que falhe não recebe nenhuma vaga, porque qualquer veredito ali seria ruído.

Os tipos de correção que ganharam mais são escolhidos mais vezes (legenda 2), com cerca de 20 % dos braços reservados para tipos de correção ainda sem veredito (amostragem de Thompson, Beta(1 + vitórias, 1 + derrotas + inconclusivos)).

A atribuição usa a data como semente aleatória, baralha dentro de cada grupo de diagnóstico e distribui as famílias à vez, com o controlo em primeiro lugar (legenda 3). Cada grupo recebe 17 famílias. É o pulso seguinte, e não o planeador, que despacha as quatro tarefas.

Registar: a ficha vem primeiro

A ficha da experiência no estado registered: cabeçalho, uma hipótese refutável, a regra que a refuta, as famílias e a linha de base, tudo com commit antes de o agente tocar numa página.

A ficha contém um tipo de correção (legenda 1), uma frase refutável (3), a regra que a refuta (4) e uma linha de base de 28 dias (5). Depois do commit, só o estado e as datas mudam. Fazemos o pré-registo porque um agente, tal como uma pessoa, consegue encontrar a posteriori uma história em qualquer número; uma regra de refutação com commit não deixa nada para reinterpretar.

Implementar, rever, publicar, entrar em produção

No braço A, o Claude Code acrescenta um resumo orientado por perguntas e um bloco de FAQ às 17 famílias tratadas de modelos de faturas. Essa é a única variável. Nunca toca em URLs, slugs, redirecionamentos, no layout partilhado nem em factos, e atualiza a data em cada página alterada. A revisão estática passa; uma pessoa faz o merge. Eis o braço B da mesma vaga, parado depois da entrada em produção.

Uma tarefa de experiência irmã depois da entrada em produção: a nota de cada passo na tarefa, a verificação em produção destacada, Intercalar (dia 15) a seguir, e o prazo definido para o dia 15 para que a tarefa fique adormecida até lá.

A entrada em produção verifica o tratamento no HTML de produção das 17 páginas (legenda 1). A Google diz que o rastreio pode demorar de alguns dias a algumas semanas (Google Search Central, 2025(abre num novo separador)), por isso o dia 0 é o dia em que a alteração é verificada em produção, não o dia do merge. A entrada em produção define o dia 0 e os dois prazos, e depois deixa a tarefa parada até ao dia 15 (legendas 2 e 3).

Dia 15 e dia 31: decide um script

O passo Final (dia 31) leva as regras de decisão nas suas instruções: correr o script de veredito e depois vitória, derrota ou inconclusivo, com um prolongamento até ao dia 59.

As regras de decisão estão nas instruções do passo (legenda 2), por isso o agente não pode discutir com elas. Corre o script de veredito e segue o ramo correspondente.

A nota de decisão na mesma tarefa regista cada avaliação como uma linha; aqui a avaliação final é inconclusiva, por isso a tarefa é prolongada uma vez até ao dia 59.

Ao dia 15, o script lê rácio 1,08, p 0,31: sem prejuízo, sem vitória antecipada, continua. Ao dia 31, lê rácio 1,11, p 0,19 (legenda 1): inconclusivo, por isso a tarefa é prolongada uma vez até ao dia 59 e volta a ficar parada.

Como é o resultado: o registo central

O que este ciclo produz é o registo central, não um gráfico de tráfego.

O registo central tem uma linha por experiência, com os nomes reais das colunas, e a coluna de estado mostra em que ponto da execução está cada uma.

Uma experiência passa pelos estados registered (registada), awaiting-merge (à espera de merge), live (publicada), interim-done (intercalar concluída) e final, e pode terminar como extended (prolongada), rolled-back (revertida) ou void (anulada). Cada braço é uma tarefa própria, com o seu próprio veredito.

O script de veredito corre um diff-in-diff por permutação ao nível da família, com 10.000 baralhamentos. O rácio é a variação do grupo tratado dividida pela variação do grupo de controlo na mesma janela, por isso 1,5 significa que o grupo tratado se moveu 50 % mais do que o de controlo. Para os acessos de IA (cada métrica tem os seus próprios limiares), uma vitória exige p ≤ 0,0477 ao dia 31, um rácio de 1,5 ou mais e pelo menos 60 % das famílias tratadas acima da mediana do controlo. Um resultado de acessos de IA ao dia 15 com p ≤ 0,0074 que também cumpra as regras do rácio e da proporção termina o braço mais cedo: é final e vai diretamente para Agir. Uma derrota é a imagem invertida (rácio de 0,67 ou menos, 60 % abaixo da mediana), e segue-se a reversão. Tudo o resto, ou menos de 15 famílias por braço, é inconclusivo.

Os dois limiares de p dividem um único orçamento de 5 % de falsas vitórias pelas duas avaliações, por isso parar mais cedo ao dia 15 não custa falsas vitórias adicionais. O rácio e a proporção de 60 % travam um resultado que é estatisticamente real mas minúsculo, ou que assenta numa única página grande.

Como uma avaliação se torna uma decisão: na avaliação intercalar do dia 15, um resultado de acessos de IA com p ≤ 0,0074 e rácio ≥ 1,5 é uma vitória antecipada que termina o braço e vai para Agir, um prejuízo reverte, uma atualização do Google anula a avaliação, tudo o resto continua; a avaliação final do dia 31 devolve vitória, derrota ou inconclusivo (limiares do verdict.py), com um prolongamento até ao dia 59; uma vitória só regista uma ideia de replicação.

Inconclusivo não é uma derrota. Diz que o efeito, se existir, é menor do que aquilo que este site consegue detetar. A tarefa é prolongada uma vez até ao dia 59 e depois fecha, porque um teste que corre até ganhar acaba por ganhar por causa do ruído. Uma vitória também não gera mais experiências. Regista uma ideia de replicação para uma pessoa, porque um orçamento de 5 % de falsas vitórias significa que algumas vitórias são ruído, e só uma segunda execução com famílias novas as distingue.

O que corre mal: o agente que inventou uma crise

A nossa pior manhã veio de um agente a tentar ser útil. A nossa verificação diária ignorou a sua lista de verificações e escreveu o seu próprio relatório. Calculou uma taxa de cliques, comparou-a com um «padrão do setor» que ninguém lhe deu, classificou-a como CRÍTICA, recomendou alterações e citou bugs de tracking que nunca tinham sido registados. Todos os números pareciam plausíveis. Nenhum vinha de uma verificação definida. Arquivámos o relatório e reescrevemos o passo no mesmo dia. Aqui fica recontado com dados da Tidewell.

Antes: o agente avaliou a CTR com uma referência inventada e recomendou alterações; depois: um script cria o snapshot e só quatro verificações fixas decidem, e apanham uma anomalia real, um sitemap a devolver 500.

A regra que daí resultou tem duas partes. Primeiro, um script cria o snapshot, e o agente nunca calcula um número do snapshot nem escreve o ficheiro à mão. Segundo, só quatro verificações fixas contam como anomalias:

1. As impressões caem para menos de metade da sua média de 7 dias.
2. Os acessos de crawlers de IA caem para menos de 50 % ou sobem acima de 300 % da sua média de 7 dias.
3. Uma família de uma vaga ativa falta nos dados durante 7 dias.
4. A página inicial ou o sitemap não devolvem HTTP 200 a um crawler de IA.

Sem juízos sobre a CTR, sem rankings, sem referências, sem recomendações. Um bug só é citado pelo id que o sistema de gestão de bugs devolveu.

A segunda falha foi mais silenciosa, e pior. Uma nova versão de um pacote de um dos nossos sites trazia uma alteração de produto ainda não lançada, que reescreveu o texto de uma das nossas páginas de controlo antes do dia 0. Um controlo que muda deixa de ser um controlo: qualquer diferença que mostre é edição nossa, não da correção. Apanhámo-lo antes da entrada em produção. A regra: uma família tocada depois da atribuição passa para «Excluded after assignment» (excluída após a atribuição) e sai da comparação.

Construa o seu: a versão mínima

Não precisa de cinco fluxos de trabalho para começar. Precisa de um repositório, dois scripts, um modelo de ficha e um agendador diário.

A versão mínima que pode copiar: um agendador diário corre um script de snapshot para um único repositório de registo central, as fichas saem de um modelo, e um script de veredito nos prazos devolve manter, prolongar ou reverter.

O modelo de ficha, um ficheiro por experiência:

---
experiment: exp-0001
site: example
wave: example-2026-01-05
arm: A
fix_type: internal-links
primary_metric: impressions
status: registered
branch: exp/exp-0001
day0: null
interim_due: null
final_due: null
---
Hypothesis:
One falsifiable sentence: what changes, on which treated families, against which control, by day 31.

Falsified if:
The day 31 verdict is not a win under the thresholds fixed in the verdict script.

Families:
treated (15+): ...
control (15+): ...

Baseline (28 days):
treated ... | control ...

Verdicts:
| Look | Date | n treated / control | Ratio | p | Verdict |
|---|---|---|---|---|---|

Lesson:

Copie o modelo de ficha e depois agende o pulso diário no ConvOps(abre num novo separador), para que cada experiência seja acordada no seu prazo.