Crawl budget 2026: gobernanza multibot para crawlers de IA

Durante mucho tiempo, el crawl budget se consideró un tema de nicho para sitios web muy grandes. En 2026 eso ha cambiado. Además de Googlebot, ahora accede a los sitios web todo un abanico de crawlers de IA, con sus propios objetivos, su propia carga y su propia utilidad. Así, el crawl budget ha pasado de ser una cuestión exclusiva de Google a un problema de gobernanza multibot. Este artículo explica cómo funciona técnicamente el crawl budget, a partir de qué punto es realmente relevante en el B2B europeo y cómo es en la práctica una gestión diferenciada de Googlebot, Bingbot y los crawlers de IA.

Por qué el crawl budget es un problema multibot en 2026

En su sentido clásico, el crawl budget describe cuántas páginas de un sitio web solicita un buscador en un periodo determinado. Mientras solo importaba Googlebot, esto afectaba casi exclusivamente a sitios muy grandes. En 2026 esa premisa se queda corta, porque el panorama de crawlers se ha ampliado de forma radical.

El aumento es medible. Según el análisis internacional de Cloudflare, en 2025 los bots de IA supusieron de media anual el 4,2 % de todas las peticiones HTML, y Googlebot el 4,5 %, con lo que este ya solo superaba por poco a todos los bots de IA juntos. Especialmente dinámico es el rastreo de IA impulsado por usuarios: creció en 2025 más de 15 veces. Se trata del rastreo en el que un bot visita una página en tiempo real como respuesta a una pregunta hecha a un chatbot. Entre los crawlers puramente de IA, el peso se desplazó con fuerza hacia OpenAI: GPTBot pasó entre mayo de 2024 y mayo de 2025 del 5 % al 30 % de cuota entre los crawlers de IA, con un crecimiento de peticiones del 305 %, mientras que Bytespider cayó en el mismo periodo del 42 % al 7,2 %.

Para el mercado B2B austriaco, Googlebot sigue siendo el crawler más importante, porque Google domina claramente en mayo de 2026 con un 81,87 % de cuota de mercado, por delante de Bing con un 9,01 % y DuckDuckGo con un 2,75 %. Pero los crawlers de IA se suman a todo eso: consumen recursos del servidor, ocupan capacidad de edge y CDN y plantean la pregunta de qué retorno aporta cada bot. Precisamente eso convierte el crawl budget en una cuestión de gestión para todos los actores implicados, no solo para Google.

Crawl Capacity Limit y Crawl Demand: cuándo empieza a ser relevante

Google define el crawl budget de un sitio web como la cantidad de URL que Google puede y quiere rastrear. Se compone de dos elementos: el Crawl Capacity Limit y la Crawl Demand.

• Crawl Capacity Limit: el límite máximo de lo que el servidor soporta sin sobrecargarse. Si un sitio web responde rápido y sin errores, el límite sube. Si se vuelve lento o devuelve errores de servidor, Google reduce el rastreo para no sobrecargarlo.
• Crawl Demand: la necesidad de rastrear una URL. Depende de la popularidad de una página y de la frecuencia con la que cambia su contenido. Las páginas obsoletas o sin cambios se visitan con menos frecuencia.

La pregunta decisiva es a partir de cuándo esto importa realmente. Google es claro: su propia guía se dirige a sitios grandes con más de 1 millón de páginas únicas y contenido que cambia cada semana, y a sitios medianos y más grandes con más de 10.000 páginas únicas y contenido que cambia con mucha frecuencia, por ejemplo a diario. Para el típico sitio web B2B con unos cientos de páginas, el crawl budget rara vez es, por tanto, el cuello de botella desde la perspectiva exclusiva de Googlebot.

Sin embargo, esta tranquilidad solo vale para Googlebot y solo para el rastreo clásico. En cuanto la navegación facetada, las URL de filtros o un gran catálogo de productos inflan artificialmente el número de URL, también un sitio web mediano puede tener un problema de presupuesto. Y los crawlers de IA siguen su propia lógica, que no tiene nada que ver con los umbrales de Google.

