CRAWL BUDGET · NOTAS DE CAMPO PRIMERO DEL REPO
Crawl Budget: Cuándo Realmente Importa (y Cuándo No)
La propia documentación de Google dice a la mayoría de los sitios que no se preocupen por el crawl budget — luego el resto de la página uno les enseña a optimizarlo de todas formas. Aquí está cómo saber si realmente vincula tu sitio, y las cuatro palancas para accionar si lo hace.
Busca “crawl budget” y la página de resultados ofrece una pequeña comedia. El resultado orgánico principal es la propia documentación de Google, que comienza diciendo a la mayoría de los lectores que cierren la pestaña: si tu sitio tiene menos de algunos miles de URLs, será rastreado eficientemente, y no hay nada aquí para que optimices. Cada guía clasificada debajo enseña a los mismos lectores a optimizarlo de todas formas — podando tu blog de 40 páginas, bloqueando tu CSS, preocupándote por un “presupuesto” que no podrías agotar aunque lo intentaras. El resultado es una generación de pequeños propietarios de sitios haciendo cirugía de crawl-budget en sitios que Google nunca tuvo dificultad para rastrear, a veces cortando cosas que realmente estaban ayudando.
Esta guía toma a Google por su palabra. El crawl budget es real, importa enormemente — para una clase específica de sitio — y para esa clase hay exactamente cuatro palancas que vale la pena accionar: eliminar trampas de rastreo, arreglar enlaces internos, higiene del sitemap, y salud del servidor, diagnosticados desde Crawl Stats y registros del servidor en lugar de intuiciones. Para todos los demás, la respuesta honesta es que tu problema es casi con seguridad algo más económico de arreglar. Esta es la capa de rastreo de nuestro pilar SEO agéntico, y una compañera de la guía de auditoría técnica de SEO más amplia — la misma regla se aplica aquí: ninguna solución se realiza hasta que Search Console dice que funcionó.
Qué es realmente el crawl budget
El crawl budget no es una cuota que Google te asigne como un plan de teléfono. Es la intersección de dos fuerzas que Google documenta explícitamente. La primera es el límite de capacidad de rastreo: la velocidad máxima a la que Googlebot obtendrá tus páginas sin dañar tu servidor. Es elástico — responde rápido y saludable y el límite sube; responde lentamente, o con errores de servidor, y Googlebot se retrae. Tu infraestructura establece este techo, no tu SEO.
La segunda es demanda de rastreo: cuánto Google quiere rastrear tu sitio, impulsado por cuántas URLs conoce, cuán populares son, y cuán antiguas se han vuelto sus copias. Un sitio que publica diariamente y recibe enlaces construye demanda; un sitio de mil páginas estáticas que nunca cambian no necesita re-rastreo, y Google no desperdiciará las visitas. El crawl budget es cualquiera de los dos que se agote primero — y este es el detalle que las guías de pánico omiten: para un sitio pequeño, ninguno de los dos se agota nunca. El límite de capacidad nunca se acerca y la demanda se satisface fácilmente. No hay presupuesto para optimizar porque nada se está racionando.
Cuándo importa realmente el crawl budget: los umbrales propios de Google
La guía de crawl budget para sitios grandes de Google nombra su audiencia en números, que casi nadie cita porque los números descalifican a casi todos. La guía está escrita para sitios con más de un millón de páginas únicas cuyo contenido cambia semanalmente, o más de diez mil páginas únicas cuyo contenido cambia diariamente — más un caso basado en síntomas: sitios donde Search Console clasifica una gran parte de URLs como “Descubiertas — actualmente no indexadas,” lo que significa que Google sabe que las páginas existen y ha elegido no obtenerlas aún. El post de crawl-budget de Googlebot de 2017 del equipo de búsqueda de Google dibuja el piso aún más bajo: algunos miles de URLs o menos, rastreadas eficientemente, nada de qué preocuparse — y si tus páginas nuevas tienden a ser rastreadas el mismo día que las publicas, deja de leer.
¿Quién realmente supera la barra? Catálogos de comercio electrónico con navegación facetada, tableros de clasificados y empleos con alta rotación de listados, editores con archivos profundos y salida diaria, y cualquier plataforma que genere páginas programáticamente — una matriz locale × categoría × filtro se convierte en millones de URLs rápidamente. El hilo común no es el recuento bruto de páginas sino espacio de URL que crece más rápido que el valor. Un sitio de 500 páginas con rutas limpias no tiene problema de crawl-budget por definición. Una tienda de 50.000 productos cuyos filtros acuñan una nueva URL por combinación puede desnutrir sus propias páginas de dinero mientras Googlebot deambula por la combinatoria.
El pánico del sitio pequeño, desacreditado
El guión de pánico es reconocible a primera vista: un blog de 200 páginas bloqueando su CSS y JS para “ahorrar presupuesto,” noindexando paginación, deshabilitando páginas de categoría, podando posts que estaban ganando silenciosamente clics de cola larga. Cada uno de esos movimientos tiene un costo real y ninguno tiene un beneficio de rastreo en esa escala. Bloquear recursos de renderizado hace que las páginas sean más difíciles para Google de evaluar. Y el truco de noindex ni siquiera hace lo que sus usuarios piensan: Googlebot tiene que rastrear una página para ver la etiqueta noindex, así que no ahorra rastreo en absoluto — la documentación de crawl-budget de Google lo dice directamente.
Cuando las páginas de un sitio pequeño no se están indexando, la restricción casi nunca es crawl budget. Es demanda de rastreo — Google obtuvo la página, la evaluó, y declinó. Ese es un problema de calidad y relevancia disfrazado de problema de plomería.
La distinción importa porque los dos problemas tienen soluciones opuestas. Un problema de presupuesto se arregla con resta: menos URLs basura compitiendo por obtenciones. Un problema de demanda se arregla con suma: páginas más fuertes, enlaces internos reales, evidencia de que el contenido vale la pena almacenar. El pequeño propietario de sitio que poda y bloquea está aplicando la cura de sitio grande a la enfermedad de sitio pequeño — y si lo que realmente se está racionando es la atención en una página de resultados mediada por IA en lugar de obtenciones de Googlebot, la solución vive en territorio de SEO de cero clics, no robots.txt.
Diagnostica antes de optimizar: Crawl Stats y registros del servidor
Si podrías genuinamente tener un problema de crawl-budget, el diagnóstico es observable — nadie debería estar optimizando crawl por intuición. El informe Crawl Stats de Search Console (bajo Configuración, fácil de pasar por alto) es el primer instrumento gratuito: solicitudes totales de rastreo en 90 días, tiempo de respuesta promedio, y tres desgloses que llevan la mayoría de la señal. Por respuesta — una parte significativa de obtenciones gastadas en 404s, redirecciones, o errores de servidor es presupuesto quemado en nada. Por propósito — descubrimiento versus actualización te dice si Google está encontrando nuevas URLs o re-leyendo las antiguas. Por tipo de archivo — miles de obtenciones de basura parametrizada aparecen aquí antes que en cualquier otro lugar.
Los registros del servidor son el segundo instrumento, y pasada cierta escala el definitivo: el único registro de cada URL que Googlebot realmente solicitó, no una muestra. La pregunta que hacer a los registros es brutal y simple — ¿qué parte de las solicitudes de Googlebot golpean URLs que quiero indexadas? En sitios grandes la respuesta es rutinariamente una minoría. En un sitio que auditamos, el rastreo fue dominado por URLs de combinación de filtros que ningún buscador querría, mientras que páginas de productos genuinamente nuevas permanecieron sin descubrir durante semanas — el problema de crawl-budget en una oración: Google trabajó duro y obtuvo las cosas equivocadas.
Las cuatro palancas que realmente mueven el crawl budget
Para sitios que superan los umbrales, cuatro palancas hacen casi todo el trabajo, en orden descendente de impacto. Cada una debería dejar el diagnóstico como una tarea con una métrica comprometida por adelantado — el mismo contrato de prueba que cada solución lleva en un sistema de SEO de bucle cerrado.
Elimina trampas de rastreo
Una trampa de rastreo es cualquier patrón que acuña URLs más rápido de lo que pueden llevar valor: navegación facetada que convierte cada combinación de filtro en una dirección, IDs de sesión y parámetros de seguimiento en enlaces internos, paginación de calendario infinita, y órdenes que duplican una categoría completa bajo una nueva cadena de consulta. La propia lista de Google de tipos de URL que desperdician rastreo es encabezada por exactamente estos. La jerarquía de soluciones: deja de generar las URLs cuando sea posible, deja de vincular a ellas cuando no sea así, y desautentica los patrones residuales en robots.txt — que, a diferencia de noindex, realmente previene la obtención. Una trampa a nivel de plantilla supera mil páginas podadas individualmente.
Arregla los enlaces internos
La demanda de rastreo sigue los enlaces. Las páginas enterradas cinco clics profundas, o accesibles solo a través del sitemap, se rastrean tarde y raramente; las páginas huérfanas efectivamente se ofrecen como voluntarias para ser olvidadas. La palanca es arquitectónica, no cosmética: páginas importantes dentro de algunos clics de la página de inicio, páginas hub que concentren enlaces internos en lo que debería clasificarse, y sin enlaces internos apuntando a redirecciones, URLs muertas, o duplicados parametrizados — cada tal enlace es una instrucción a Googlebot para gastar una obtención en nada.
Higiene del sitemap
El sitemap es una declaración de lo que quieres rastreado, y la mayoría de los sitios grandes dejan que se pudra en una mentira: listados expirados, URLs redirigidas, páginas noindexadas, duplicados delgados. Un sitemap que Google ha aprendido a desconfiar deja de ser una señal de descubrimiento útil. El estándar es estricto — solo URLs canónicas, indexables, con estado 200, con valores lastmod precisos, para que una página cambiada sea una invitación de re-rastreo y una sin cambios no lo sea. En sitios generados este es un arreglo de plantilla, no un proyecto editorial.
Salud del servidor y velocidad de respuesta
La palanca que todos olvidan porque pertenece a un equipo diferente: el límite de capacidad de rastreo se establece por el comportamiento de tu servidor. Las respuestas consistentemente lentas lo reducen; los errores 5xx y los 429s hacen que Googlebot se retracte directamente — Google documenta ambos. Las respuestas más rápidas elevan el techo en cada otra palanca. Aquí es donde viven también las cadenas de redirección y los soft 404s: cada salto en una cadena es una obtención separada, y un soft 404 es lo peor de ambos mundos — presupuesto gastado y una señal de baja calidad registrada.

