Idiomas

Pruebas A/B en el edge para SEO

Cómo ejecutar pruebas A/B y multivariantes en la CDN o el edge con Cloudflare Workers, Akamai, Fastly, Optimizely o VWO sin introducir cloaking, duplicados ni desperdicio de rastreo.

Publicado por primera vez: 3 jul 2026 · Última actualización: 22 ago 2026 · Avanzado
Idiomas
AIEscrito porAI v2

Las pruebas A/B en el edge sirven variantes HTML o redirecciones desde la CDN antes de llegar al origen. Al entregar HTML de servidor, evitan parte de la incertidumbre del testing basado en JavaScript, pero introducen riesgos propios: asignaciones inestables cuando Googlebot no conserva cookies, señales canonical contradictorias si existen URL de variante y multiplicación de URL rastreables en pruebas multivariantes. Google admite experimentar, no hacer cloaking. Mantén determinista el tráfico sin cookie y de bots, apunta las URL alternativas al control con canonical, utiliza 302 y no 301 mientras la prueba sea temporal y retírala al elegir ganador. Detectar bots por user-agent solo es aceptable si el control mostrado es realmente el contenido que pretendes indexar.

TL;DR — El Edge A/B testing sirve HTML de variantes o redirecciones desde la capa de workers de la CDN antes de que el origen llegue a ver la petición. Como los motores reciben HTML real (y no un cambio hecho con JS en el cliente), es el lugar más seguro para hacer tests, pero tiene una superficie de riesgo propia del edge. Divídalo en dos patrones: reescrituras de HTML en la misma URL (riesgo: Googlebot por lo general no conserva cookies, así que el bucketing por cookie puede mostrarle una variante aleatoria nueva en cada rastreo) y redirecciones a una URL de variante (riesgo: contenido duplicado y confusión de canónicas). Soluciones: haga que el tráfico de bots o sin cookie sea determinista, apunte con rel=canonical de la variante al control, use un 302 y no un 301 mientras esté activo, y desmonte el test en cuanto tenga un ganador. La línea de Google es “hacer tests está bien, el cloaking no”, y el cloaking tiene que ver con la intención y la asimetría, no con que “un bot haya visto una vez la variante B”. Aquí solo trataría brevemente qué es el edge SEO: el artículo general sobre edge SEO de este clúster se ocupa del recorrido por las plataformas; este artículo trata de los riesgos específicos de hacer tests.

Qué es lo que realmente cambia al hacer tests en el edge

Un worker en el edge puede enrutar o transformar una respuesta cerca del visitante, lo que cambia dónde ocurre la asignación pero no la lógica experimental subyacente. 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: Cloudflare: Workers overview La seguridad de cara a los buscadores depende de servir variantes de test legítimas de forma consistente, y no de dirigir contenido sustancialmente distinto a los rastreadores de los buscadores. Evidence for this claim Google permits website testing, warns against cloaking, and recommends appropriate canonicals or temporary redirects and limited test duration. Scope: Google Search guidance for website testing; it applies regardless of whether assignment occurs at the edge or origin. Confidence: high · Verified: Google: Website testing and Search

El Edge A/B testing es un caso de uso del edge SEO: el bucketing y la reescritura del HTML (o la redirección) se hacen en un worker de la CDN —Cloudflare Workers, Akamai EdgeWorkers/EdgeKV, Fastly Compute o las integraciones en el edge o del lado del servidor de Optimizely y VWO— antes de que la petición llegue al origen. SearchPilot describe el SEO en el 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,” (traducción) «cualquier cambio de SEO que se hace después de que el HTML lo haya creado su CMS o servidor de origen y antes de que se sirva al usuario», y añade el punto clave para nosotros: “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.” (traducción) «Aparecen ante todos los usuarios y ante Googlebot como cambios de HTML del lado del servidor, así que no hay riesgos ni inconvenientes desde el punto de vista de la indexación». Esa es la ventaja de partida: el edge es un lugar seguro para hacer tests porque los motores reciben HTML real, igual que del lado del origen.

Entonces, ¿por qué existe este artículo si el edge es seguro? Porque dónde se hace el test es seguro; cómo se hace el bucketing en el edge es donde viven las trampas específicas de SEO. Dos de ellas son casi exclusivas de este patrón, y los artículos genéricos sobre “testing A/B y SEO” pasan por alto ambas.

