Crawl Budget: qué es realmente y cuándo importa según la documentación oficial de Google

El crawl budget de un dominio depende de dos variables independientes que Google combina. La primera es el límite de velocidad de rastreo, una cifra técnica que refleja cuántas peticiones simultáneas puede aguantar el servidor sin degradarse. Google la calcula midiendo tiempos de respuesta y tasa de errores: un servidor lento o que devuelve muchos errores 5xx recibe menos peticiones, no más, aunque el sitio tenga miles de páginas pendientes de rastrear.

La segunda variable es la demanda de rastreo, que refleja cuánto interés tiene Google en visitar ese sitio con frecuencia. Depende de la popularidad de las páginas, de la frecuencia real con la que cambia el contenido y de si Google detecta que el sitio en conjunto merece atención. Un blog que publica un artículo al mes no genera la misma demanda que un portal de noticias que publica cien al día.

La demanda de rastreo también reacciona a eventos concretos: un cambio de dominio, una migración de HTTP a HTTPS o una reestructuración masiva de URLs pueden disparar temporalmente el interés de Google por revisar el sitio entero, mientras que un sitio que lleva meses sin publicar nada nuevo suele ver cómo Google reduce poco a poco la frecuencia con la que vuelve. Ninguna de las dos variables se controla directamente; solo se influyen de forma indirecta mejorando el rendimiento del servidor y publicando contenido que de verdad cambie.

Estas dos variables solo se combinan en un problema real cuando el rastreo, la fase previa a la indexación, no logra cubrir todas las páginas que importan. Por eso este artículo se entiende mejor junto al de indexación: sin rastreo suficiente, Google nunca llega a decidir si una página merece estar en el índice.

En comunidades SEO es habitual leer que "hay que optimizar el crawl budget" como si fuera un requisito universal. La propia documentación oficial de Google lo desmiente de forma directa. La guía de gestión de crawl budget para sitios grandes dice textualmente que está pensada, entre otros casos, para sitios con más de un millón de páginas únicas que cambian moderadamente, cada semana aproximadamente, o para sitios de tamaño medio o grande, más de diez mil páginas únicas, con contenido que cambia muy rápido, a diario.

Y añade una frase que suele omitirse cuando se cita esta guía fuera de contexto: "Si tu sitio no tiene un gran número de páginas que cambian rápidamente, o si tus páginas parecen rastrearse el mismo día en que se publican, no necesitas leer esta guía." Google matiza además que esas cifras son "una estimación aproximada, no umbrales exactos". Esta cita está verificada directamente contra la documentación oficial de Google Search Central, consultada el 08.08.2026, no es una paráfrasis de segunda mano.

Otro mito relacionado que conviene desmontar con la misma fuente oficial: mucha gente cree que los campos <priority> y <changefreq> del sitemap XML sirven para decirle a Google qué páginas son más importantes. Google declara explícitamente que ignora ambos valores. El único campo que Google puede llegar a usar, y solo si es preciso y verificable, es <lastmod>. Un ejemplo de sitemap correcto, tal y como lo documenta Google:

<?xml versión="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://www.tudominio.com/producto/zapatillas-running.html</loc>
    <lastmod>2026-07-15</lastmod>
  </url>
</urlset>

lastmod solo sirve si refleja cambios reales de contenido, no si se actualiza automáticamente cada vez que se regenera el sitemap sin que nada haya cambiado en la página. Google detecta ese patrón y deja de confiar en el campo para todo el dominio.

Para muchos gestores de CMS, esa es precisamente la trampa real: numerosos plugins de sitemap fijan lastmod por defecto en la fecha de la última generación del sitemap, no en la fecha real de cambio del contenido. Quien no corrige eso a mano acaba enviando a Google una señal falsa durante meses y luego se pregunta por qué lastmod parece haber dejado de tener efecto.

Según la propia guía de Google, el crawl budget se vuelve un problema real cuando aparecen muchas URLs con estado "Detectada: actualmente sin indexar" en el informe de indexación de páginas de Search Console, señal de que Google conoce las URLs pero no está priorizando rastrearlas. Los casos donde esto ocurre con frecuencia son tiendas online con navegación por facetas que multiplica combinaciones de filtros hasta generar millones de URLs técnicamente distintas, portales de noticias con miles de artículos nuevos al día, y sitios grandes con largas cadenas de redirecciones o soft 404, páginas que devuelven 200 pero están vacías, que desperdician rastreo en URLs que no aportan nada.

Fuera de esos escenarios, para un sitio corporativo, un blog o un e-commerce pequeño con unos cientos o pocos miles de URLs, el crawl budget casi nunca es el factor que limita la indexación. Si una página nueva no se indexa, la causa suele estar en la calidad del contenido, en la falta de enlaces internos hacia ella, o en errores de canonical, no en que Google se haya quedado sin presupuesto de rastreo para llegar hasta ella.

El informe de Estadísticas de rastreo, dentro de la configuración de Search Console, es la herramienta pensada precisamente para no tener que adivinar. Muestra el número de peticiones de rastreo a lo largo del tiempo, desglosadas por código de respuesta, por tipo de archivo, por finalidad del rastreo, descubrimiento de URLs nuevas frente a actualización de las ya conocidas, y por tipo de Googlebot. Un pico sostenido de errores 5xx o de respuestas lentas en ese informe es una señal mucho más fiable de un problema de crawl budget que cualquier suposición basada en el tamaño del sitio.

También conviene distinguir entre un problema de crawl budget real y uno de arquitectura. Si Google rastrea con normalidad pero decide no indexar lo que encuentra, el cuello de botella no es de presupuesto de rastreo sino de calidad o duplicidad de contenido, y ningún ajuste de robots.txt o de servidor lo va a resolver. Antes de invertir tiempo en optimizar crawl budget conviene descartar primero las causas de indexación más comunes, descritas en el artículo sobre indexación.

• Bloquea en robots.txt las URLs de parámetros de filtro y búsqueda interna que no aportan contenido único.
• Corrige las cadenas largas de redirecciones 301 y elimina los soft 404, ambos desperdician rastreo sin devolver valor.
• Mantén tiempos de respuesta del servidor bajos; un servidor rápido recibe más peticiones de Googlebot, no al revés.
• Usa lastmod en el sitemap solo cuando refleje un cambio real de contenido, nunca como fecha automática.
• Consolida contenido duplicado con canonical o redirecciones antes de que genere miles de URLs redundantes.
• Revisa en Search Console las URLs marcadas como "Detectada: actualmente sin indexar" para detectar cuellos de botella reales.
• Prioriza el enlazado interno hacia las páginas más importantes; Google interpreta esos enlaces como señal de relevancia.
• Consulta el informe de Estadísticas de rastreo con regularidad, no solo cuando ya sospechas que hay un problema.

• Obsesionarse con el crawl budget en un sitio de unos cientos de páginas, donde casi nunca es el problema real.
• Pensar que rellenar priority y changefreq en el sitemap influye en el rastreo: Google los ignora por completo.
• Bloquear por error páginas importantes al intentar ahorrar rastreo con reglas de robots.txt demasiado agresivas.
• Dejar que la navegación por facetas o los parámetros de sesión generen combinaciones infinitas de URLs rastreables.
• Ignorar la tasa de errores del servidor como causa de un rastreo pobre, cuando suele ser el primer sospechoso.
• Confundir crawl budget con indexación: tener presupuesto de rastreo no garantiza que una URL acabe en el índice.
• Optimizar crawl budget antes de descartar problemas de calidad o duplicidad de contenido, que suelen ser la causa real.