Redirecciones 301: cadenas, bucles y cuándo no redirigir

Respuesta breve

Una redirección 301 declara que una URL se ha movido de forma permanente a otra que resuelve la misma tarea. Funciona bien cuando el destino es equivalente, la regla es directa y nadie vuelve a encadenarla. Falla cuando se usa para tapar contenido eliminado, cuando acumula saltos intermedios o cuando forma un bucle. Y hay casos en los que la respuesta correcta no es redirigir, sino devolver 404 o 410.

Puntos clave

• Elige el código por lo que ha pasado de verdad: permanente, temporal o recurso retirado.
• Una cadena funciona en el navegador y por eso sobrevive a las revisiones manuales.
• Un bucle es una incidencia de servicio: la página deja de ser accesible.
• Redirigir todo a la portada equivale a esconder un 404, no a resolverlo.
• Los enlaces internos deben apuntar al destino final, no apoyarse en la redirección.
• Las reglas se prueban con la lista completa de orígenes, no con una muestra.

El código, por lo que ha pasado de verdad

301

Traslado definitivo a una URL que resuelve la misma tarea.

302

Provisional: la URL original va a volver.

404 o 410

No hay equivalente. Es información, no un defecto que tapar.

Cadena o bucle

Funciona en el navegador y por eso sobrevive: se detecta con la lista completa de orígenes.

Qué código corresponde a cada situación

El código de estado es una afirmación sobre el recurso, no una preferencia de estilo. Elegirlo mal genera trabajo posterior porque obliga a revisar decisiones que ya se habían tomado.

Qué código de respuesta corresponde a cada situación, y por qué.

Situación	Respuesta	Motivo
La URL se ha movido y no volverá	301 o 308	traslado permanente con destino equivalente
Cambio provisional, la original volverá	302 o 307	no consolida el destino como definitivo
Contenido eliminado sin sustituto	404 o 410	informa del estado real del recurso
Producto agotado que volverá al catálogo	200	la página sigue resolviendo una tarea
Página duplicada que debe seguir accesible	200 con canonical	ambas versiones tienen función distinta
Acceso restringido por sesión o rol	401 o 403	no es un traslado

La diferencia entre 404 y 410 es de intención declarada: el segundo afirma que la retirada es deliberada. Ninguno de los dos es un error de configuración por sí mismo; un sitio sano tiene 404 para lo que nunca existió y lo que se retiró conscientemente. El caso del catálogo tiene matices propios que están desarrollados en el artículo sobre productos agotados o descatalogados.

Qué es una cadena y por qué molesta

Una cadena aparece cuando el destino de una redirección es, a su vez, origen de otra. Se forma sola con el tiempo: cada rediseño añade una capa de reglas sin revisar las anteriores —motivo de peso para levantar la auditoría técnica previa al rediseño—, y al cabo de unos años una URL antigua puede recorrer varios saltos antes de llegar a su destino real.

El problema práctico es doble. Por un lado, cada salto es una petición adicional que el usuario paga en tiempo de espera, especialmente en conexiones móviles. Por otro, cada salto es una oportunidad de que algo se rompa: si un eslabón intermedio deja de existir, la cadena entera se convierte en un error aunque el destino final siga vivo.

Las cadenas son invisibles en las comprobaciones habituales porque el navegador las sigue en silencio y muestra la página final. Solo aparecen cuando se lee la secuencia de cabeceras completa, o cuando un rastreo las clasifica explícitamente. Esa es la razón por la que se detectan tarde.

Cómo detectar cadenas y bucles

La detección necesita una lista de orígenes y una herramienta que no siga las redirecciones automáticamente, o que registre cada salto. Lo que se busca es siempre lo mismo: cuántos saltos hay, si el destino final responde 200 y si alguna URL aparece dos veces en la misma secuencia.

• parte del inventario de URLs históricas, no solo de las que hoy están enlazadas;
• registra la secuencia completa de cada petición, con el código de cada salto;
• marca como incidencia cualquier secuencia con más de un salto;
• marca como bloqueante cualquier secuencia que repita una URL: es un bucle;
• revisa también el comportamiento con y sin barra final, y con y sin www;
• comprueba la combinación de esquema y host, donde suelen aparecer saltos redundantes;
• repite la comprobación desde fuera de la red, para que responda el CDN y no el origen.