La postura real de Google: hacer tests está bien, el cloaking no

Digámoslo claramente, porque la mitad del miedo que rodea a los tests de SEO está fuera de lugar. Google apoya explícitamente los tests A/B y multivariante y publica buenas prácticas para ellos. La línea que traza es el cloaking, que su política de spam define como “presenting different content to users and search engines with the intent to manipulate search rankings and mislead users.” (traducción) «presentar contenido distinto a los usuarios y a los motores de búsqueda con la intención de manipular los rankings de búsqueda y engañar a los usuarios». Fíjese en la intención de manipular y en la asimetría entre usuarios y motores, no en que “un bot haya visto alguna vez una variante”. Optimizely parafrasea lo mismo para sus propios clientes: “Google encourages constructive testing and does not view the ethical use of testing tools such as Optimize to constitute cloaking.” (traducción) «Google fomenta los tests constructivos y no considera que el uso ético de herramientas de testing como Optimize constituya cloaking».

La línea práctica y clara que da Google en su documentación sobre testing es contundente: “Don’t show one set of URLs to Googlebot, and a different set to humans.” (traducción) «No muestres un conjunto de URLs a Googlebot y otro distinto a las personas». Si su test en el edge respeta eso —todos, bots incluidos, pueden recibir las mismas variantes legítimas, servidas de forma consistente—, está del lado correcto de la política.

Los dos patrones de testing en el edge (y sus distintos riesgos)

Manténgalos separados mentalmente, porque fallan de forma distinta y se arreglan de forma distinta.

Patrón 1 — HTML reescrito en el edge en la misma URL

El worker mantiene la misma URL (/product/123) y cambia un titular, un CTA, un formato de visualización de precio: el HTML Rewriter reescribe la respuesta al vuelo. Este es el modelo de «pruebas A/B con acceso directo a la misma URL» de Cloudflare Workers que, como dice su documentación, “Choose a group and set the cookie (50/50 split)” (traducción) «Elige un grupo y establece la cookie (reparto 50/50)» para un visitante nuevo.

El riesgo específico del edge: las cookies. Google lo dice directamente: “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.” (traducción) «Googlebot por lo general no admite cookies. Esto significa que solo verá la versión del contenido que es accesible para los usuarios con navegadores que no aceptan cookies». Casi todas las implementaciones en el edge guardan el bucket en una cookie para que una persona que vuelve siga en el mismo grupo (el ejemplo con EdgeKV de Akamai hace exactamente esto: “Client bucket selection will be persistent via a cookie value to ensure a client is locked to the same URL on subsequent visits” (traducción) «La selección del bucket del cliente será persistente mediante el valor de una cookie para asegurar que un cliente quede fijado a la misma URL en visitas posteriores»). Pero Googlebot no lleva esa cookie, así que en cada rastreo puede volver a entrar en el sorteo y caer en un bucket distinto al de la vez anterior. Eso no es cloaking engañoso, pero significa que Google puede indexar con el tiempo una versión fluctuante e inconsistente de la misma URL. Es el primo sutil y nativo del edge del clásico problema de “mostramos deliberadamente algo distinto a los bots”, y es lo más importante que este artículo existe para explicar.

Patrón 2 — una redirección en el edge a una URL de variante

Aquí el worker redirige con un 302 /product/123 a una URL distinta: /product/123?v=b o /product/123-b. Ahora tiene una URL genuinamente diferente que los motores pueden descubrir e indexar por sí sola.

El riesgo específico del edge: contenido duplicado y confusión de canónicas. Si Google indexa la URL de variante como una página propia, ha dividido las señales y posiblemente ha creado un duplicado.

Cómo arreglar el Patrón 1: haga que los rastreadores sean deterministas

La solución no es “detectar al bot y ocultar el test”. Es: no deje que las peticiones sin cookie reciban una tirada aleatoria. Reparta a las personas por cookie si quiere, pero para cualquier petición sin cookie —lo que incluye a Googlebot— resuelva la variante de forma determinista: aplique un hash a la URL, fíjela mediante una clave estable o, simplemente, sirva siempre el control. La idea es que la misma URL siempre produzca la misma variante para cualquier cliente sin cookie, de modo que Google vea una página estable en cada rastreo en vez de un lanzamiento de moneda.

