CDN y SEO: qué mejora y qué puede romper

Un CDN no es un factor de posicionamiento. Google no otorga mejor ranking por el mero hecho de servir tu web a través de Cloudflare, Fastly, Akamai o CloudFront en lugar de hacerlo directamente desde tu servidor de origen. Lo que sí hace un CDN es interponerse entre Googlebot y tu contenido, y ahí es donde empiezan los problemas reales: no en si el CDN ayuda, sino en qué puede romper sin que nadie se dé cuenta hasta que el tráfico orgánico ya ha bajado.

La mayoría de las guías tratan el CDN como un capítulo más de la velocidad del sitio: reduce la latencia, mejora el tiempo hasta el primer byte, ayuda con Core Web Vitals. Eso es cierto, pero es la parte que ya cubre cualquier auditoría de hosting y TTFB. La parte que casi nadie explica es la operativa: qué falla cuando el WAF del CDN confunde a Googlebot con un bot malicioso, qué pasa cuando una redirección queda cacheada mucho después de corregirla en origen, por qué las imágenes servidas desde un hostname de CDN pueden perder su indexación por su cuenta, y por qué la geolocalización por IP no funciona como cree la mayoría cuando quien visita es un rastreador.

Qué hace un CDN, exactamente, entre Googlebot y tu servidor

Un CDN (red de distribución de contenidos) es una capa de servidores intermedios —puntos de presencia o PoPs— repartidos geográficamente, que se sitúan delante de tu servidor de origen. Cuando alguien, humano o bot, pide una URL de tu dominio, la petición llega primero al PoP más cercano a quien la hace. Si ese PoP tiene una copia en caché válida de la respuesta, la sirve él mismo y tu servidor de origen nunca se entera de la visita. Si no la tiene, o ha caducado, el PoP pide la página a tu origen, la entrega, y normalmente guarda una copia para la siguiente petición.

Esto tiene una consecuencia que se olvida con frecuencia: el CDN no es un simple tubo transparente. Es un punto donde se aplican reglas propias —caché, compresión, reescritura de cabeceras, firewall de aplicaciones web (WAF), limitación de tasa, detección de bots— antes de que la petición llegue a tu código o la respuesta llegue al cliente. Cada una de esas reglas está pensada, por defecto, para tráfico humano y para atacantes. Ninguna configuración de fábrica contempla explícitamente que uno de los visitantes con más peticiones por minuto y comportamiento «no humano» es precisamente el rastreador cuyo trabajo necesitas.

WAF y protección antibots: cuando el que bloqueas es Googlebot

La causa más frecuente de una caída de indexación tras activar o reconfigurar un CDN no es la caché: es la seguridad. Los firewalls de aplicaciones web y los sistemas de mitigación de bots evalúan cada petición por volumen, patrón de user-agent, cookies y ejecución de JavaScript. Googlebot dispara varias de esas señales por diseño: hace muchas peticiones en poco tiempo, no acepta cookies de sesión, no siempre ejecuta JavaScript en el primer pase de rastreo, y llega desde rangos de IP que, sin documentar, un sistema de detección no distingue de los de un scraper.

El síntoma no es un error 403 evidente que alguien vaya a mirar en el navegador: es un desplome silencioso en el informe de indexación de páginas de Search Console, con URLs que pasan a «Descubierta, no indexada» o a errores de servidor, mientras la web funciona con normalidad para cualquier persona que la visite desde un navegador. La comprobación no es visual, es de cabeceras: hay que pedir la URL con el user-agent de Googlebot, verificando además el rango de IP real del rastreador por reverse DNS, y comparar esa respuesta con la que recibe un navegador normal.

• Revisa los logs del WAF filtrando por user-agent que contenga «Googlebot» y comprueba cuántas de esas peticiones se bloquearon o recibieron un challenge JavaScript o CAPTCHA.
• Si usas reglas gestionadas de bot management, añade una excepción explícita para los rangos de IP publicados por Google, verificados por reverse DNS, no solo por el nombre del user-agent, que cualquiera puede falsificar.
• Usa la inspección de URL en Search Console para lanzar una prueba en vivo: si el renderizado en vivo difiere de lo que ve un navegador normal, el problema está entre el CDN y tu origen, no en tu código.

Redirecciones cacheadas y cabeceras que ya no son ciertas

Cuando corriges una redirección en tu aplicación —cambias un 302 temporal por un 301 permanente, apuntas una URL antigua a un destino distinto, o la eliminas— ese cambio vive en tu origen. El CDN, sin embargo, puede seguir sirviendo la respuesta anterior desde caché durante minutos, horas o días, según el Cache-Control o el TTL de esa regla. Google puede seguir viendo, y siguiendo, la redirección vieja mucho después de que en tu código ya no exista.

El caso más costoso es el inverso: una respuesta de error cacheada por accidente durante un despliegue y servida después como si fuera normal durante horas, mientras Google la revisita y empieza a tratar la página como caída. También ocurre con cabeceras que condicionan la interpretación sin ser la redirección en sí: un Cache-Control demasiado agresivo en una página con canonical dinámico, o un Vary mal configurado, puede hacer que el CDN sirva a Googlebot una variante pensada para otro cliente —por dispositivo, por idioma, por cookie de sesión— sin relación real con lo que debería indexarse.

La forma de prevenir esto no es dejar de cachear, sino purgar de forma explícita las rutas que cambian en lugar de fiarte del TTL, y usar políticas distintas para el HTML —más cortas, con revalidación— que para los activos estáticos como CSS o JS. Un fallo típico es aplicar la misma política larga a ambos solo porque simplifica la configuración.

