Contenido del artículo

Imagina que construiste un centro comercial con diez mil tiendas, pero el inspector que otorga los permisos de funcionamiento entra una vez al día y solo alcanza a revisar quinientas puertas. Y encima pasa la mitad del tiempo en los depósitos, los almacenes y los baños, adonde lo llevaron por accidente tus propios carteles. Así se ve la indexación web en la mayoría de los proyectos de tamaño medio y grande. El robot de búsqueda llega, gasta recursos en basura y se va sin haber visto tus mejores páginas.

En 2026 este problema se agravó. Los buscadores se volvieron notablemente más selectivos: el índice dejó de ser un depósito infinito donde se guarda todo. Al mismo tiempo, una ola de nuevos crawlers que recolectan datos para modelos de IA cayó sobre los servidores, y compiten por el mismo ancho de banda que los bots de búsqueda. El dueño de un sitio que no gestiona cómo se rastrea su recurso pierde, más que puntos abstractos, dinero real: los productos nuevos no aparecen en los resultados durante semanas, los precios actualizados quedan desactualizados y las landing pages de las campañas permanecen invisibles.

Esta guía está dedicada a un tema concreto: cómo deciden los buscadores qué y cuándo rastrear en tu sitio, y cómo influir en esa decisión. Deliberadamente no vamos a repasar cómo armar un sitemap o escribir directivas para robots. Esos temas están desarrollados por separado en nuestro blog. Aquí hablaremos del mecanismo en sí: de lo que ocurre entre el momento en que el robot se entera de la existencia de una URL y el momento en que la página aparece en el índice.

¿A quién le sirve esto? A los marketers cuyas nuevas landings se indexan demasiado lento. A los desarrolladores cuyo servidor gime bajo la carga de los bots, pero cuyas secciones importantes quedan sin rastrear. A los arbitrajistas con decenas de sitios y cientos de landing pages, donde la velocidad de entrada al índice influye directamente en la rentabilidad. A los dueños de tiendas online y agregadores, donde la navegación facetada multiplica millones de direcciones. Vamos a explicar la teoría en lenguaje claro, dar cuatro métodos prácticos con instrucciones paso a paso, mostrar errores típicos, herramientas y casos reales con cifras. Al final del artículo tendrás un framework completo de gestión del crawl budget que podrás aplicar ya esta semana.

Fundamentos: cómo funciona la indexación web y qué es el crawl budget

Empecemos por la base, porque aquí es donde se esconden la mayoría de los malentendidos. Muchos creen que la indexación web ocurre al instante y de forma automática: publicaste una página y ya está en el buscador. En la práctica, cada URL pasa por varias etapas y puede quedarse atascada en cualquiera de ellas.

Las cinco etapas del camino de una página hacia el índice

  1. Descubrimiento. El buscador se entera de la existencia de la dirección: por un enlace interno, por un enlace externo, desde el sitemap, a través del contador de analítica o por una notificación. La URL descubierta entra en la cola.
  2. Planificación. El sistema decide cuándo y si vale la pena rastrear esa dirección. Se tiene en cuenta el valor estimado de la página, el historial de cambios, la carga del servidor y la prioridad actual de la cola.
  3. Rastreo (crawling). El robot envía una petición HTTP y recibe la respuesta: código HTML, estado, encabezados. Aquí es donde se gasta ese famoso presupuesto.
  4. Procesamiento y renderizado. El código recibido se analiza, se extraen los enlaces y, si es necesario, la página se envía a la cola de ejecución de JavaScript. Luego el sistema evalúa el contenido, determina la dirección canónica y verifica si hay duplicados.
  5. Indexación. La página se añade al índice y queda disponible para el ranking, o se rechaza: por duplicada, por poco valor, por bloqueada con directivas.

Fíjate bien: el rastreo y la indexación son eventos distintos. Pueden rastrear una página pero no indexarla. Y al revés: una URL puede indexarse por señales externas sin un rastreo completo del contenido. Entender esta diferencia elimina la mitad de los errores al diagnosticar.

Qué es el crawl budget

El crawl budget (presupuesto de rastreo) es la cantidad de URLs que un robot de búsqueda está dispuesto y es capaz de rastrear en tu sitio durante un período determinado. Se compone de dos elementos.

  • Límite de velocidad de rastreo (crawl capacity limit): cuántas conexiones y peticiones paralelas puede abrir el robot sin sobrecargar tu servidor. Es el techo técnico. Crece dinámicamente cuando el servidor responde rápido y de forma estable, y baja con errores, timeouts y respuestas lentas.
  • Demanda de rastreo (crawl demand): qué tan interesado está el buscador en tu contenido. Las páginas populares, que se actualizan con frecuencia y bien citadas, se solicitan más. Las páginas huérfanas de baja calidad pueden no solicitarse durante meses incluso con el límite libre.

El presupuesto final es el menor de los dos valores. El servidor puede aguantar mil peticiones por segundo, pero si el robot no ve demanda, vendrá por diez páginas. Y al revés: el contenido puede ser demandado, pero si el servidor devuelve errores, el límite se recortará.

A quién le afecta

La posición oficial de los grandes buscadores: el crawl budget se convierte en un problema real para sitios de varias decenas de miles de páginas con cambios frecuentes o de un millón de páginas en general. Es cierto, pero con una salvedad. Un sitio pequeño de dos mil direcciones también puede sufrir si de esas dos mil, mil quinientas son basura técnica, y el presupuesto, por la juventud del dominio y una masa de enlaces débil, es de cien URLs al día. La proporción importa más que los números absolutos. Por eso la pregunta «cuánto presupuesto tengo» siempre va de la mano con la pregunta «en qué se gasta».

Inmersión profunda: cómo deciden los robots en 2026

Ahora miremos dentro del mecanismo. Los algoritmos exactos de los buscadores son cerrados, pero según la documentación oficial, las patentes, los experimentos y los logs de grandes proyectos, el panorama se vuelve bastante claro.

Una cola con prioridades, no una lista