Primero el repo: las trampas de rastreo están escritas en código
Aquí está lo que las guías orientadas al rastreo estructuralmente pierden: cada trampa de rastreo es algunas líneas de código fuente. La trampa de navegación facetada es un manejador de rutas que acepta combinaciones de parámetros arbitrarias y una plantilla que vincula a ellas. El calendario infinito es un componente de paginación sin límite superior. El sitemap podrido es un generador de sitemap consultando el conjunto equivocado. Un rastreador te muestra cien mil URLs sintomáticas; el repositorio te muestra los cinco archivos que las acuñan — y el diff que las detiene. Si tú o tu agente pueden leer la base de código, la auditoría de crawl-budget es principalmente lecturas de archivos, exactamente como se argumenta en el método de auditoría primero del repo.
| Palanca | Dónde vive en el repo | Señal de verificación |
|---|---|---|
| Elimina trampas de rastreo | Manejadores de rutas, plantillas de enlaces de filtro/parámetro, reglas de robots | Crawl Stats: obtenciones de patrón de basura colapsan; la parte de descubrimiento se desplaza a URLs reales |
| Enlaces internos | Componentes de nav y hub, ayudantes de enlaces, destinos de enlaces de plantilla | Impresiones en páginas anteriormente profundas u huérfanas |
| Higiene del sitemap | Generador de sitemap + la consulta que lo alimenta, fuente de lastmod | El sitemap enviado vs indexado convergen; páginas frescas rastreadas más pronto |
| Salud del servidor | Rutas de almacenamiento en caché y renderización, configuración de redirección, manejo de errores | Crawl Stats: el tiempo de respuesta promedio baja, la parte 5xx baja, las solicitudes totales suben |
El repo es también donde la solución se vuelve exhaustiva en lugar de estadística. Podar URLs de basura de una exportación de rastreo trata síntomas uno a la vez; cambiar la plantilla que las genera trata cada instancia actual y futura en un commit. Esta asimetría es por qué un agente trabajando dentro de la base de código real — leyendo rutas, editando plantillas, abriendo un PR — supera a un panel de control exportando hallazgos para que alguien más interprete.
Verifica: ninguna solución de crawl se realiza hasta que Crawl Stats lo dice
El trabajo de crawl-budget tiene una propiedad que la mayoría del SEO carece: retroalimentación inusualmente rápida, inusualmente directa. Bloquea un patrón de trampa y la mezcla de obtenciones en Crawl Stats se desplaza dentro de días — puedes observar la parte de basura caer y el promedio de tiempo de respuesta mejorar. Eso hace que sea indefendible omitir la verificación aquí, y sin embargo el guión estándar lo hace: el cambio de robots.txt se lanza, el ticket se cierra, y nadie lee el informe que mostraría si el comportamiento de Googlebot realmente cambió.
El flujo de trabajo honesto compromete la métrica antes de la solución, en dos etapas. Etapa uno, mecánica: la señal de Crawl Stats de la tabla anterior — ¿el rastreo realmente se redistribuyó? Etapa dos, la que justifica el trabajo: ¿las páginas que estaban hambrientas de rastreo comenzaron a ganar impresiones? Esa segunda lectura necesita aproximadamente tres semanas de datos de Search Console, la misma física que cada veredicto en la disciplina de movimiento causal verificado — y mantiene los postes de meta honestos, porque un rastreo que se redistribuyó sin que ninguna página ganara visibilidad es un nulo interesante, no una victoria.
Crawl budget como folclore
Un sitio de 200 páginas bloquea CSS, noindexea paginación, y poda posts de cola larga para "ahorrar presupuesto" que nadie estaba gastando. Ninguna línea base fue leída, ninguna métrica se comprometió, ninguna re-medición se programó. El trabajo no puede ser probado como inútil — que es la única razón por la que sobrevive.
Crawl budget como diagnóstico
Crawl Stats y registros se leen primero. Veredicto: o "sin problema — rastreado con prontitud, continúa," o una trampa nombrada con una solución a nivel de plantilla, una regla de robots, una señal de Crawl Stats esperada en días, y un veredicto de impresiones leído tres semanas después. Confirmado, retrocedido, o inconclusivo — escrito de cualquier forma.
Ejecuta esto como un panel en lugar de un proyecto y el bucle se cierra a sí mismo: la trampa aterriza como una tarea con su impacto esperado y métrica de verificación, el enlace de PR registra exactamente lo que se lanzó, y el monitor semanal lee Search Console y escribe el veredicto. El crawl budget deja de ser un tema de folclore y se convierte en lo que siempre debería haber sido — una restricción medible que o vincula tu sitio o no lo hace, con la respuesta en los datos en lugar de en una publicación de blog escrita para un sitio mil veces tu tamaño.
La forma más rápida de descubrir de qué lado del umbral estás es mirar tus propios números. Un informe SEO gratuito conecta tu Search Console y muestra dónde se encuentra la restricción real — páginas que Google no está mostrando, páginas mostradas pero nunca elegidas, y si el rastreo está en algún lugar de esa lista. Y si lo está, y preferirías que todo el bucle se ejecutara a sí mismo — trampas encontradas en la fuente, soluciones lanzadas como PRs, veredictos leídos desde Crawl Stats e impresiones — reserva una llamada y te mostraremos el panel haciendo exactamente eso.
Frequently asked questions

Escrito por
Luke McCormackFundador, My Agentic SEO
Especialista en SEO y Google, responsable del go-to-market y el crecimiento de My Agentic SEO.
Más sobre LukeParte del clúster
SEO Agentic: Qué Es y Cómo Un Agente Ejecuta Su SEODeje que el agente ejecute la primera etapa sobre sus datos reales
Conecte su Google Search Console y reciba un informe SEO profesional gratis — diagnosticado y priorizado sobre su sitio real. Lleva unos minutos.