Experimentos SEO + GEO con Claude Code y un grupo de control

Qué hace el bucle de experimentos SEO

Los experimentos SEO solo te dicen algo cuando las páginas que cambiaste se movieron más que un grupo de páginas sin tocar. Pasamos todas las correcciones SEO de nuestro sitio por esa regla. Claude Code escribe la ficha del experimento antes de tocar una página, cambia un grupo tratado elegido al azar, deja intacto un grupo de control equivalente, y un script compara los dos en el día 15 y en el día 31. ConvOps lo ejecuta todo como tareas programadas con flujos de trabajo, y una persona hace el merge de cada cambio. Es uno de los bucles con los que dirigimos nuestra empresa.

Un experimento SEO prerregistrado es un cambio de página cuya hipótesis, métrica, grupos de páginas y regla de descarte se registran en un commit antes de publicar el cambio, y nunca se editan después. Una familia de páginas es una página más sus variantes de idioma (en, es, de). Las familias son la unidad que el bucle asigna al grupo tratado o al de control.

Todas las pantallas y cifras que verás a continuación usan datos de ejemplo de Tidewell, una app ficticia de facturación en tidewell.example.com.

Cómo funciona el bucle: la investigación mensual y la estrategia aprobada por una persona alimentan un planificador semanal que crea tareas de experimento, un pulso diario despierta las que vencen, todo lee y escribe en un único repositorio de registro, y una persona hace el merge de cada cambio antes de que se publique.

Lo mueven cuatro programaciones: un pulso diario, un planificador semanal y una investigación y una estrategia mensuales.

Cuatro programaciones mueven el bucle: un pulso diario, un planificador semanal, una investigación mensual y una estrategia mensual, cada una con su regla y lo que hace.

Por qué lo construimos: una página es ruido, y los agentes se inventan cifras

La mayoría de los tests SEO en sitios pequeños te engañan: una página oscila un tercio sin que haya cambiado nada. Las actualizaciones de Google, la estacionalidad, el ritmo de rastreo y las caídas generales del sitio mueven una página por sí solos. Un gráfico de antes y después de una sola página no distingue una corrección de una semana tranquila.

La respuesta es un grupo de control del mismo sitio, asignado al azar en el mismo momento. Los dos grupos afrontan las mismas condiciones, así que la diferencia entre ellos es el efecto. La guía de Google sobre pruebas dice que el tiempo que necesita una prueba fiable depende del tráfico que recibe el sitio (Google Search Central, 2025(se abre en una pestaña nueva)). Este bucle nunca cambia una URL ni añade una redirección, y un sitio pequeño tiene 28 días medidos más una prórroga.

Una página oscila un tercio de una semana a otra sin que cambie nada, mientras que los grupos tratado y de control se mueven juntos durante una caída general del sitio, así que lo que mides es la diferencia entre ellos.

El segundo problema es el agente. Pide a un agente que «revise los datos» y calculará ratios, los comparará con referencias que se ha inventado y recomendará cambios. El nuestro hizo exactamente eso. Por eso un script calcula todas las métricas y los veredictos, y Claude Code ejecuta los pasos y lee los resultados.

Si quieres un bucle programado como este, con pasos, puertas y aprobaciones humanas, descubre cómo lo ejecuta ConvOps(se abre en una pestaña nueva).

Cómo funciona: cuatro programaciones, cinco flujos de trabajo

Un bucle de experimentos solo es tan honesto como su reloj, así que aquí nada depende de que alguien se acuerde.

El planificador solo usa un informe de estrategia cuya tarea de aprobación esté completada. Si no lo hay, mantiene sus valores por defecto. Un informe dirige semanas de experimentos, así que lo firma una persona.

Un pool es el conjunto de familias en las que una métrica se puede medir: visitas de rastreadores de IA, impresiones de Google, posición o porcentaje de clics. Un brazo es un tipo de corrección aplicado a un grupo de familias de páginas. Una oleada es el conjunto de brazos que arrancan juntos un mismo lunes y comparten un grupo de control.

Cada brazo es su propia tarea con un flujo de trabajo de 10 pasos, un grafo de pasos y puertas, la forma que describimos en ¿Qué es graph engineering?.

Cada merge espera a una persona, la puerta humana que describimos en Cómo construir sistemas de IA con human in the loop.

El flujo de trabajo del experimento como grafo: registrar, implementar y revisar, un paso Ship que necesita aprobación humana, después Go live (día 0), Interim (día 15) y Final (día 31), con resultados de puerta que saltan a Rollback o a Act antes de Learn.

Entre revisiones, la tarea queda aparcada hasta su fecha de vencimiento y el pulso diario la despierta.

Nuestro bucle de web que se autorrepara usa el mismo patrón para el QA del sitio: un barrido semanal registra bugs, y cada bug tiene su propia ejecución de reparación que solo se cierra después de volver a comprobarlo.

