La mayoría de guías sobre este tema cometen el mismo error: te sueltan siete trucos sin decirte en qué orden aplicarlos. Bloquea esto, canonicaliza aquello, limpia el sitemap. Y te quedas con la sensación de que es un checklist de tareas sueltas cuando en realidad es un protocolo con secuencia obligatoria.
Después de diez años auditando webs (muchas de ellas ecommerce con más de cien mil URLs) he visto a equipos enteros tocar robots.txt antes de leer un solo log. Resultado: bloquean páginas que Google ya había canonicalizado bien, generan conflictos de señales y empeoran la indexación que querían arreglar. Esta guía va de hacer lo contrario: optimizar el crawl budget desde la evidencia del servidor, no desde la intuición.
Indice
- 1 Por qué casi todas las guías de crawl budget fallan en la práctica
- 2 Paso 1: Diagnosticar antes de tocar nada (logs y Search Console)
- 3 Paso 2: Identificar las URLs que están drenando tu presupuesto
- 4 Paso 3: Cortar el desperdicio con robots.txt y canonical en ese orden
- 5 Paso 4: Limpiar redirecciones y enlaces rotos que Googlebot sigue persiguiendo
- 6 Paso 5: Acelerar la respuesta del servidor para que Google rastree más
- 7 Paso 6: Reforzar las páginas que sí importan con enlazado interno
- 8 Cómo medir si la optimización está funcionando en 30 días
- 9 Errores que revierten todo el trabajo en una semana
- 10 Preguntas frecuentes
Por qué casi todas las guías de crawl budget fallan en la práctica
El crawl budget es el tiempo y los recursos que Googlebot dedica a rastrear tu web, y se compone de dos variables: el rate limit (lo que tu servidor aguanta sin caerse) y el demand (el interés real que Google tiene en tus páginas). Optimizarlo no consiste en forzar a Google a rastrear más, sino en que lo haga mejor.
¿Dónde fallan las guías estándar? En que tratan las técnicas como intercambiables. Te dicen «optimiza robots.txt» en el punto 3 y «corrige canonicals» en el punto 5, como si el orden fuera decorativo. No lo es. Si canonicalizas una URL que luego vas a bloquear, acabas de desperdiciar la señal canonical porque Google ni siquiera llegará a leerla.
Total, que lo primero no es tocar. Lo primero es mirar.
Paso 1: Diagnosticar antes de tocar nada (logs y Search Console)
Aquí es donde el 80% de los proyectos se tuercen. Equipos que llevan tres años repitiendo los mismos «optimizaciones» sin saber si tienen un problema real o están arreglando algo que ya funciona. Antes de mover un bit, necesitas dos fuentes: el informe de Estadísticas de rastreo en Search Console y los logs del servidor de los últimos 30 días.
El informe oficial te muestra los últimos 90 días de actividad de Googlebot. Es gratis, está ahí, y la mayoría no lo abre nunca. Los logs del servidor son la radiografía completa: cada visita, cada user-agent, cada código de respuesta.
Cómo leer el informe de Estadísticas de rastreo sin perderte
Entras en Search Console, Ajustes, Estadísticas de rastreo. Lo que aparece parece abrumador, pero hay exactamente ocho indicadores que importan:
- Total de solicitudes de rastreo en los últimos 90 días
- Tamaño medio de descarga por página
- Tiempo medio de respuesta del servidor
- Distribución de códigos de estado (200, 301, 404, 5xx)
- Tipos de archivo rastreados (HTML, CSS, JS, imágenes)
- Propósito del rastreo (actualización vs descubrimiento)
- Tipo de Googlebot (smartphone, desktop, imagen)
- Ejemplos de URLs rastreadas por categoría
Las banderas rojas aparecen rápido. Si más del 15% de las solicitudes devuelven 4xx, tienes un problema de enlaces internos rotos. Si el tiempo medio de respuesta supera los 600 ms, el servidor está limitando cuántas páginas Google puede pedir por segundo. Y si el porcentaje de «descubrimiento» es muy bajo, significa que Google ya no encuentra contenido nuevo que le interese.
Qué buscar en los logs del servidor en menos de 30 minutos
Los logs son donde está la verdad. Search Console resume, los logs no mienten. Con Screaming Frog Log Analyzer o con un simple grep sobre el access.log puedes responder a tres preguntas en media hora:
¿Qué porcentaje del tiempo de Googlebot se va a URLs que no quieres indexar? En un ecommerce que auditamos el año pasado, el 62% del rastreo se iba a URLs con parámetros de filtrado irrelevantes. Sesenta y dos por ciento. Eso es presupuesto tirado a la basura antes de desayunar.
¿Cuántas páginas estratégicas no ha visitado Googlebot en los últimos 30 días? Si tus fichas de producto principales no se han rastreado en un mes, ningún canonical ni sitemap va a arreglar el problema de fondo.
¿Cuál es la distribución real de códigos de respuesta que ve Googlebot? A veces difiere brutalmente de lo que ves tú como usuario.
Paso 2: Identificar las URLs que están drenando tu presupuesto
Con los datos del paso anterior, toca clasificar. Aquí no improvisas: necesitas una hoja de cálculo con todas las URLs que Googlebot ha tocado en los últimos 30 días, agrupadas por patrón.
La categorización útil es esta: URLs estratégicas (las que quieres posicionar), URLs de apoyo (categorías, hubs), URLs necesarias pero no indexables (login, carrito), URLs duplicadas por parámetros, URLs huérfanas sin enlaces internos, y URLs basura (paginaciones infinitas, ordenaciones, filtros combinados).
Parámetros, facetas y URLs basura: el 80% del problema
En sitios con más de 10.000 URLs, y sobre todo en ecommerce, los parámetros de filtrado son responsables de la mayoría del desperdicio. Piensa en una tienda de zapatillas con filtros de talla, color, marca y precio: con solo cuatro filtros de cinco opciones cada uno, generas 625 combinaciones técnicamente rastreables para una sola categoría.
¿El 100% de esas combinaciones merece rastreo? Ni de lejos. La mayoría duplica contenido, no genera tráfico orgánico y solo sirve para dispersar la autoridad interna.
Herramientas como OnCrawl y JetOctopus te permiten cruzar datos de logs con la estructura del sitio y detectar qué patrones de URL están consumiendo más y aportando menos. Si trabajas con equipos que necesitan una auditoría técnica completa que incluya este análisis, nuestro servicio de auditoría SEO integra el análisis de logs como parte del diagnóstico base porque sin ese dato cualquier recomendación es a ciegas.
Paso 3: Cortar el desperdicio con robots.txt y canonical en ese orden
Ahora sí, a tocar. Pero con una regla de oro: primero bloqueas con robots.txt lo que no debe rastrearse bajo ningún concepto, y después canonicalizas lo que sí puede rastrearse pero no debe indexarse como entidad propia. No al revés.
El robots.txt gestiona rastreo. El canonical gestiona indexación y consolidación de señales. Son capas distintas y trabajan en momentos distintos del proceso.
Por qué bloquear antes de canonicalizar (y no al revés)
Si aplicas un canonical a una URL y luego la bloqueas en robots.txt, Google nunca leerá el canonical. Resultado: pierdes la oportunidad de consolidar señales y además la URL sigue en el índice sin dirección clara. Lo he visto en docenas de auditorías: webs con miles de canonicals perfectamente configurados que Google jamás ha leído porque están tras un Disallow.
La secuencia correcta es: primero decides qué patrones NO deben rastrearse jamás (carrito, login, filtros combinados que generan duplicados masivos) y los bloqueas. Luego, entre las URLs que sí se rastrean, decides cuáles deben indexarse solas y cuáles deben consolidar su señal hacia una versión canónica.
Un ejemplo concreto: la URL /zapatillas?color=negro probablemente merece un canonical hacia /zapatillas porque aún quieres que Google la rastree ocasionalmente para encontrar productos. Pero /zapatillas?color=negro&talla=42&orden=precio-asc probablemente merece un bloqueo total en robots.txt porque no aporta nada.
Paso 4: Limpiar redirecciones y enlaces rotos que Googlebot sigue persiguiendo
Las cadenas de redirección son uno de los drenajes más silenciosos del presupuesto de rastreo. Cada salto es una petición adicional que Googlebot hace, y las cadenas de 3-4 saltos son más comunes de lo que te imaginas en sitios con años de historia.
El objetivo: cero cadenas de más de un salto. Si tienes un 301 que va a otro 301, lo limpias y apuntas directo al destino final. Screaming Frog te saca esta lista en diez minutos con un crawl en modo «Follow Redirects».
Los enlaces internos que apuntan a URLs con 404 son peor todavía. Cada uno es una invitación a que Googlebot gaste tiempo en nada. En la auditoría de un cliente del sector turismo, encontré 4.700 enlaces internos apuntando a páginas que ya no existían. Cuando los eliminamos, el rastreo de páginas estratégicas subió un 34% en seis semanas sin tocar ninguna otra cosa.
¿Vale la pena hacer esto a mano? Nunca. Exportas todos los enlaces internos con Screaming Frog, cruzas con el status code, y tienes la lista lista para priorizar.
Paso 5: Acelerar la respuesta del servidor para que Google rastree más
Aquí entra la parte que más impacto tiene y que más gente ignora. El rate limit, uno de los dos componentes del presupuesto de rastreo, depende directamente de cómo responde tu servidor. Si tarda en contestar, Google reduce la frecuencia de peticiones para no saturarte. Si responde rápido, puede pedir más páginas por segundo.
El factor TTFB y cómo impacta directamente en el crawl rate
TTFB (Time To First Byte) es el tiempo que pasa desde que el navegador hace la petición hasta que recibe el primer byte de respuesta. Debería estar por debajo de 200 ms en el percentil 75 de tus URLs. Si supera los 600 ms, Googlebot va a ralentizar el rastreo activamente.
¿Qué mueve la aguja del TTFB? Tres cosas, en este orden: la calidad del hosting, el tiempo de procesamiento del backend (base de datos, queries lentas) y la resolución DNS. Este último punto es sutil pero importante: cada vez que Googlebot abre una sesión de rastreo, resuelve tu dominio. Un TTL de DNS mal configurado puede añadir latencia extra a cada petición.
Mi experiencia: los servidores compartidos genéricos rara vez aguantan bien un crawl agresivo. Para sitios por encima de 50.000 URLs, un VPS decente o un managed hosting especializado cambia completamente la foto. No es glamuroso, pero funciona.
Un detalle que pocos consideran: Googlebot aplica un límite de 2 MB por página HTML. Si tu HTML supera ese tamaño, el contenido se trunca y Google no lee lo que queda. En ecommerce con listados enormes esto ocurre más de lo que parece.
Paso 6: Reforzar las páginas que sí importan con enlazado interno
Con los cinco pasos anteriores has limpiado. Ahora toca construir. El enlazado interno es la señal más clara que le das a Google sobre qué páginas son importantes para ti, y es la última capa del proceso porque solo tiene sentido después de eliminar el ruido.
Regla operativa: las URLs estratégicas deben estar a 3 clics o menos desde la home, recibir enlaces desde otras URLs de alta autoridad interna y aparecer en sitemaps XML segmentados por tipo de contenido.
Los hubs temáticos (páginas que agrupan enlaces hacia subcategorías) son especialmente eficaces. En un cliente B2B, crear cinco hubs bien estructurados aumentó la frecuencia de rastreo de las páginas objetivo en un 78% en dos meses. Sin tocar nada más.
¿Y las páginas huérfanas? Si una URL no tiene enlaces internos, Google la considera poco importante aunque esté en el sitemap. O le construyes enlaces o la eliminas del índice. No hay tercera opción que funcione.
Cómo medir si la optimización está funcionando en 30 días
Aquí es donde la mayoría de proyectos mueren. Se implementan cambios, se cruza de dedos y se espera. Treinta días después, nadie sabe qué funcionó y qué no. La medición tiene que estar planificada antes de tocar el primer archivo.
Tu línea base son los datos de Search Console y logs de los 30 días previos a la intervención. Anota: solicitudes totales de rastreo, porcentaje de 4xx/5xx, tiempo medio de respuesta, páginas estratégicas rastreadas, y distribución de rastreo por tipo de URL.
Métricas reales que indican que vas por buen camino
A los 30 días deberías ver cambios en este orden aproximado:
En los primeros 7-14 días, caída del porcentaje de URLs rastreadas con parámetros basura (si bloqueaste bien en robots.txt) y reducción de errores 4xx/5xx. Estos son cambios mecánicos: si los hiciste, se notan rápido.
Entre los días 15 y 25, aumento de frecuencia de rastreo en páginas estratégicas. Esta es la señal que de verdad importa. Significa que Google está redirigiendo su atención hacia donde tú querías.
En los días 25-30, debería haber mejora en cobertura: más URLs indexadas entre las estratégicas, menos URLs «descubiertas pero no indexadas». Este es el KPI final.
¿Tráfico orgánico? Eso es otra historia, requiere 60-90 días más y depende de factores que van mucho más allá del budget. No mezcles los tiempos o te frustrarás sin motivo.
Errores que revierten todo el trabajo en una semana
He visto auditorías perfectas arruinadas en siete días por decisiones tomadas sin entender el sistema completo. Los errores más comunes:
Primero, el clásico: desbloquear en robots.txt algo que estaba bloqueado «por si acaso», sin mirar qué consecuencias tiene. He visto a equipos técnicos desbloquear facetas completas porque «alguien dijo que era mejor», y devolver el 40% del desperdicio en una sola noche.
Segundo: migrar la web sin redirecciones mapeadas URL a URL. En una migración reciente, el equipo implementó un 301 genérico hacia la home para todas las URLs antiguas que no encontraba. Tres semanas después, el presupuesto de rastreo se había desplomado porque Google detectó que el sitio entero era soft 404.
Tercero: añadir noindex a páginas que antes tenían canonical. Parece más fuerte, pero es redundante y a veces conflictivo. Google prioriza señales consistentes; si mandas dos mensajes distintos, se queda con el más cauto.
Cuarto: publicar contenido nuevo masivo justo después de la optimización. Tiene sentido intuitivamente («ahora que Google me rastrea mejor, le doy más»), pero diluye el efecto de la limpieza. Mejor esperar 30 días a que se estabilicen las métricas antes de añadir carga nueva.
Y el error que más me ha costado explicar a clientes a lo largo de los años: asumir que optimizar el presupuesto de rastreo resuelve problemas de indexación. No lo hace. Si tu contenido es débil, duplicado o no responde a ninguna intención de búsqueda, ningún ajuste técnico lo va a rescatar. El rastreo eficiente amplifica lo que ya funciona; no crea calidad donde no existe.
Preguntas frecuentes
¿Qué es el crawl budget en SEO?
El budget es la cantidad de tiempo y recursos que Googlebot destina a rastrear un sitio web en un periodo determinado. Se compone de dos variables: el rate limit, que es lo que tu servidor soporta sin saturarse, y el demand, que refleja el interés real de Google por tus páginas.
¿Cómo se mide el crawl budget en Search Console?
En Google Search Console se mide accediendo a Ajustes, Estadísticas de rastreo. Ahí aparecen los datos de los últimos 90 días: total de solicitudes, tiempo medio de respuesta, tamaño de descarga y distribución por tipo de archivo y código de estado. Es el punto de partida oficial para diagnosticar.
¿El crawl budget afecta a sitios pequeños?
En sitios con menos de 10.000 URLs el impacto directo es mínimo, salvo que tengan muchos errores 4xx/5xx o un servidor muy lento. Google suele tener capacidad sobrada para rastrear webs pequeñas. La optimización tiene sentido crítico en ecommerce grandes, sitios con parámetros de URL o proyectos que superan las decenas de miles de páginas.
¿Cuánto tarda Google en rastrear una web tras optimizarla?
Los cambios mecánicos (bloqueos en robots.txt, reducción de errores) se notan en 7-14 días. El aumento real de frecuencia de rastreo en páginas estratégicas aparece entre los días 15 y 30. La mejora en cobertura e indexación llega hacia el final del primer mes. El impacto en tráfico orgánico requiere 60-90 días adicionales.
¿Qué diferencia hay entre rate limit y demand?
El crawl rate limit es el techo técnico: cuántas peticiones por segundo puede hacer Googlebot sin saturar tu servidor. Depende de la velocidad de respuesta del hosting. El crawl demand es el interés real que Google tiene en rastrearte, basado en la autoridad del sitio, la frescura del contenido y la popularidad de las URLs.