El robot no recorre el sitio «en orden». Todas las URLs conocidas están en una enorme cola donde cada dirección tiene una puntuación de prioridad. Se forma a partir de varios factores:

  • Importancia por enlaces: cantidad y calidad de enlaces internos y externos hacia la URL. La página principal y las secciones de nivel superior casi siempre están en la cima de la cola.
  • Frecuencia de cambios prevista. Si la página cambió en los últimos diez rastreos cada vez, el robot vendrá antes. Si no cambió ni una vez, el intervalo crecerá.
  • Utilidad histórica. Las páginas que reciben clics desde los resultados se rastrean más. Las páginas que fueron rastreadas y rechazadas pierden prioridad.
  • Tipo de URL y patrón. Los sistemas aprenden de los patrones de direcciones. Si cientos de páginas del tipo /catalog/?sort=price resultaron duplicadas, todo el patrón recibirá prioridad reducida.
  • Estado del servidor. Cada respuesta 5xx, cada timeout, es una señal de bajar la intensidad para todo el host.

De ahí una conclusión importante: el crawl budget no es solo la cantidad de peticiones, sino también su distribución. Puedes tener un límite generoso y aun así ver cómo el robot revisa por décima vez en el día una página vacía de filtro, ignorando un producto nuevo.

Dos olas de procesamiento y el costo de JavaScript

Los robots modernos saben ejecutar JavaScript, pero lo hacen en una cola aparte con un recurso aparte. Primero el sistema procesa el HTML inicial, extrae enlaces y contenido. Si la página depende de los scripts, se envía a renderizado, que puede ocurrir horas o días después. Los enlaces que aparecen solo tras ejecutar el JS se descubrirán con retraso. El contenido que se carga por script se evalúa más tarde.

Para los sitios en frameworks de cliente sin renderizado en servidor, esto significa doble gasto: el presupuesto de rastreo se gasta en el HTML, el presupuesto de renderizado en ejecutar el código, y entre ambos se pierde tiempo. En 2026 esto sigue siendo una de las principales causas de indexación lenta en proyectos tecnológicamente modernos. Paradójico, ¿no?

Estados que hay que saber leer

En los paneles para webmasters hay varios estados, y cada uno indica una etapa concreta del problema.

  • Descubierta, sin indexar. El robot sabe de la dirección, pero aún no la ha rastreado. Síntoma clásico de déficit de presupuesto o de baja prioridad: la cola es larga y la URL está al final.
  • Rastreada, sin indexar. El robot obtuvo el contenido y decidió no añadirlo al índice. Esto ya no es cuestión de presupuesto, sino de calidad, duplicación o contenido escaso. El presupuesto, en este caso, se gastó en vano.
  • La página es una copia, el usuario no eligió la dirección canónica. El sistema encontró un duplicado y eligió otra URL. Cada una de esas páginas es un rastreo a la basura.
  • Error del servidor o redirección. Señal directa de que el presupuesto se va en direcciones que no funcionan.

Particularidades de Yandex

El robot de Yandex funciona con principios similares, pero con matices. Tiene una cuota aparte para el recrawl forzado, limitada por día. Usa activamente los datos del contador de analítica para descubrir páginas nuevas. Es sensible a la vinculación regional y puede rastrear la misma dirección en el contexto de distintas regiones. Y es bastante agresivo al inicio del conocimiento del sitio: un proyecto nuevo puede recibir un pico de peticiones que luego se estabiliza. Ignorar estos matices al trabajar en el mercado ruso es un error.

Qué cambió hacia 2026

Tres tendencias definen el panorama actual. Primera: el índice se volvió más estricto. Los buscadores dicen abiertamente que no están obligados a indexar todo. Las páginas escasas, plantilladas o generadas sin valor se descartan en la etapa de procesamiento. Segunda: el aumento del número de crawlers de IA. Los bots que recolectan datos para modelos de lenguaje pueden generar una carga comparable a la de los de búsqueda, y a veces superior. No traen tráfico de búsqueda, pero consumen recursos del servidor y reducen indirectamente el límite para los robots de búsqueda reales. Tercera: la frescura del contenido como señal de demanda se reforzó. Los sitios que realmente actualizan páginas reciben más atención, y la simulación de actualización cambiando la fecha sin modificar el contenido se detecta y se castiga con reducción de prioridad.

Método 1: Auditoría de logs del servidor como base de la gestión del presupuesto

Si quieres gestionar algo, debes medirlo. Los paneles para webmasters ofrecen estadísticas agregadas de rastreo, pero son suavizadas, con retraso e incompletas. La única fuente de verdad sobre adónde va realmente el robot son los logs de tu servidor. Este es el primer método y el principal.

Para qué los logs, si existe el panel para webmasters

El informe de estadísticas de rastreo muestra el número total de peticiones, el tamaño medio de la respuesta y la distribución por tipos. Pero no dirá que el robot pasó el 40 por ciento del tiempo en páginas de ordenación del catálogo. No mostrará que una sección importante no se visitó en tres semanas. No revelará que la mitad de las peticiones a productos devuelve una redirección. Los logs mostrarán todo esto por cada URL concreta.

Instrucciones paso a paso para la auditoría

  1. Recopilar logs de al menos 30 días. Para sitios con rastreo poco frecuente, mejor 60-90 días. Asegúrate de que se registren todos los nodos: balanceadores, CDN, servidores individuales. Omitir un nodo distorsiona el panorama.
  2. Filtrar las peticiones de los robots de búsqueda. Filtra por la cadena User-Agent, pero verifica obligatoriamente la autenticidad: los robots reales llegan desde rangos de IP conocidos que publican los buscadores, y se confirman con una consulta DNS inversa. Los bots falsos que se hacen pasar por buscadores pueden representar hasta un tercio del total en los logs. Contarlos es analizar ruido.
  3. Clasificar las URLs por tipos. Divide las direcciones en categorías: principal, secciones, fichas de producto o artículos, páginas con parámetros, paginación, búsqueda interna, páginas de servicio, recursos estáticos, inexistentes. Para esto basta con un conjunto de expresiones regulares según la estructura de las direcciones.
  4. Construir una tabla resumen. Para cada categoría, cuenta: número de peticiones del robot, porcentaje del total, distribución de códigos de estado, tiempo de respuesta medio, número de URLs únicas. Compáralo con el valor de negocio de la categoría.
  5. Encontrar las brechas. Coteja la lista de URLs rastreadas por el robot con la lista de URLs de tu estructura del sitio. Aparecerán dos grupos: direcciones que se rastrean pero no deberían existir, y direcciones que deberían rastrearse pero no se visitaron.
  6. Calcular la frecuencia de recorrido de las páginas clave. Para las cien URLs más importantes, mira el intervalo entre visitas del robot. Si los productos nuevos se visitan una vez cada dos semanas, esa es tu velocidad real de indexación web.

