Idiomas

Demanda de rastreo

El lado del «deseo» del presupuesto de rastreo: lo que hace que Google quiera rastrear tus páginas (popularidad, obsolescencia, inventario percibido), cómo la demanda se encuentra con la capacidad de carga del host y por qué no puedes forzarla.

Publicado por primera vez: 3 jul 2026 · Última actualización: 8 ago 2026 · Avanzado
Idiomas
AIEscrito porAI v2

La demanda de rastreo es el lado del «deseo» del presupuesto de rastreo: cuánto quiere rastrear un motor de búsqueda un sitio o URL, a diferencia de la rapidez con que puede hacerlo (eso es frecuencia de rastreo/capacidad). Google señala la popularidad (enlaces/PageRank), la obsolescencia (con qué frecuencia cambia una página) y el inventario percibido (cuántas URL cree Google que existen, incluida la basura — «el factor que más puedes controlar positivamente») como factores generales importantes de la demanda, no como una fórmula cerrada de tres elementos; Google también apunta al tamaño del sitio, la frecuencia de actualización, la calidad de la página y cómo se compara un sitio con otros similares. Las migraciones web aumentan temporalmente la demanda. La carga del host actúa como un límite sobre la demanda efectiva, no como un impulsor — mi síntesis: la demanda establece el orden de prioridad de las URL, y la capacidad decide hasta qué punto de esa cola llega Googlebot. No puedes establecer la demanda directamente: mueves sus factores consiguiendo enlaces, manteniendo el contenido genuinamente actualizado y reduciendo el inventario de URL basura para que las señales de calidad retroalimenten el programador de rastreo. En realidad, Google intenta rastrear menos en general mientras dirige la demanda con mayor precisión, por lo que el objetivo real nunca fue el volumen, sino la priorización correcta. La mayoría de los sitios nunca necesitan gestionar esto.

TL;DR — La demanda de rastreo es el lado del querer del presupuesto de rastreo; la frecuencia de rastreo/capacidad es el lado del poder. Google señala la popularidad (enlaces / PageRank), la obsolescencia (con qué frecuencia cambia una página) y el inventario percibido (cuántas URL cree Google que existen, incluida la basura — “the factor you can positively control the most” (traducción) «el factor que más puedes controlar positivamente») como factores generales significativos de la demanda — no una fórmula cerrada; el tamaño del sitio, la frecuencia de actualización, la calidad de la página y la relevancia comparativa también influyen. Las migraciones web aumentan temporalmente la demanda. Mi síntesis para integrarlo: la demanda establece el orden de prioridad de las URL; la capacidad de carga del host decide hasta qué punto de esa cola llega Googlebot — Google no documenta esto como un algoritmo literal, pero es el modelo que encaja con la evidencia. Un servidor en buen estado no fabrica demanda, y la demanda alta aún puede verse limitada por la capacidad. No puedes establecer la demanda directamente — las únicas palancas son sus entradas, y el programador aumenta la demanda cuando mejoran las señales de calidad de la indexación. Mientras tanto, Google está intentando activamente rastrear menos mientras enruta la demanda con mayor precisión, por lo que el objetivo real nunca fue el volumen — es la priorización correcta. La mayoría de los sitios nunca necesita gestionar nada de esto.

Evidence for this claim Google says Googlebot demand varies by site size, update frequency, page quality, and relevance compared with other sites; significant general demand factors are perceived inventory, popularity, and staleness. Scope: large or rapidly changing websites Confidence: high · Verified: Optimize your crawl budget

La demanda de rastreo es el «querer», la frecuencia de rastreo es el «poder»

Google es explícito en que el presupuesto de rastreo tiene dos mitades: la cantidad de tiempo y recursos que Google dedica a rastrear un sitio _“is determined by two main elements: crawl capacity limit and crawl demand.” (traducción) «está determinada por dos elementos principales: el límite de capacidad de rastreo y la demanda de rastreo.» La forma en que lo planteo en mi guía de presupuesto de rastreo de Ahrefs: el presupuesto de rastreo está _“made up crawl demand which is how many pages a search engine wants to crawl on your site and crawl rate which is how fast they can crawl.” (traducción) «compuesto por la demanda de rastreo, que es cuántas páginas quiere rastrear un motor de búsqueda en tu sitio, y la frecuencia de rastreo, que es qué tan rápido puede rastrear.» La demanda es el querer; la frecuencia es el poder. Evidence for this claim Google describes crawl demand as one of the two main elements of crawl budget, alongside crawl capacity limit. Scope: Google Search crawling. Confidence: high · Verified: Google: Large site crawl budget guide