Gobernanza multibot: estrategia diferenciada de robots.txt

La primera palanca es el robots.txt. En 2026 ya no es un simple permitir o bloquear, sino una tabla de control para distintas clases de bots. A nivel internacional, el robots.txt hace tiempo que se ha convertido en el escenario de la gestión de crawlers de IA. Según el Web Almanac 2025, los principales user agents de IA ya se abordan allí de forma específica: GPTBot en el 4,5 %, ClaudeBot en el 3,6 %, CCBot en el 3,5 % y Google-Extended en el 3,4 % de los archivos robots.txt de escritorio, y GPTBot casi se ha duplicado respecto a 2024. La directiva más frecuente con diferencia sigue siendo el comodín: el user agent comodín asterisco (*) apareció en 2025 en el 77 % de los archivos.

Una estrategia bien pensada distingue los bots según su finalidad:

• Crawlers de buscadores (Googlebot, Bingbot): acceso completo. Aportan el tráfico orgánico y son la base del negocio. Aquí nunca se bloquea de forma general; solo se evita de forma específica el desperdicio de rastreo.
• Crawlers de búsqueda de IA (OAI-SearchBot, PerplexityBot): sirven respuestas en tiempo real con citación de fuentes y posible tráfico de referencia. Quien quiere ser visible en las respuestas de IA normalmente los deja pasar.
• Crawlers de entrenamiento de IA (GPTBot, ClaudeBot, CCBot, Meta-ExternalAgent): recopilan datos para entrenar modelos. Aquí hace falta sopesar con criterio, porque el consumo de recursos a menudo no tiene un retorno directo.

Es importante separar bien los user agents. Google-Extended no es un crawler propio. Según Google, no tiene una cadena de user agent propia, sino que es un simple token de control para el robots.txt. El rastreo lo hacen los crawlers habituales de Google. El token solo determina si Google puede usar los contenidos para entrenar los modelos Gemini y para el grounding. Grounding significa que Gemini, al responder una consulta, utiliza como fuente contenidos del índice de Google. No influye en la inclusión en la Búsqueda de Google ni en el ranking. Quien bloquea Google-Extended conserva, por tanto, su visibilidad en Google y solo excluye el uso para Gemini. Esta diferenciación es el núcleo de la gobernanza multibot.

Distinguir los tipos de carga de los crawlers de IA: entrenamiento, búsqueda, tiempo real

Bloquear o permitir de forma general ignora que los crawlers de IA cumplen tres funciones completamente distintas. El análisis internacional de datos de Cloudflare cuantifica la proporción con claridad: el entrenamiento impulsa ya casi el 80 % de la actividad de los bots de IA, el 18 % corresponde a la búsqueda y solo el 2 % a acciones iniciadas por usuarios.

• Rastreo para entrenamiento: bots como GPTBot, ClaudeBot o CCBot descargan contenidos para entrenar modelos. Este acceso genera carga, pero rara vez se traduce en tráfico directamente atribuible. Es el tipo de carga con el retorno inmediato más débil.
• Rastreo para búsqueda: los sistemas de búsqueda con IA obtienen contenidos para citarlos en sus respuestas. Aquí existe la oportunidad de conseguir tráfico de referencia y visibilidad de marca, de forma comparable a la búsqueda clásica.
• Rastreo en tiempo real impulsado por usuarios: bots como ChatGPT-User visitan una página en directo porque un usuario ha hecho una pregunta en el chat. Este tipo de carga es pequeño en volumen, pero indica un interés concreto del usuario precisamente en ese contenido en el momento de la consulta.

La consecuencia práctica: si quieres reducir costes de servidor sin sacrificar visibilidad, limita primero el rastreo para entrenamiento y mantén el rastreo para búsqueda y en tiempo real. Bloquear de forma general todos los bots de IA, en cambio, cortaría también los accesos potencialmente valiosos.