Una línea típica de log con la que vas a trabajar se ve así:

66.249.66.1 - - [12/Feb/2026:08:14:22 +0300] "GET /catalog/phones/?sort=price&page=17 HTTP/1.1" 200 48211 "-" "Mozilla/5.0 (compatible; Googlebot/2.1)"

Un solo vistazo dice mucho: el robot vino por la decimoséptima página de la lista ordenada por precio. La probabilidad de que esta página sea valiosa para el índice tiende a cero. Y de esas líneas hay decenas de miles al día en los logs de una tienda grande.

El framework de los cuatro cuadrantes

Los resultados de la auditoría conviene organizarlos en una matriz de «se rastrea / no se rastrea» frente a «valioso / no valioso».

  • Se rastrea y es valioso. Zona de normalidad. La tarea es vigilar que la frecuencia de recorrido corresponda a la frecuencia de cambios.
  • Se rastrea y no es valioso. Zona de fuga. Aquí es donde se quema el presupuesto. Primer objetivo a eliminar.
  • No se rastrea y es valioso. Zona de oportunidad perdida. Aquí hay que redirigir el recurso liberado mediante enlaces internos y señales de prioridad.
  • No se rastrea y no es valioso. Zona de reposo. No hay que hacer nada, pero conviene asegurarse de que estas páginas no empiecen a descubrirse de repente.

Checklist de señales de alerta en los logs

  • Más del 20 por ciento de las peticiones del robot corresponde a URLs con parámetros que no crean contenido único.
  • Más del 10 por ciento de las respuestas al robot son redirecciones o errores 404.
  • Hay respuestas 5xx o el tiempo de respuesta al robot supera los dos segundos en una proporción notable de peticiones.
  • Las páginas comerciales clave se visitan menos de una vez por semana cuando los precios y la disponibilidad cambian a diario.
  • El robot solicita URLs que no están ni en la estructura ni en el sitemap: señal de «fuga» de direcciones a través de scripts, enlaces antiguos o hackeo.
  • Una parte significativa de las peticiones corresponde a recursos estáticos que no se cachean y se sirven cada vez de nuevo.

La auditoría de logs es el trabajo más subestimado del SEO técnico. Requiere tiempo, pero después de ella todos los demás métodos dejan de ser adivinanzas y se convierten en cirugía de precisión.

Método 2: Eliminar a los devoradores del crawl budget

Cuando el mapa de fugas está listo, pasamos a la liquidación. Aquí importa un principio: no intentar corregir todo a la vez, sino golpear las fuentes más grandes. Veamos los devoradores típicos y las formas de trabajar con cada uno.

Navegación facetada y parámetros de URL

El principal enemigo de la indexación de sitios grandes. Un catálogo con diez filtros de cinco valores cada uno genera teóricamente millones de combinaciones de direcciones. El robot, al encontrar enlaces hacia ellas, irá honestamente por todas. Qué hacer:

  • Determina qué combinaciones de filtros tienen demanda de búsqueda real. Por lo general son los filtros individuales y los pares poco frecuentes: «zapatillas rojas», «portátil 16 pulgadas». Estos los dejamos abiertos con contenido único, títulos y descripciones.
  • Todas las demás combinaciones, así como las ordenaciones, los conmutadores de vista y la cantidad por página, no deben generar URLs indexables. Opciones: indicar la dirección canónica de la categoría base, implementar el filtrado sin cambiar la URL, usar la directiva noindex.
  • Los enlaces hacia combinaciones sin valor no deben ser enlaces normales en el HTML. Si el robot no los ve, no los gasta. Esta es la opción más económica.

Paginación y espacios infinitos

Listados de cientos de páginas, calendarios de eventos con desplazamiento infinito hacia adelante, archivos por día: todo esto son «espacios infinitos» en los que el robot puede quedarse atascado. Soluciones: limitar la profundidad de la paginación a un número razonable, no crear enlaces a fechas vacías, dar al robot enlaces directos a los elementos profundos a través de categorías y etiquetas, y no solo mediante el desplazamiento secuencial.

Duplicados de origen técnico

El mismo contenido está disponible en direcciones con barra final y sin ella, en mayúsculas y minúsculas, con index.php y sin él, por http y https, con www y sin www, con etiqueta utm y sin ella. Cada variante es una petición distinta. La regla es simple: un contenido, una dirección. Todas las variantes deben devolver una redirección 301 a la principal o, como mínimo, contener la dirección canónica. Verifícalo no de forma selectiva, sino masivamente, con un crawler por todo el sitio.

Cadenas de redirecciones y enlaces rotos

El robot que recibe un 301 hace una segunda petición. Si ahí también hay redirección, una tercera. Una cadena de cuatro redirecciones gasta cinco peticiones en una sola página. Además, las cadenas largas pueden cortarse: el robot deja de seguir después de varios saltos. Lo mismo con los enlaces internos a páginas eliminadas: cada visita por ellos es una petición que devolvió 404, es decir, presupuesto tirado a la basura. La tarea: todos los enlaces internos deben llevar directamente a la dirección final con respuesta 200.

404 suaves y páginas vacías

La página «producto no encontrado» con código 200, una categoría vacía, un resultado de búsqueda sin resultados: todo esto es un soft 404. El robot recibe una respuesta completa, gasta recursos en procesarla y luego entiende que no hay contenido. Las páginas vacías deben devolver un 404 o 410 honesto, o no existir en absoluto.

Búsqueda interna y secciones de servicio