• Después de cualquier cambio de redirección, purga esa ruta específica en el CDN; no asumas que expirará sola a tiempo.
• Si usas la cabecera Vary, revisa exactamente sobre qué varía la caché: un Vary mal pensado puede multiplicar las variantes guardadas hasta el punto de servir la incorrecta a quien no debía recibirla.

El hostname de las imágenes: cuando el CDN cambia de dominio

Muchas configuraciones de CDN para imágenes no sirven los archivos desde tu dominio principal, sino desde un hostname propio del proveedor o un subdominio dedicado. Técnicamente esto no rompe nada por sí solo, pero desplaza la propiedad de esas URLs a un host que tu configuración de SEO puede no estar cubriendo.

Si tu sitemap de imágenes referencia URLs con el dominio antiguo mientras el HTML real ya sirve las imágenes desde el nuevo hostname del CDN, Google Imágenes rastrea URLs que devuelven redirecciones o ya no existen, y deja de asociar esas imágenes con las páginas que las usan. Si el subdominio de imágenes no está verificado como propiedad aparte en Search Console, además pierdes visibilidad sobre su rastreo: los informes de tu propiedad principal no lo reflejan porque, a efectos de Google, es un host distinto.

Hay un matiz adicional con los datos estructurados: si tu marcado indica una URL de imagen que no coincide con la que realmente se sirve —por ejemplo, porque el sitemap se generó antes de migrar al CDN—, Google puede no encontrar la imagen al validarlo, e incluso si el resto del marcado es correcto, la miniatura asociada en los resultados no llega a aparecer.

• Alinea el dominio de imágenes en tu sitemap, tu marcado de datos estructurados y el HTML real; los tres deben apuntar exactamente al mismo hostname.
• Si usas un subdominio propio de CDN para imágenes, añádelo como propiedad separada en Search Console para poder diagnosticar su rastreo de forma independiente.
• Revisa las cabeceras de acceso entre orígenes si el CDN también sirve fuentes tipográficas: su ausencia puede bloquear silenciosamente esa carga durante el renderizado.

El mito de la geolocalización por IP

Un error habitual es asumir que, porque el CDN detecta la ubicación geográfica de cada IP para enrutar la petición al punto de presencia más cercano, esa misma detección sirve para decidir qué versión de idioma o país mostrar a cada visitante, incluido Googlebot. La lógica parece razonable, pero falla en el punto exacto donde más importa: Googlebot rastrea mayoritariamente desde rangos de IP de Estados Unidos, con independencia de qué mercado o idioma esté rastreando en ese momento.

Si tu web redirige automáticamente según la IP de origen —a quien llega desde una IP estadounidense se le fuerza, por ejemplo, a la versión en inglés—, Googlebot recibe siempre esa redirección al intentar rastrear otros idiomas, y nunca llega a ver su contenido real. El resultado no es un problema de posicionamiento internacional en abstracto: las versiones no inglesas directamente no se indexan.

La forma correcta de servir contenido por idioma o país no es una redirección forzada por IP en el CDN, sino anotaciones hreflang correctas entre versiones, cada una accesible en su propia URL sin redirección obligatoria, dejando que la persona usuaria elija o cambie de versión con un selector visible. Detectar el idioma del navegador, o redirigir según una cookie de preferencia que el propio usuario ya eligió antes, es aceptable como mejora de experiencia; la redirección incondicional por IP, aplicada también al rastreador, no lo es.

Cómo comprobar tu CDN antes de que rompa algo

Ninguno de los fallos anteriores requiere herramientas especializadas; requiere mirar en el sitio correcto antes de que el tráfico caiga, no después.

• Pide una URL clave identificándote como Googlebot y compárala con la misma petición sin ese user-agent: si la respuesta, el código de estado o las cabeceras difieren entre una y otra, hay una regla del CDN o del WAF discriminando por user-agent.
• Revisa el informe de indexación de páginas de Search Console por motivo, no solo el total: un aumento concreto en errores de servidor o en páginas rastreadas pero no indexadas, coincidiendo con un cambio de configuración del CDN, es la señal más temprana.
• Comprueba que robots.txt y el sitemap XML no pasan por ninguna regla de caché agresiva ni de bot management; son las URLs que Google pide con más frecuencia.
• Antes de desplegar cualquier cambio en las reglas del WAF o del bot management, pruébalo primero en modo de solo registro durante unos días y revisa qué tráfico de Googlebot verificado habría bloqueado la regla nueva.

Qué sí aporta un CDN, y qué no debes esperar de él

Dicho todo lo anterior, un CDN bien configurado sigue siendo una mejora real, solo que no del tipo que se suele vender. Reduce la varianza de latencia para audiencias repartidas geográficamente, algo que un solo servidor de origen no puede igualar si tus visitantes están en distintos continentes. Descarga al origen el tráfico de activos estáticos, dejando más capacidad para las peticiones dinámicas que sí importan. Y añade resistencia frente a picos de tráfico inesperados, lo que se traduce en menos caídas y en un rastreo más consistente en el tiempo.

Lo que no aporta es una señal de ranking directa. No mejora el posicionamiento por su nombre, su marca o su cobertura geográfica; mejora, cuando lo hace, la experiencia y la fiabilidad técnica que las señales de rendimiento sí miden. Tratarlo como una casilla de SEO que se marca al contratarlo, en vez de como infraestructura que hay que auditar igual que cualquier otra, es lo que produce los fallos descritos en este artículo: no un CDN mal elegido, sino uno que nunca se ha revisado desde el punto de vista de cómo lo experimenta un rastreador.