Si has llegado aquí buscando cómo arreglar tu presupuesto de rastreo, lo más probable es que no tengas ningún problema que arreglar. Suena raro viniendo de alguien que vive del SEO, pero es así. En mi cartera de proyectos de los últimos doce años, menos de uno de cada cinco sitios tenía realmente un cuello de botella en la exploración de Googlebot. El resto venía con otro diagnóstico mal puesto por algún auditor con prisa.
¿Por qué se ha convertido entonces en el tema favorito de las auditorías? Porque es difícil de refutar. Nadie puede demostrarte en dos minutos que Google tiene cuota sobrada para tu web de 400 páginas. Y mientras tanto se factura un informe de cuarenta folios.
La cosa es que, cuando el problema existe de verdad, es brutal. Hemos visto catálogos donde el bot dedicaba el 73% de sus solicitudes mensuales a combinaciones de filtros que no generaban una sola visita. Así que el trabajo útil no consiste en aplicar recetas, sino en saber en qué situación estás antes de tocar nada.
Qué decide Google antes de pedir una sola URL de tu web
El presupuesto de rastreo es el número de URLs que Googlebot pide en un sitio durante un periodo concreto. Resulta de dos variables: la capacidad de rastreo, que depende de lo que el servidor tolera sin degradarse, y la demanda, que refleja el interés real de Google por esas direcciones.
Esos dos cálculos ocurren en paralelo y casi nunca se explican por separado. El primero tiene que ver con lo que la infraestructura aguanta. El segundo, con lo que Google considera que merece la pena.
El límite técnico se ajusta solo. Si las respuestas se vuelven lentas o empiezan a devolver errores de servidor, el ritmo de solicitudes baja en cuestión de horas. Trabajamos un portal donde el tiempo de respuesta medio estaba en 1,8 segundos: tras mover la caché a nivel de CDN y dejarlo en unos 420 milisegundos, la actividad diaria del bot se multiplicó por 2,3 en tres semanas sin que tocáramos una sola línea de robots.txt.
La segunda variable es la interesante, y la que nadie puede comprar. Google estima cuánta atención merece un dominio en función de la frecuencia con la que publica algo nuevo, de si lo ya explorado cambia o permanece igual, y de la demanda que detecta en búsquedas. Un sitio con 2.000 URLs que no se han modificado desde 2021 recibirá cada vez menos visitas del bot, y eso no es un castigo: es aritmética.
La diferencia entre lo que se pide y lo que se indexa
Aquí se confunde media profesión. Que Googlebot descargue una URL no implica que vaya a formar parte del índice, y que no esté indexada no significa necesariamente que no se haya pedido. Son dos embudos encadenados, con criterios distintos y con informes distintos en Search Console.
Mira, lo que pasa es que cuando alguien ve 40.000 páginas en «Detectada: actualmente sin indexar» asume automáticamente un problema de cuota. En la mitad de los casos revisados el origen era calidad de contenido duplicado, no escasez de solicitudes. Y el tratamiento es justo el contrario.
Por qué la autoridad del dominio entra en la ecuación
Un dominio con enlaces entrantes de medios y referencias editoriales consolidadas recibe más atención del explorador que uno recién nacido con el mismo número de páginas. Se comprueba cada vez que lanzamos una estrategia de enlaces para un cliente nacional: el volumen de descargas diarias sube semanas antes de que suba el tráfico. No es magia, es señal de demanda.
Si tu web tiene menos de unos miles de URLs, esto no es tu problema
La propia documentación de Google lo dice con una claridad que incomoda a bastantes consultores: los sitios pequeños y medianos se exploran de forma eficiente sin que nadie intervenga. Si tu web tiene 300, 900 o 4.000 direcciones y todas devuelven 200, deja esto y vuelve al contenido.
¿Y si aun así alguien te ha vendido una auditoría de cuota para tu blog de 180 entradas? Pide que te muestre qué URLs relevantes llevan más de dos meses sin ser pedidas por el bot. Si no puede, ya tienes la respuesta.
Cuando gestionas un ecommerce con filtros y variantes: el escenario crítico
Aquí es donde el asunto se pone serio de verdad. Un catálogo con 18.000 referencias, cinco atributos filtrables y ordenación por tres criterios puede generar millones de combinaciones de URL válidas desde el punto de vista del servidor. Todas responden 200. Todas parecen páginas. Ninguna aporta nada.
El caso más llamativo fue una tienda de componentes industriales auditada hace unos años. Los logs de treinta días mostraban 1,2 millones de descargas de Googlebot al mes. De esas, el 73% iban a parámetros de ordenación y combinaciones de dos o más facetas. Las fichas de producto nuevas tardaban entre 19 y 34 días en recibir su primera visita del explorador.
Total, que el equipo de marketing publicaba novedades que tardaban un mes en existir para Google. Y mientras, el bot se entretenía descubriendo si existía la combinación «color negro + precio ascendente + página 7».
Qué hicimos y en qué orden
Lo primero no fue bloquear. Fue medir cuáles de esas combinaciones generaban impresiones reales: había exactamente 11 facetas simples con demanda de búsqueda propia, y esas se quedaron abiertas con contenido editorial propio. El resto, fuera.
- Bloqueo por patrón de parámetro en robots.txt
- Enlaces a facetas sin valor servidos sin href navegable
- Paginación limitada a profundidad razonable
- Sitemaps segmentados por tipología y actualizados a diario
Resultado medido a los 90 días: las solicitudes cayeron de unas 40.000 diarias a 11.500, pero las dirigidas a fichas de producto subieron un 180%. El tiempo medio hasta primera exploración de una referencia nueva se quedó en 36 horas. Reconozco que los dos primeros meses fueron un infierno de nervios, porque las impresiones totales bajaron antes de subir y hubo que explicarlo tres veces en comité.
El error que cometíamos al principio
Durante los primeros años aplicábamos noindex a las facetas y nos quedábamos tranquilos. Craso error. Una página con esa etiqueta hay que pedirla para leerla, así que el consumo seguía intacto; solo se limpiaba el índice. Y conviene recordar que la directiva no funciona dentro de robots.txt: Google retiró su soporte en septiembre de 2019. El bloqueo por fichero de exclusión y el noindex resuelven problemas distintos, y combinarlos mal deja URLs que Google no puede leer ni desindexar. Esto y otros fallos parecidos los recogimos en nuestro análisis de errores SEO técnicos en sitios grandes, porque se repiten con una constancia desesperante en proyectos de más de cien mil URLs.
Si publicas a diario: medios y portales con archivo histórico
El caso de un medio digital se parece poco al del comercio electrónico. No hay explosión combinatoria, hay acumulación. Veinte años de hemeroteca suman cientos de miles de direcciones que siguen vivas, siguen enlazadas desde el archivo y siguen pidiendo atención del explorador cada cierto tiempo.
Imagina un diario regional con 480.000 artículos publicados desde 2005. Si el bot dedica una parte considerable de su cuota a comprobar si algo cambió en una noticia de 2011, la portada y las piezas de hoy compiten con ese ruido. En un proyecto así medimos que el 44% de las descargas iban a contenido de más de cinco años de antigüedad.
La estrategia no es borrar el archivo, que sería tirar autoridad a la basura, sino jerarquizarlo. Sitemaps separados por año, con fecha de última modificación honesta (y digo honesta porque hay CMS que ponen la fecha de hoy en los 480.000 registros, lo cual destruye cualquier credibilidad de la señal). Enlazado interno que empuje hacia lo reciente y hacia lo evergreen que sigue rindiendo, no hacia todo por igual.
En el caso de webs con JavaScript, APIs y renderizado pesado
Este perfil es el más subestimado de los cinco. Una aplicación que requiere ejecutar JavaScript para mostrar su contenido no consume una petición por página: consume la del documento, más las de los bundles, más las de cada llamada a API que el renderizador necesite resolver.
¿Cuánto cuesta eso en la práctica? En una plataforma de servicios con arquitectura de cliente revisada en 2023, cada URL útil arrastraba entre 7 y 14 llamadas adicionales. El bot pedía mucho y descubría poco. La sensación desde fuera era de cuota agotada, cuando el problema era de eficiencia por unidad explorada.
Si tu stack es así, renderizar en servidor las plantillas que importan para búsqueda suele devolver más margen que cualquier ajuste en el fichero de exclusión. Lo planteamos siempre antes de tocar directivas, y es una de las primeras cosas que miramos cuando nos piden una revisión desde la agencia de SEO técnico de Autoridad Digital, porque ningún bloqueo compensa una arquitectura que exige catorce descargas para mostrar un párrafo.
Para quien migra o reestructura: el pico de demanda que nadie prevé
Una migración crea, durante unas semanas, la situación más exigente posible. Todas las direcciones antiguas devuelven redirección y hay que pedirlas. Todas las nuevas son desconocidas y hay que descubrirlas. El volumen de trabajo para el explorador se duplica justo cuando menos margen de error tienes.
Mi hipótesis inicial, allá por 2015, era que con un mapa de redirecciones impecable el proceso se resolvía solo. Después de acompañar una treintena de migraciones, el dato que me hizo cambiar de opinión fue otro: las cadenas de dos o tres saltos multiplicaban el consumo y retrasaban la consolidación entre seis y diez semanas respecto a los proyectos con redirección directa.
Lo aprendido tras ese cálculo cambió el procedimiento. Ahora exigimos redirección de un solo salto desde el primer día, sitemaps nuevos enviados el mismo día del cambio, y mantenemos los antiguos accesibles unas semanas para que el descubrimiento de equivalencias sea rápido. ¿Elegante? No especialmente. ¿Funciona? En la práctica totalidad de los casos.
Y una advertencia que ahorra disgustos: si durante la migración el servidor empieza a devolver 5xx o 429 por saturación, el explorador frena en seco. Recuperar el ritmo anterior puede llevar semanas.
Cómo saber en qué escenario estás: señales en los informes de rastreo
Antes de intervenir, diagnóstico. Y el diagnóstico tiene tres fuentes, en este orden de fiabilidad: logs de servidor, informe de estadísticas de exploración de Search Console, y un crawler propio para entender la arquitectura.
Seis señales que confirman un problema real
Estas son las observaciones que, cuando aparecen juntas, justifican intervenir.
- Más del 50% de solicitudes dirigidas a URLs con parámetros
- URLs nuevas que tardan más de diez días en recibir su primera visita
- Predominio del propósito «actualización» frente a «descubrimiento»
- Volumen alto de respuestas 3xx encadenadas servidas al bot
- Secciones con valor comercial sin visitas del bot en sesenta días
- Caída sostenida de solicitudes diarias tras picos de errores 5xx
Qué buscar en los logs
Un mes de registros filtrados por user-agent verificado da lo que ninguna herramienta estima. Conviene mirar siempre estos cinco ratios.
- Solicitudes a URLs con parámetros sobre el total
- Solicitudes a contenido de más de dos años
- Porcentaje de respuestas 3xx, 4xx y 5xx servidas al bot
- Días medios hasta primera petición de una URL nueva
- Reparto de solicitudes por tipo de plantilla o directorio
Qué buscar en Search Console
El informe conserva 90 días y agrupa por propósito, tipo de archivo y respuesta. Si el grueso del volumen es «actualización» y apenas hay «descubrimiento», el explorador está reciclando en lugar de avanzar. Esa es la señal más fiable de que algo le impide llegar a lo nuevo.
¿Y si los números salen normales? Entonces enhorabuena: tu problema está en otra parte y acabas de ahorrarte tres meses de trabajo inútil. Esto, que parece un chiste, es el resultado más habitual de los diagnósticos que hacemos en Autoridad Digital.
Qué hacer en cada caso sin romper nada por el camino
Hay una jerarquía de intervenciones que respetamos siempre, porque las primeras son reversibles y las últimas no tanto.
Empieza por velocidad de respuesta del servidor. Es la palanca que más margen devuelve y la única sin contraindicaciones: nadie ha perdido tráfico por servir más rápido. Después, limpieza de enlazado interno, que es donde se decide qué descubre el explorador y en qué orden.
El tercer nivel es la segmentación de sitemaps, con fechas de modificación veraces. El cuarto, ya con más cuidado, el bloqueo por patrón de parámetros. Y el quinto, solo en catálogos muy grandes y con datos encima de la mesa, la poda de contenido que ni se visita ni se posiciona.
Tabla de correspondencia: perfil, síntoma y acción prioritaria
| Perfil de proyecto | Síntoma característico | Acción prioritaria |
|---|---|---|
| Web pequeña o mediana (<5.000 URLs) | Ninguno medible en los informes | No intervenir: contenido y autoridad |
| Ecommerce con navegación facetada | Mayoría de solicitudes a parámetros y ordenaciones | Bloqueo por patrón y facetas sin href navegable |
| Medio con archivo histórico | Peso alto del contenido antiguo en las descargas | Sitemaps por año con lastmod veraz y enlazado a lo reciente |
| Aplicación dependiente de JavaScript | Muchas solicitudes por cada URL útil descubierta | Renderizado en servidor de las plantillas de búsqueda |
| Proyecto en migración | Pico de 3xx y caída de descubrimiento | Redirección de un solo salto y sitemaps nuevos el día cero |
Lo que nunca conviene tocar a la ligera es la etiqueta canónica masiva ni las reglas de exclusión escritas con expresiones amplias. Hemos visto bloquear accidentalmente un directorio entero de categorías por una barra mal puesta, y el coste de ese descuido fue de siete semanas de visibilidad en un proyecto que facturaba bien. El detalle que todos pasan por alto: haz siempre pruebas con el probador de robots antes de subir el fichero a producción.
Dudas frecuentes sobre la gestión del rastreo
¿Qué es el presupuesto de rastreo?
Es el volumen de URLs que los bots de Google piden en un sitio durante un periodo determinado. Depende de dos factores combinados: la capacidad que tolera el servidor sin degradar sus respuestas y la demanda que Google atribuye a esas direcciones según su novedad, sus cambios y su interés en búsquedas.
¿Cómo se calcula?
No existe una cifra pública ni una fórmula consultable. Se estima a posteriori contando en los logs cuántas direcciones distintas pidió el bot verificado en treinta días. El informe de estadísticas de exploración ofrece la aproximación agregada equivalente.
¿Cuántas URLs debe tener una web para que esto importe?
No hay umbral exacto, pero por debajo de unos pocos miles de direcciones la exploración se resuelve sola. El indicador útil no es el número total, sino la proporción entre direcciones existentes y direcciones con valor: una web de 5.000 páginas que genera 800.000 combinaciones con parámetros tiene un problema que una de 50.000 páginas limpias no tiene.
¿Bloquear en robots.txt elimina las páginas del índice?
No. Impide que se lean, no que figuren. Una dirección bloqueada que recibe enlaces puede seguir apareciendo en resultados sin descripción. Si quieres sacarla del índice, debe ser accesible con etiqueta noindex hasta que Google la procese, y solo después se bloquea.
¿Qué herramientas sirven para analizar el rastreo?
Para arquitectura y detección de duplicados, Screaming Frog o Sitebulb cubren la mayoría de proyectos. Para catálogos de cientos de miles de URLs con análisis de logs integrado, Botify. Y por encima de todo, el propio fichero de registros del servidor: es la única fuente que no estima.
¿Sirve de algo la herramienta de inspección de URLs para acelerar?
Para casos puntuales, sí. Para escala, no: el número de solicitudes diarias es muy limitado y no sustituye un sitemap bien mantenido. Se usa cuando publicamos algo con caducidad corta, no como procedimiento habitual.
¿Afecta esto al posicionamiento directamente?
No es un factor de ordenación. Es un prerrequisito: lo que no se explora no se indexa, y lo que no se indexa no compite. Confundir ambas cosas lleva a optimizar la cuota de exploración esperando subidas de posición que nunca llegan, porque el contenido ya estaba perfectamente indexado y el problema era otro.
¿Con qué frecuencia conviene revisar los logs?
En sitios grandes, mensual. En migraciones, diario durante las primeras tres semanas. En webs pequeñas, cuando haya un cambio estructural y no antes.
Conclusión
Vuelvo al punto de partida, porque es lo único que de verdad quiero que te lleves: antes de abrir el fichero de exclusión, averigua si perteneces a alguno de los cinco perfiles que merecen intervención. Catálogo con facetas, archivo histórico voluminoso, arquitectura dependiente de JavaScript, migración en curso o crecimiento programático descontrolado.
Si no estás en ninguno, el presupuesto de rastreo no es tu palanca y gastar trimestres en afinarlo te va a costar el tiempo que debías dedicar a contenido y autoridad. Y si sí estás, mide primero, interviene en el orden correcto y acepta que los resultados tardan entre dos y tres meses en estabilizarse. No hay atajo decente.
