Glosario

Explore Meshline

Products Pricing Blog Support Log In

Ready to map the first workflow?

Book a Demo
Operaciones autónomas

¿Las pruebas A/B dañan el SEO? Cómo probar páginas de búsqueda con seguridad

Descubre si las pruebas A/B dañan el SEO y cómo probar páginas de búsqueda con seguridad usando las prácticas documentadas de Google sobre cloaking, canónicas, redirecciones y duración de la prueba.

Una ilustración editorial plana sobre un fondo neutro con textura que presenta una pila vertical central de barras azul marino y turquesa, con flechas discontinuas naranjas que la conectan a pilas más pequeñas de barras a cada lado.

Las pruebas A/B no dañan el SEO cuando se ejecutan correctamente.

Google documenta cómo probar variaciones de un sitio con impacto mínimo en la búsqueda.

El riesgo proviene de la configuración, no de hacer pruebas.

El cloaking, las redirecciones permanentes y los experimentos abandonados son las cosas que causan problemas.

Este artículo explica qué afecta los rankings durante una prueba, qué configuración protege tus páginas y cómo cerrar la prueba de forma limpia.

Está escrito para operadores que coordinan sistemas de marketing y ventas y necesitan probar páginas de aterrizaje sin poner en riesgo los ingresos orgánicos.

Lo que Google realmente dice sobre las pruebas y los rankings

Los cambios pequeños, como el tamaño, color o texto de un botón, suelen tener poco o ningún impacto en fragmentos o rankings (Google Search Central).

Aun así, dichos cambios pueden alterar de forma significativa el comportamiento del usuario.

Google señala que, si su rastreador indexa tu experimento, probablemente indexará las actualizaciones finales bastante rápido tras concluir la prueba.

En otras palabras, una prueba bien ejecutada es un estado temporal que el buscador puede manejar.

Los riesgos documentados son específicos:

  • Cloaking. Mostrar a Googlebot un conjunto de URLs y a las personas otro viola las políticas de spam de Google, con o sin prueba en curso. Google advierte que esto puede provocar que un sitio sea degradado o eliminado de los resultados.
  • Ejecutar una prueba demasiado tiempo. Google puede interpretar un experimento innecesariamente largo, especialmente uno que sirve una variante a una gran proporción de usuarios, como un intento de engañar a los motores de búsqueda.
  • Tipos de redirección incorrectos. Usar redirecciones permanentes para una prueba temporal puede indicar que la URL original debería reemplazarse en el índice.

Todo lo demás, incluido el hecho de que Google puede rastrear e indexar algunas de tus variaciones durante la prueba, se describe como de impacto generalmente bajo.

Google dice explícitamente que puede no importar mucho si algunas variaciones de contenido se indexan mientras haces la prueba.

Pruebas basadas en URLs frente a pruebas en la misma URL

Hay dos formas documentadas de ejecutar una prueba, y cada una conlleva consideraciones de SEO distintas.

Probar con URLs separadas

Creas varias versiones de una página, cada una con su propia URL.

Cuando los usuarios visitan la URL original, algunos son redirigidos a las URLs de las variaciones, y comparas el comportamiento entre versiones.

Este enfoque necesita las salvaguardas de redirección y canónica descritas más abajo.

Probar en la misma URL

Insertas las variaciones dinámicamente en la página, por ejemplo usando JavaScript para decidir qué variante mostrar.

No existen URLs alternativas, así que no hay nada que canonicalizar ni redirigir.

Una advertencia: Googlebot generalmente no admite cookies, según documenta Google.

Solo verá la versión del contenido que se muestra a los usuarios cuyos navegadores rechazan cookies.

Para la mayoría de los equipos que prueban una página de aterrizaje enfocada en búsqueda, el enfoque de misma URL es el camino más simple.

Esa opción elimina por completo la cuestión de las URLs duplicadas.

La contrapartida es la complejidad de implementación en la propia página.