Las páginas de resultados de búsqueda interna, el carrito, el área personal, las páginas de comparación de productos, las versiones para imprimir: el robot no debe entrar ahí a través de enlaces. Aquí funcionan precisamente las directivas para robots, pero recuerda que esta herramienta está analizada en detalle en otro artículo del blog.

Un matiz importante: noindex no ahorra presupuesto

Un error muy común: pusimos noindex y el problema está resuelto. No. Para ver el noindex, el robot debe solicitar la página. Lo hará con menos frecuencia que con las páginas indexables, pero lo hará. Lo único que ahorra presupuesto es: la ausencia de enlaces hacia la URL o el bloqueo del rastreo. Para eliminar basura ya indexada, lo más rápido es el código 410: comunica de forma inequívoca que la página se eliminó para siempre, y el robot deja de volver antes que con un 404.

Algoritmo de priorización de correcciones

  1. Para cada fuente de fuga, anota el porcentaje de peticiones del robot según la auditoría de logs.
  2. Evalúa la dificultad de la corrección: configuración del servidor, fácil; cambio de plantilla, medio; rehacer la lógica de los filtros, difícil.
  3. Evalúa el riesgo: ¿los cambios pueden afectar el tráfico o los escenarios de usuario?
  4. Empieza por la combinación «gran porcentaje, corrección fácil, riesgo bajo». Normalmente son las redirecciones, los enlaces rotos y los duplicados técnicos. Después pasa a los parámetros y las facetas.
  5. Tras cada etapa, dale al robot dos o tres semanas y revisa los logs. El presupuesto liberado debe redistribuirse hacia las páginas valiosas. Si no ocurrió, pasa al tercer método.

Método 3: Arquitectura del sitio y señales de prioridad para el robot

Liberar presupuesto es la mitad del trabajo. Ahora hay que dirigirlo adonde aporte valor. El robot sigue las señales, y las principales son la estructura de enlaces y la frescura.

La profundidad de clics como medida de prioridad

Cuanto más lejos está la página de la principal en la cadena de enlaces, menor es su prioridad en la cola de rastreo. Regla práctica: todas las páginas que deben generar tráfico deben ser accesibles en no más de tres o cuatro clics. Un producto en una subcategoría en la vigésima página de paginación está a una profundidad de siete u ocho: para el robot es una zona casi invisible. Cómo reducir la profundidad:

  • Páginas hub: secciones que agrupan enlaces hacia decenas de páginas finales por tema.
  • Bloques de enlazado interno en fichas y artículos: «productos similares», «lee también», «vistos juntos con frecuencia». No solo retienen a los usuarios, sino que crean rutas adicionales para el robot.
  • Enlaces a páginas nuevas desde la principal y las secciones: un bloque de «novedades» acelera directamente el descubrimiento y el rastreo.
  • Recopilaciones por etiquetas y temáticas como rutas alternativas hacia el contenido profundo.

La frescura como combustible de la demanda

El robot viene más seguido adonde algo cambia. Pero el cambio debe ser real: una descripción actualizada, reseñas nuevas, un precio vigente, una sección del artículo ampliada. Cambiar la fecha de publicación sin modificar el contenido se detecta rápido y juega en tu contra. Un buen truco práctico es colocar en las páginas importantes bloques dinámicos pero con sentido: últimas reseñas, promociones vigentes, novedades relacionadas. La página vive y el robot lo ve.

Encabezados Last-Modified honestos

Si el servidor entrega correctamente la fecha de última modificación y soporta peticiones condicionales, el robot puede verificar la página y recibir una respuesta 304 Not Modified sin descargar el cuerpo. Es una petición muy barata: casi no consume el límite y a la vez actualiza la información sobre la vigencia. Configúralo para todas las páginas estáticas o que cambian poco. Pero el encabezado debe ser honesto: si la fecha cambia en cada petición, el robot dejará de confiar en él.

Consolidación de contenido escaso

Diez páginas de cien palabras sobre temas cercanos son diez peticiones del robot y, probablemente, diez decisiones de «no indexar». Una página completa de mil palabras es una petición y una alta probabilidad de entrar al índice. Busca clústeres de páginas débiles: fichas de producto sin descripciones, noticias cortas, páginas de características individuales. Únelas, haciendo una redirección desde las direcciones antiguas hacia la nueva.

Lanzamiento controlado de páginas nuevas

Un error frecuente: publicar cien mil direcciones nuevas en un solo día. El robot verá el pico, pero su presupuesto no crecerá al instante. La cola se estirará durante meses y la prioridad de las páginas nuevas se distribuirá al azar. Mejor lanzar por oleadas: primero las secciones más valiosas, con enlaces directos desde los niveles superiores; luego las siguientes. Y de antemano, varias semanas antes, reforzar la infraestructura del servidor y el enlazado interno.

Consistencia de las señales

El robot se pierde cuando las señales se contradicen. La dirección canónica apunta a una página que redirige a una tercera. Las versiones de idioma se enlazan mal entre sí. El sitemap contiene direcciones con noindex. Cada contradicción son peticiones extra para aclarar y una pérdida de confianza en el sitio en general. Una vez por trimestre, haz una verificación de consistencia: todas las direcciones canónicas responden 200, todas apuntan a sí mismas, todos los enlaces dentro del sitio llevan a las versiones canónicas.

Checklist de arquitectura

  • Todas las páginas valiosas son accesibles en 3-4 clics desde la principal.
  • Las páginas nuevas reciben enlaces desde las secciones en las primeras 24 horas.
  • No hay páginas huérfanas entre las URLs comerciales.
  • Last-Modified y el soporte de peticiones condicionales están configurados y son correctos.
  • Los clústeres de páginas escasas están unidos o eliminados.
  • Las direcciones canónicas, las redirecciones y los atributos de idioma no se contradicen entre sí.
  • El lanzamiento de secciones nuevas se planifica por oleadas con preparación previa.

Método 4: Rendimiento, renderizado y monitoreo continuo de la indexación

El cuarto método tiene que ver con el techo técnico del presupuesto y con el sistema de control. Aquí el papel de los desarrolladores es especialmente grande, y a los marketers les conviene entender qué exigir exactamente.

