Redirecciones: cadenas, bucles y cómo corregirlos

Una cadena de redirecciones se produce cuando una URL redirige a otra que también redirige: A va a B, y B va a C. Un bucle es cuando la secuencia vuelve a una URL por la que ya pasó (A va a B, y B vuelve a A) y nunca llega a una página. La corrección es la misma en los dos casos: cada URL antigua debe apuntar directamente al destino final, con una redirección permanente (301 o 308) en el servidor, y los enlaces internos del sitio deben usar la URL final. Googlebot sigue hasta 10 saltos, pero Google recomienda redirigir directamente al destino y, cuando no sea posible, mantener la cadena corta: preferiblemente hasta 3 saltos y menos de 5 (Google, traslado de sitio con cambios de URL).

Alcance: el comportamiento de Google descrito aquí sale de la documentación de Google Search Central consultada en octubre de 2026, y la semántica de los códigos HTTP sale de la RFC 9110. Para el proceso completo de rastreo e indexación, consulta la guía de rastreo e indexación.

Los tipos de redirección y cómo trata Google cada uno

Una redirección es la respuesta que le indica al navegador o al robot que busque otra URL. Las más comunes las hace el servidor, con un código 3xx y la cabecera Location indicando el destino.

Las fuentes de la tabla son la RFC 9110, sección 15.4, la página de Google sobre redirecciones y la Búsqueda de Google y la de códigos de estado HTTP.

La diferencia entre permanente y temporal se nota en la búsqueda. Con 301 o 308, Google muestra la URL de destino en los resultados. Con 302, 303 o 307, la URL de origen puede seguir apareciendo. Google recomienda la redirección permanente en el servidor cuando hay certeza de que no se va a deshacer, y la temporal para cambios cortos, como un servicio fuera de línea durante un tiempo.

Dos detalles de la RFC pesan en la práctica. Primero, las respuestas 301 y 308 pueden quedarse en la caché del navegador incluso sin una cabecera de caché explícita: un 301 equivocado sigue funcionando para quien ya visitó la página, aunque se haya corregido en el servidor. Por eso conviene probar la regla antes de publicarla y, en las pruebas, desactivar la caché del navegador. Segundo, el 308 es de 2014 y la propia RFC advierte que no todos los clientes HTTP lo reconocen. Para páginas normales, a las que se accede con GET, el 301 basta; el 308 importa cuando hay que conservar el método de la petición.

Meta refresh, JavaScript y redirección "cripto"

El meta refresh es una etiqueta del HTML:

<meta http-equiv="refresh" content="0; url=https://www.ejemplo.com/nuevo">

Con retraso 0, Google lo trata como permanente; con un retraso mayor, como temporal. Google solo ve la redirección por JavaScript si renderiza la página, y advierte que la renderización puede fallar. El orden de preferencia de la documentación es este: redirección en el servidor, meta refresh, JavaScript y, por último, lo que Google llama redirección "cripto", una página con un enlace y una explicación que apunta a la dirección nueva, y que Google puede entender o no como redirección.

Qué causan las cadenas y los bucles

En el rastreo

Por defecto, los rastreadores de Google siguen hasta 10 saltos de redirección. Se ignora el contenido de las URLs intermedias; solo se procesa el destino final (Google, códigos de estado HTTP). Cuando la cadena supera el límite, entra en bucle, contiene una URL vacía o no válida o una URL por encima del tamaño máximo, el informe Indexación de páginas de Search Console muestra "Error de redirección" para la URL (ayuda de Search Console).

Incluso dentro del límite, las cadenas tienen un coste. La guía del presupuesto de rastreo pide evitar las cadenas largas porque perjudican el rastreo. La misma página de estados HTTP dice que las herramientas de inspección de Google no siguen redirecciones, así que la URL que hay que inspeccionar es la final.

Para quien visita el sitio

Cada salto es una petición más antes de que la página empiece a cargarse. El tiempo de redirección forma parte del TTFB (tiempo hasta el primer byte), que web.dev considera bueno hasta 0,8 segundos (web.dev, tiempo hasta el primer byte). El TTFB, a su vez, es la primera de las cuatro partes del LCP, como explica el artículo sobre cómo mejorar el LCP. Una redirección ya añade latencia; una cadena añade más. La guía de migración de Google recuerda además que no todos los navegadores y agentes de usuario admiten cadenas largas.

Las redirecciones de otro origen, como los acortadores de enlaces y las plataformas de campañas, suelen estar fuera de tu control. web.dev recomienda que la URL que se entrega a anunciantes y newsletters ya sea la final (web.dev, optimizar el TTFB).

http, https, www y barra final: cadenas creadas por reglas separadas

