¿El Test A/B Afecta a Cómo la IA Cita tu Sitio?
Test A/B y cita por IA: por qué el test client-side es invisible para el crawler, qué cambia en server-side y cómo testear GEO sin engañarse.
📚 Este artículo es parte de la guía GEO en 2026: la Búsqueda por IA Cambiando CRO y SEO.
En la configuración más común, un test A/B no afecta a cómo la IA cita tu sitio, porque la IA ni siquiera ve el test: casi toda herramienta de CRO cambia el contenido vía JavaScript en el navegador, y ninguno de los grandes crawlers de IA ejecuta JavaScript. Esto cambia cuando el test es server-side, y ahí valen las mismas reglas de siempre contra el cloaking. Esta guía, parte de la guía de GEO en 2026, cubre lo que la evidencia de logs de servidor muestra sobre los crawlers de IA, la diferencia práctica entre testear en el cliente y en el servidor, las cuatro precauciones técnicas que la documentación de Google exige de cualquier test, y el problema que casi nadie trata con honestidad: el segmento de tráfico venido de IA casi nunca tiene volumen para cerrar muestra, así que no puede ser la métrica que decide tu test.
Qué consiguen leer realmente los crawlers de IA
La pregunta de fondo tiene una respuesta técnica, no filosófica: para que una IA cite tu página, algún crawler necesita haber leído ese contenido. Y lo que esos crawlers leen es bastante más limitado de lo que se imagina.
Un estudio de Vercel en colaboración con MERJ, publicado en diciembre de 2024 a partir de logs reales de servidor de la red de Vercel, midió el comportamiento de los principales crawlers de IA. El hallazgo central: ninguno de los grandes crawlers de IA renderiza JavaScript. GPTBot, de OpenAI, descargó archivos JavaScript en el 11,50% de las peticiones, y el crawler de Anthropic en el 23,84%, pero ninguno de los dos ejecuta esos archivos (Vercel, The rise of the AI crawler). AppleBot es la excepción relevante: renderiza JavaScript a través de un crawler basado en navegador, parecido a Googlebot.
El volumen ayuda a dimensionar el asunto: en el período analizado, GPTBot hizo 569 millones de peticiones en la red de Vercel y el crawler de Anthropic 370 millones, frente a 4.500 millones de Googlebot. Es decir, los crawlers de IA ya son un tráfico relevante, pero todavía una fracción de Googlebot, y ven menos.
Client-side frente a server-side: la diferencia que lo decide todo
Toda la respuesta práctica a esta pregunta cabe en esa distinción.
En un test client-side, el servidor entrega el mismo HTML a todo el mundo y un script reescribe la página en el navegador del visitante. Es el formato estándar de prácticamente toda herramienta de CRO por snippet, incluida Donnu. Como el crawler de IA no ejecuta ese script, lee exactamente el HTML original: el control. La variación, para él, no existe.
En un test server-side, el servidor decide qué versión montar antes de responder a la petición. El crawler recibe HTML de verdad, y ese HTML puede ser el de la variación. Es aquí donde un test pasa a poder cambiar lo que una IA lee y eventualmente cita.
Esa distinción es la misma que separa los dos modelos en la guía de test A/B client-side frente a server-side, solo que leída bajo otra lente: no la de latencia o de parpadeo, sino la de quién consigue leer qué.
| Escenario | Lo que ve el crawler de IA | Riesgo de cloaking | Qué hacer |
|---|---|---|---|
| Test client-side por snippet (estándar de CRO) | Siempre el control | Ninguno, el HTML es igual para todos | Nada más allá de lo normal; la variación simplemente no existe para él |
| Test server-side con sorteo aleatorio | Control o variación, según el sorteo | Ninguno, el sorteo no mira quién pidió | Mantener el sorteo independiente del user-agent y de la IP |
| Test server-side que fuerza al robot al control | Siempre el control, por decisión basada en el robot | Alto, es la definición de cloaking | No hacerlo; eliminar la excepción por user-agent |
| Split URL con URLs de variación indexables | La URL que salga sorteada | Bajo, si está bien configurado | rel="canonical" a la URL original y redirección 302 |
Las cuatro precauciones técnicas que exige la documentación de Google
Cuando el test toca lo que se sirve (server-side o split URL), la documentación oficial de Google sobre testing en sitios es corta y directa (Google Search Central, A/B testing best practices for Search):
- Nunca hagas cloaking. La regla es “no muestres un conjunto de URLs a Googlebot y otro a las personas”. Eso vale tanto si la decisión se toma por lógica de servidor, por robots.txt o por cualquier otro medio. Un test con sorteo aleatorio de verdad no viola esto, porque no mira quién está pidiendo la página.
- Usa
rel="canonical"en las URLs de variación. Si el test usa URLs distintas, cada URL alternativa debe apuntar por canonical a la URL original. Google recomienda esto en lugar denoindex, porque refleja mejor la intención: no quieres que la página deje de ser indexada, quieres que las versiones se entiendan como variaciones agrupadas bajo la original. - Usa redirección 302, nunca 301. El 302 (temporal) dice que la URL original debe seguir en el índice. El 301 (permanente) señala que la original fue sustituida, que es exactamente lo contrario de lo que significa un test temporal.
- Cierra el test en cuanto acabe. Terminado el experimento, actualiza el sitio con la variación elegida y elimina los elementos del test. Un test que queda en el aire indefinidamente puede interpretarse como un intento de engañar a los motores de búsqueda.
Vale un quinto punto, que la misma documentación registra y que casi nadie recuerda: Googlebot generalmente no soporta cookies. Un test controlado por cookie tiende a mostrarle solo la versión que vería una persona sin cookies, normalmente el control. No es un problema, es una consecuencia a conocer antes de intentar explicar por qué la variación “no apareció en el índice”.
La consecuencia que casi nadie extrae: el test no expone la mejora
Aquí está la parte contraintuitiva. Si ejecutas un test client-side, la IA sigue leyendo el control durante todo el experimento. Eso es cómodo a corto plazo (nada de lo que testeas puede “confundir” a un motor generativo), pero tiene un coste práctico: la variación ganadora solo pasa a existir para los sistemas de IA cuando es promovida a contenido servido de verdad, en el HTML de la página.
Eso reordena el trabajo de forma útil. El test A/B prueba que el cambio convierte mejor con personas. La implementación definitiva en el HTML es el paso que también la expone a crawlers y motores generativos. Tratar las dos cosas como un solo evento, “voy a testear y ver si la IA cita más”, es confundir dos procesos que ocurren en tiempos distintos y con mecanismos distintos.
El problema de muestra: el tráfico de IA es demasiado pequeño para decidir
Supón que quieres ir más allá y testear si un cambio de estructura de contenido (la materia de la guía de GEO) mejora la conversión de quien llega desde un asistente. La intención es buena, pero la cuenta casi nunca cierra.
Un sitio con 12.000 visitas por semana, de las cuales 320 vienen de asistentes de IA, con una tasa de conversión base del 2,6%, queriendo detectar una mejora relativa del 20% (llevando la tasa a cerca del 3,1%), al 95% de confianza y 80% de poder, necesita:
Cálculo por aproximación normal de dos proporciones, 2 variaciones (50/50). Cambia los campos y mira el impacto en vivo.
Ajustando la calculadora de arriba a tasa base 2,6, efecto mínimo detectable 20 (relativo) y 12.000 visitantes por semana, el resultado es 16.128 visitas por variación (32.256 en total), lo que lleva cerca de 19 días ejecutándose en el sitio entero. Ahora repite la cuenta con las mismas 16.128 por variación, pero alimentadas solo por las 320 visitas semanales venidas de IA: serían cerca de 706 días, casi dos años, para un único test. En ese plazo, el propio comportamiento de los asistentes ya habría cambiado varias veces.
Se puede invertir la pregunta y preguntar qué consigue detectar el segmento de IA en el plazo que aceptas esperar. Con 320 visitas por semana a lo largo de 8 semanas, acumulas 1.280 visitas por variación. En ese tamaño, sobre una base del 2,6%, el menor efecto detectable es de aproximadamente 67,8% relativo (tasa objetivo de cerca del 4,36%). Es decir, solo una diferencia enorme aparecería, y las diferencias enormes de conversión raramente existen en un cambio de estructura de contenido.
Muestra por variación: -. Cálculo por aproximación normal de dos proporciones, división igualitaria entre las variaciones. Cambia los campos y mira el menor efecto que tu tráfico puede probar.
Ajusta la calculadora de arriba a tasa base 2,6, 320 visitantes por semana, 8 semanas y 2 variaciones para reproducir ese número. La lectura práctica: el segmento de IA es una lectura secundaria, nunca la métrica de decisión. Ejecuta el test en el sitio entero, decide por él, y mira el segmento de IA como contexto direccional, sabiendo que no tiene poder estadístico para sostener una decisión por sí solo. Es la misma disciplina descrita en la guía completa de optimización de conversión: cuando el volumen no financia la precisión, cambia lo que prometes medir, no el rigor.
Cómo medir la cita por IA de verdad (fuera del test A/B)
Si la cita no puede ser métrica primaria de un test A/B, todavía necesita ser seguida de alguna forma. Cuatro señales, ninguna de ellas suficiente por sí sola:
| Señal | Qué muestra | Qué NO prueba |
|---|---|---|
| Accesos de crawlers de IA en los logs del servidor | Que tu página está siendo leída por esos sistemas | Que fue citada en alguna respuesta |
| Tráfico de referencia de asistentes en la analítica | Que alguien hizo clic a partir de una respuesta generada | El volumen total de citas, ya que buena parte no genera clic |
| Comprobación manual periódica en consultas objetivo | Si tu página aparece citada hoy, en esa consulta específica | Estabilidad, porque la respuesta cambia entre ejecuciones |
| Evolución de búsquedas por marca | Si la exposición en respuestas está generando recuerdo | Causalidad directa con cualquier cambio específico |
El punto honesto: ninguna de esas cuatro tiene la granularidad y el volumen que un test A/B exige. Componen un panel de seguimiento, no un experimento.
Los errores más comunes en esa intersección
| Error | Señal de alerta | Corrección |
|---|---|---|
| Esconder el test del robot por user-agent | “Configuré para que Googlebot vea siempre el control” | Eso es cloaking según la definición de Google; deja el sorteo aleatorio e independiente de quién pide |
| Usar 301 en el split URL | La redirección del test es permanente | Cámbiala a 302; el 301 dice que la URL original fue sustituida |
| Esperar que el test client-side cambie la cita | “Testeé tres meses y la IA no cita la versión nueva” | Nunca leyó la versión nueva; solo cuenta el HTML servido |
| Decidir el test por el segmento de IA | “En el tráfico de IA ganó la variación B” | Comprueba la muestra de ese recorte; casi siempre falta poder estadístico |
| Dejar el test en el aire indefinidamente | El experimento lleva meses sin decisión | La propia documentación de Google pide que se cierre y se elimine el test al final |
| Tratar la cita como métrica de conversión | El panel mezcla cita con ingresos | La cita es señal de exposición; la conversión es lo que el test A/B decide |
Hazlo automático en Donnu
Acabas de ver que la pregunta del título tiene una respuesta técnica y no una respuesta de opinión: depende de dónde se decida la variación, y el test A/B por snippet, el formato más común, es invisible para los crawlers que alimentan a los sistemas generativos. Lo que Donnu resuelve es el otro lado de la cuenta, el lado que realmente decide: dimensionar la muestra correcta antes de ejecutar, medir la conversión de personas de verdad en el sitio entero y devolver un veredicto honesto, en lugar de dejar que declares un ganador en un recorte de tráfico demasiado pequeño para sostener cualquier conclusión.
Empieza una prueba gratis de 14 días y lleva ese rigor a tus cambios de contenido. Para la base completa del asunto, mira la guía de GEO en 2026.
Referencias
- Vercel y MERJ. The rise of the AI crawler. Análisis de logs de servidor publicado el 17 de diciembre de 2024. vercel.com/blog/the-rise-of-the-ai-crawler.
- Google Search Central. A/B testing best practices for Search. developers.google.com/search/docs/crawling-indexing/website-testing.
- Aggarwal, P., Murahari, V., Rajpurohit, T., Kalyan, A., Narasimhan, K., Deshpande, A. GEO: Generative Engine Optimization. ACM SIGKDD 2024. arxiv.org/abs/2311.09735.
Lee también:
Preguntas frecuentes
- ¿Ejecutar un test A/B perjudica la probabilidad de que mi sitio sea citado por una IA?
- En la configuración más común, no, porque la IA ni siquiera ve el test. Un test A/B client-side (el formato estándar de casi toda herramienta de CRO) cambia el contenido vía JavaScript en el navegador, y ninguno de los grandes crawlers de IA ejecuta JavaScript. Según el estudio de Vercel con datos de servidor de diciembre de 2024, GPTBot y el crawler de Anthropic descargan archivos JavaScript (11,50% y 23,84% de las peticiones, respectivamente) pero no los ejecutan. Lo que indexan es el HTML original, es decir, el control. Los tests server-side son otra historia, y es en ellos donde valen las precauciones de esta guía.
- ¿Cuál es la diferencia entre un test client-side y uno server-side para un crawler de IA?
- En el client-side, el servidor entrega el mismo HTML a todo el mundo y el JavaScript reescribe la página después, ya en el navegador. Como el crawler de IA no ejecuta ese JavaScript, lee exactamente el HTML original, el control. En el server-side, el servidor decide qué variación entregar antes de responder, así que el crawler puede recibir la variación en lugar del control. Es solo en ese segundo caso donde el test tiene alguna probabilidad de cambiar lo que una IA lee y eventualmente cita.
- ¿Un test A/B server-side cuenta como cloaking?
- No, siempre que la decisión de variación sea aleatoria e independiente de quién está pidiendo la página. La documentación de Google sobre testing en sitios es explícita: el problema es mostrar un conjunto de URLs al robot y otro a las personas. Si tu servidor sortea la variación sin mirar el user-agent o la IP del visitante, no está discriminando robot de persona, y por eso no es cloaking. El riesgo aparece cuando alguien intenta "proteger el SEO" forzando que el robot vea siempre el control, que es exactamente la definición del problema.
- ¿Se puede hacer un test A/B solo sobre el tráfico que viene de asistentes de IA?
- Casi nunca con rigor estadístico, porque ese segmento suele ser demasiado pequeño. En el ejemplo trabajado de esta guía, un sitio con 12.000 visitas por semana y 320 de ellas venidas de asistentes necesitaría 16.128 visitas por variación para detectar una mejora relativa del 20% sobre una tasa base del 2,6%. En el sitio entero eso lleva 19 días; solo en el segmento de IA llevaría cerca de 706 días. La salida honesta es ejecutar el test en el sitio entero y seguir el segmento de IA como lectura secundaria, nunca como métrica de decisión.
- ¿Qué precauciones técnicas necesita un test A/B para no perjudicar la búsqueda y la cita?
- La documentación de Google lista cuatro: no hacer cloaking (nunca decidir la variación por el user-agent), usar rel="canonical" en las URLs de variación apuntando a la URL original cuando el test usa URLs distintas, usar redirección 302 (temporal) y nunca 301 (permanente), y cerrar el experimento en cuanto termine, eliminando los elementos de test. Vale recordar también que Googlebot generalmente no soporta cookies, así que un test controlado por cookie tiende a mostrarle solo la versión de quien no acepta cookies.
- Si la IA solo lee el control, ¿mi test ganador nunca mejora la probabilidad de cita?
- Mientras el test está corriendo en client-side, correcto: el crawler sigue viendo el HTML original. La mejora solo pasa a existir para los sistemas de IA cuando la variación ganadora es promovida a contenido servido de verdad, en el HTML de la página. Eso cambia el orden práctico del trabajo: usa el test A/B para probar que el cambio convierte mejor con personas, y trata la implementación definitiva en el HTML como el paso que también la expone a crawlers y motores generativos.
- ¿Cómo medir si un cambio mejoró mi cita por IA?
- Ninguna métrica aislada lo resuelve, y es honesto decir que la medición todavía es imperfecta. El conjunto más útil combina cuatro señales: accesos de crawlers de IA en los logs del servidor, tráfico de referencia venido de asistentes generativos en la analítica, comprobaciones periódicas y manuales de cita en consultas objetivo, y la evolución de las búsquedas por marca. Ninguna de ellas por separado prueba causalidad, y ninguna tiene volumen suficiente para convertirse en métrica primaria de un test A/B.