Velocidad de respuesta para el robot

El límite de rastreo depende directamente de qué tan rápido responde el servidor al robot. La métrica clave es el tiempo hasta el primer byte. La práctica muestra: con respuestas estables por debajo de 300-500 milisegundos, el robot aumenta gradualmente la intensidad; con respuestas superiores a uno o dos segundos, la reduce. Ojo: importa la velocidad para el robot, no para el usuario con caché del navegador caliente. El robot suele solicitar páginas frías, por lo que el caché de HTML en servidor para peticiones no autenticadas da el mayor efecto. Verifica el tiempo de respuesta en los logs con filtro por robot, no en la analítica general.

Errores del servidor y códigos de sobrecarga

Las respuestas 5xx son la forma más rápida de derrumbar el presupuesto. Unos cientos de errores en una hora y el robot puede reducir la intensidad durante días. Si el servidor realmente está sobrecargado, lo correcto es devolver 503 o 429 con el encabezado Retry-After: es una señal clara de «vuelve más tarde» que no se percibe como una avería del sitio. Pero hay que usarla solo de forma temporal. Un problema aparte y traicionero: los sistemas de protección contra sobrecargas y actividad sospechosa que empiezan a bloquear al robot o a mostrarle una página de verificación. En los logs esto se ve como respuestas 403 o como un 200 con un código de captcha en lugar del contenido. Añade obligatoriamente los rangos oficiales de los robots de búsqueda a las excepciones de los sistemas de protección y verifica con regularidad que el robot vea precisamente tu contenido.

Renderizado sin sorpresas

Para los sitios en frameworks de JavaScript, el estándar de 2026 es el renderizado en servidor o la generación previa de HTML. El robot debe recibir en el código fuente todo el contenido crítico y todos los enlaces. Verifícalo con la herramienta de inspección de URL del panel para webmasters: compara el HTML renderizado con lo que ve el usuario. Si los enlaces a los productos aparecen solo tras ejecutar el script, el descubrimiento de páginas nuevas se retrasará semanas. Vigila también el tamaño del HTML: los robots limitan el volumen del documento descargado, y las páginas pesadas con megabytes de datos incrustados pueden procesarse de forma incompleta.

Crawlers de IA y competencia por el recurso

La nueva realidad: los bots que recolectan datos para modelos de lenguaje pueden generar decenas de por ciento de toda la carga automática. No traen tráfico de búsqueda directamente, pero ralentizan el servidor, y por eso baja el límite para los robots de búsqueda. La solución es evaluar la proporción de esos bots en los logs y decidir conscientemente a cuáles permitir el acceso y con qué intensidad. Algunos respetan las directivas estándar; para los demás se usan límites de frecuencia de peticiones a nivel de servidor. No es bloquear actividad útil, sino gestionar los recursos de tu infraestructura.

Sistema de monitoreo de la indexación

Una auditoría única queda obsoleta al mes. Hace falta un sistema. Así se construye paso a paso.

  1. Recolección diaria de métricas desde los logs. Número de peticiones de los robots, distribución por categorías de URL, proporción de errores, tiempo de respuesta medio. Se automatiza con un script que vuelca los datos a una tabla o base de datos.
  2. Control semanal de los estados en los paneles para webmasters. Dinámica del número de páginas indexadas, crecimiento de las excluidas, aparición de nuevos tipos de errores.
  3. Verificación de la presencia real en el índice. Los paneles muestran datos con retraso y no siempre completos. Para las páginas críticas —landings nuevas, productos, artículos— conviene verificar la presencia en los resultados directamente por la URL exacta o por un fragmento único de texto. En las verificaciones masivas, los buscadores empiezan rápidamente a mostrar captcha desde una sola dirección IP. Aquí vienen al rescate los proxies móviles con rotación: las peticiones se distribuyen entre direcciones de operadores de telefonía reales, lo que permite recolectar datos de forma estable y en un volumen acorde al tamaño de tu sitio. Además, a través de un proxy de una región concreta puedes ver los resultados tal como los ven los usuarios de esa región, algo crítico para sitios con vinculación regional.
  4. Verificación de la disponibilidad del sitio para los bots desde distintas redes. Solicita periódicamente las páginas clave desde direcciones IP externas, incluidas redes móviles, para asegurarte de que los sistemas de protección no devuelven captcha o bloqueo en lugar del contenido. Es una verificación sencilla a través de proxy que detecta problemas antes de que se reflejen en las estadísticas de rastreo.
  5. Alertas. Configura alertas ante un aumento brusco de errores al robot, una caída del número de peticiones superior al 30 por ciento en un día, la aparición de nuevos patrones de URL en los logs. La reacción temprana ahorra semanas de recuperación.

Este circuito de monitoreo convierte la gestión del crawl budget de una acción puntual en un proceso constante. Y es la única forma de mantener el resultado.

Errores típicos que queman el crawl budget

