Google explica por qué el rastreo se dispara cuando un sitio migra a una CDN

Google publicó el 11 de noviembre una guía para los sitios que van a empezar a usar una red de distribución de contenido, o CDN. La advertencia principal: justo después del cambio, el tráfico de los rastreadores en el servidor de origen puede subir casi de inmediato, que es precisamente el problema que la CDN debería resolver.

Según Google Search Central, la explicación está en cómo la infraestructura de rastreo calcula el límite de capacidad de cada sitio, también llamado hostload. Cuando las respuestas son cada vez más lentas, los rastreadores reducen el ritmo. Cuando son rápidas y estables, y hay demanda de rastreo, ese límite sube poco a poco.

En cuanto el DNS empieza a apuntar a la CDN, los tiempos de conexión y de respuesta bajan mucho. Para los sistemas de Google, es como si el servidor hubiera recibido una gran mejora de hardware, y los rastreadores aumentan el ritmo de las solicitudes en consecuencia.

La caché empieza vacía

Ese ritmo mayor no sería un problema si la CDN absorbiera todas las solicitudes. Pero una CDN nueva arranca con la caché vacía. En la primera solicitud de cada dirección, el servidor perimetral todavía no tiene la copia del archivo (HTML, CSS, JavaScript, imágenes) y tiene que ir a buscarla al origen. Solo las solicitudes siguientes a la misma dirección se sirven directamente desde el perímetro.

Los visitantes humanos se concentran en pocas páginas populares, como la página de inicio, los artículos más leídos y las promociones activas, que entran rápido en la caché. Los rastreadores hacen lo contrario: recorren todo el inventario de URL del sitio, y cada dirección que aún no está en caché va directo al origen. Google matiza que los rastreadores no aceleran de golpe y que muchas CDN ya suavizan los picos de tráfico, pero, hasta que la caché se calienta, quien carga con el peso sigue siendo el servidor de origen.

Ver ese pico en los registros suele llevar a los administradores a activar el bloqueo general de bots en el panel de la CDN. Sin excepciones, estas reglas tratan todo el tráfico automatizado de la misma forma. Cuando la CDN o el firewall de aplicaciones web (WAF) responde a la solicitud con un CAPTCHA, los rastreadores de Google fallan. El sitio parece restringido o roto, los rastreadores retroceden y las páginas, incluidas las fichas de productos de Shopping, empiezan a desaparecer de la Búsqueda.

Lo que recomienda Google

• Permitir los bots verificados. La mayoría de las CDN y de los WAF tienen una opción o una regla predefinida para permitir bots conocidos, y los de Google se pueden identificar por los rangos de IP que la empresa publica. Otra salida es usar el robots.txt o reglas dirigidas solo a los bots no deseados.
• Calentar la caché con antelación. Antes de pasar todo el tráfico por la CDN, acceder a través de ella, a un ritmo controlado, a las páginas con más tráfico, a las que tendrán picos previstos (lanzamientos promocionales o de temporada) y a las más rastreadas.
• Usar 429 o 503 como freno temporal. Si la carga en el origen se vuelve crítica mientras la caché se calienta, configurar el servidor o la CDN para devolver los códigos 429 (Too Many Requests) o 503 (Service Unavailable) durante poco tiempo: unas horas, o de 1 a 2 días como máximo.

Para quien gestiona una marca, el mensaje es que una migración de infraestructura también afecta a la presencia en los resultados de búsqueda. Una regla de seguridad demasiado amplia, sin excepción para los bots verificados, puede sacar páginas de la Búsqueda y de otros productos que dependen de los datos rastreados.