301 vs 302: redirecciones, SEO y los errores que se quedan pegados

Qué ocurre realmente en una redirección

Cuando un navegador pide una URL y el servidor responde con un código 3xx y una cabecera Location, el navegador lanza en silencio una segunda petición a esa nueva dirección. El visitante solo ve el destino; el coste — un viaje de ida y vuelta extra — y la semántica viajan en el código de estado.

Un 301 dice que el recurso se mudó de forma permanente: los clientes deben ir a la nueva URL ahora y recordar saltarse la antigua la próxima vez. Un 302 dice que está temporalmente en otro sitio: ve allí ahora, pero vuelve a preguntar a la original en el futuro. Todo lo que importa de las redirecciones — SEO, caché, reversibilidad — se deriva de cuál de esas dos promesas hiciste.

Qué hacen los buscadores con cada uno

Ante un 301, los buscadores tratan la mudanza como un hecho editorial: las señales acumuladas de la URL antigua — enlaces, historial, posicionamiento — se transfieren a la nueva, y en las semanas siguientes la nueva URL sustituye a la antigua en los resultados. Por eso las migraciones de sitios, los cambios a HTTPS y los renombrados de slugs se hacen con 301: la reputación sigue al contenido.

Ante un 302, los buscadores hacen lo literal: mantienen indexada la URL antigua, porque les dijiste que el contenido volvería. Un 302 dejado en su sitio para una mudanza permanente es uno de los clásicos errores SEO silenciosos — todo funciona para los visitantes, pero la nueva URL no construye historial mientras la antigua envejece poco a poco. Si descubres uno, basta con cambiarlo a 301 para que empiece la transferencia; los buscadores gestionan la corrección sin problemas.

El error espejo también existe: un 301 usado para algo genuinamente temporal (una página de campaña, un test A/B) dice a los buscadores que desindexen la original — que es exactamente lo que no querías.

La parte que se aprende por las malas: los 301 se quedan pegados

Los navegadores tienen permiso para cachear un 301 sin caducidad — y varios hacen exactamente eso. La primera vez que el navegador de un visitante ve la redirección puede recordarla indefinidamente y no volver a preguntar nunca a la URL antigua. Arregla el servidor mañana y ese visitante seguirá aterrizando en la página equivocada, porque la redirección ahora vive en su navegador, fuera de tu alcance. No existe un botón de purga para los navegadores de otras personas.

Dos consecuencias prácticas. Primera: prueba una mudanza con un 302 y promuévela a 301 solo cuando estés seguro — el código temporal es el reversible. Segunda: pon un Cache-Control explícito en las redirecciones, porque una vida acotada convierte "pegado para siempre" en "pegado un día como mucho". En este sitio seguimos esa regla: nuestras redirecciones canónicas llevan Cache-Control: public, max-age=86400, así que incluso una redirección que cambiemos más tarde se corrige sola en un día para cada visitante y cada caché intermedia.

Una redirección con una vida acotada y cacheable

$ curl -sI https://cdn.com.tr/en/features/almacenamiento-objetos-s3 | grep -iE 'http|location|cache-control'
HTTP/2 301
location: https://cdn.com.tr/en/features/object-storage
cache-control: max-age=86400, public

Cadenas de redirecciones: el impuesto que pagas en cada clic

Las redirecciones se acumulan. La regla http→https añade un salto, la regla www otro, el slug renombrado un tercero — y ahora cada visitante paga tres viajes de ida y vuelta antes de que se mueva contenido alguno, mientras los buscadores diluyen un poco de señal en cada paso intermedio y dejan de seguir por completo las cadenas muy largas.

La solución no es evitar las redirecciones; es hacer que cada URL antigua apunte directamente al destino final. Cuando renombras una página que ya tenía una redirección apuntándole, actualiza también la regla ANTIGUA, para que ambas generaciones de URL vayan directas a la nueva dirección en un solo salto. Una auditoría ocasional es un comando por URL, y la forma que quieres ver es un único 301 seguido de un 200.

Sigue la cadena completa y cuenta los saltos

# -L follows redirects; print each hop's code and target
curl -sIL -o /dev/null -w '%{http_code} %{url_effective}\n' http://example.com/old-page

# see every hop explicitly (one line per response)
curl -sIL http://example.com/old-page | grep -iE '^HTTP|^location'

# healthy: HTTP/1.1 301 -> HTTP/2 200. unhealthy: 301 -> 301 -> 302 -> 200

Redirecciones en una CDN: dónde deberían vivir y cómo cachearlas

Una redirección servida por tu aplicación funciona, pero cuesta un viaje completo al origen para producir una cabecera que nunca cambia. Mover las redirecciones conocidas al edge — o dejar que el edge cachee las que emite tu aplicación — las responde cerca del visitante.

Aquí tienes las dos mitades disponibles. Las reglas de entrega pueden redirigir directamente en el edge (la redirección al sitio móvil es un ajuste de un solo campo en el panel), y desde una mejora reciente el edge también cachea los 301 y 302 de tu origen con vidas acotadas, de modo que los rastreos repetidos de una URL mudada dejan de llegar a tu aplicación por completo. La guía práctica: da a tus redirecciones un Cache-Control explícito como a cualquier otra respuesta, corto para los 302, hasta un día para los 301 — lo bastante largo para absorber el tráfico, lo bastante corto para sobrevivir a tus propios errores.

Elegir en cinco segundos

Renombraste una página, cambiaste de dominio, pasaste a HTTPS, consolidaste duplicados: 301, y actualiza las cadenas antiguas para que apunten directamente a la URL final. Página de campaña, desvío por mantenimiento, test A/B, división geográfica, cualquier cosa que piensas deshacer: 302. Aún no lo tienes claro: 302 primero — es el reversible — y promuévelo a 301 cuando la mudanza esté asentada.

Y la meta-regla que atrapa el resto: una redirección es una promesa sobre el futuro de una URL. Elige el código que corresponda a la promesa que de verdad puedes cumplir.