Debes confirmar que tu herramienta renderiza el contenido de forma accesible para los rastreadores.

Usa rel=canonical, no noindex, en las URLs de las variaciones

Si ejecutas una prueba de múltiples URLs, coloca un atributo de enlace rel=canonical en cada URL alternativa apuntando a la original.

Google recomienda canonical sobre noindex porque coincide mejor con tu intención.

Quieres que las URLs de prueba se agrupen con la original como canónica, no que se eliminen del índice.

Google advierte que usar noindex en lugar de rel=canonical en esta situación puede a veces tener efectos negativos inesperados.

Esa es la respuesta práctica a una pregunta común de los operadores: prefiere canonical sobre noindex en las variantes de prueba de páginas que quieres mantener posicionadas.

Si necesitas repasar cómo funcionan las etiquetas canónicas fuera de los escenarios de prueba, consulta cómo especificar una URL canónica para páginas duplicadas.

Usa redirecciones 302, no 301, para el tráfico de prueba

Cuando una prueba redirige a los usuarios de la URL original a una URL de variación, usa una redirección temporal 302, no una redirección permanente 301.

El 302 indica a los motores que la redirección solo dura el experimento, así que mantienen la URL original en el índice en lugar de reemplazarla.

Google también confirma que las redirecciones basadas en JavaScript son válidas para este propósito.

La lógica es directa: un 301 señala un movimiento permanente, mientras que una prueba es temporal.

Enviar una señal permanente para un cambio temporal es el desajuste que crea el riesgo.

No hagas cloaking en tus páginas de prueba

El cloaking significa mostrar un conjunto de URLs o de contenido a Googlebot y otro diferente a las personas.

Google lo cuenta como cloaking ya lo hagas mediante lógica de servidor, robots.txt o cualquier otro método, y va contra las políticas de spam con o sin una prueba en curso.

La consecuencia documentada es la degradación o la eliminación de los resultados de búsqueda de Google.

El patrón seguro que Google describe en cambio es usar enlaces o redirecciones, y dejar que Googlebot vea el mismo contenido accesible que ven los usuarios.

Si tu configuración de pruebas depende de cookies o de la detección del user-agent para ocultar variantes a los rastreadores, rediseñala antes del lanzamiento.

Ejecuta el experimento solo el tiempo necesario

La duración de la prueba es donde muchos equipos crean un riesgo evitable.

Google indica que la duración confiable de una prueba varía según las tasas de conversión y el tráfico del sitio.

Una buena herramienta de pruebas te indica cuándo existen datos suficientes para una conclusión confiable.

De esto se siguen dos reglas prácticas:

  • Deja que la lógica de significancia de la herramienta decida la fecha de finalización, en lugar de dejar que una prueba siga corriendo en un servidor olvidado.
  • Cuando la prueba concluya, actualiza tu sitio con la variación ganadora y elimina todos los elementos de la prueba, como URLs alternativas, scripts de prueba y marcado, lo antes posible.

Google advierte que puede interpretar un experimento innecesariamente largo como un engaño.

Esto es especialmente cierto si una variante se sirve a un gran porcentaje de los usuarios.

Una prueba que sigue corriendo en silencio durante meses después de que ya se tomó una decisión es el modo clásico de fallo aquí.

Una lista de verificación previa al lanzamiento para probar páginas de búsqueda con seguridad

Antes de iniciar una prueba en una página que recibe tráfico orgánico, confirma cada uno de los siguientes puntos:

  1. Acceso a las variantes. Googlebot puede llegar a la página original y ve contenido comparable al que ven los usuarios. Sin ocultamiento de variantes mediante cookies ni user-agent.
  2. Etiquetas canónicas. Cada URL alternativa en una prueba de múltiples URLs lleva un rel=canonical apuntando a la original. Sin noindex en variantes de páginas que quieres mantener indexadas.
  3. Tipo de redirección. Cualquier redirección de prueba es una redirección temporal 302 o una redirección basada en JavaScript, nunca un 301.
  4. Condición de finalización. La herramienta de pruebas está configurada para declarar un resultado confiable, y alguien es responsable de terminar la prueba y eliminar scripts, marcado y URLs alternativas.
  5. Plan de despliegue. La variación ganadora se aplicará a la URL original de inmediato después de que termine la prueba.