Una ejecución paso a paso (datos de ejemplo)

Esta es una ejecución completa de Tidewell, desde el planificador del lunes hasta el veredicto del día 31.

Lunes: el planificador abre una oleada

El informe del planificador semanal: familias elegibles y capacidad de brazos por pool, los tipos de corrección elegidos para cada oleada, la asignación con semilla y cuatro tareas de experimento que el siguiente pulso despachará.

El planificador cuenta las familias elegibles y la capacidad de brazos por pool (indicador 1). La capacidad es el número de elegibles dividido entre 15, redondeado hacia abajo, menos uno: las 68 familias del pool de IA de Tidewell permiten 3 brazos. El pool de Google tiene un máximo de 1 brazo, y cada pool lleva una sola oleada activa a la vez.

Un pool solo recibe una oleada cuando su línea base A/A histórica está bien. Esa línea base reproduce datos pasados con divisiones falsas y cuenta con qué frecuencia el ruido por sí solo parece una victoria (un 2,1 % en el ejemplo). Un pool que no la supera no recibe oleada, porque cualquier veredicto ahí sería ruido.

Los tipos de corrección que más han ganado se eligen más a menudo (indicador 2), y alrededor del 20 % de los brazos se reserva para tipos de corrección sin veredicto (muestreo de Thompson, Beta(1 + victorias, 1 + derrotas + no concluyentes)).

La asignación usa la fecha como semilla aleatoria, baraja dentro de cada grupo de diagnóstico y reparte las familias por turnos empezando por el control (indicador 3). Cada grupo recibe 17 familias. Es el siguiente pulso, y no el planificador, el que despacha las cuatro tareas.

Register: primero la ficha

La ficha del experimento en estado registered: metadatos, una hipótesis falsable, la regla que la descarta, familias y línea base, todo con commit antes de que el agente toque una página.

La ficha contiene un tipo de corrección (indicador 1), una frase falsable (3), la regla que la descarta (4) y una línea base de 28 días (5). Después del commit, solo se mueven el estado y las fechas. Prerregistramos porque un agente, igual que una persona, puede encontrar una historia en cualquier cifra a posteriori; una regla de descarte con commit no deja nada que reinterpretar.

Implementación, revisión, envío y puesta en producción

En el brazo A, Claude Code añade un resumen planteado como pregunta y un bloque de preguntas frecuentes a las 17 familias tratadas de plantillas de factura. Esa es la única variable. Nunca toca URL, slugs, redirecciones, el diseño compartido ni los datos, y actualiza la fecha de cada página modificada. La revisión estática pasa y una persona hace el merge. Este es el brazo B de la misma oleada, aparcado después de la puesta en producción.

Una tarea de experimento hermana después de la puesta en producción: la nota de cada paso en la tarea, la comprobación en producción resaltada, Interim (día 15) a continuación y la fecha de vencimiento fijada en el día 15 para que la tarea duerma hasta entonces.

Go live comprueba el tratamiento en el HTML de producción de las 17 páginas (indicador 1). Google dice que el rastreo puede tardar desde unos días hasta unas semanas (Google Search Central, 2025(se abre en una pestaña nueva)), así que el día 0 es el día en que se verifica el cambio en producción, no el día del merge. Go live fija el día 0 y las dos fechas de vencimiento, y después aparca la tarea hasta el día 15 (indicadores 2 y 3).

Días 15 y 31: decide un script

El paso Final (día 31) lleva las reglas de decisión en sus instrucciones: ejecutar el script de veredicto y después victoria, derrota o no concluyente con una prórroga hasta el día 59.

Las reglas de decisión viven en las instrucciones del paso (indicador 2), así que el agente no puede discutirlas. Ejecuta el script de veredicto y sigue la rama que corresponda.

La nota de decisión de la misma tarea registra cada revisión como una fila; aquí la revisión final es no concluyente, así que la tarea se prorroga una vez hasta el día 59.

En el día 15, el script da un ratio de 1,08 con p 0,31: no hay daño ni victoria anticipada, así que continúa. En el día 31 da un ratio de 1,11 con p 0,19 (indicador 1): no concluyente, así que la tarea se prorroga una vez hasta el día 59 y vuelve a aparcarse.

Cómo es la salida: el registro

Lo que produce este bucle es el registro, no un gráfico de tráfico.

El registro guarda una fila por experimento con los nombres de columna reales, y la columna de estado muestra en qué punto de su ejecución está cada uno.

Un experimento pasa por registered, awaiting-merge, live, interim-done y final, y puede terminar como extended, rolled-back o void. Cada brazo es su propia tarea con su propio veredicto.

