El resumen de cinco segundos

  • 301 (Moved Permanently): úsalo para movimientos permanentes. Transfiere la señal SEO al nuevo URL. El default para HTTP→HTTPS, www→non-www y migraciones de dominio.
  • 302 (Found / Moved Temporarily): úsalo para redirects genuinamente temporales. No transfiere señal SEO igual. Default para A/B testing, geo-redirects, flujos de login.
  • 307 (Temporary Redirect, estricto): como 302 pero preservando el método HTTP. Equivalente moderno.
  • 308 (Permanent Redirect, estricto): como 301 pero preservando el método HTTP. Equivalente moderno.

Para la mayoría de casos de contenido estático, 301 es lo que quieres. Para envíos de formularios y APIs, 308 es técnicamente correcto. La distinción importa más para APIs que para SEO; los buscadores tratan 308 como 301.

Por qué HTTP→HTTPS es el caso más común

Configuras SSL en tu dominio. Ahora tienes dos versiones de cada URL: http://example.com/page y https://example.com/page. Sin redirect, los buscadores pueden indexar ambas, tus páginas reciben señal partida, y los usuarios de enlaces HTTP directos ven el aviso "No seguro".

El arreglo es un redirect 301 de cada URL HTTP a su equivalente HTTPS. Configúralo en el servidor web, el CDN o la capa de aplicación — cualquiera vale.

Las cuatro variaciones a manejar

Para la mayoría de dominios hay cuatro variantes que deben converger en una forma canónica:

  1. http://example.com/page
  2. http://www.example.com/page
  3. https://example.com/page
  4. https://www.example.com/page

Elige una canónica (lo más común https://example.com o https://www.example.com — ambas válidas). Redirige las otras tres con 301.

Crítico: el redirect debe ir directo a la canónica, no por saltos intermedios. Evita la cadena "HTTP non-www → HTTP www → HTTPS www → HTTPS non-www" — cada salto pierde señal y añade latencia.

Anatomía de una cadena de redirect correcta

Para una canónica de https://example.com:

  • http://example.com/page → 301 → https://example.com/page
  • http://www.example.com/page → 301 → https://example.com/page
  • https://www.example.com/page → 301 → https://example.com/page

Un salto, siempre. Verifica con curl -I -L o un redirect-checker — si ves dos o más 301 seguidos, arregla la cadena.

Errores 301 que matan el SEO

1. Usar 302 por defecto

Muchos frameworks web devuelven 302 por defecto. En Express.js, Django, Rails, debes pedir 301 explícito. Muchos developers no lo hacen. Resultado: años de redirects "temporales" que Google trata con transferencia de señal reducida.

Fija siempre el status explícitamente. Express: res.redirect(301, '/new'). Django: HttpResponsePermanentRedirect(). Rails: redirect_to '/new', status: :moved_permanently.

2. Cadenas de redirect

"http://yoursite.com/old → https://www.yoursite.com/old → https://yoursite.com/old → https://yoursite.com/new" es una cadena de cuatro saltos. Cada salto:

  • Añade 50–200ms de latencia.
  • Reduce la transferencia de señal que hace Google.
  • Aumenta la probabilidad de que un salto se rompa y la cadena entera falle.

Colapsa a un salto. Siempre.

3. Redirigir todo a la home

"Reestructuramos el sitio, así que redirigimos todo lo viejo a la home". Es el peor patrón habitual. Pierdes la señal a nivel de página. Google lo trata como si el contenido viejo desapareciera.

Mapea cada URL eliminada al equivalente más próximo en la nueva estructura. Si genuinamente no hay equivalente, devuelve 410 Gone (Google la des-indexa de forma más limpia que un 404 o un 301-a-home engañoso).

4. No redirigir variantes con/sin barra final

example.com/page y example.com/page/ son URLs distintas. Si tu CMS permite ambas, los buscadores pueden indexar ambas y partir señal. Elige una (con o sin barra) y redirige la otra con 301.

5. Quitar redirects antiguos demasiado pronto

Hiciste la migración hace dos años. ¿Por qué seguir manteniendo los redirects? Porque sitios externos siguen enlazando a URLs viejas, y esos enlaces siguen recibiendo clics. El coste de la regla de redirect es cero. Quitarla te hace perder ese tráfico residual para siempre.

6. Loops

Si tu regla "forzar HTTPS" coincide incorrectamente con HTTP y HTTPS, obtienes un loop infinito. Los navegadores lo detectan y muestran ERR_TOO_MANY_REDIRECTS. Causas comunes: cabeceras del balanceador mal configuradas (X-Forwarded-Proto faltante), HSTS con CDN desalineado.

Prueba tus redirects con curl -L -I --max-redirects 5 en cada cambio. Si salta max-redirects, tienes un loop.

Casos de uso de 302 / 307

Existen redirects genuinamente temporales:

  • Páginas de mantenimiento. Mientras el sitio está caído, redirige a una página de estado. Cuando termina, deshaz el redirect. 302 aquí es correcto.
  • A/B testing. Redirigir a la mitad de usuarios a la variante B durante un test. Debería ser 302; el redirect no es permanente.
  • Geo-routing. Enviar a usuarios europeos a /eu/ durante un lanzamiento regional. 302, porque la URL canónica que tipeó el usuario sigue siendo significativa.
  • Flujos de login/autenticación. Devolver al usuario a la página que intentaba alcanzar tras autenticarse. 302/307 es convencional.

El test: si el redirect es para siempre, usa 301. Si es un desvío puntual, usa 302.

HSTS: la capa por encima de los redirects

Incluso con un 301 perfecto de HTTP a HTTPS, la primera petición del usuario aún va por HTTP y puede ser interceptada. HSTS (HTTP Strict Transport Security) lo arregla:

  • Devuelves la cabecera Strict-Transport-Security: max-age=31536000; includeSubDomains.
  • El navegador lo recuerda durante 1 año.
  • Las siguientes peticiones, aunque se tipeen como HTTP, van directo a HTTPS — sin tan siquiera intentar HTTP.

Combinado con HSTS preload (donde los navegadores incluyen una lista preinstalada de dominios HSTS), elimina el redirect HTTP→HTTPS para visitantes recurrentes.

Cuidado: HSTS es difícil de deshacer dentro de su max-age. Prueba a fondo. Empieza con max-age corto (300 segundos) y sube cuando estés seguro.

El proceso de verificación

Para cualquier cambio de redirect:

  1. Prueba con curl: curl -I -L -A "Googlebot" http://example.com/somepage. Confirma códigos, URLs intermedias, destino final.
  2. Prueba como lo ve un buscador. Usa URL Inspection de Google Search Console sobre la URL antigua — muestra lo que Google ve.
  3. Prueba cadenas. Si ves más de un 301/302 en la salida de curl, arréglalo.
  4. Prueba bordes. URLs con/sin barra final, con query strings, con fragments. Cada una debería redirigir limpia.

Las reglas en una frase

Usa 301 para movimientos permanentes, 302 para desvíos temporales, redirects de un solo salto siempre, mantenlos para siempre, verifica con curl tras cada cambio. Casi todas las historias de "perdimos rankings tras la migración" se reducen a violar una de esas reglas.