Reunamos en un solo lugar lo que no hay que hacer. Cada uno de estos puntos lo encontramos en proyectos reales, y casi cada uno les costó a sus dueños meses de visibilidad perdida.

  • Envíos forzosos masivos a recrawl. Las herramientas de solicitud de indexación están pensadas para páginas importantes puntuales. Enviar miles de URLs al día mediante scripts no aumenta el presupuesto, sino que acostumbra al sistema a ignorar tus solicitudes. Envía solo lo que realmente cambió y es importante.
  • Apoyarse en noindex como forma de ahorro. Ya lo dijimos: el robot viene igual. Si la tarea es no gastar peticiones, hay que quitar enlaces o bloquear el rastreo, no prohibir la indexación.
  • Ignorar los bots falsos al analizar. Sin verificar la IP, analizas una mezcla del robot real y de los scrapers de la competencia. Las conclusiones serán erróneas.
  • Páginas de filtros abiertas «por si acaso». El argumento «y si alguien busca por esto» lleva a millones de combinaciones rastreadas. Abre solo donde la demanda esté demostrada.
  • Cambio brusco de la estructura de URLs sin plan. Mudar todo el sitio a direcciones nuevas a la vez es duplicar la cola: el robot debe rastrear tanto las redirecciones antiguas como las páginas nuevas. Planifica por secciones.
  • Servidor lento «solo para los bots». Los usuarios reciben páginas cacheadas, y el robot, generación en frío con consultas a la base de datos. Ve un sitio lento y reduce el límite.
  • Protección anti-DDoS que bloquea a los robots de búsqueda. Clásico: tras conectar el servicio de protección, la indexación se detuvo y en los logs hay puros 403 para el robot. Los rangos de los robots deben estar en la lista blanca.
  • Contenido y enlaces solo a través de JavaScript. El robot los verá con retraso o no los verá. Los elementos críticos deben estar en el HTML inicial.
  • Autogeneración de miles de páginas «para las consultas». Las páginas plantilladas sin valor único no solo no se indexan, sino que arrastran hacia abajo la evaluación de todo el sitio. El presupuesto se gasta y el resultado es negativo.
  • Ausencia de monitoreo tras las correcciones. Hicimos la auditoría, corregimos, olvidamos. Medio año después, un nuevo release añadió un parámetro en la URL y todo se repitió. El control debe ser continuo.
  • Sustituir la actualización real por una ficticia. Cambiar la fecha, reordenar párrafos, añadir bloques vacíos por «frescura». El sistema lo detecta y reduce la prioridad en lugar de aumentarla.

Si reconociste en esta lista al menos tres puntos de tu proyecto, no estás solo. Según nuestras observaciones, la tienda online media tiene cinco o seis de estos problemas a la vez. La buena noticia es que todos son solucionables.

Herramientas y recursos para trabajar con la indexación

El instrumental correcto reduce la auditoría de semanas a días. Lo dividimos por tareas.

Paneles para webmasters

Google Search Console y Яндекс Вебмастер son la base obligatoria. En la primera son críticamente importantes el informe de indexación de páginas con desglose por causas de exclusión, el informe de estadísticas de rastreo con datos por host, códigos de respuesta y tipos de archivo, así como la herramienta de inspección de URL con posibilidad de ver el HTML renderizado. En la segunda, las secciones de indexación con historial de recorrido, estadísticas de recorrido, diagnóstico del sitio y la herramienta de recrawl con cuota diaria. Ambas fuentes dan datos agregados con retraso, por lo que se usan como orientación, no como única fuente.

Analizadores de logs

  • Screaming Frog Log File Analyser: herramienta de escritorio cómoda para volúmenes medios: importación de logs, verificación de robots, cotejo con los datos del crawler.
  • GoAccess: analizador ligero para un resumen rápido directamente en el servidor.
  • Stack basado en ClickHouse o Elasticsearch con visualización: solución para grandes proyectos con millones de líneas al día. Permite construir dashboards y alertas en tiempo real.
  • Scripts propios en Python con bibliotecas para procesar logs y pandas para la agregación: la variante más flexible para desarrolladores.

Crawlers para auditar la estructura

Screaming Frog SEO Spider, Sitebulb, Netpeak Spider y soluciones en la nube para sitios grandes. La tarea es obtener la lista completa de URLs del sitio con profundidad de clics, códigos de estado, direcciones canónicas, redirecciones y enlaces internos. Cotejar esta lista con los logs da la matriz de cuatro cuadrantes. Opción importante: el modo de rastreo con ejecución de JavaScript para compararlo con el modo normal. La diferencia muestra lo que el robot verá con retraso.

Verificación de rendimiento

Lighthouse y PageSpeed Insights para el panorama general, pero para el crawl budget importan más las métricas del servidor: tiempo hasta el primer byte en los logs con filtro por robot, monitoreo de disponibilidad desde varios puntos, pruebas de carga antes de lanzamientos grandes.

Monitoreo de la presencia en el índice y de los resultados regionales

Para la verificación masiva de indexación y posiciones se usan scripts propios o servicios SERP. En ambos casos, el volumen de peticiones a los buscadores es considerable, y desde una sola dirección rápidamente chocan con el captcha. Los proxies móviles con rotación de IP resuelven esta tarea: las peticiones salen desde direcciones de operadores móviles reales, se distribuyen por un pool, y el targeting por región permite ver los resultados con los ojos de un usuario de la ciudad deseada. Esto es especialmente importante para proyectos con subdominios regionales y para arbitrajistas que monitorean la indexación de decenas de landing pages a la vez. La misma herramienta ayuda a verificar cómo responde el sitio a los usuarios de redes móviles y si la protección bloquea tráfico legítimo.

Notificaciones a los buscadores

El protocolo IndexNow permite informar al instante sobre páginas nuevas y modificadas a los sistemas que lo soportan, incluido Yandex. No aumenta el presupuesto, pero ayuda al robot a priorizar y no gastar peticiones en reverificar páginas sin cambios. Úsalo para cambios reales, no para enviar todo el sitio en masa.

Casos: cómo la gestión del presupuesto cambia la indexación en la práctica

La teoría convence, las cifras demuestran. Tres casos de la práctica con datos anonimizados.

Caso 1: tienda online de electrónica, 180 mil productos

Problema. Los productos nuevos aparecían en el índice entre 18 y 25 días después de publicarse. En el índice había unas 70 mil páginas con 180 mil productos. El panel para webmasters mostraba 2,3 millones de URLs en estado «descubierta, sin indexar».

Diagnóstico. La auditoría de logs de 45 días mostró: el robot hacía unas 95 mil peticiones al día. De ellas, el 61 por ciento correspondía a URLs con parámetros de ordenación y filtros, el 12 por ciento a paginación más allá de la décima página, el 8 por ciento a redirecciones desde direcciones antiguas tras una mudanza de dos años atrás. Las fichas de producto representaban el 14 por ciento.

Acciones. Los enlaces a ordenaciones y conmutadores de vista se reemplazaron por elementos sin URL. Se dejaron abiertas 340 páginas de filtro con demanda demostrada; las demás recibieron la dirección canónica de la categoría. La paginación se limitó a 30 páginas con la adición de recopilaciones por etiquetas para acceder a productos profundos. Las cadenas de redirecciones se colapsaron a un solo paso y los enlaces internos se actualizaron a las direcciones finales. Se activó la entrega de 304 para páginas sin cambios.

