¿El uso de una CDN afecta al rastreo de páginas web por parte de los motores de búsqueda?

El uso de una CDN no impide por sí mismo que los motores de búsqueda rastreen las páginas web, ni afecta directamente a la indexación por el hecho de que el sitio utilice una IP de nodo compartida. Lo que realmente determina el resultado del rastreo es si el motor de búsqueda puede acceder de forma estable a la URL de destino a través de la CDN y obtener el código de estado, el contenido de la página y las directivas de indexación correctos. Si está bien configurada, una CDN puede reducir la latencia de acceso y aliviar la carga del servidor de origen; si está mal configurada, también puede distribuir a los rastreadores páginas de bloqueo, contenido desactualizado o respuestas erróneas.

Por tanto, para evaluar el impacto de una CDN en el SEO, no basta con comprobar si el sitio web carga más rápido. Hay que distinguir entre tres etapas: rastreo, renderizado e indexación. Que una solicitud tenga éxito no significa que la página pueda renderizarse por completo; que devuelva un 200 no significa que el contenido cumpla los requisitos de indexación, y tampoco garantiza una mejora del posicionamiento.

Una CDN cambia la ruta de acceso, pero no necesariamente la identidad de la página

Tras implementar una CDN de tipo proxy inverso, el dominio se resuelve mediante DNS a un nodo perimetral. Si el contenido está en caché, el nodo responde directamente; si no lo está, solicita el contenido al servidor de origen. Mientras la URL pública no cambie, los motores de búsqueda seguirán accediendo a la página original y no será necesario crear un conjunto nuevo de direcciones web por haber incorporado una CDN.

Es importante comprobar el certificado HTTPS, el protocolo de conexión con el servidor de origen y la transmisión del nombre de host. Si la CDN y el servidor de origen interpretan de forma distinta el estado de HTTPS, pueden producirse redirecciones en bucle; si el nombre de host es incorrecto al solicitar contenido al servidor de origen, este puede devolver el sitio predeterminado o una página de error. Se trata de fallos en la ruta de acceso, no de una incompatibilidad de los motores de búsqueda con las CDN.

Si solo se trasladan imágenes, scripts y hojas de estilo a un dominio independiente de recursos, la ruta de rastreo de las páginas HTML no cambia. No obstante, el dominio de recursos debe resolverse correctamente, tener un certificado válido y no bloquear los archivos que los motores de búsqueda necesitan para renderizar la página.

Las reglas de seguridad son el obstáculo para el rastreo que más fácilmente se pasa por alto

Que una página se abra con normalidad en un navegador no demuestra que los rastreadores puedan acceder a ella correctamente. Un WAF, la protección contra bots, las restricciones geográficas y los controles de frecuencia de acceso pueden aplicar distintos tratamientos según la IP, los encabezados de la solicitud o los patrones de comportamiento. Es posible que se permita el acceso a los usuarios reales, mientras que los rastreadores reciben un 403 o un 429, o una página de verificación que exige ejecutar un script para continuar.

Un caso más difícil de detectar se produce cuando la página de verificación devuelve un 200. En la capa de transporte, la solicitud parece haber tenido éxito, pero el motor de búsqueda recibe contenido que no corresponde a la página del producto. Esto puede impedir que identifique el texto principal o hacer que clasifique la página como un soft 404. Para diagnosticarlo, hay que revisar el cuerpo de la respuesta, no solo el código de estado.

Las reglas de permiso tampoco deben basarse únicamente en cadenas de User-Agent como Googlebot, ya que este campo se puede falsificar. Se debe utilizar el mecanismo de verificación de bots que proporciona la CDN o verificar el origen según el método oficial del motor de búsqueda, por ejemplo, comprobando los rangos de IP publicados o realizando una verificación de DNS inversa y directa. Se pueden establecer reglas específicas para las solicitudes verificadas, en lugar de desactivar la protección de seguridad de todo el sitio.

En los sitios web dirigidos a varios mercados internacionales, también hay que comprobar si las restricciones geográficas afectan a las ubicaciones de salida reales de los rastreadores y si los límites de velocidad perjudican involuntariamente el rastreo concentrado. La aparición persistente de respuestas 429 o 5xx puede afectar a la estabilidad del rastreo, pero un único error no basta para concluir que el sitio será eliminado del índice.

Los errores de caché son más preocupantes que una duración de caché prolongada