Eliminar el desperdicio de crawl budget

Antes de pensar en la gestión de bots, deberías haber eliminado el desperdicio de cosecha propia. En la práctica es el mayor problema, y afecta por igual a todos los crawlers. Un estudio de caso internacional de Botify muestra lo drástica que puede llegar a ser la desproporción: allí el 97 % de alrededor de 1 millón de páginas rastreadas no eran canónicas, con solo unas 25.000 URL indexables, de las que Google rastreaba cada mes apenas algo más de la mitad. En el conjunto del sector, según la misma fuente, en sitios web sin optimizar Google rastrea cada mes de media solo el 40 % de las URL estratégicas, y el 60 % se queda sin rastrear.

Las fuentes típicas de desperdicio se pueden cerrar de forma específica:

• Navegación facetada y URL con parámetros: las combinaciones de filtros y ordenación generan un número casi ilimitado de URL con contenido apenas distinto. Se controlan con etiquetas canonical, noindex selectivo o bloqueando rutas de parámetros completas en el robots.txt.
• Contenido duplicado: varias URL con contenido idéntico, por ejemplo por mayúsculas y minúsculas, barras finales o identificadores de sesión. Una estrategia de canonical coherente concentra las señales en una URL preferida.
• Soft 404: páginas sin contenido real que devuelven por error un estado 200 en lugar de 404 o 410. Consumen crawl budget en contenidos sin valor.
• Rutas de rastreo infinitas: calendarios, paginaciones sin fin o filtros anidados que llevan a los crawlers a profundidades cada vez mayores.

El principio es: los crawlers deben dedicar su tiempo limitado a las páginas que deben posicionarse o ser citadas, no a lastre técnico.

Control activo del índice: sitemaps e IndexNow

En lugar de limitarte a evitar el desperdicio, puedes dirigir activamente a los crawlers hacia las URL correctas. Para ello hay dos instrumentos complementarios.

• Sitemaps XML: recogen las URL canónicas y dignas de indexación junto con su fecha de actualización. Un sitemap bien mantenido ayuda a los buscadores a encontrar páginas nuevas y modificadas de forma eficiente, sin tener que recorrer todo el sitio web. Es la base de cualquier ahorro de rastreo.
• IndexNow: un protocolo push con el que un sitio web informa activamente a los buscadores sobre URL nuevas o modificadas, en lugar de esperar al siguiente rastreo. La adopción es considerable: según Bing, a través de IndexNow se envían más de 3,5 mil millones de URL al día, y de ahí procede el 18 % de todas las URL nuevas en las que se hizo clic en los resultados de búsqueda web.

La salvedad decisiva: IndexNow es compatible con Bing, Yandex y otros, pero no con Google. Como Google domina el mercado en Austria, IndexNow es aquí un complemento útil para la visibilidad en Bing, pero no sustituye una estrategia limpia de sitemaps y de rastreo para Google. Ambos instrumentos son complementarios: sitemaps para Google, IndexNow además para los participantes de IndexNow.

Gestión de bots en las capas de edge, CDN y servidor

El robots.txt es una petición, no una obligación. Los crawlers serios lo respetan; otros no. Si quieres impedir técnicamente la sobrecarga por rastreo o detener de forma fiable bots no deseados, necesitas control a nivel de edge, CDN y servidor.

• Verificación de bots legítimos: los crawlers reales se pueden verificar mediante sus rangos de IP publicados oficialmente o por DNS inverso. Así separas el Googlebot auténtico de los bots que solo se hacen pasar por él.
• Rate limiting: limita la frecuencia de peticiones por bot o por rango de IP. Protege el servidor de origen frente a picos de carga sin dejar fuera por completo a los crawlers legítimos.
• Bloqueo y permiso selectivos: a nivel de CDN se pueden bloquear de forma específica los bots de entrenamiento de IA y dejar pasar los de búsqueda y tiempo real. Es más preciso y más eficaz que el robots.txt por sí solo.
• Protección de la caché: los crawlers de IA acceden a menudo a contenidos long tail poco visitados que no están en la caché de edge. Esos accesos van directamente al servidor de origen y compiten por los recursos con el tráfico humano. El rate limiting y un enrutamiento específico alivian aquí la carga.