El bucle merece atención inmediata porque no degrada el servicio: lo interrumpe. El navegador aborta tras un número de saltos y el usuario ve el error de demasiadas redirecciones (en Chrome, ERR_TOO_MANY_REDIRECTS). Los bucles más habituales nacen de dos reglas que se contradicen, por ejemplo una que fuerza la barra final y otra que la elimina, o una regla de idioma que reenvía a una versión que a su vez reenvía a la original.

El orden de las reglas importa

En la mayoría de servidores, las reglas se evalúan en orden y la primera que coincide gana. Una regla amplia colocada antes que una específica impide que la específica llegue a aplicarse nunca. El síntoma es desconcertante: la regla existe, está bien escrita y no funciona.

Conviene ordenar de lo más específico a lo más general y documentar por qué cada bloque está donde está. En despliegues donde conviven redirecciones del servidor y redirecciones de un plugin o de la aplicación, hay que decidir cuál manda y evitar que ambos actúen sobre la misma ruta: cuando las dos capas redirigen, el resultado típico es una cadena que nadie escribió a propósito.

Los parámetros de URL son otro punto de fricción. Una regla que reescribe la ruta puede descartar la cadena de consulta sin que sea evidente, y con ella se pierden los parámetros de campaña que la analítica necesita. Si el destino debe conservarlos, hay que decirlo explícitamente en la regla y comprobarlo con una petición real.

Una regla amplia colocada antes que una específica impide que la específica llegue a aplicarse nunca.

Cuándo no hay que redirigir

La redirección se ha convertido en respuesta por defecto ante cualquier URL que ya no sirve, y no siempre es la correcta. Estos son los casos en los que conviene no hacerlo:

• No existe destino equivalente. Redirigir a la portada o a la categoría padre no resuelve la tarea del usuario. Un 404 con buena navegación es más honesto y más útil.
• El contenido se retiró a propósito. Un 410 comunica que la retirada es deliberada. Google trata igual el 404 y el 410, así que la elección es de claridad, no de rapidez.
• Las dos páginas deben seguir accesibles. Si ambas versiones tienen usuarios, la herramienta es el canonical, no la redirección; el artículo sobre errores de canonical distingue ambos casos.
• El cambio es temporal. Un mantenimiento o una promoción piden 302 o 307, no 301.
• Se trata de contenido similar pero no equivalente. Consolidar dos páginas puede ser correcto, pero entonces hay que fusionar el contenido de verdad, según el criterio de cuándo actualizar, fusionar o retirar contenido.
• La URL nunca existió. Los enlaces mal escritos que llegan desde fuera no justifican inventar reglas: producen mantenimiento perpetuo.

Redirecciones que no son de servidor

Existen alternativas cuando no hay acceso a la configuración del servidor, y no son equivalentes entre sí. La documentación de Google sobre redirecciones ordena las opciones y reserva las de JavaScript para cuando no es posible usar una redirección de servidor ni un meta refresh.

El motivo es de fiabilidad. Una redirección de servidor se resuelve en la respuesta HTTP y no depende de nada más. Un meta refresh exige que el HTML se descargue y se procese. Una redirección en JavaScript exige además que el script se descargue, se ejecute y no falle. Cada capa añadida es una condición más que puede no cumplirse.

Esto no significa que las redirecciones de cliente sean inútiles, sino que son un recurso para situaciones concretas, no la base de una arquitectura. Si un proyecto entero depende de redirecciones en JavaScript, el problema está en la falta de acceso al servidor y ahí es donde conviene actuar.

Mantenimiento a lo largo del tiempo

Un fichero de redirecciones es código, y envejece como el código. Sin mantenimiento se convierte en una capa que nadie entiende y que nadie se atreve a tocar, lo que a su vez garantiza que siga creciendo.

1. guarda las reglas en control de versiones, con un comentario que diga qué migración las originó;
2. cada vez que añadas reglas, revisa si alguna de las nuevas apunta a un origen ya redirigido;
3. ejecuta la comprobación de cadenas y bucles como parte del despliegue, no como revisión anual;
4. actualiza los enlaces internos al destino final para que la regla deje de recibir tráfico interno;
5. mide qué reglas siguen recibiendo peticiones usando los logs antes de retirar ninguna;
6. retira solo lo que lleve tiempo sin uso, y guarda constancia de qué se retiró.