El script de veredicto ejecuta una diferencia en diferencias por permutación a nivel de familia con 10 000 barajados. El ratio es el cambio del grupo tratado dividido entre el cambio del grupo de control en la misma ventana, así que 1,5 significa que el tratado se movió un 50 % más que el control. Para las visitas de IA (cada métrica tiene sus propios umbrales), una victoria necesita p ≤ 0,0477 en el día 31, un ratio de 1,5 o más y que al menos el 60 % de las familias tratadas esté por encima de la mediana del control. Un resultado de visitas de IA en el día 15 con p ≤ 0,0074 que además cumpla las reglas de ratio y de proporción detiene el brazo antes de tiempo: es definitivo y pasa directamente a Act. Una derrota es la imagen especular (ratio de 0,67 o menos, 60 % por debajo de la mediana), y le sigue la reversión. Cualquier otra cosa, o menos de 15 familias por brazo, es no concluyente.

Los dos umbrales de p reparten un único presupuesto del 5 % de falsas victorias entre las dos revisiones, así que parar antes de tiempo en el día 15 no añade falsas victorias. El ratio y la proporción del 60 % frenan un resultado que es estadísticamente real pero minúsculo, o que depende de una sola página grande.

Cómo una revisión se convierte en una decisión: en la revisión intermedia del día 15, un resultado de visitas de IA con p ≤ 0,0074 y ratio ≥ 1,5 es una victoria anticipada que detiene el brazo y pasa a Act, el daño se revierte, una actualización de Google anula la revisión y cualquier otra cosa continúa; la revisión final del día 31 da victoria, derrota o no concluyente (umbrales de verdict.py) con una prórroga hasta el día 59; una victoria solo abre una idea de replicación.

No concluyente no es una derrota. Dice que el efecto, si existe, es menor de lo que este sitio puede detectar. La tarea se prorroga una vez hasta el día 59 y después se cierra, porque una prueba que sigue hasta que gana acaba ganando por ruido. Una victoria tampoco genera más experimentos. Abre una idea de replicación para una persona, porque un presupuesto del 5 % de falsas victorias implica que algunas victorias son ruido, y solo una segunda ejecución con familias nuevas permite distinguirlas.

Qué sale mal: el agente que se inventó una crisis

Nuestra peor mañana llegó de un agente que intentaba ayudar. Nuestra revisión diaria se saltó su lista de comprobaciones y escribió su propio informe. Calculó un porcentaje de clics, lo comparó con un «estándar del sector» que nadie le había dado, lo etiquetó como CRÍTICO, recomendó cambios y citó bugs de seguimiento que nunca se habían abierto. Todas las cifras parecían verosímiles. Ninguna salía de una comprobación definida. Archivamos el informe y reescribimos el paso ese mismo día. Aquí lo contamos con datos de Tidewell.

Antes: el agente juzgaba el CTR frente a una referencia inventada y recomendaba cambios; después: un script construye la instantánea y solo deciden cuatro comprobaciones fijas, que detectan una anomalía real, un sitemap que devuelve 500.

La regla que salió de ahí tiene dos partes. Primero, un script construye la instantánea, y el agente nunca calcula una cifra de la instantánea ni escribe el archivo a mano. Segundo, solo cuatro comprobaciones fijas cuentan como anomalías:

1. Las impresiones caen por debajo de la mitad de su media de 7 días.
2. Las visitas de rastreadores de IA caen por debajo del 50 % o suben por encima del 300 % de su media de 7 días.
3. Una familia de una oleada activa falta en los datos durante 7 días.
4. La página de inicio o el sitemap no devuelven HTTP 200 a un rastreador de IA.

Nada de juicios sobre el CTR, posiciones, referencias ni recomendaciones. Un bug solo se cita con el id que devolvió el gestor de incidencias.

El segundo fallo fue más silencioso, y peor. Una versión de un paquete para uno de nuestros sitios llevaba un cambio de producto sin publicar, y reescribió el texto de una de nuestras páginas de control antes del día 0. Un control que cambia ya no es un control: cualquier diferencia que muestre es nuestra propia edición, no la corrección. Lo detectamos antes de la puesta en producción. La regla: una familia tocada después de la asignación pasa a «Excluded after assignment» (excluida tras la asignación) y sale de la comparación.

Monta el tuyo: la versión mínima

No necesitas cinco flujos de trabajo para empezar. Necesitas un repositorio, dos scripts, una plantilla de ficha y una programación diaria.

La versión mínima que puedes copiar: una programación diaria ejecuta un script de instantáneas en un único repositorio de registro, las fichas salen de una plantilla y un script de veredicto en las fechas de vencimiento devuelve mantener, prorrogar o revertir.

La plantilla de ficha, un archivo por experimento:

---
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:

Copia la plantilla de ficha y después programa el pulso diario en ConvOps(se abre en una pestaña nueva) para que cada experimento se despierte en su fecha de vencimiento.