Esta página trata solo sobre el querer. El lado del poder — el límite de capacidad de rastreo, el control deslizante de frecuencia de GSC que se eliminó en enero de 2024, cómo las respuestas 5xx/429 ralentizan a Googlebot y la cuadrícula manual de Crawl Control de Bing — se encuentra en la página de frecuencia de rastreo. No voy a volver a derivarlo aquí; cuando ambos interactúan, enlazaré a esa página.

Los tres factores de demanda

La orientación actual de Google califica el inventario percibido, la popularidad y la falta de actualización como factores generales significativos que impulsan cuánto quiere rastrear; no los presenta como una fórmula exhaustiva y cerrada. La misma orientación también menciona el tamaño del sitio, la frecuencia con la que se actualiza, la calidad de la página y cómo se compara con sitios similares como factores que Googlebot pondera. Los tres siguientes son los que Google explica con mayor profundidad y los que puedes abordar directamente. Evidence for this claim Google's crawl-demand guidance discusses perceived inventory, popularity, and staleness. Scope: These inputs influence crawling but do not provide a user-controlled demand setting. Confidence: high · Verified: Google: Large site crawl budget guide

Demand decides which URLs sit at the front of the queue; a healthy server only determines how much of that demand can be realized. Fuente: Google Search Central

Crawl demand orders URLs using popularity, genuine change, and the perceived value of the site's URL inventory. Crawl capacity, based on server response speed, stability, and errors, determines how far Googlebot can proceed through that ordered queue. Faster infrastructure raises the capacity ceiling but does not create demand for low-priority URLs.

© Patrick Stox LLC · CC BY 4.0 ·

Popularidad

“URLs that are more popular on the Internet tend to be crawled more often to keep them fresher in our systems.” (traducción) «Las URL que son más populares en Internet tienden a rastrearse con más frecuencia para mantenerlas más actualizadas en nuestros sistemas.» Más enlaces y más PageRank que apuntan a una URL son una señal de demanda: por eso tu página de inicio se rastrea constantemente y una página profunda y sin enlaces apenas se rastrea. Como explico en mi guía sobre presupuesto de rastreo, “Popular pages, or those with more links and PageRank, will generally receive priority over other pages.” (traducción) «Las páginas populares, o aquellas con más enlaces y PageRank, generalmente recibirán prioridad sobre otras páginas.» Los enlaces internos también cuentan aquí: una página a la que no enlaza nada (una página huérfana) casi no tiene demanda a su favor.

Falta de actualización

“Our systems want to recrawl documents frequently enough to pick up any changes.” (traducción) «Nuestros sistemas quieren volver a rastrear los documentos con la frecuencia suficiente para detectar cualquier cambio.» Google aprende el ritmo de cada página. Una página que cambia constantemente obtiene nuevos rastreos frecuentes; una página que nunca cambia se comprueba cada vez menos. En mi guía sobre presupuesto de rastreo describo el retroceso que Google aplica a una página estática: “if they crawl a page and see no changes after a day, they may wait three days before crawling again, ten days the next time, 30 days, 100 days, etc.” (traducción) «si rastrean una página y no ven cambios después de un día, pueden esperar tres días antes de volver a rastrear, diez días la próxima vez, 30 días, 100 días, etc.» Esa cadencia de nuevos rastreos por URL es en realidad una cuestión de frecuencia de rastreo — allí cubro la mecánica — pero la fuerza subyacente es la demanda, y específicamente la falta de actualización.

Inventario percibido (el que más controlas)

Esta es la palanca principal. Google: “Without guidance from you, Google tries to crawl all or most of the URLs that it knows about on your site. If many of these URLs are duplicates, or you don’t want them crawled for some other reason (removed, unimportant, and so on), this wastes a lot of Google crawling time on your site. This is the factor that you can positively control the most.” (traducción) «Sin orientación por tu parte, Google intenta rastrear todas o la mayoría de las URL que conoce en tu sitio. Si muchas de estas URL son duplicadas, o no quieres que se rastreen por alguna otra razón (eliminadas, poco importantes, etc.), esto desperdicia mucho tiempo de rastreo de Google en tu sitio. Este es el factor que puedes controlar positivamente en mayor medida.»