La regla de decisión para retirar es sencilla: mientras una redirección siga recibiendo peticiones de personas o de rastreadores, sigue haciendo un trabajo. Eliminarla por antigüedad convierte en 404 lo que aún era útil, y eso reaparece semanas después como un problema que cuesta relacionar con su causa.

En cuatro láminas

curl -sI https://seonidas.com/blog. HTTP/1.1 301 / location: https://seonidas.com/blog/. Leído el 28 de septiembre de 2026.

shell: $ curl -sIL http://ejemplo.es/pagina / HTTP/1.1 301 / location: https://ejemplo.es/pagina / HTTP/1.1 301 / location: https://ejemplo.es/pagina/ / HTTP/1.1 200 / / # tres peticiones para llegar

0 saltos intermedios. El destino final se conoce y se escribe directamente; los enlaces internos apuntan a él, no a la redirección.

Errores frecuentes

• Usar 302 para un traslado definitivo o 301 para uno provisional.
• Redirigir en masa a la portada lo que no tiene equivalente.
• Apilar reglas nuevas sobre las antiguas sin reescribir los destinos intermedios.
• Colocar una regla general antes que las específicas y dar por rota la específica.
• Dejar activas a la vez la redirección del servidor y la del plugin sobre la misma ruta.
• Perder la cadena de consulta y con ella los parámetros de campaña.
• Comprobar solo desde dentro de la red, sin pasar por el CDN.
• Mantener enlaces internos hacia URLs redirigidas de forma indefinida.
• Tratar cualquier 404 como un defecto que hay que tapar.
• No versionar el fichero de reglas ni documentar su origen.

Preguntas habituales

¿301 o 302?

El código se elige por lo que ha pasado de verdad, no por costumbre: 301 si el traslado es definitivo, 302 si es provisional y la URL original va a volver. Usar 302 para un cambio permanente mantiene viva una expectativa que ya no existe; usar 301 para algo temporal la hace difícil de revertir.

¿Puedo redirigir a la portada todo lo que he eliminado?

Equivale a esconder un 404, no a resolverlo: quien buscaba una página concreta aterriza en un sitio que no responde a su tarea. Cuando no hay equivalente, la respuesta correcta es 404 —o 410 si la retirada es definitiva—. Un 404 no es un defecto que haya que tapar: es información.

¿Cuántos saltos son demasiados en una cadena?

Cualquier salto intermedio evitable sobra, porque el destino final se conoce y se puede escribir directamente. El problema de las cadenas es que funcionan en el navegador, y por eso sobreviven a las revisiones manuales durante años, acumulando un salto más en cada migración hasta que alguien cierra el círculo y aparece el bucle.

¿Basta con comprobar las redirecciones desde mi ordenador?

No si hay un CDN delante. Comprobar solo desde dentro de la red deja fuera la capa que de verdad responde al visitante, que puede tener sus propias reglas o una copia antigua. Las reglas se prueban con la lista completa de orígenes y desde fuera, no con una muestra ni desde el origen.

Próximo paso

Toma la lista de URLs históricas del proyecto y ejecuta una comprobación que registre cada salto, no solo el destino final. Ordena el resultado por número de saltos y trata los bucles como incidencia inmediata. Con esa tabla delante, la conversación deja de ser sobre si hay muchas redirecciones y pasa a ser sobre cuáles siguen resolviendo una tarea real.

Fuentes

• Google Search Central, redirecciones y la Búsqueda — documentación oficial.
• Chromium, lista de errores de red: ERR_TOO_MANY_REDIRECTS (-310) — código.
• Google Search Central, consolidar URLs duplicadas — documentación oficial.
• Google, infraestructura de rastreo, cómo afectan los códigos de estado HTTP a los rastreadores de Google: «Todos los errores 4xx, salvo 429, se tratan del mismo modo» —documentación oficial.

Servicio relacionado

Si esto es lo que te está pasando, seo técnico es el trabajo que lo resuelve. Diagnóstico primero, prioridades después.

Ver seo técnico