Las variaciones de dirección generan cadenas sin que nadie se dé cuenta, porque cada regla se creó en un momento distinto. Un ejemplo:

http://ejemplo.com/producto
  301 → https://ejemplo.com/producto
  301 → https://www.ejemplo.com/producto
  301 → https://www.ejemplo.com/producto/

Son tres saltos para llegar a una página. Cada regla es correcta por separado; el problema es la suma. La corrección tiene dos partes:

1. Una regla única que lleve cualquier variación directamente a la forma canónica (https, con o sin www y con o sin barra final, según el estándar del sitio) en un solo salto.

2. Enlaces internos, etiquetas canónicas y sitemap escritos ya en la forma final, para que el navegador ni siquiera necesite la redirección.

web.dev señala la redirección de http a https como una fuente importante de tiempo de redirección. La cabecera HSTS resuelve parte del problema: después de recibirla por https, el navegador cambia por su cuenta http por https en las visitas siguientes, sin pasar por la redirección. En la primera visita la redirección sigue ocurriendo; la lista de precarga de HSTS cubre ese caso (MDN, Strict-Transport-Security). El artículo sobre cabeceras de seguridad HTTP trata la configuración. Por qué el HTTPS va primero se explica en seguridad básica de un sitio web.

Cómo mapear y corregir después de una migración

Los pasos siguientes siguen la guía de Google para el traslado de sitio con cambios de URL, con un paso más para las cadenas heredadas de migraciones anteriores.

1. Haz la lista de las URLs antiguas. Google sugiere reunir sitemaps, registros del servidor, datos de analítica y el propio CMS, incluidos imágenes, vídeos, CSS y JavaScript.

2. Crea el mapa de cada URL antigua a su equivalente nueva. El contenido que no pase al sitio nuevo debe responder 404 o 410.

3. Configura redirecciones permanentes (301 o 308) en el servidor, cada una apuntando directamente al destino final.

4. Aplana las cadenas heredadas. Si el sitio ya pasó por otras migraciones, puede haber reglas antiguas que apunten a URLs que ahora también redirigen. Cambia el destino de esas reglas por la URL final.

5. Actualiza lo que está bajo tu control: enlaces internos, rel="canonical" (cada URL nueva con una canónica que apunte a sí misma), anotaciones hreflang y sitemap con las URLs nuevas. Incluye las URLs que aparecen en los datos estructurados, como los elementos del BreadcrumbList. Google recuerda que las redirecciones son lentas para quien visita el sitio, y los enlaces actualizados evitan el salto.

6. Si cambias de dominio, envía el cambio de dirección en Search Console para todas las variantes verificadas del dominio antiguo, incluidos subdominios, www y sin www, aunque no las uses.

7. Prueba antes y después de publicar (siguiente sección) y sigue el informe Indexación de páginas, los registros y la analítica. Lo esperado es que el tráfico baje en la dirección antigua y suba en la nueva.

Cómo probar las redirecciones

En la línea de comandos, curl muestra cada salto:

curl -sIL https://ejemplo.com/producto

-I pide solo las cabeceras, -L sigue las redirecciones y -s oculta la barra de progreso. Cada bloque de la salida es un salto, con el código de estado y la cabecera location del siguiente destino. Algunos servidores responden de forma distinta a HEAD, que es lo que envía -I, y a GET. Para comprobar una lista de URLs con GET, una por línea en un archivo:

while read -r url; do
  curl -s -o /dev/null -L --max-redirs 10 \
    -w "%{http_code} %{num_redirects} $url %{url_effective}\n" "$url"
done < urls.txt

La salida muestra el estado final, el número de saltos, la URL probada y el destino. Cualquier línea con más de un salto es una cadena que hay que aplanar. En un bucle, curl se detiene en el límite de --max-redirs y termina con el código de salida 47 (demasiadas redirecciones).

En el navegador, la pestaña Red de las herramientas para desarrolladores muestra la secuencia si marcas la opción de conservar el registro y desactivas la caché, por la caché de los 301 y 308. Para el sitio completo, un rastreador de SEO enumera los enlaces internos que apuntan a URLs con redirección; cada uno se puede cambiar por la URL final. Para URLs sueltas, Google sugiere la Inspección de URLs de Search Console, con la salvedad de que no sigue la redirección: muestra que la URL redirige, y el destino hay que inspeccionarlo aparte.

Cómo revisar tu sitio

El verificador de redirecciones de WebVyze, una de las herramientas gratuitas, revisa los saltos de una URL sin necesidad de la terminal. Para saber lo que Google ha registrado realmente, la referencia sigue siendo el informe Indexación de páginas de Search Console.