Alrededor de la página 47,000 de un informe de rastreo, consideré genuinamente un cambio de carrera. El sitio, un gran catálogo de comercio electrónico con sede en Reino Unido y alrededor de 91,000 URLs indexables, había estado estancado en aproximadamente 34,000 páginas indexadas durante seis meses. Sin crecer. El cliente estaba convencido de que algo estaba "roto". Les dije que nada estaba roto. Tenía media razón.
Punto clave: En un sitio de 91,000 páginas, Googlebot rastrea lo que tu arquitectura le indica: la estructura de enlaces internos, la disciplina del mapa del sitio y eliminar el contenido innecesario determinan qué páginas se indexan.
Ese proyecto cambió completamente cómo pienso sobre el presupuesto de rastreo. No la teoría, ya había leído la documentación de Google, había visto los videos de Search Central, sabía qué era el presupuesto de rastreo. Pero conocerlo y administrarlo realmente a escala son dos cosas radicalmente diferentes. Lo que sigue es todo lo que me hubiera dicho a mí mismo si pudiera volver a ese martes por la mañana de marzo de 2022 cuando abrí por primera vez las estadísticas de rastreo en Google Search Console y sentí que se me hundía el estómago.
Qué significa realmente el presupuesto de rastreo (y qué no)
Aquí está la cosa que confunde a la gente constantemente: presupuesto de rastreo no significa "la cantidad de páginas que Google alguna vez indexará para ti". Significa aproximadamente la cantidad de URLs que Googlebot traerá dentro de una ventana de rastreo dada, que Google mismo define como una combinación de límite de velocidad de rastreo y demanda de rastreo.
La velocidad de rastreo es qué tan rápido puede rastrear Googlebot sin sobrecargar tu servidor. La demanda de rastreo es cuánto quiere rastrear Google, impulsado por qué tan populares son tus URLs y con qué frecuencia cambian. Multiplica estos dos factores juntos y tendrás una idea aproximada de cuánta atención de rastreo recibe tu sitio.
Para la mayoría de sitios menores a 1,000 páginas, esto es irrelevante. Google rastreará todo. Pero una vez que estés en decenas de miles, y absolutamente una vez que superes seis cifras, Googlebot comienza a hacer elecciones. Priorizará. Ignorará. Y si no lo has configurado para priorizar lo correcto, alegremente dedicará su tiempo a rastrear tus URLs con parámetros de ID de sesión y tus páginas de facetas filtradas mientras tus nuevos productos pasan desapercibidos durante semanas.
Eso no es hipotético. Eso es lo que sucedió en el proyecto de 91,000 páginas.
El Problema de Navegación Facetada que Nadie Me Advirtió
La navegación facetada es el mayor asesino del presupuesto de rastreo que he encontrado en sitios grandes. Consistentemente. Cada vez.
El sitio de catálogo tenía un sistema de filtros facetados: color, tamaño, material, marca, sin ningún manejo de parámetros de URL configurado en ningún lado. Cada combinación de filtros generaba una URL única. Podías seleccionar "azul", "mediano", "algodón" y "MarcaX" y obtener /shop?colour=blue&size=medium&material=cotton&brand=brandx. Entonces alguien cambió el orden y obtuvo /shop?size=medium&colour=blue&brand=brandx&material=cotton. URL diferente, contenido idéntico.
Ejecuté un rastreo con Screaming Frog (versión 18, que maneja mucho mejor la renderización de JavaScript que las versiones anteriores) y encontré más de 200,000 URLs siendo generadas solo por el sistema de filtros. Googlebot estaba visitando estas. Constantemente. Mientras miles de páginas de productos legítimas permanecían sin indexarse.
La Solución Que Realmente Funcionó
Abordamos esto en dos etapas. Primero, configuré el manejo de parámetros de URL en Google Search Console, marcando los parámetros de filtro como "No cambia el contenido de la página" para indicarle a Googlebot que los consolidara. Segundo, y más importante, el equipo de desarrollo implementó una estrategia canónica adecuada, apuntando todas las combinaciones de filtros nuevamente a la página de categoría base. También agregamos noindex a las páginas filtradas de bajo valor que no podían ser canonicalizadas de manera práctica.
Dentro de aproximadamente ocho semanas, el número de páginas indexadas comenzó a aumentar. No explosivamente, de manera constante. Lo cual es en realidad lo que deseas. Un aumento repentino en páginas indexadas puede a veces desencadenar una reevaluación de Google en lugar de una victoria limpia.
Estadísticas de Rastreo en Search Console: Los Datos que la Mayoría de Personas Ignora
He auditado cerca de 80 sitios en los últimos tres años específicamente por problemas de rastreo. Quizás el 15% de las personas que me entregaron esos sitios había mirado alguna vez el reporte de Estadísticas de Rastreo en Search Console. Ese número debería ser mucho más alto.
El informe de Estadísticas de rastreo te muestra el promedio de solicitudes de rastreo por día, el tiempo de respuesta promedio, y, crucialmente, qué es lo que realmente está rastreando Googlebot desglosado por propósito (descubrimiento vs. actualización). Si tus rastreos de "actualización" dominan y los rastreos de descubrimiento son mínimos, Google está dedicando su tiempo a verificar nuevamente páginas que ya conoce. No encontrando nuevas. Esa es una señal de que tu vinculación interna es probablemente superficial o tu mapa del sitio XML no está haciendo nada útil.
En el proyecto de 91,000 páginas, estábamos recibiendo alrededor de 2,400 solicitudes de rastreo por día. Para un sitio de ese tamaño, eso significa que Google teóricamente tardaría aproximadamente 38 días en rastrear todo una vez, asumiendo que cada solicitud alcanzara una página única y útil. No era así. Aproximadamente el 40% de las solicitudes de rastreo estaban golpeando cadenas de redirecciones o duplicados inflados por parámetros.
El Tiempo de Respuesta Promedio Importa Más de lo Que Crees
Algo que subestimé temprano en mi carrera: Googlebot es genuinamente sensible a la velocidad del servidor. No de una manera de ranking (bueno, no directamente), sino en una manera de disposición de rastreo. Los servidores lentos hacen que Googlebot retroceda. Google reducirá su tasa de rastreo para evitar estresar un servidor que está teniendo dificultades.
El sitio del catálogo tenía un Time to First Byte alrededor de 1.8 segundos en páginas de categoría durante el tráfico pico. Después de que el cliente se mudó de hosting compartido a un VPS dedicado con caché apropiado (WP Rocket para caché de páginas, Redis para caché de objetos), TTFB bajó a menos de 400ms. Las solicitudes de rastreo por día subieron notoriamente durante las seis semanas siguientes. Correlación, obviamente, pero he visto este patrón demasiadas veces como para descartarlo.
Sitemaps XML: Deja de Tratarlos Como una Formalidad
La mayoría de sitemaps que heredo están mal. No dramáticamente mal, solo silenciosa, inútilmente mal.
Problemas comunes que veo:
- Páginas en el sitemap que devuelven 404s o redirecciones 301
- Páginas sin indexar incluidas en el sitemap (esto confunde a Googlebot, simultáneamente estás diciendo "rastreá esto" y "no indexes esto")
- Fechas <lastmod> que son estáticas o simplemente incorrectas
- Sitemaps con 70,000+ URLs en un único archivo (el límite es 50,000 por archivo, y los archivos grandes ralentizan el procesamiento)
- Sin archivo de índice de sitemap, solo un blob XML monolítico
En el proyecto del catálogo grande, el sitemap tenía 91,000 URLs en un solo archivo. También estaba incluyendo cada URL filtrada que se hubiera generado alguna vez, más de 40,000 de las cuales tenían noindex. Googlebot estaba procesando este archivo gigante y luego descubriendo que la mayoría de las URLs no deberían rastrearse de todas formas. Señal desperdiciada en ambos lados.
Reconstruimos la arquitectura del sitemap como un índice de sitemap apropiado apuntando a sitemaps secundarios segmentados: uno para páginas de categoría principal, uno para páginas de producto (dividido en dos archivos dada la volumen), uno para contenido editorial. Cada archivo bajo 40,000 URLs. Valores <lastmod> generados dinámicamente a partir de la fecha de última modificación real en la base de datos. Sin páginas sin indexar, sin redirecciones.
Los datos de Bing Webmaster Tools (sí, vale la pena revisar, Bing a veces te muestra patrones de comportamiento de rastreo que sugieren problemas estructurales que Google también está experimentando) mostraron una caída en el tiempo de procesamiento del sitemap superior al 60%.
Enlazado Interno: La Palanca Que Realmente Controlas
Aquí hay algo que genuinamente no aprecié hasta que Seahawk asumió un sitio de contenido grande, aproximadamente 65,000 artículos, para un cliente de medios allá por 2020. El sitio tenía problemas de presupuesto de rastreo a pesar de tener un sitemap bien formado y una estructura de URLs limpia. El problema era la profundidad de enlaces internos. Miles de artículos estaban efectivamente huérfanos, sin enlaces internos que apuntaran a ellos desde ninguna página rastreada.
Googlebot no solo sigue sitemaps. Sigue enlaces. Si una página solo es descubrible a través de una entrada de sitemap y tiene cero enlaces internos, se deprioritiza. Eso no está documentado oficialmente en términos claros, pero la orientación de Google sobre enlaces internos deja claro que los enlaces rastreables desde páginas importantes son cómo Googlebot prioriza el descubrimiento.
Para ese cliente de medios, auditamos enlaces internos usando la herramienta Site Audit de Ahrefs e identificamos alrededor de 12,000 artículos con tres o menos enlaces internos apuntando hacia ellos. Construimos un bloque automático de "artículos relacionados" en el CMS (WordPress, bloque Gutenberg personalizado) que extraía contenido contextualmente similar. En el trimestre siguiente, las páginas indexadas en ese sitio pasaron de 41,000 a más de 58,000. Misma autoridad de dominio. Misma tasa de producción de contenido. Solo un mejor enlazado interno.
El enfoque numerado que ahora uso en cada auditoría de sitio grande:
- Ejecuta un rastreo completo de Screaming Frog y exporta datos de enlaces internos
- Identifica cada página con menos de tres enlaces internos entrantes
- Haz referencias cruzadas contra páginas que tienen buenos enlaces, encuentra grupos temáticos
- Construye enlaces internos contextuales desde páginas de alto tráfico hacia las páginas con poco enlazado
- Valida en la herramienta de Inspección de URLs de Search Console que las páginas recién enlazadas pasen de "Descubierta, actualmente no indexada" a "Rastreada"
Ese estado "Descubierta, actualmente no indexada" en Search Console es tu indicador de alerta. Significa que Google sabe que la página existe pero no ha priorizado su obtención. Mejorar los enlaces internos es generalmente la forma más rápida de resolverlo.
Análisis de archivos de registro: Incómodo pero necesario
Seré honesto, el análisis de archivos de registro es algo que evité durante años. Parecía una profundidad innecesaria cuando las herramientas de rastreo te daban la mayor parte de lo que necesitabas. Estaba equivocado.
Los archivos de registro te dicen qué hizo Googlebot en realidad, no lo que inferís que hizo a partir de tu sitemap o herramienta de rastreo. En un proyecto, una empresa SaaS con aproximadamente 8,000 páginas de documentación de productos, el análisis de registros reveló que Googlebot estaba gastando casi el 30% de su tiempo de rastreo en URLs adyacentes a /wp-admin/ y activos del lado del administrador que deberían haber sido bloqueados en robots.txt. Nadie lo había configurado correctamente. Páginas de documentación que no habían sido rastreadas en cuatro meses.
Screaming Frog's Log File Analyser es la herramienta que uso. No es glamorosa pero es confiable. Importa tus registros de servidor, filtra por el agente de usuario de Googlebot y ordena por frecuencia de visitas de URL. Los patrones que emergen casi siempre son iluminadores, y casi siempre incluyen algo que se está rastreando cuando no debería.
Cuándo Preocuparse y Cuándo Dejar Pasar
No todo sitio grande necesita gestión agresiva del presupuesto de rastreo. Si tienes 10,000 páginas y 9,800 están indexadas, no empieces a mover palancas. Crearás problemas donde no los hay.
La gestión del presupuesto de rastreo realmente vale tu tiempo cuando:
- Tienes más de ~15,000 páginas indexables
- Tu conteo de indexadas se ha estancado a pesar de que se agregue contenido nuevo
- Crawl Stats muestra solicitudes de rastreo promedio muy por debajo de lo que esperarías para tu volumen de páginas
- Ves miles de URLs en estado "Descubierto, actualmente no indexado" o "Rastreado, actualmente no indexado"
Ese segundo estado, "Rastreado, actualmente no indexado", es diferente y vale la pena separarlo. Significa que Google obtuvo la página y decidió no indexarla, generalmente debido a contenido delgado o problemas de duplicación cercana. Ninguna cantidad de optimización de presupuesto de rastreo soluciona un problema de calidad.
---
FAQ
¿El presupuesto de rastreo afecta los sitios pequeños?
Raramente de manera significativa. Si tu sitio tiene menos de 1,000 páginas y carga rápidamente, Google casi seguramente rastreará todo de todos modos. El presupuesto de rastreo se convierte en una preocupación genuina a escala, típicamente por encima de 10,000 a 15,000 páginas, o en sitios donde una gran porción de URLs se generan dinámicamente.
¿Enviar un sitemap directamente solucionará los problemas de presupuesto de rastreo?
No. Un sitemap ayuda con el descubrimiento, le dice a Google que estas URLs existen. Pero si tu sitio tiene problemas estructurales (spam de navegación facetada, respuesta lenta del servidor, vinculación interna superficial), un sitemap no anulará esas señales. Piensa en un sitemap como una sugerencia, no como un comando.
¿Cómo verifico si Googlebot está desperdiciando rastreo en URLs de basura?
Comienza con el reporte de Estadísticas de rastreo en Google Search Console y observa qué tipos de URLs están recibiendo más solicitudes. Luego haz una referencia cruzada con un rastreo de Screaming Frog para identificar patrones de URLs de alto volumen que sean duplicados, noindexados, o de bajo valor. El análisis de archivos de registro te dará la imagen más precisa si tienes acceso a los registros del servidor.
¿Debo usar `noindex` o `robots.txt disallow` para ahorrar presupuesto de rastreo?
Herramientas diferentes para trabajos diferentes. Disallow en robots.txt evita que Googlebot obtenga la página en absoluto, ahorrando presupuesto de rastreo pero significando que Google no puede leer ninguna señal en esa página. Noindex permite que Google obtenga la página pero le dice que no la incluya en los resultados de búsqueda. Para el presupuesto de rastreo específicamente, disallow es más efectivo en URLs verdaderamente basura (rutas de administración, resultados de búsqueda interna). Para páginas de faceta filtrada donde quieres que Google comprenda el contenido pero no la indexe, noindex con un canonical es generalmente la llamada correcta.
¿Cuál es un plazo realista para ver mejoras después de solucionar problemas de presupuesto de rastreo?
Honestamente, depende de tu tasa de rastreo. En el proyecto de 91,000 páginas, movimiento significativo en conteos de páginas indexadas tardó aproximadamente seis a ocho semanas después de que se implementaron las correcciones principales. No esperes cambios de la noche a la mañana, Googlebot necesita re-rastrear, re-evaluar, y la canalización de indexación tiene su propia latencia además de eso.
---
El proyecto de 91,000 páginas terminó bien. Las páginas indexadas aumentaron de 34,000 a poco más de 71,000 durante cinco meses. No es perfecto, había genuinamente páginas de producto delgadas que merecían no ser indexadas, pero el contenido que importaba fue encontrado. El cliente dejó de preguntar si algo estaba roto. Y dejé de considerar cambios de carrera alrededor de la página 47,000 de reportes de rastreo. Más o menos.
Lecturas relacionadas: Investigación de palabras clave con IA en 2026: qué es, por qué tradicional, Redirecciones 301 vs 302: Cuál realmente importa para SEO, y palabras clave LSI en 2026: qué son, qué no son, qué.