Durante la noche
A las 3am hora del Pacífico, mi sitio en producción sirve más solicitudes que en cualquier momento del día laboral. No a usuarios. A bots.
Googlebot está rastreando 21.000 páginas. Bingbot está rastreando 10.000. Mi nightcheck exhaustivo procesa 15.000 publicaciones de blog y páginas de empresas. Un pase de calentamiento prepara la caché del edge de Cloudflare para el tráfico del día siguiente. En conjunto, los procesos nocturnos tocan más páginas que todos los visitantes humanos combinados.
El sitio que construyo durante el día no es el sitio que más importa. El sitio que más importa es el que los rastreadores ven a las 3am.
El censo de rastreo
Cada día ejecuto un censo de rastreo que cuenta lo que los bots vieron en las últimas 24 horas. El censo utiliza la API de analytics de Cloudflare filtrada por user agent. Los números cuentan una historia sobre lo que los motores de búsqueda valoran:
Google: 21,463 (67%)
Bing: 10,620 (33%)
Combined: 32,083
Jobs: 16,111 (50% of all crawls)
Blog: 298
Locale: 1,233
Programmatic: 257
Companies: 14
Los empleos consumen la mitad del presupuesto de rastreo. Googlebot rastrea 10.654 páginas de empleo por día. El sitemap de empleos no tiene límite. Cada oferta de empleo elegible está incluida. La asignación del presupuesto de rastreo me dice qué considera Google como el contenido de mayor valor en el sitio.
Las publicaciones del blog reciben 298 rastreos por día a pesar de ser el contenido de mayor calidad. La proporción de inversión en rastreo (empleos 50 veces más que blog) no coincide con la inversión en contenido (el blog requiere 100 veces más esfuerzo por página que los empleos). Los motores de búsqueda rastrean lo que pueden indexar a escala, no lo que requirió más esfuerzo producir.
Las empresas reciben 14 rastreos por día a pesar de tener más de 7.000 páginas en el sitemap. Este es un problema de inanición del presupuesto de rastreo: las páginas de empleo consumen tanto presupuesto que las páginas de empresas apenas son descubiertas. Los datos nocturnos revelaron este problema. Sin el censo, no habría sabido que 7.000 páginas de empresas son esencialmente invisibles para los rastreadores.
Lo que el 410 te dice
El censo rastrea códigos de estado HTTP. El más interesante es el 410: Gone.
Google 410s: 7,614 (35.5% of crawls)
Bing 410s: 4,494 (42.3% of crawls)
Más de un tercio de todas las solicitudes de rastreadores llegan a páginas de empleo expiradas que devuelven 410. Son empleos que existían cuando el rastreador los descubrió por primera vez, fueron indexados y desde entonces han sido eliminados. El 410 le dice al rastreador “esta página existió pero desapareció permanentemente, deja de solicitarla”.
La tasa de 410 está disminuyendo. La semana pasada fue de 8.858 para Google. Esta semana es de 7.614. Los rastreadores están aprendiendo. Cada día, el número de solicitudes fantasma baja a medida que los motores de búsqueda actualizan sus índices. Pero el aprendizaje es lento. La tasa de 410 de Bing (42,3%) es más alta que la de Google (35,5%) porque Bing es más lento procesando señales de eliminación.
La tendencia del 410 es la señal nocturna más clara. Me indica la velocidad a la que los motores de búsqueda convergen hacia el estado actual del sitio. Una tasa de 410 en aumento significa que estoy eliminando contenido más rápido de lo que los rastreadores pueden adaptarse. Una tasa de 410 en descenso significa que el índice se está poniendo al día. El equilibrio es cero 410, lo que significa que cada página que el rastreador solicita todavía existe.
El problema del 524
Cloudflare devuelve 524 cuando el servidor de origen no responde dentro de la ventana de timeout. En un día de despliegue intenso (87 commits), el censo mostró:
Google 524s: 68 (0.3%)
Bing 524s: 0
Sesenta y ocho timeouts de origen en 24 horas. Cada uno significa que Googlebot solicitó una página, Cloudflare reenvió la solicitud a Railway, y Railway no respondió a tiempo. La causa más probable fueron los reinicios de workers de Railway durante despliegues frecuentes. Cada despliegue reinicia la aplicación, creando una breve ventana donde las solicitudes caducan.
Para el 0,3% de los rastreos, Google vio un sitio roto. Los errores 524 no aparecieron en ningún log de la aplicación porque la aplicación no estaba ejecutándose cuando ocurrieron. El error existía únicamente en el espacio entre Cloudflare y Railway, visible solo a través del censo de rastreo.
A la mañana siguiente, el conteo de 524 bajó a cero. Los despliegues se habían detenido. Los workers estaban estables. Los datos nocturnos confirmaron que el problema era rotación transitoria de despliegues, no un problema estructural.
El pase de calentamiento
Antes de que lleguen los rastreadores, se ejecuta el pase de calentamiento. Solicita cada publicación del blog, cada variante de idioma y 50 páginas de empresas a través de la caché del edge de Cloudflare. El objetivo es asegurar que cuando Googlebot acceda a una página, obtenga una respuesta cacheada en lugar de esperar un renderizado desde el origen.
La diferencia importa. Una publicación cacheada responde en 80ms. Una sin caché tarda 1,5 segundos desde el origen. Googlebot tiene un presupuesto de tasa de rastreo medido en solicitudes por segundo. Respuestas más rápidas significan más páginas rastreadas en la misma ventana. Una caché caliente duplica la cobertura efectiva de rastreo.
El pase de calentamiento es invisible para los usuarios. Ningún visitante humano se beneficia de una publicación cacheada a las 2am. Pero el pase de calentamiento determina si Googlebot descubre 300 publicaciones o 600 en su ventana nocturna. El impacto en SEO es real aunque ningún humano vea el mecanismo.
Lo que la noche revela
Cada mañana leo los logs nocturnos. El patrón es el mismo: mayormente verde, algunas anomalías, una o dos cosas que vale la pena investigar. El ritmo es aburrido. El valor está en el ritmo aburrido.
Una noche aburrida significa que los despliegues no rompieron nada, los rastreadores encontraron lo que esperaban, la caché funciona y el sitio está listo para el tráfico del día siguiente. Una noche interesante significa que algo cambió: un nuevo patrón de errores, una regla de caché que dejó de funcionar, un cambio en el presupuesto de rastreo que indica un cambio en las señales de ranking.
El censo de rastreo me mostró que 7.000 páginas de empresas son invisibles para Google. Ninguna métrica diurna habría revelado esto. Los analytics de usuarios muestran cero tráfico en páginas de empresas, lo que atribuí a baja demanda. El censo mostró cero rastreos de páginas de empresas, lo que significa que Google ni siquiera ha evaluado las páginas. El problema no es la demanda. El problema es el descubrimiento.
El análisis de 524 me mostró que los despliegues en Railway crean ventanas de timeout de origen que Googlebot encuentra. Ningún monitoreo de aplicación habría revelado esto porque la aplicación no está ejecutándose durante el timeout. El problema existe en la brecha de infraestructura entre el despliegue y la disponibilidad.
La tendencia del 410 me mostró que Bing procesa señales de eliminación un 20% más lento que Google. Esto importa para SEO: las páginas de empleo expiradas permanecen en el índice de Bing más tiempo, potencialmente sirviendo resultados obsoletos a usuarios que buscan en superficies impulsadas por Bing (DuckDuckGo, Yahoo).
Cada uno de estos hallazgos provino de los datos nocturnos. El día te dice qué hacen los usuarios. La noche te dice qué hace la infraestructura cuando no estás mirando. Ambos importan. La noche importa más para SEO.
FAQ
¿Cómo ejecutas el censo de rastreo?
El censo utiliza la API de analytics GraphQL de Cloudflare (httpRequestsAdaptiveGroups) filtrada por patrones de user agent (%Googlebot% y %bingbot%). Categoriza las páginas por prefijo de ruta URL y agrega códigos de estado. El script se ejecuta en 30 segundos y produce una comparación lado a lado del comportamiento de rastreo de Google y Bing.
¿Por qué no usar Google Search Console para datos de rastreo?
Google Search Console reporta estadísticas de rastreo con un retraso de 2-3 días y granularidad limitada. El censo de Cloudflare es en tiempo real (últimas 24 horas) e incluye códigos de estado, categorías de contenido y estado de caché que GSC no reporta. GSC es útil para tendencias. El censo es útil para decisiones operativas.
¿El pase de calentamiento incrementa los costos de Cloudflare?
No. Las cachés de Cloudflare se llenan con cualquier solicitud, sin importar la fuente. El pase de calentamiento usa solicitudes HTTP estándar que cuentan contra la cuota normal de solicitudes. En el plan gratuito, no hay límite de solicitudes para respuestas cacheadas. Las solicitudes al origen durante el pase de calentamiento cuentan contra el ancho de banda de Railway, pero con 15.000 páginas promediando 50KB cada una, el total es aproximadamente 750MB por pase de calentamiento.
¿Qué pasa si los rastreadores cambian su comportamiento?
El censo captura lo que sea que hagan los rastreadores, independientemente de los cambios. Un cambio en el patrón de rastreo (más páginas de empleo, menos páginas de blog) aparece inmediatamente en el siguiente censo. Los datos de tendencia a lo largo de los días revelan si el cambio es una anomalía puntual o un cambio sostenido.
Fuentes
Este artículo se basa en datos diarios del censo de rastreo recopilados a través de la API GraphQL de Cloudflare desde marzo de 2026. Herramienta del censo: ~/Projects/Utility/crawl_census.py. Herramienta de nightcheck: ~/.claude/skills/nightcheck/.