Evidence for this claim Google calls perceived inventory the crawl-demand factor site owners can positively control the most; duplicate, removed, and unimportant known URLs can waste crawling time. Scope: large or rapidly changing websites Confidence: high · Verified: Optimize your crawl budget

La parte sutil es lo que hace a la demanda, no solo a la capacidad. Es fácil pensar que las URL basura “desperdician presupuesto de rastreo” — gastar recuperaciones en copias en lugar de contenido nuevo. Cierto. Pero también hay un efecto del lado de la demanda: un sitio cuyo inventario conocible está compuesto principalmente por duplicados de bajo valor y proliferación de parámetros parece, para Google, un sitio de menor valor para rastrear. Reducir el inventario percibido no solo libera capacidad; con el tiempo concentra la demanda en las URL que la merecen. La navegación por facetas, los ID de sesión, los espacios de calendario infinitos y otras spider traps son los clásicos infladores de inventario — y los clásicos supresores de demanda.

Migraciones de sitio y otros picos de demanda

Un factor de demanda no está relacionado con una sola URL: “Additionally, site-wide events like site moves may trigger an increase in crawl demand in order to reprocess the content under the new URLs.” (traducción) «Además, los eventos que afectan a todo el sitio, como las migraciones de sitio, pueden provocar un aumento en la demanda de rastreo para volver a procesar el contenido bajo las nuevas URL.» Si haces una migración de dominio o un cambio de plataforma importante y observas que Googlebot te impacta mucho más de lo habitual durante unas semanas, eso es esperable: Google tiene que volver a obtener y volver a procesar todo bajo las nuevas direcciones. Es un pico temporal, no una nueva línea base, y es un evento de demanda que las guías de la competencia casi nunca mencionan, a pesar de que aparece textualmente en la propia documentación de Google.

Evidence for this claim Google says site-wide events such as site moves may temporarily increase crawl demand so content can be reprocessed under new URLs. Scope: large or rapidly changing websites Confidence: high · Verified: Optimize your crawl budget

Cómo interactúan la demanda y la carga del host: orden de la cola vs. puerta de capacidad

Aquí tienes un modelo mental que hace que todo el tema encaje —y quiero ser transparente al decir que es mi síntesis, no algo que Google documente como un algoritmo literal. Se basa en una sesión de preguntas y respuestas de Gary Illyes, citada aquí a través de la cobertura de Search Engine Roundtable: la carga del host _“sets a bucket of URLs in importance order and GoogleBot will crawl in that order based on the schedule the host load decided. If Google thinks your server can handle it, it will crawl the whole bucket, if not, it will stop.” (traducción) «establece un cubo de URL en orden de importancia y Googlebot rastreará en ese orden según la programación que la carga del host decidió. Si Google considera que tu servidor puede manejarlo, rastreará el cubo completo; si no, se detendrá.» Cabe destacar que, según esa misma sesión de preguntas y respuestas, la carga del host registra la importancia de tus páginas, no la cantidad bruta de URL que tienes ni cuántas quieres que se rastreen. Esa página bloquea la obtención automatizada, por lo que no he podido reconfirmar la redacción exacta directamente con la fuente en vivo en esta revisión; trata esto como una paráfrasis bien corroborada, no como una cita textual de fuente primaria.

Lee eso con atención y se desprende una relación —de nuevo, así es como conecto las piezas, no un mecanismo que Google haya detallado de principio a fin:

  • La demanda establece el orden. El “bucket of URLs in importance order” es la demanda de rastreo: la popularidad y la falta de actualización deciden qué URL se ubican en los primeros puestos de la cola.
  • La capacidad determina hasta dónde llega Google. La carga del host / la frecuencia de rastreo decide qué tan profundo dentro de ese cubo ordenado rastrea realmente Googlebot en un día determinado. _“If your server can handle it, it crawls the whole bucket; if not, it stops.” (traducción) «Si tu servidor puede manejarlo, rastrea el cubo completo; si no, se detiene.»