Esta lista de verificación se corresponde directamente con las mejores prácticas documentadas de Google, por lo que es una base razonable y no una garantía.

El rendimiento en búsqueda también depende de factores externos a tu prueba, como la competencia y la calidad del contenido.

Trata el movimiento de rankings durante una prueba corta con cautela antes de atribuirlo al experimento.

¿Y las pruebas multivariantes?

Las pruebas multivariantes significan probar más de un tipo de cambio a la vez, buscando el impacto de cada cambio y las posibles sinergias entre ellos.

El ejemplo de Google: probar varias tipografías de un botón mientras se cambia, y no se cambia, la tipografía del resto de la página.

Esto revela si una tipografía es más fácil de leer en todas partes o si se beneficia del contraste.

Las mismas reglas de SEO aplican.

Las pruebas multivariantes suelen ejecutarse en la misma URL con inserción dinámica, lo que evita URLs alternativas, pero las reglas de cloaking y duración siguen aplicando.

Si tu herramienta multivariante crea URLs separadas, aplica la orientación de canonical y 302 exactamente como lo harías en una prueba A/B simple.

Conectar los resultados de las pruebas con las decisiones de ingresos

Para los líderes de operaciones de ingresos, el valor duradero es el comportamiento de conversión que aprendes, no la posición de ranking durante el experimento.

Un titular ganador o un encuadre de oferta que funciona merece propagarse a la página permanente, a las páginas de aterrizaje pagadas y a los mensajes de ventas.

Mantener los resultados de las pruebas en el mismo flujo de trabajo que gobierna la publicación y los mensajes del ciclo de vida ayuda a que ese aprendizaje perdure.

Probar el creativo antes de escalar el gasto es una disciplina relacionada del lado pagado.

El marco de pruebas creativas antes de escalar el gasto (en ingles) cubre cómo estructurar esos experimentos.

El artículo sobre pruebas creativas frente a pruebas A/B (en ingles) aclara diferencias de terminología que a menudo confunden la planificación.

La respuesta corta

Las pruebas A/B no dañan el SEO por defecto. El riesgo proviene del cloaking, de aplicar noindex a variantes que quieres indexadas, de usar 301 para redirecciones temporales o de dejar que una prueba terminada siga corriendo. Sigue las prácticas documentadas de Google y elimina la prueba de forma limpia cuando termine.

Verifica tu configuración contra la documentación de tu plataforma de pruebas, porque las herramientas difieren en cómo insertan variantes y manejan cookies.

Las cinco comprobaciones anteriores cubren el lado del motor de búsqueda.

El lado de la herramienta merece confirmarse antes de tu primera prueba en una página con tráfico orgánico significativo.

Cómo puede ayudar Meshline.

Conecta la automatización, el Marketing Orgánico (generación de demanda) y la gestión del ciclo de vida del cliente (Inteligencia de Ingresos).

Introduce la planificación de temas, la publicación de contenido y la retroalimentación de rendimiento en la conversación sobre tu flujo de trabajo. Reserva una demo de Meshline.

Revenue Intel

Consúltanos sobre este flujo de trabajo.

Cuéntanos qué quieres mejorar o automatizar. Te responderemos con el siguiente paso más útil.

Agenda una demo

Decisiones de implementación

Lleva esta idea a tu operación

Antes de invertir en ¿Las pruebas A/B dañan el SEO? Cómo probar páginas de búsqueda con seguridad, define el problema, los datos disponibles y quién revisará el resultado.