Este nivel es especialmente relevante para sitios web B2B sensibles a los recursos, en los que la capacidad del servidor y unos tiempos de respuesta estables para los clientes de pago tienen prioridad sobre el acceso descontrolado de bots.

El análisis de logs como instrumento de control

Sin medición, cualquier gestión del rastreo es un vuelo a ciegas. La analítica web estándar como GA4 prácticamente no registra los crawlers de IA, porque estos no ejecutan JavaScript ni guardan cookies. La única fuente de datos fiable es el archivo de log del servidor. Muestra qué bot ha solicitado qué URL, cuándo y con qué código de estado.

A partir de los logs se pueden derivar las magnitudes de control decisivas:

• Frecuencia de rastreo por bot: ¿con qué frecuencia visitan Googlebot, GPTBot o ClaudeBot el sitio web, y qué áreas de URL? Así detectas si el presupuesto se va a páginas sin valor.
• Ratio crawl-to-refer: la relación entre páginas rastreadas y visitantes realmente derivados mide el retorno de un bot. Los valores internacionales de Cloudflare de julio de 2025 muestran la enorme dispersión: Anthropic rastreó unas 38.065 páginas por visitante derivado, OpenAI unas 1.091 y Google solo 5,4. Cuanto más alto es este valor, peor es la relación entre carga y beneficio.
• Distribución de códigos de estado: si se acumulan 404 o 5xx en el tráfico de bots, apunta a desperdicio de rastreo o a problemas de servidor que reducen el Crawl Capacity Limit.

Con esta base de datos se puede redirigir el presupuesto de forma específica: limitar los bots con una mala relación crawl-to-refer y dirigir los crawlers valiosos hacia las URL estratégicas. El análisis de logs es, por tanto, el instrumento de medición central de la gobernanza multibot.

Next.js y JavaScript SEO: tener en cuenta el presupuesto de renderizado

El crawl budget tiene una segunda dimensión que a menudo se pasa por alto: el presupuesto de renderizado. Si construyes los contenidos en el cliente con JavaScript, exiges al crawler un segundo paso costoso. Google tiene que rastrear y renderizar la página para ver el contenido. Eso consume recursos adicionales y retrasa la indexación.

Para una arquitectura moderna con Next.js, de ahí se deriva un orden de prioridad claro entre las estrategias de renderizado:

• SSG (Static Site Generation): las páginas se prerrenderizan en el momento del build y se entregan como HTML listo. Es el enfoque más eficiente para el rastreo y el renderizado, ideal para contenidos estables como artículos especializados o páginas de servicios.
• ISR (Incremental Static Regeneration): las páginas estáticas se regeneran periódicamente en segundo plano. Combina la eficiencia de SSG con la actualidad y es adecuado para contenidos que cambian a menudo, pero no cada segundo.
• SSR (Server-Side Rendering): el HTML se genera en el servidor en cada petición. El crawler recibe HTML completo sin tener que renderizar por su cuenta. Útil para páginas personalizadas o muy dinámicas.
• CSR (Client-Side Rendering): el contenido se genera solo en el navegador. Es el peor caso para el SEO, porque carga doblemente el crawl budget y el presupuesto de renderizado y deja con las manos vacías sobre todo a los crawlers de IA, que a menudo no ejecutan JavaScript en absoluto.

La regla general para sitios web B2B eficientes en rastreo es: servir los contenidos relevantes para la indexación renderizados en el servidor o de forma estática, para que cualquier crawler encuentre el contenido completo directamente en el HTML. Eso ahorra presupuesto de renderizado y hace que los contenidos sean accesibles también para los crawlers de IA que no ven JavaScript.

Crawlers de IA, GEO y monetización: llms.txt y pay per crawl