Por lo tanto, ambos no se limitan a multiplicarse entre sí — desempeñan funciones diferentes. Un servidor saludable y rápido no fabrica demanda (solo eleva el límite de cuánta de tu demanda existente llega a materializarse), y una demanda alta todavía puede verse limitada por la capacidad (un servidor lento o propenso a errores detiene a Googlebot a mitad de la cola sin importar cuánto quiera rastrear). Por eso, “I bought a faster server and Google still isn’t crawling my new pages” (traducción) «Compré un servidor más rápido y Google sigue sin rastrear mis nuevas páginas» es un resultado tan común y frustrante: la capacidad nunca fue la limitación — lo era la demanda.

No puedes establecer la demanda directamente — pero el planificador escucha

Respuesta corta: no estableces la demanda directamente. La ganas, indirectamente, mediante enlaces reales y mejoras reales de calidad que aparecen en las señales de indexación — nada más la mueve.

No hay una solicitud de “rastrear más” para la demanda, al igual que no la hay para la frecuencia de rastreo. Pero la demanda es dinámica, y Google ha sido inusualmente sincero sobre cómo se mueve. Gary Illyes: “If you want to increase how much we crawl, then you somehow have to convince search that your stuff is worth fetching, which is basically what the scheduler is listening to.” (traducción) «Si quieres aumentar cuánto rastreamos, entonces de alguna manera tienes que convencer a la búsqueda de que tu contenido vale la pena obtener, que es básicamente lo que el planificador está escuchando.» Y el bucle de retroalimentación es casi en tiempo real: “Scheduling is very dynamic. As soon as we get the signals back from search indexing that the quality of the content has increased across this many URLs, we would just start turning up demand.” (traducción) «La planificación es muy dinámica. En cuanto recibimos las señales de vuelta de la indexación de búsqueda de que la calidad del contenido ha aumentado en esta cantidad de URLs, simplemente empezaríamos a aumentar la demanda.» La otra cara también: “If search demand goes down, then that also correlates to the crawl limit going down.” (traducción) «Si la demanda de búsqueda baja, entonces eso también se correlaciona con que el límite de rastreo baje.» (Volví a comprobar estas tres líneas con la cobertura de Search Engine Journal en esta pasada y coinciden textualmente; todavía no he localizado el audio/transcripción del propio podcast de Google para confirmarlas como fuente primaria, así que considéralas citas secundarias bien corroboradas.)

Eso replantea “cómo aumento la demanda de rastreo” alejándolo de los trucos. Las marcas de tiempo falsas de lastmod, los pings de sitemap y el volumen de publicación no convencen al planificador. Las dos cosas que sí lo hacen son las dos cosas difíciles: popularidad real (enlaces) y mejoras de calidad reales que aparecen en las señales de indexación y retroalimentan al planificador. Todo lo demás es teatro.

Google está intentando rastrear menos, no más

El ángulo más novedoso aquí, y uno que las guías antiguas pasan por alto por completo: el objetivo declarado por el propio Google es reducir el volumen de rastreo total, no aumentarlo. En una publicación de LinkedIn de abril de 2024, Illyes escribió: “My mission this year is to figure out how to crawl even less, and have fewer bytes on wire.” (traducción) «Mi misión este año es averiguar cómo rastrear aún menos, y tener menos bytes en la red». Rechazó la idea de que Google había recortado el rastreo — “we’re crawling roughly as much as before, however scheduling got more intelligent” (traducción) «estamos rastreando aproximadamente tanto como antes, sin embargo la programación se volvió más inteligente» — y presentó el objetivo como una ganancia compartida: “Decreasing crawling without sacrificing crawl-quality would benefit everyone.” (traducción) «Disminuir el rastreo sin sacrificar la calidad del rastreo beneficiaría a todos». Los mecanismos que señaló fueron un mejor almacenamiento en caché, el uso compartido de caché entre agentes de usuario (user-agent) y menos bytes transferidos, no «rastrea más mi sitio».

La conclusión: la demanda de rastreo nunca fue algo que maximizar. Google está optimizando activamente para menos rastreo total con una calidad de rastreo igual o mejor, dirigiendo la demanda que sí tiene hacia URLs con más probabilidades de merecerla. Tu objetivo no es más demanda — es la correcta priorización de la demanda que has ganado.

¿Tienes siquiera un problema de demanda?