Una duración de caché larga no perjudica necesariamente al SEO. La cuestión es si el objeto almacenado en caché, la clave de caché y el mecanismo de invalidación son correctos. Si, después de actualizar una página de producto, los nodos perimetrales siguen devolviendo el título, el texto principal o el canonical anteriores, los motores de búsqueda no podrán ver los cambios a tiempo. También puede ocurrir que la caché siga sirviendo una directiva noindex o una redirección errónea que ya se haya corregido en el servidor de origen.

En los sitios web multilingües, es especialmente importante revisar la clave de caché. Si una página ofrece distintos idiomas según la cookie o el encabezado Accept-Language y la CDN no distingue esas condiciones, puede servir un mismo idioma a todas las solicitudes. Para las páginas en distintos idiomas que deben indexarse por separado, suele ser más fácil mantener la coherencia mediante URL independientes, estables y accesibles que depender de cambios de contenido según el entorno del visitante.

Las reglas de caché también deben distinguir el contenido normal de las respuestas de error. Una estrategia de caché incorrecta puede hacer que, incluso después de recuperarse el servidor de origen, se sigan devolviendo respuestas 404 o 5xx. A la inversa, reescribir todas las URL inexistentes para que la página de inicio devuelva un 200 oculta el estado real. Las páginas eliminadas deben devolver un 404 o un 410 adecuado; las migraciones permanentes deben utilizar la redirección correcta.

Hay que comprobar qué versiones devuelven realmente los nodos perimetrales de robots.txt, los mapas del sitio, las directivas robots en HTML y el encabezado de respuesta X-Robots-Tag. En particular, un error al solicitar robots.txt no significa lo mismo que una prohibición explícita de rastreo; no se debe dar por hecho que los motores de búsqueda pueden leer el archivo solo porque exista en el servidor de origen.

Una página más rápida no significa necesariamente más rastreo ni mejores posiciones

Al reducir la latencia de respuesta y evitar la sobrecarga del servidor de origen, una CDN ayuda a proporcionar condiciones estables para el rastreo. Sin embargo, la demanda de rastreo también depende del valor de las páginas, la frecuencia de actualización y el tamaño del sitio, entre otros factores. No se puede traducir directamente una mayor velocidad de acceso en un aumento del volumen de rastreo.

Si las páginas dependen de JavaScript para cargar el texto principal, también hay que confirmar que no se bloqueen los scripts, las interfaces y las hojas de estilo. Asimismo, se debe comprobar si las funciones de la CDN para retrasar la ejecución, combinar o reescribir scripts modifican el resultado del renderizado. La mejora de las métricas de velocidad de la página no compensa la falta de contenido principal, un canonical incorrecto o una directiva noindex.

El diagnóstico debe basarse en las respuestas de los nodos perimetrales y en los registros reales de rastreo

Antes y después de implementar una CDN, se pueden seleccionar como muestra la página de inicio, páginas de productos, páginas multilingües, páginas eliminadas y URL con redirecciones, y comparar sus códigos de estado, cadenas de redirección, contenido principal y encabezados de respuesta importantes. Al revisar los campos relacionados con la caché, hay que tener en cuenta las definiciones específicas del proveedor; no se debe concluir que el contenido es correcto basándose únicamente en un indicador de acierto de caché.

Al utilizar curl, hay que comprobar la respuesta completa mediante una solicitud GET y no depender únicamente de HEAD. Cambiar el User-Agent puede ayudar a detectar diferencias en las reglas, pero no simula el origen real de un motor de búsqueda. La prueba de URL en tiempo real de Google Search Console puede ayudar a comprobar el acceso y el renderizado desde el lado de Google, pero superarla no garantiza la indexación.

El análisis de registros debe abarcar tanto la CDN como el servidor de origen. Las solicitudes atendidas desde la caché no llegan al servidor de origen, por lo que consultar únicamente los registros de este puede llevar a concluir erróneamente que «el rastreador no ha accedido». Para distinguir entre un bloqueo de seguridad, un fallo del nodo y un problema de respuesta del servidor de origen, hay que correlacionar los registros de acceso perimetral, los eventos de seguridad y los errores de conexión con el servidor de origen con el momento en que se produjeron las anomalías de rastreo.

La decisión de mantener o cambiar la CDN debe basarse en las pruebas obtenidas de estos recorridos, no en las fluctuaciones del número de páginas indexadas a corto plazo después de su implementación. Mientras las URL públicas sean estables, los rastreadores reales puedan acceder y el contenido coincida con las directivas de indexación, la CDN no debería ser un obstáculo para el rastreo. Si se producen anomalías, se deben corregir primero las reglas concretas en lugar de retirar directamente toda la capa de aceleración.