Crawl budget: por qué una redirección mal planteada puede costarte visibilidad en Google

Cuando una web cambia de estructura —una inmobiliaria que renueva su plataforma, una empresa que fusiona dos dominios, un catálogo que reorganiza sus categorías— casi siempre aparece la misma pregunta: “¿hacemos redirecciones y ya está?”. La respuesta corta es sí, pero la forma en que se hacen importa mucho más de lo que parece, y ahí es donde entra un concepto que rara vez se explica bien: el crawl budget.

Qué es el crawl budget, sin jerga

Google no rastrea una web de forma ilimitada. Le asigna un presupuesto de rastreo — un número aproximado de páginas que va a visitar en un periodo de tiempo, en función del tamaño del sitio, su velocidad de respuesta y la calidad histórica de lo que encuentra. Para una web pequeña de pocas páginas, esto casi nunca es un problema real. Pero en migraciones, catálogos grandes o sitios con años de historial (URLs antiguas, parámetros, versiones de idioma), gastar ese presupuesto en las páginas equivocadas tiene un coste directo: contenido nuevo o corregido que tarda más en indexarse, o que directamente Google deja de visitar con la frecuencia necesaria.

Por qué las redirecciones son donde más se desperdicia

En varios proyectos de redirecciones que hemos llevado, el patrón de error se repite con pocas variaciones:

Cadenas de redirección. Una URL antigua redirige a otra URL que a su vez redirige a la definitiva. Cada salto adicional consume presupuesto de rastreo y diluye la señal de relevancia que se transmite en un 301. Lo correcto es que cada URL antigua apunte directamente a su destino final, sin pasos intermedios.

Redirigir todo a la home “por si acaso”. Cuando no se sabe bien dónde debería ir cada URL antigua, la solución fácil es mandarlo todo a la página principal. Google interpreta esto como una señal de baja calidad — no es una redirección real, es un parche — y con el tiempo puede dejar de dar valor SEO a esas URLs heredadas.

Dejar URLs antiguas huérfanas pero rastreables. Es habitual migrar el contenido visible pero olvidar que las URLs antiguas siguen siendo accesibles (y a veces todavía enlazadas desde algún sitio externo, un backlink antiguo o una entrada de blog de hace años). Si no llevan redirección ni noindex, Google sigue gastando presupuesto en visitarlas sin ningún propósito.

No actualizar el sitemap tras la migración. Un sitemap que sigue listando URLs antiguas, ya redirigidas, manda una señal confusa: le estás diciendo a Google que rastree algo que tú mismo ya has movido.

Cuándo esto importa de verdad

No todos los proyectos necesitan este nivel de cuidado. Una web pequeña con pocas páginas y sin historial largo no tiene un problema real de presupuesto de rastreo — Google la visita entera sin esfuerzo. Donde sí importa, y mucho, es en:

• Migraciones de plataforma (cambio de CMS, de dominio, o ambos a la vez).
• Catálogos grandes con muchas URLs históricas — listados de propiedades vendidas o retiradas, por ejemplo, es un caso muy habitual en inmobiliarias con años de actividad.
• Sitios multiidioma, donde cada versión multiplica el número de URLs a gestionar.

Un checklist mínimo para cualquier proyecto de redirecciones

• Mapear cada URL antigua a su destino final real, sin cadenas intermedias.
• Usar 301 (permanente) solo cuando el cambio es definitivo; 302 si es temporal.
• Revisar backlinks externos hacia URLs antiguas antes de dar la migración por cerrada.
• Actualizar el sitemap para que solo liste URLs vivas.
• Monitorizar en Search Console, durante las semanas posteriores, los errores de rastreo y las URLs “descubiertas pero no indexadas”.

---

Si estás valorando una migración o un cambio de plataforma y quieres que las redirecciones se planteen bien desde el principio, es exactamente el tipo de trabajo que entra dentro de un SEO Foundation Project.