El presupuesto de tiempo que Google te asigna
Googlebot no tiene tiempo infinito para rastrear tu sitio. Tiene un conjunto de recursos —peticiones HTTP, tiempo de procesamiento, ancho de banda— que puede destinar a un dominio durante un período determinado. Cuando ese presupuesto se agota, Google se va. Las páginas que no alcanzó a visitar quedan sin indexar hasta su próxima visita, que puede tardar días o semanas.
A ese conjunto de recursos se le llama crawl budget. Y aunque suena técnico, tiene implicaciones muy concretas: si Google gasta su presupuesto rastreando miles de URLs con parámetros de sesión o filtros de faceta irrelevantes, las páginas de producto nuevas o las actualizaciones de contenido que realmente importan pueden tardar semanas en indexarse.
Antes de que cualquier página aparezca en los resultados de búsqueda, Google completa tres pasos: rastrear, indexar y posicionar. El crawl budget afecta al primer eslabón de esa cadena. Si Google no rastrea una página, no puede indexarla. Si no la indexa, no puede posicionarla.
Esta guía explica cómo funciona ese presupuesto, cuándo merece atención real y cómo conseguir que Googlebot destine sus recursos a las páginas que generan negocio.
Qué determina el crawl budget: dos factores que trabajan juntos
Google publicó formalmente el concepto de crawl budget en enero de 2017. Según esa documentación —todavía vigente—, el presupuesto efectivo de rastreo resulta de la combinación de dos factores independientes.
Crawl rate limit (límite de tasa de rastreo): Es la velocidad máxima a la que Googlebot puede rastrear tu sitio sin degradar la experiencia de los usuarios reales. Google ajusta este límite automáticamente en función del tiempo de respuesta de tu servidor. Si tu servidor responde en 200 ms, Googlebot puede hacer más peticiones por segundo que si responde en 1.500 ms. Puedes ajustar este límite manualmente en Google Search Console, aunque rara vez es recomendable hacerlo a la baja.
Crawl demand (demanda de rastreo): Es cuánto quiere Google rastrear tu sitio, determinado por dos subfactores: la popularidad de las URLs (medida aproximadamente por PageRank) y la frecuencia de cambios. Una página con muchos enlaces entrantes de calidad tiene alta demanda. Una página de producto que cambia su precio y disponibilidad cada hora también la tiene. Las páginas sin popularidad y sin cambios recientes tienen demanda baja y Googlebot las visita con menos frecuencia.
El crawl budget efectivo es el resultado de equilibrar ambos factores. Un sitio con servidores muy rápidos pero con URLs poco populares no necesariamente recibirá más rastreos. Un sitio con contenido fresco y popular pero con servidor lento verá cómo Googlebot throttlea sus visitas para no sobrecargar la infraestructura.
¿Cuándo importa realmente?
John Mueller, de Google, ha sido directo al respecto: “IMO crawl-budget is over-rated. Most sites never need to worry about this.”
Según la documentación oficial de Google, el crawl budget es relevante principalmente en dos escenarios:
- Sitios con más de 1 millón de páginas únicas actualizadas con frecuencia semanal o superior.
- Sitios con más de 10.000 páginas que cambian a diario.
El umbral de 1 millón de páginas no ha cambiado desde 2020, según confirmó Gary Illyes en 2025. Esto significa que para el 99% de las webs empresariales, los problemas que parecen de crawl budget son en realidad problemas de calidad del contenido, estructura de enlaces internos o velocidad del servidor.
Si tu sitio tiene 5.000 páginas y hay contenido sin indexar, antes de mirar el crawl budget revisa si ese contenido tiene valor real para el usuario y si está correctamente enlazado desde páginas con autoridad.
El insight clave: la base de datos importa más que el volumen
Durante décadas, la conversación sobre crawl budget ha girado en torno al número de páginas. La intuición era lógica: más páginas implica más URLs que rastrear, lo que puede agotar el presupuesto. Sin embargo, en mayo de 2025, Gary Illyes compartió un insight que invierte esa prioridad de forma significativa.
En el podcast Search Off the Record, Illyes explicó: “If you are making expensive database calls, that’s going to cost the server a lot.” Y añadió un ejemplo concreto: un sitio con 500.000 páginas que hace consultas SQL costosas puede tener más problemas de rastreo que un sitio con 2 millones de páginas que sirve contenido estático en caché.
Este dato tiene implicaciones prácticas inmediatas. Si tienes un e-commerce con catálogo mediano (50.000-200.000 productos) y experimentas problemas de indexación, la primera pregunta no debería ser “¿cuántas URLs tengo?” sino “¿cuánto tardan mis páginas en responder y qué queries de base de datos ejecutan?”.
La documentación de Google confirma la referencia: “Aim for server response times below 300-400 milliseconds on average.” Ese umbral no se refiere al tiempo de carga percibido por el usuario (que incluye renderizado), sino al tiempo hasta el primer byte (TTFB) que Googlebot experimenta.
Cómo medir el TTFB real para Googlebot
Googlebot actúa como un cliente HTTP simple: solicita la URL, espera la respuesta del servidor y procesa el HTML. No ejecuta JavaScript en la primera visita. Para medir el TTFB que experimenta Googlebot:
- Google Search Console → Cobertura → URLs indexadas: Busca señales de tiempo de rastreo en el informe de estadísticas.
- Logs del servidor: Filtra las peticiones de Googlebot (
Googlebot/2.1) y analiza los tiempos de respuesta reales, no los de simulación. - Search Console Performance → Crawl Stats: Muestra el tiempo de descarga promedio que Googlebot registra en tus páginas.
- Herramientas de terceros: Screaming Frog puede simular peticiones HTTP sin JavaScript para medir TTFB programáticamente.
Un TTFB consistentemente por encima de los 500 ms en un porcentaje significativo de páginas es una señal de alerta incluso para sitios medianos.
Los 10 factores que desperdician crawl budget
Saber que el crawl budget puede agotarse es útil. Saber exactamente qué lo agota es lo que permite actuar. Estos son los principales responsables.
1. Contenido duplicado técnico
El 60% de la web es contenido duplicado, principalmente de naturaleza técnica, según datos de Ahrefs. Las variantes más comunes en un mismo sitio:
http://vs.https://www.dominio.comvs.dominio.com- URLs con trailing slash vs. sin trailing slash:
/categoria/vs./categoria - Parámetros de seguimiento:
?utm_source=email,?fbclid=... - Session IDs en URLs:
?PHPSESSID=abc123 - Versiones de impresión o exportación:
?format=print
Cada variante es una petición HTTP diferente para Googlebot. Si tienes 100.000 URLs con cuatro variantes cada una, estás generando 400.000 URLs que compiten por el mismo presupuesto. La solución es consolidar mediante canónicas, configurar correctamente el servidor para redirigir variantes a la URL principal y gestionar los parámetros en Google Search Console.
2. Navegación facetada (faceted navigation)
La navegación facetada es el mayor multiplicador de URLs en e-commerce. Una categoría de “zapatillas deportivas” con filtros de talla (12 opciones), color (8 opciones), marca (20 opciones) y precio (5 rangos) puede generar matemáticamente hasta 9.600 combinaciones de URLs únicas. Si además permites múltiples filtros activos simultáneamente, el número se dispara exponencialmente.
La mayoría de esas combinaciones no tienen valor SEO independiente: son variantes de la misma categoría con contenido similar o idéntico. Sin embargo, si Googlebot puede acceder a ellas (porque tienen enlace desde el HTML), las rastreará todas.
Las estrategias de mitigación incluyen: implementar etiquetas <meta name="robots" content="noindex"> en URLs facetadas, configurar JavaScript para que los filtros modifiquen el contenido sin cambiar la URL (patrón de hash o history.pushState con noindex dinámico), o bloquear esas rutas específicas en robots.txt. Cada opción tiene sus propias implicaciones para la indexación de contenido filtrado relevante —es un equilibrio que debe evaluarse caso a caso.
3. Cadenas de redirección
Cada redirección HTTP es una petición adicional para Googlebot. Si tienes una URL A que redirige a B que redirige a C, Googlebot hace tres peticiones para obtener el contenido final. En sitios con histórico de migraciones, es común encontrar cadenas de tres, cuatro o cinco saltos.
Herramientas como Screaming Frog permiten rastrear y mapear todas las cadenas de redirección del sitio. La regla general: ninguna redirección debería tener más de un salto. Las cadenas deben colapsarse apuntando directamente al destino final.
4. Errores de rastreo (404, soft 404, 5xx)
Los errores consumen presupuesto sin aportar valor. Un 404 es una respuesta, y Googlebot necesita procesar esa respuesta antes de seguir. Los soft 404 (páginas que responden 200 pero con contenido del tipo “No se encontraron resultados”) son especialmente perniciosos porque Googlebot necesita más recursos para detectarlos.
Los errores 5xx (errores de servidor) son los más dañinos: indican sobrecarga o fallos en la infraestructura, y Googlebot puede reducir agresivamente la tasa de rastreo si los encuentra con frecuencia.
5. Estructura de enlazado interno deficiente
Googlebot descubre URLs principalmente siguiendo enlaces. Si tienes páginas valiosas a más de tres clics de profundidad desde la portada, Googlebot puede no alcanzarlas en cada ciclo de rastreo. Peor aún, las páginas sin ningún enlace interno entrante (“páginas huérfanas”) pueden no rastrearse en absoluto a pesar de estar en el sitemap.
La arquitectura de enlazado interno es la herramienta más directa para guiar el presupuesto de rastreo hacia las páginas prioritarias. Para profundizar en este aspecto y su relación con el SEO técnico general, consulta nuestra guía de SEO técnico.
6. Sitemaps XML con URLs incorrectas
Un sitemap debería listar únicamente URLs que devuelven 200 y son canónicas. Sin embargo, es frecuente encontrar sitemaps con: URLs que han sido movidas (devuelven 301), URLs con errores (404), URLs con parámetros no canónicos, o URLs que tienen noindex pero siguen en el sitemap.
Cada error en el sitemap es una señal de calidad negativa para Google sobre el sitio. Además, Googlebot rastreará esas URLs aunque no sean las canónicas, desperdiciando presupuesto.
7. Thin content y páginas de baja calidad
Google combina la demanda de rastreo con señales de calidad. Las páginas con poco contenido original, las páginas de paginación profunda (página 47 de 50 de resultados de búsqueda interna) o las páginas de etiquetas/tags con escasas entradas tienen baja demanda de rastreo. Google las visita con menos frecuencia —y en caso de presupuesto limitado, puede saltárselas completamente.
Consolidar contenido thin, eliminar páginas de paginación profunda sin valor independiente y deshabilitar el rastreo de taxonomías irrelevantes libera presupuesto para el contenido principal.
8. Velocidad de base de datos: el factor oculto
Como señaló Gary Illyes en mayo de 2025, las consultas costosas a la base de datos pueden ralentizar el servidor hasta el punto de que Googlebot reduzca su tasa de rastreo. Esto es especialmente relevante para:
- Páginas de producto con inventario en tiempo real (consultas de stock y precio en cada carga)
- Páginas de listado con filtros aplicados que generan queries complejas
- Sistemas CMS con relaciones complejas entre entidades
Implementar caché de página completa (full-page caching) para Googlebot, o al menos para los tipos de respuesta más frecuentes, puede mejorar drásticamente el TTFB y, por tanto, el crawl rate.
Cómo medir tu crawl budget actual
Antes de optimizar, necesitas datos. Estas son las fuentes de información más fiables.
Google Search Console — Cobertura (Coverage). El informe de Cobertura muestra el estado de indexación de todas las URLs conocidas. Presta especial atención a las categorías “Descubiertas: actualmente no indexadas” y “Rastreadas: actualmente no indexadas”. La primera indica URLs que Google conoce pero a las que no ha llegado aún; es el síntoma más directo de presupuesto insuficiente.
Google Search Console — Estadísticas de rastreo (Crawl Stats). Disponible en Configuración → Estadísticas de rastreo. Muestra el número de peticiones diarias de Googlebot, el tiempo de descarga promedio y el propósito de cada petición. Compara el número de páginas rastreadas diariamente con el total de páginas de tu sitio para calcular el ratio:
- Ratio páginas/rastreos diarios > 10:1 → problema urgente
- Ratio entre 3:1 y 10:1 → monitorizar activamente
- Ratio ≤ 3:1 → no prioritario en este momento
Análisis de logs del servidor. Los logs son la fuente de verdad. Herramientas como Screaming Frog Log Analyzer, SEOlyzer o una configuración personalizada de ELK Stack permiten filtrar peticiones de Googlebot, calcular tasas de rastreo por sección, identificar URLs con errores y detectar picos de bot-traffic que compitan con Googlebot.
El impacto de los crawlers de IA en 2026
Un factor que no existía en la discusión hace tres años es el impacto de los crawlers de IA. GPTBot (OpenAI), CCBot (Common Crawl para entrenamiento de modelos), Google Extended, Anthropic Claude Bot y similares rastrean la web de forma independiente a Googlebot, y pueden consumir hasta el 40% del ancho de banda disponible durante ciclos de rastreo profundo.
Este consumo adicional tiene un efecto colateral: reduce la disponibilidad del servidor para Googlebot, lo que puede deprimir el crawl rate limit. En servidores con recursos ajustados, el tráfico de bots de IA puede ser la causa silenciosa de un crawl budget efectivo más bajo de lo esperado.
La respuesta parece obvia: bloquear esos bots en robots.txt. Sin embargo, los datos de 2026 apuntan a un coste asociado. Según datos de DEV Community, los sitios que bloquearon GPTBot fueron citados un 73% menos en respuestas de ChatGPT. Para negocios que dependen de la visibilidad en IA generativa, ese no es un trade-off trivial.
La decisión óptima depende de la estrategia de visibilidad de cada negocio: si la presencia en ChatGPT o Perplexity genera valor real para tu audiencia, bloquear GPTBot tiene un coste claro. Si tu modelo de negocio depende exclusivamente del tráfico orgánico de Google, bloquear bots de IA puede mejorar el crawl rate de Googlebot.
Para entender mejor la intersección entre SEO técnico y visibilidad en motores de IA, revisa nuestra guía sobre problemas de indexación en Google.
Plan de acción: priorización por impacto
No todas las optimizaciones tienen el mismo retorno. Este es el orden de intervención recomendado en función del impacto potencial:
Prioridad 1 — Impacto inmediato
- Corregir errores 5xx en el servidor (mejoran el crawl rate limit directamente)
- Eliminar variantes de URL no canónicas (redirige HTTP→HTTPS, www→non-www, trailing slash inconsistente)
- Consolidar cadenas de redirección en saltos únicos
- Corregir el sitemap XML: solo URLs 200 canónicas
Prioridad 2 — Impacto medio
- Implementar caché de página completa para reducir TTFB
- Gestionar URLs facetadas (noindex o bloqueo en robots.txt)
- Eliminar o noindex páginas thin sin valor independiente
- Depurar consultas de base de datos lentas (EXPLAIN ANALYZE en PostgreSQL/MySQL)
Prioridad 3 — Optimización estructural
- Revisar y optimizar enlazado interno para páginas prioritarias a menos de 3 clics
- Configurar el límite de rastreo en GSC solo si el servidor tiene restricciones reales de capacidad
- Definir política para crawlers de IA (GPTBot, Google Extended, etc.)
- Implementar monitorización continua de logs para detectar regresiones
El dato que corrige la perspectiva
Un sitio de comercio electrónico implementó un programa completo de optimización de crawl budget —consolidación de duplicados, gestión de facetada, mejora de tiempos de servidor— y aumentó su tasa de rastreo 10x en dos años, de 60.000 a 600.000 URLs rastreadas diariamente, según un caso documentado por Conductor Academy. El efecto sobre la indexación fue proporcional: páginas que llevaban meses en estado “Descubiertas: no indexadas” comenzaron a aparecer en los resultados en semanas.
Sin embargo, el mismo resultado —o incluso mejor— puede obtenerse simplemente mejorando la velocidad del servidor. Hay sitios documentados que multiplicaron por 4 su tasa de rastreo (de 150.000 a 600.000 URLs/día) únicamente al mejorar el TTFB de 800 ms a 180 ms, sin tocar su arquitectura de contenido.
La jerarquía correcta de prioridades para optimizar el crawl budget, a la luz del insight de Gary Illyes de 2025, es esta: primero la velocidad del servidor, después la calidad del contenido rastreable, y finalmente el volumen de URLs.
Cuándo actuar y cuándo no
John Mueller tiene razón cuando dice que el crawl budget está sobredimensionado para la mayoría de sitios. Si tu web tiene menos de 100.000 páginas, un servidor que responde en menos de 400 ms y un contenido sin duplicados masivos, el crawl budget no es tu problema.
Para e-commerces grandes, portales con navegación facetada o sitios con historial de migraciones, el crawl budget puede ser el cuello de botella que explique por qué páginas con buen contenido no aparecen en Google. El síntoma más claro: GSC → Cobertura → “Discovered – currently not indexed” con una cifra grande que crece semana a semana.
En 2026, la gestión del crawl budget ya incluye una decisión que no existía hace dos años: qué hacer con los bots de IA que compiten con Googlebot por los recursos del servidor. No hay una respuesta universal, pero ignorar el problema tampoco es neutral.