Con la carga de los crawlers de IA surge la pregunta estratégica del retorno. En 2026 están apareciendo nuevos mecanismos, todavía jóvenes y poco homogéneos.

• llms.txt: un archivo propuesto que ofrece a los sistemas de IA, de forma agrupada, contenidos seleccionados y bien estructurados. Sin embargo, su difusión sigue siendo escasa: según el Web Almanac 2025, solo el 2,13 % de los sitios web de escritorio ofrece un llms.txt válido, y el 39,6 % de ellos se genera con el plugin All in One SEO. Hasta ahora no se ha convertido en un estándar vinculante.
• Enfoques pay per crawl: modelos en los que los proveedores de IA pagan por acceder a los contenidos en lugar de rastrearlos gratis. Abordan precisamente el desequilibrio entre una alta carga de rastreo y un bajo tráfico de referencia que ponen de manifiesto los ratios crawl-to-refer.

En el fondo, es una cuestión de equilibrio: por un lado, la visibilidad en las respuestas de IA (GEO); por otro, los costes de servidor y el control sobre los propios contenidos. Para las empresas B2B en Europa, cuyos contenidos especializados son un activo central, merece la pena decidir con criterio para cada clase de crawler en lugar de permitir o bloquear todo sin distinción.

RGPD, reserva de TDM y dimensión jurídica

En la región DACH (Alemania, Austria y Suiza), la gestión de los crawlers de IA tiene también una dimensión jurídica. Es relevante para las empresas austriacas, porque va más allá del mero control técnico.

• Opt-out para el entrenamiento de IA: con directivas como el bloqueo de Google-Extended o GPTBot en el robots.txt, un sitio web indica que sus contenidos no deben usarse para entrenar IA. Es la aplicación técnica de una reserva de uso.
• Reserva de TDM (minería de textos y datos): la normativa de derechos de autor de la UE permite a los titulares de derechos prohibir de forma legible por máquina el uso de sus obras para la minería de textos y datos con fines comerciales. Una reserva recogida en el robots.txt o en una declaración legible por máquina es la base para excluir legalmente el entrenamiento de IA.
• Relación con el RGPD: si las páginas públicas contienen datos personales, su inclusión en corpus de entrenamiento plantea cuestiones de protección de datos. Una gestión consciente de los crawlers forma parte, por tanto, de un cumplimiento normativo bien hecho.

La conexión entre el control técnico y el jurídico es aquí lo esencial: el robots.txt no es solo una herramienta de rastreo, sino que documenta al mismo tiempo la voluntad del titular de los derechos. Para cumplir el RGPD en el contexto austriaco, este control debería ser consciente y trazable, idealmente coordinado con el departamento jurídico.

Más información y conclusión

En 2026, el crawl budget ya no es un tema exclusivo de los sitios grandes, sino un problema multibot que hay que gestionar activamente. Desde la perspectiva exclusiva de Googlebot, los umbrales siguen siendo altos, pero la variedad de crawlers de IA, su carga dispar y su retorno muy variable hacen que una gobernanza diferenciada tenga sentido también para sitios web B2B medianos.

Las prioridades en la práctica están claras: primero, eliminar el desperdicio de rastreo de cosecha propia con una buena higiene de canonical, noindex y robots.txt; segundo, configurar un robots.txt diferenciado que trate de forma distinta a los buscadores, los crawlers de búsqueda de IA y los crawlers de entrenamiento de IA; tercero, analizar los logs del servidor para medir la frecuencia de rastreo y los ratios crawl-to-refer y redirigir el presupuesto; cuarto, elegir la arquitectura de renderizado de modo que los contenidos sean accesibles sin esfuerzo de renderizado. Si combinas estos cuatro niveles y tienes en cuenta la dimensión jurídica, mantienes el control sobre tu propio servidor y decides con criterio qué contenido queda abierto a qué bot. Puedes profundizar en el tema en los artículos relacionados sobre robots.txt, sitemaps XML, etiquetas canonical y gestión de crawlers de IA.