Hay una ironía cruel en el mundo del A/B testing: la herramienta que instalaste para mejorar la conversión puede estar hundiéndola. Un script de testing client-side mal integrado añade cientos de milisegundos de JavaScript bloqueante, provoca ese parpadeo donde el usuario ve la versión original antes de que aparezca la variante, y degrada los Core Web Vitals que Google usa para rankear — y que tus usuarios sufren en cada visita, participen o no en un test.
En nuestra guía de CRO contamos el proceso: investigación, hipótesis, priorización. Aquí vamos a la parte técnica: cómo ejecutar los tests sin pagar un peaje de rendimiento, sin sustos con Google y sin conclusiones falsas.
El coste oculto de los testers client-side
La mayoría de las herramientas populares de A/B testing funcionan igual: insertas un snippet de JavaScript, y ese script descarga la configuración de los experimentos, decide qué variante ve el usuario y modifica el DOM al vuelo. Cómodo para marketing, caro para todos los demás:
- Flicker (o FOOC, flash of original content): el navegador pinta la página original y, milisegundos después, el script la reescribe. El usuario ve el cambio suceder. Además de dar sensación de web rota, contamina el experimento — la variante que testeas no es “el hero nuevo”, es “el hero viejo que muta delante de ti”.
- JavaScript bloqueante: para evitar el flicker, muchas herramientas recomiendan cargar su script de forma síncrona en el
<head>, o peor, con un “anti-flicker snippet” que oculta la página entera hasta que el script decide. Traducción: tu LCP empeora para el 100% de las visitas, incluidas las que no participan en ningún test. - La paradoja de conversión: los Core Web Vitals afectan directamente a la conversión, sobre todo en móvil. Si tu tester añade 300-500 ms de bloqueo, necesitas que cada test gane bastante solo para compensar lo que el propio tester te quita. Estás midiendo mejoras del +5% con una herramienta que te costó un -3% de base.
Esto no significa que el client-side esté prohibido — significa que tiene un coste que hay que medir. Si instalas un tester, compara tus Core Web Vitals antes y después. Muchos equipos descubren que su “programa de experimentación” era, en neto, un programa de degradación de rendimiento.
Qué dice Google sobre testing y SEO
El miedo a que “los tests A/B penalizan el SEO” es de los mitos más persistentes. La postura de Google es pública y bastante razonable: experimentar está permitido, con cuatro condiciones:
rel=canonicalen las variantes. Si sirves la variante en otra URL (/landing-b), esa URL debe apuntar con canonical a la original. Así Google entiende que no es contenido duplicado, sino una variación temporal de la misma página.- Redirects 302, no 301. Si rediriges tráfico a la variante, usa una redirección temporal (302). Un 301 le dice a Google que el cambio es permanente y puede transferir la indexación a la URL del test.
- Nada de cloaking. Googlebot debe poder ver lo mismo que un usuario cualquiera: si detectas al bot y le sirves siempre la versión original “por si acaso”, eso es cloaking y sí es motivo de penalización. Deja que el bot entre en el reparto como un usuario más.
- Duración limitada. Un experimento es temporal por definición. Cuando el test concluye, implementa la variante ganadora y retira la maquinaria. Un test “vivo” durante ocho meses deja de ser un experimento y empieza a parecer contenido duplicado con adorno.
Cumpliendo esto, el riesgo SEO real de un test A/B no viene de Google interpretándolo mal: viene del JavaScript bloqueante degradando tus Core Web Vitals. Que es exactamente el punto anterior.
Server-side y feature flags: la alternativa seria
En el testing server-side, la decisión de qué variante servir se toma en el servidor (o en el edge) antes de renderizar. El usuario recibe directamente la versión que le toca: sin scripts de terceros reescribiendo el DOM, sin flicker, sin peaje de rendimiento.
La forma moderna de implementarlo son los feature flags: interruptores en el código que activan una variante para un porcentaje de usuarios, con asignación estable (el mismo usuario ve siempre la misma versión) y exposición registrada en tu analítica. Herramientas open source como GrowthBook dan la infraestructura completa — asignación, targeting, análisis estadístico — y se integran con tu propio data warehouse, con lo que los datos no salen de casa. Y para casos simples, unos flags propios (una asignación por hash de usuario y un evento de exposición) son perfectamente dignos: menos de un día de trabajo y control total.
| Client-side | Server-side / flags | |
|---|---|---|
| Velocidad de carga | Penaliza LCP/INP (script bloqueante) | Impacto nulo o marginal |
| Flicker | Frecuente, difícil de eliminar del todo | Inexistente |
| Capacidades | Cambios visuales (copy, layout, CTAs) | Cualquier cosa: flujos, lógica, pricing, algoritmos |
| Quién lanza tests | Marketing, sin deploy | Requiere desarrollo y deploy |
| Coste de ingeniería | Bajo al inicio, deuda después | Setup inicial, barato después |
| Riesgo SEO/CWV | Real si se integra mal | Mínimo (respetando canonical/302) |
Nuestra regla práctica: client-side solo para tests superficiales de copy o layout en páginas donde el rendimiento no sea crítico; server-side para todo lo que toque el flujo de conversión, el producto o cualquier página que te importe en buscadores.
Estadística práctica, sin dogmas
No hace falta un doctorado, pero sí tres disciplinas:
- Calcula muestra y MDE antes de lanzar. Define el efecto mínimo detectable — la mejora más pequeña que justificaría implementar el cambio — y mete tu tráfico en cualquier calculadora de tests. Si el resultado es “necesitas 14 semanas”, el test no es viable tal cual: busca un cambio más grande, una métrica más frecuente o una página con más tráfico. Lanzar sin este cálculo es la forma educada de tirar una moneda.
- El pecado del peeking. Mirar el resultado cada día y parar en cuanto aparece la significancia infla los falsos positivos hasta niveles absurdos: con suficientes miradas, casi cualquier test “gana” en algún momento. La duración se fija antes y se respeta, cubriendo ciclos de negocio completos (los lunes no convierten como los sábados).
- Secuenciales y bayesianos, si los entiendes. Existen métodos diseñados para poder mirar sin trampa: tests secuenciales y enfoques bayesianos (los que usa GrowthBook, por ejemplo) que dan una lectura continua honesta del riesgo. Son una opción legítima — no un truco para parar antes cuando el resultado te gusta. El método importa menos que la disciplina: decide las reglas antes de ver los datos.
QA de experimentos: el paso que todo el mundo se salta
Un test es código en producción y merece el mismo QA:
- Prueba cada variante en dispositivos reales. La variante B que quedaba perfecta en el desktop del diseñador puede romper el layout en un móvil de gama media. Si la mitad de tu tráfico es móvil y la variante está rota en móvil, el test no mide tu hipótesis: mide un bug.
- Verifica la analítica antes de lanzar. ¿El evento de exposición se dispara una sola vez? ¿La conversión se atribuye a la variante correcta? ¿El tester no ha duplicado el pageview? Un experimento con tracking roto es peor que no experimentar: produce conclusiones con apariencia de rigor.
- Define guardrail metrics. Además de la métrica objetivo, vigila las que no deben empeorar: rendimiento (LCP, INP), tasa de errores JS, y las métricas de negocio aguas abajo — un CTA “ganador” en clics que trae peores leads o menos ingresos por pedido es una derrota disfrazada. Si un guardrail se rompe, el test se para, gane lo que gane la métrica principal.
Cuándo NO testear
Con poco tráfico, un test A/B honesto tarda meses o años en dar señal, y la tentación de “leerlo igual” produce decisiones aleatorias con disfraz científico. Como regla, por debajo de ~1.000 conversiones mensuales en la página a testar, es mejor hacer cambios fundamentados — heurísticas contrastadas, research cualitativo, cambios grandes medidos antes/después con humildad — que simular experimentación. Desarrollamos cuándo aplica cada enfoque en nuestra guía de CRO.
Checklist antes de lanzar un test
- Hipótesis escrita, con métrica objetivo y MDE definidos
- Muestra y duración calculadas (y viables) antes de lanzar
- Método elegido con criterio: server-side/flags para tests que importan
-
rel=canonicalen variantes con URL propia; redirects 302, no 301 - Googlebot ve lo mismo que los usuarios (cero cloaking)
- Core Web Vitals medidos con la maquinaria de testing activa
- Variantes probadas en móvil y navegadores principales
- Eventos de exposición y conversión verificados en analítica
- Guardrail metrics definidas: rendimiento, errores, ingresos
- Fecha de fin fijada y compromiso de no hacer peeking
- Plan post-test: implementar la ganadora y retirar el experimento
Conclusión
El A/B testing bien ejecutado es tanto un problema de ingeniería como de estadística: servir variantes sin degradar la web, cumplir las reglas de Google, medir sin autoengañarse y vigilar lo que no debe romperse. Por eso los tests que importan se montan desde el código — con feature flags, QA y guardrails — y no desde un snippet pegado en el <head>.
¿Quieres experimentar sin hipotecar tu rendimiento ni tu SEO? Descubre nuestro servicio de growth marketing →