Crawl budget: cuando preocuparse y como medirlo

El crawl budget es ese tema que solo entra en la conversacion cuando ya se convirtio en problema. Google publico en 2017 que sitios con menos de unos miles de URLs no necesitan preocuparse, y esa frase se volvio excusa para ignorar el tema incluso en e-commerces con 800 mil PDPs. El punto de quiebre rara vez es el numero de URLs en el sitemap, sino la razon entre paginas utiles y paginas que Googlebot encuentra. Cuando esa razon cae por debajo del 30%, ya estas sangrando rastreo, aunque el trafico organico no lo muestre todavia.

La primera senal practica aparece en Search Console, en Configuracion > Estadisticas de rastreo. Si las solicitudes diarias caen 40% en dos semanas sin cambio de servidor, o si el tiempo medio de respuesta pasa de 300ms a 1.2s, tienes un problema de presupuesto. Otro sintoma clasico: paginas nuevas tardando mas de 10 dias en indexarse en un sitio que recibia Googlebot el mismo dia. Antes de tocar nada, conviene hacer una Como auditar SEO on-page sin caer en conjeturas honesta para descartar que el problema este en el propio contenido.

El diagnostico real vive en los logs del servidor. Filtrar por user-agent de Googlebot en 30 dias de log de Nginx o Cloudflare revela cosas que GSC nunca te va a mostrar: cuantas veces el bot golpeo URLs con parametro ?sort=, cuantas volvio en 404, cuantos hits a paginaciones infinitas generadas por filtros facetados. En un cliente nuestro, 62% del crawl iba a URLs con tres o mas parametros, todas canonicas a la version limpia. La solucion no fue noindex, fue corregir enlaces internos y revisar los Canonical tags: errores comunes que sangran trafico organico para detener la hemorragia en el origen.

Tres trampas tecnicas concentran la mayoria de los casos. La primera es robots.txt mal configurado bloqueando recursos que el renderer necesita, y ahi entra la lectura obligatoria sobre robots.txt: trampas que bloquean la indexacion en silencio. La segunda es un sitemap inflado con URLs 404, redirigidas o con noindex, cubierto en Sitemap XML moderno: prioridad, lastmod y que ignorar. La tercera, mas sutil, es JavaScript que solo renderiza contenido tras interaccion, haciendo que Googlebot vea paginas vacias y gaste cuota intentando entender. La guia de JavaScript SEO: renderizado, hydration e indexacion cubre los patrones que funcionan en 2026 con Next.js y Astro.

Para medir con precision, arma una query en BigQuery cruzando el export de GSC con los logs del CDN. Cuenta URLs distintas rastreadas por dia, agrupa por patron de path (/p/, /c/, /blog/, /tag/), y calcula la razon entre rastreadas e indexadas. Si /tag/ representa 35% del crawl pero 2% de las impresiones, tienes una fuga clara. Este tipo de analisis esta detallado en BigQuery + GSC: consultas que tu agencia no ejecuta y en Log file analysis: que esta haciendo realmente Googlebot, que muestra como separar Googlebot real de bots que falsifican user-agent (cerca de 18% del trafico que se identifica como Googlebot, segun datos de Cloudflare en 2024).

Hay un momento en que el problema deja de ser tecnico y se vuelve de arquitectura. Sitios con mas de 100 mil URLs activas necesitan logica de priorizacion en el propio HTML: lastmod confiable, interlinking que refleje la importancia comercial de las paginas, y remocion agresiva de variaciones que no generan demanda. Si tu categoria principal recibe menos hits de Googlebot que una pagina de tag obsoleta, el problema no es el presupuesto, es el diseno. Takeaway practico: corre log analysis de 30 dias antes del proximo trimestre, clasifica URLs en tres cubos (activas, dormidas, basura) y ataca el tercero primero. El crawl budget se recupera en 6 a 8 semanas cuando dejas de alimentar lo que no deberia existir.