Resultado a las 8 semanas. El número total de peticiones del robot casi no cambió: unas 100 mil al día. Pero la proporción de fichas de producto creció del 14 al 58 por ciento. Los productos nuevos empezaron a entrar al índice en 2-4 días. El número de páginas indexadas creció hasta 152 mil. El tráfico orgánico a las fichas aumentó un 34 por ciento en el trimestre sin un solo enlace externo nuevo. Lo sorprendente: la carga del servidor bajó, porque el robot dejó de generar pesadas consultas de filtros a la base de datos.

Caso 2: red de 40 sitios para arbitraje de tráfico

Problema. El dueño lanzaba landing pages para campañas en varias decenas de dominios. Parte de las landings se indexaba en un día, parte no se indexaba en semanas, y era imposible predecirlo. La verificación manual de la indexación tomaba horas y chocaba constantemente con el captcha.

Diagnóstico. Los logs mostraron que en los dominios jóvenes el robot hacía 20-40 peticiones al día, y la mitad se iba en páginas de servicio de la plantilla: políticas, formularios, páginas de agradecimiento, que se duplicaban en cada landing. Además, el servicio de protección en un tercio de los dominios devolvía al robot una página de verificación en lugar del contenido.

Acciones. Las páginas de servicio de la plantilla se quitaron de la navegación y se bloquearon al rastreo. Los rangos de los robots se incluyeron en las excepciones de la protección. Las landings nuevas empezaron a recibir un enlace desde la página principal del dominio en el momento de la publicación, y la notificación de la página nueva se enviaba vía IndexNow. El monitoreo de la indexación se automatizó: un script diario verifica la presencia de cada landing en los resultados a través de un pool de proxies móviles con rotación, sin captchas y con verificación regional para cada campaña.

Resultado. El tiempo mediano de entrada de la landing al índice se redujo de 9 días a 1,5 días. La proporción de páginas no indexadas en una semana cayó del 38 al 4 por ciento. El tiempo de control de la indexación se redujo de varias horas al día a cero trabajo manual: el informe llega automáticamente.

Caso 3: portal de medios en framework de JavaScript, 400 mil artículos

Problema. Tras pasarse al renderizado de cliente, los artículos nuevos aparecían en el índice con un retraso de 3-7 días, y para un recurso de noticias eso es una catástrofe. El panel mostraba crecimiento del número de páginas en estado «rastreada, sin indexar».

Diagnóstico. La inspección de URL mostró que el HTML inicial contenía solo el esqueleto; todo el texto y los enlaces a materiales relacionados se cargaban por script. El robot recibía la página, la ponía en la cola de renderizado y solo días después veía el contenido. Los enlaces a artículos nuevos desde el feed también aparecían solo tras el renderizado, por lo que el descubrimiento se retrasaba. Además, los logs mostraron que los crawlers de IA generaban el 44 por ciento de toda la carga automática, y el tiempo de respuesta al robot de búsqueda en horas pico superaba los 2,5 segundos.

Acciones. Se implementó renderizado en servidor para las páginas de artículos y feeds; el contenido crítico y los enlaces se pasaron al HTML inicial. Para los crawlers de IA se establecieron límites de frecuencia de peticiones a nivel de servidor. Se configuró una capa aparte de caché de HTML para peticiones no autenticadas. Se implementó un bloque de últimos materiales en la principal con enlaces directos.

Resultado a las 6 semanas. El tiempo de respuesta al robot bajó a 280 milisegundos en promedio. El número de peticiones del robot de búsqueda creció 2,1 veces: el límite subió junto con la velocidad. Los artículos nuevos empezaron a indexarse en 20-60 minutos. El número de páginas «rastreada, sin indexar» se redujo un 71 por ciento. Asombra cuánto efecto dio una solución técnicamente tan simple: entregar el contenido en HTML.

FAQ: preguntas complejas sobre la indexación web y el crawl budget

¿Cómo saber si realmente tengo un problema de crawl budget y no de calidad del contenido?

Mira los estados. Si predomina «descubierta, sin indexar», el robot no llega a las páginas: es presupuesto y prioridad. Si predomina «rastreada, sin indexar», el robot llegó pero la rechazó: es calidad o duplicación. A menudo hay ambos problemas, y entonces resolver el primero agudiza el segundo: el presupuesto liberado se gasta en páginas que igual no se indexarán. Trabaja en paralelo: limpia las fugas y a la vez mejora o consolida el contenido débil.

¿Se puede aumentar el crawl budget directamente pidiéndoselo al buscador?

No. No existen herramientas de aumento manual del límite, y las configuraciones de velocidad de rastreo que existían se eliminaron. El presupuesto crece solo por dos canales: un servidor rápido y estable eleva el límite técnico, y el aumento del valor y la actualización del contenido junto con la masa de enlaces eleva la demanda. Todo lo demás es gestionar la distribución del recurso ya existente.

¿Cuánto tiempo pasa entre las correcciones y el cambio de comportamiento del robot?

Los primeros cambios en los logs se ven a los 7-14 días: el robot empieza a solicitar menos los patrones eliminados. La redistribución estable toma de 4 a 8 semanas. El olvido completo de los conjuntos de URLs antiguas toma meses, a veces más de un año: el robot vuelve periódicamente a comprobar si reaparecieron. No esperes un efecto instantáneo ni reviertas los cambios a la semana.

¿Influyen los crawlers de IA en la indexación en los buscadores?

Directamente, no: los robots de búsqueda tienen su propio presupuesto independiente. Indirectamente, sí. Si los bots de IA generan una carga que hace que el servidor responda más lento al robot de búsqueda, el límite de rastreo baja. La solución no es bloquear todo, sino gestionar: evalúa la proporción de cada bot en los logs, limita la frecuencia de peticiones de los que no aportan valor y vigila el tiempo de respuesta al robot de búsqueda por separado.

¿Conviene eliminar del índice las páginas con poco tráfico para liberar presupuesto?