Cloudflare documenta un mecanismo útil para esto: “Enable Passthrough to allow direct access to control and test routes.” (traducción) «Habilita Passthrough para permitir el acceso directo a las rutas de control y de test». Passthrough permite que cualquiera —bots, QA, responsables implicados— llegue de forma consistente a /control/* o /test/* en vez de ser rerandomizado en cada petición sin cookie. Esa es la palanca documentada oficialmente para dar a los rastreadores una variante consistente sin inventarse una ruta de código exclusiva para bots.

El modelo de SearchPilot esquiva esto por completo dividiendo a otro nivel: “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.” (traducción) «Cuando se hace SEO A/B testing, solo hay una versión de la página. No estamos mostrando versiones distintas de la misma página a los usuarios ni a Google. Esto no es cloaking y no crea versiones duplicadas de la misma página». Dividen páginas de forma determinista (una página dada muestra siempre la misma variante a todo el mundo) en lugar de dividir usuarios de forma aleatoria: la filosofía de bucketing opuesta a la del ejemplo de cookie 50/50 de Cloudflare, y un perfil de riesgo SEO genuinamente distinto aunque a ambos se les llame “edge A/B testing”. Como ellos lo expresan: “There is only one Googlebot. You also can’t make two versions of a single page because it would cause problems like duplicate content.” (traducción) «Solo hay un Googlebot. Tampoco puedes hacer dos versiones de una misma página porque causaría problemas como contenido duplicado».

Cómo arreglar el Patrón 2: disciplina de canónicas y redirecciones

Cuando el test vive en su propia URL, se aplican directamente tres reglas de la documentación de testing de Google:

  • Apunte la URL de referencia de la variante de vuelta al control. 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.” (traducción) «puedes usar el atributo de enlace rel=“canonical” en todas tus URLs alternativas para indicar que la URL original es la versión preferida». Cada URL de variante apunta a su URL de referencia a la URL de control.
  • Use un 302, no un 301, mientras el test esté activo. Google: “use a 302 (temporary) redirect, not a 301 (permanent) redirect.” (traducción) «usa una redirección 302 (temporal), no una redirección 301 (permanente)». Un 302 le dice a Google que el movimiento es temporal y que mantenga indexada la original; un 301 dice que es permanente. Reserve el 301 para después de elegir un ganador y comprometerse con él.
  • Desmóntelo cuando termine. 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.” (traducción) «Una vez que hayas concluido el test, actualiza tu sitio con la variación o variaciones de contenido deseadas y elimina todos los elementos del test lo antes posible… podemos interpretarlo como un intento de engañar a los motores de búsqueda y actuar en consecuencia».

Una advertencia honesta sobre la URL de referencia: es una pista, no una directiva. Si el contenido de la variante difiere sustancialmente del control, Google puede ignorar esa señal e indexar ambas, que es exactamente por lo que el Patrón 2 es más arriesgado que una reescritura en la misma URL, y por lo que los cambios estructurales grandes se gestionan mejor como una división de páginas que como una URL de variante por usuario.

Presupuesto de rastreo: el problema de la multiplicación multivariante

Un solo test A/B añade un estado extra que un rastreador podría ver. Un test multivariante los multiplica: tres variables independientes con dos variantes cada una son hasta ocho combinaciones distintas que un rastreador podría encontrarse en teoría si su bucketing no es fijo y determinista por URL. Un bucketing no determinista convierte una URL en una nube cambiante de estados, y cada estado rastreable distinto es presupuesto de rastreo gastado. Este ángulo de las permutaciones que se acumulan está prácticamente ausente en la mayoría de los artículos sobre testing y SEO, y es la razón por la que un bucketing determinista y fijo importa para la eficiencia de rastreo y no solo para el cloaking. (La guía de Google de “Crawling December” de 2024 sobre las CDN y el presupuesto de rastreo es la lectura de fondo adecuada; el artículo general sobre edge SEO de este clúster remite a ella.)

”Servir a los bots la variante de control”: ¿atajo o trampa?

Esto requiere cuidado, porque es un consejo a medias. Servir a los rastreadores una versión de control estable está bien —incluso es bueno— si ese control es genuinamente la versión que le gustaría que cualquier usuario recibiera siempre y que Google indexara. La seguridad viene de la consistencia y la legitimidad, no de la detección de bots.

Cruza hacia el cloaking en el momento en que la “ruta para bots” existe específicamente para mostrar a los motores de búsqueda una realidad distinta de la que reciben los usuarios reales: eso es literalmente el “Don’t show one set of URLs to Googlebot, and a different set to humans” (traducción) «No muestres un conjunto de URLs a Googlebot y otro distinto a las personas» de Google. Así que el planteamiento correcto es: sirva a los rastreadores la misma variante determinista que le parecería bien que cualquier usuario viera siempre, no una ruta especial solo para bots creada para esquivar el escrutinio. Detectar el agente de usuario (user-agent) para “excluir a los bots del test” solo es seguro porque resulta que se ha estandarizado una única versión verdadera; no es seguro como técnica general.

¿Cuánto tiempo se puede mantener un test en el edge?

Google no da un número de días. Advierte contra dejar los elementos del test en su sitio tanto tiempo que el “test” se haya convertido silenciosamente en el estado permanente del sitio sin que nunca se haya declarado un ganador: de nuevo la línea de “remove all elements of the test as soon as possible” (traducción) «elimina todos los elementos del test lo antes posible». John Mueller, de Google, se ha pronunciado sobre esto: ejecutar continuamente nuevos experimentos uno tras otro está bien, pero un único test que se deja funcionando de forma indefinida hasta convertirse en la página permanente de facto es lo que empieza a parecer que ya no es realmente hacer tests. (Las declaraciones de Mueller aquí llegan a través de la cobertura del sector de un Google Webmaster Central Hangout, no de un documento propio de Google; trate la redacción como una paráfrasis.) Mueller también ha señalado que ejecutar un test A/B durante una migración web enturbia las señales de redirección que Google necesita para reconocer la migración limpiamente, así que evite solapar ambas cosas.

Optimizely, replanteando a Google para sus clientes, le pone una regla general: “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.” (traducción) «Si ejecutas un experimento durante un tiempo innecesariamente largo, Google puede interpretarlo como un intento de engañar a los motores de búsqueda y actuar en consecuencia». Y sobre el despliegue de un ganador, Optimizely estima que una redirección 301 conlleva “a small loss of link equity (around 10%)” (traducción) «una pequeña pérdida de link equity (alrededor del 10 %)»: esa es una cifra de Optimizely y una regla general, no un número confirmado por Google, así que tómela como tal.

La guía de Bing es más escueta: aplique la de Google por defecto

Bing no tiene una página dedicada a los tests A/B en el edge o la CDN tan detallada como la de Google. Lo que sí tiene: un estándar general de cloaking que se apoya en que el contenido sea 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” (traducción) «siempre que hagas un esfuerzo de buena fe por devolver el mismo contenido a todos los visitantes, siendo la única diferencia que el contenido se renderiza en el servidor para los bots y en el cliente para los usuarios reales, esto es aceptable y no se considera cloaking»— y una nota que dice que para “significant structural changes, we recommend hosting each version on separate URLs, or split URL testing,” (traducción) «cambios estructurales significativos, recomendamos alojar cada versión en URLs separadas, o split testing por URL», con IndexNow para que las URLs de variante se vean rápido. Como el estándar de Bing es compatible con el de Google, aplique las reglas de canónica, 302 y duración de Google como valor por defecto conservador para ambos motores.

Dónde encaja esto

Este es el complemento específico sobre testing del artículo general de edge SEO de este clúster: ese se ocupa del recorrido por las plataformas (qué workers existen, qué más se puede hacer en el edge); este solo trata del riesgo del split testing. La mecánica de canónicas y contenido duplicado del Patrón 2 se apoya en las mismas ideas que los análisis en profundidad sobre canonicalización y contenido duplicado, y el ángulo del presupuesto de rastreo conecta con el material sobre rastreo y presupuesto de rastreo, todo ello en otras partes del sitio.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.