La mayoría de los sitios no lo hacen, y no deberían dedicar ni un minuto a esto. La propia desescalada de Google se aplica plenamente a la demanda:

  • “If your site doesn’t have a large number of pages that change rapidly, or if your pages seem to be crawled the same day that they are published, you don’t need to read this guide.” (traducción) «Si tu sitio no tiene un gran número de páginas que cambian rápidamente, o si tus páginas parecen rastrearse el mismo día en que se publican, no necesitas leer esta guía.» John Mueller ha sido igualmente directo sobre la escala: según la cobertura que Search Engine Roundtable hizo de su tuit, 100 000 URL normalmente no son suficientes para afectar al presupuesto de rastreo, ya que eso equivale a muy por debajo de un rastreo por minuto durante tres meses.

Si eres lo bastante grande como para que te importe, aquí tienes el diagnóstico que separa un problema de demanda de uno de capacidad, con una advertencia previa: produce una hipótesis para probar, no un diagnóstico. Consulta el Crawl Stats report de GSC y los registros de tu servidor. Si el Host status está en buen estado y el tiempo de respuesta promedio es adecuado, pero un conjunto de URL apenas se rastrea —y están atascadas en “Discovered – currently not indexed”—, ese patrón es evidencia que apunta hacia la demanda, no una prueba de ello. Crawl Stats muestra la actividad de rastreo (una vista del lado de la capacidad), no una puntuación de demanda; no existe en ningún lugar una «puntuación de demanda de rastreo» pública por sitio, así que siempre estás infiriendo la demanda a partir de la actividad más el estado de indexación, nunca leyéndola en un panel.

Antes de actuar partiendo de «es un problema de demanda», descarta otras causas que producen el mismo síntoma de servidor saludable pero sin rastreo: Google puede no haber descubierto aún las URL (sin ruta de acceso, sin entrada en el sitemap), el renderizado puede estar ocultando el contenido que Googlebot necesita ver, la canonicalización puede dirigir a Google a otro lugar por completo, los problemas reales de calidad (contenido escaso, duplicado o de bajo valor) pueden hacer que una página se rastree, pero quede deliberadamente fuera del índice, y la propia selección de indexación de Google puede dejar fuera una página incluso cuando el rastreo y la calidad están bien. Solo después de comprobar que esos factores no lo explican, «baja demanda» se convierte en la explicación provisional —e incluso entonces, trátala como la hipótesis mejor respaldada, no como una causa confirmada. Un hardware más rápido no solucionará un problema genuino de demanda; la solución está en los factores de demanda: enlaces a esas páginas, razones genuinas para volver a rastrearlas y menos inventario basura que las ahogue.

Para obtener datos de rastreo reales por URL, el análisis de registros es la respuesta. Destacaré una herramienta actual sobre la que puedo hablar de primera mano en la pestaña Herramientas.

Demanda de rastreo vs. frecuencia de rastreo vs. presupuesto de rastreo vs. frecuencia de rastreo

Mantén clara la familia:

  • Demanda de rastreo — cuánto quiere rastrear Google (popularidad + obsolescencia + inventario percibido). Esta página.
  • Frecuencia de rastreo — qué tan rápido puede (capacidad / carga del host). Su propia página.
  • Presupuesto de rastreo — los dos juntos: _“the number of URLs Googlebot can and wants to crawl.” (traducción) «el número de URLs que Googlebot puede y quiere rastrear».
  • Frecuencia de rastreo — con qué frecuencia se vuelve a rastrear una URL determinada, lo cual es un resultado de la demanda (principalmente obsolescencia).
Evidence for this claim Google's crawl-demand guidance discusses perceived inventory, popularity, and staleness. Scope: These inputs influence crawling but do not provide a user-controlled demand setting. Confidence: high · Verified: Google: Large site crawl budget guide

Bing no usa el término “crawl demand” (demanda de rastreo) — reformula todo como eficiencia de rastreo: Fabrice Canel la define como “how often we crawl and discover new and fresh content per page crawled,” (traducción) «con qué frecuencia rastreamos y descubrimos contenido nuevo y fresco por página rastreada», y la filosofía de Bing es la reducción de inventario como prioridad, el equivalente en el lado de la demanda del inventario percibido. IndexNow es la forma de Bing de señalar eventos de cambio relevantes para la demanda en lugar de esperar a que el planificador infiera la obsolescencia — pero ten en cuenta que Google no usa IndexNow, por lo que no moverá la demanda de Google.

Evidence for this claim Google's crawl-demand guidance discusses perceived inventory, popularity, and staleness. Scope: These inputs influence crawling but do not provide a user-controlled demand setting. Confidence: high · Verified: Google: Large site crawl budget guide

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.