Solo tras analizarlo. Una página sin tráfico puede ser parte de un clúster, sostener con enlaces a otras páginas o tener valor de conversión por visitas directas. El criterio de eliminación no es el tráfico en sí, sino la ausencia de valor único: duplicados, fichas vacías obsoletas, páginas plantilladas escasas. Es mejor unirlas con una redirección o eliminarlas con código 410. La eliminación masiva de «todo lo que no trae tráfico» suele perjudicar más de lo que ayuda.

¿Cómo verificar correctamente la indexación de miles de páginas sin recibir un bloqueo por captcha?

Distribuye las peticiones en el tiempo y entre direcciones IP. La verificación desde una sola dirección choca con el captcha tras unas decenas de peticiones. Los proxies móviles con rotación resuelven esta tarea de forma técnicamente correcta: cada petición sale desde una dirección de un operador móvil real, lo que corresponde al comportamiento normal de un usuario. Añade pausas entre peticiones, rotación de encabezados y verifica solo las páginas realmente importantes, no todo el sitio a diario. Para el panorama completo, combina verificaciones directas con los datos de los paneles para webmasters.

¿Por qué en el panel para webmasters el número de páginas rastreadas crece y el de indexadas baja?

Signo clásico de fuga: el robot descubrió una nueva fuente de URLs basura y la rastrea activamente, pero esas páginas no superan la indexación. Busca en los logs nuevos patrones de direcciones aparecidos en las últimas semanas: a menudo son resultado de un release con un nuevo parámetro, la activación de un widget nuevo o un error en la plantilla de enlaces. Cuanto antes encuentres la fuente, menos tendrás que limpiar.

¿Hay que hacer algo en un sitio pequeño de 500 páginas?

Los problemas absolutos de presupuesto no te amenazan, pero las proporciones importan también aquí. Si de 500 páginas, 300 son duplicados técnicos y direcciones de servicio, el robot en un dominio joven con un presupuesto de unas decenas de peticiones al día gastará la mayor parte en ellas. Haz una verificación básica: un contenido, una dirección; sin cadenas de redirecciones; sin enlaces a 404; servidor rápido; enlaces a páginas nuevas desde la principal. Con eso basta para que la indexación web funcione de forma predecible.

¿Cómo saber si el robot ve mi contenido y no la página de verificación del servicio de protección?

Tres formas. Primera: la herramienta de inspección de URL del panel para webmasters muestra exactamente qué recibió el robot. Segunda: los logs: mira los códigos de respuesta y el tamaño de la respuesta al robot. Si el tamaño es sospechosamente igual y pequeño para páginas distintas, probablemente se entrega una página en blanco. Tercera: solicita tus páginas desde direcciones externas de distintas redes, incluidas las móviles, a través de proxy: si la protección se activa con ellas, hay riesgo de que también se active con el robot. Los rangos de los robots de búsqueda deben estar en la lista blanca de cualquier sistema de protección.

Conclusión: el crawl budget como recurso gestionable

Resumamos. La indexación web no es un evento, sino un proceso con un recurso limitado. El robot de búsqueda viene a tu sitio con un límite determinado de peticiones, y en qué las gasta determina qué páginas aparecerán en los resultados y con qué rapidez. Ese límite se compone de la potencia técnica del servidor y del interés del buscador en tu contenido. Ambos componentes se pueden captar, medir y desarrollar.

Analizamos cuatro métodos que juntos forman un ciclo completo. La auditoría de logs da el panorama objetivo: adónde va realmente el robot y dónde se fuga el presupuesto. Eliminar a los devoradores —facetas, parámetros, duplicados, redirecciones, 404 suaves— libera el recurso. La arquitectura y las señales de prioridad dirigen el recurso liberado hacia las páginas valiosas mediante la profundidad de clics, el enlazado interno y la frescura honesta. El rendimiento y el monitoreo elevan el techo técnico y evitan que los problemas vuelvan. Los casos mostraron que, con un número invariable de peticiones del robot, se puede multiplicar por cuatro la proporción de rastreos útiles y reducir el tiempo de indexación de páginas nuevas de semanas a horas.

¿Qué hacer a continuación? Proponemos un plan concreto para el primer mes.

  1. Semana 1. Descarga los logs de 30-60 días, filtra los robots confirmados, clasifica las URLs y construye la matriz de cuatro cuadrantes. En paralelo, toma las métricas actuales de los paneles para webmasters como punto de partida.
  2. Semana 2. Elimina las fugas simples: cadenas de redirecciones, enlaces internos rotos, duplicados técnicos de direcciones. Añade los rangos de los robots a la lista blanca de la protección. Verifica el tiempo de respuesta al robot y configura el caché de HTML.
  3. Semana 3. Ocúpate de los parámetros y las facetas: determina las combinaciones valiosas y bloquea las demás para que no aparezcan en enlaces. Limita la paginación y los espacios infinitos. Verifica que el contenido crítico y los enlaces estén presentes en el HTML inicial.
  4. Semana 4. Refuerza la arquitectura: reduce la profundidad de clics para las páginas valiosas, añade bloques de enlazado interno y de novedades, configura Last-Modified y las respuestas 304. Lanza el monitoreo automático: métricas diarias de los logs, estados semanales de los paneles, verificación de la presencia de las páginas clave en el índice a través de un pool de proxies móviles con targeting regional.

Ocho semanas después del inicio, compara los logs con el punto de partida. Si la proporción de páginas valiosas en las peticiones del robot creció y el tiempo de entrada de las páginas nuevas al índice se redujo, el sistema funciona. Si no, vuelve a la matriz de cuadrantes: casi siempre aparecerá una fuente de fuga no considerada.

El crawl budget es un ejemplo poco común de recurso en SEO que está totalmente bajo tu control. No puedes obligar al buscador a amar tu sitio. Pero puedes lograr que cada una de sus visitas se gaste con el máximo provecho. En 2026, cuando el índice se volvió selectivo y la competencia por la atención del robot creció, esto ya no es higiene técnica, sino ventaja competitiva. Guarda esta guía, vuelve a los checklists dentro de un trimestre y asegúrate de que tu inspector pase el tiempo en las salas de venta, y no en los depósitos.