Redirecciones SEO: tipos 301, 302, 307 y 308 según Google

Casi todo lo que se publica sobre redirecciones se reduce a «301 para permanente, 302 para temporal». Eso basta para el 80 % de los casos y falla justo en los demás: el 302 que lleva tres años puesto, la cadena de cuatro saltos que nadie vio, la home como destino de 800 URLs borradas o el redireccionamiento por idioma que deja a Googlebot sin ver la mitad del sitio.

Este es el artículo de referencia sobre el tema: qué tipos hay, qué documenta Google de cada uno, qué se transmite y qué no, cuánto mantenerlas y cómo comprobarlas. El código de cada servidor lo tienes aparte, en tres guías específicas. Los resultados con curl que verás los he obtenido yo con un nginx de prueba; lo que no he podido probar lo digo.

Tipos de redirecciones y para qué sirve cada una

Una redirección es una instrucción para que el cliente (navegador o bot) pida otra URL en lugar de la solicitada. La más habitual es una respuesta HTTP con un código 3xx y una cabecera Location. Si quieres el panorama completo de los códigos de estado, lo tienes en la guía de códigos de respuesta del servidor; aquí me quedo con los que mueven URLs.

Meta refresh y JavaScript

Existen también redirecciones que no son de servidor. La documentación de Google las recoge: el meta refresh a 0 segundos (y el refresh en cabecera HTTP) se interpreta como permanente; con retraso, como temporal. Las redirecciones con JavaScript (location) se resuelven después de renderizar la página. Google dice que se usen solo si no puedes hacer redirecciones de servidor ni meta refresh, y avisa de que, si el renderizado falla, puede que nunca la vea.

Las redirecciones de servidor son, según esa misma página, las que más probablemente se interpretan bien. Los detalles del meta refresh, incluido por qué conviene evitarlo cuando puedes tocar el servidor, están en la guía del meta refresh. Google menciona además las «crypto redirects» (un enlace visible con un aviso tipo «hemos cambiado de sitio») como último recurso y advierte de que no todos los buscadores las reconocen como redirección.

Permanentes y temporales según Google

La diferencia que Google documenta entre ambas es de canonicalización. Con una redirección permanente, el sistema de indexación la toma como señal de que el destino debe ser la URL canónica. Con una temporal, Googlebot también sigue la redirección, pero no la usa como señal de canonical: el destino «might still be indexed if other canonicalization signals are present», según el texto de Google.

En la página sobre rastreo y errores HTTP, Google lo expresa en términos de fuerza: 301 y 308 son una señal fuerte de que el destino debe procesarse, y 302 y 307 una señal débil. Dice también que 308 equivale a 301 y 307 a 302. Esto tiene una consecuencia práctica: si pones un 302 donde querías un 301, la URL antigua puede seguir apareciendo en resultados. Google lo plantea incluso como ventaja cuando de verdad quieres que la antigua se mantenga.

La contrapartida es que esto es un comportamiento documentado, no una regla de laboratorio con plazos. No hay ningún número de semanas tras el cual un 302 «se convierte» en 301; lo que verás, si dejas un 302 meses, es que Google reevalúa con el resto de señales. Y las señales conviene que no se contradigan: ya las he tratado en la guía de canonical. Una redirección que dice una cosa y un canonical que dice otra solo producen incertidumbre.

301 frente a 308, 302 frente a 307 y el caso del 303

Para Google, 301 y 308 son equivalentes, y 302 y 307 también. La diferencia está en el protocolo HTTP: con 301 y 302 el método de la petición puede cambiar a GET, mientras que 307 y 308 obligan a repetirlo igual. MDN lo resume así: con 301 y 302 los métodos distintos de GET «pueden o no» cambiar a GET; 303 los cambia siempre; 307 y 308 no los tocan.

Lo comprobé con nginx y curl -d x=1 -L (un POST que sigue la redirección), apuntando a una URL final que devuelve el método que recibe:

Para una página web que se sirve con GET, la diferencia no importa y 301 es lo más compatible. Importa en APIs, formularios y cualquier endpoint que reciba POST, PUT o DELETE: ahí 308 y 307 evitan perder el cuerpo. El 303 es el caso especial legítimo: se usa justo para eso, para que tras un envío el navegador pida el resultado con GET y un refresco de página no reenvíe el formulario. Más abajo verás que mi formulario de contacto lo usa.

Qué se transmite con una redirección

Hay dos frases que se repiten sin fuente: «un 301 pierde entre un 10 y un 15 % de PageRank» y «un 302 no pasa autoridad». No he encontrado ninguna de las dos en la documentación de Google, y no las voy a usar.

Lo que sí está documentado, en la guía de migraciones de Google: «301 and other permanent redirects don't cause a loss in PageRank». Antes, en 2016, Gary Illyes lo había dicho en un tuit recogido por Search Engine Roundtable: «30x redirects don't lose PageRank anymore». Esa segunda fuente es secundaria (el tuit original no lo he abierto) y se refiere a las 3xx en general.

Ten claro qué significa y qué no. Que no se pierda PageRank no garantiza que el destino posicione igual: depende de que sea equivalente al contenido antiguo, de que sea rastreable e indexable y de que el resto de señales apunten a él. Y una redirección tampoco arregla enlaces internos mal puestos: sigue siendo una petición extra en cada visita y en cada rastreo.

Cadenas y bucles de redirecciones

Una cadena es una URL que redirige a otra que redirige a otra. Un bucle es una cadena que vuelve sobre sí misma. En mi nginx de prueba, /a redirige a /b, /b a /c y /c a /final:

$ curl -sIL http://127.0.0.1:8361/a | grep -iE "^HTTP|^location"
HTTP/1.1 301 Moved Permanently
Location: http://127.0.0.1:8361/b
HTTP/1.1 301 Moved Permanently
Location: http://127.0.0.1:8361/c
HTTP/1.1 301 Moved Permanently
Location: http://127.0.0.1:8361/final
HTTP/1.1 200 OK

Tres saltos antes de llegar a algo. Un usuario lo nota en latencia; un bot, en peticiones. Google dice que sus rastreadores siguen por defecto hasta 10 saltos de redirección, y que otros productos pueden tener otro límite. Con un bucle, curl --max-redirs 10 corta con error 47 («Maximum (10) redirects followed»), que es lo que verás también en un rastreador, y en Search Console aparecerá como error de redirección.

En la guía de migraciones, Google pide redirigir directamente al destino final y, si no es posible, mantener las cadenas cortas, «ideally no more than 3 and fewer than 5». Es un consejo de mantenimiento, no un límite de rastreo. Si tu sitio acumula cadenas es casi siempre porque se apilaron migraciones: HTTP a HTTPS, luego www, luego un cambio de estructura. Cada vez que cambias URLs, actualiza las reglas antiguas para que apunten al destino nuevo, no añadas una regla encima. El efecto sobre el presupuesto de rastreo solo importa de verdad en sitios grandes, pero las cadenas son una de las cosas más baratas de limpiar.

Cuánto tiempo mantener las redirecciones

Google, en la guía de migraciones: «Keep the redirects for as long as possible, generally at least 1 year». El año es un mínimo general, no un plazo tras el cual puedas borrar sin riesgo. La misma página aclara que puedes mantenerlas indefinidamente para los usuarios, aunque ralenticen la experiencia, y que conviene actualizar tus enlaces y los externos de más volumen para que apunten ya al destino nuevo.

Mi criterio en la práctica: antes de quitar una redirección miro si la URL antigua sigue recibiendo enlaces externos, tráfico o rastreo de Googlebot en los logs. Si recibe cualquiera de los tres, se queda. El coste de mantener una regla es casi nulo; el de borrarla y perder los enlaces entrantes, no.

Cuándo redirigir y cuándo devolver 410 o 404

No toda URL que desaparece merece una redirección. Si no hay una página equivalente, redirigir solo genera una experiencia confusa. Google lo dice en la guía de migraciones: no redirijas muchas URLs antiguas a un único destino irrelevante, como la home de la web nueva, porque puede confundir a los usuarios y tratarse como soft 404. La excepción es cuando varias páginas se fusionaron en una: entonces todas van a la que las reúne.

Sobre 410 frente a 404, Google no los distingue en su página sobre errores HTTP: todos los 4xx salvo 429 se tratan igual, indican que el contenido no existe, y si la URL estaba indexada se retira. No he encontrado documentación de Google que diga que un 410 desindexa antes que un 404; si buscas rapidez, mide en tu caso. Lo que sí aporta un 410 es claridad para ti: es una decisión intencionada y queda registrada así en los logs.

Redirecciones automáticas por idioma o país

Redirigir al usuario a su idioma según IP o navegador parece cómodo, y es de las cosas que más rompen sitios internacionales. Google recomienda en su documentación sobre sitios multirregionales evitar redirigir automáticamente de una versión de idioma a otra, porque eso puede impedir que usuarios y buscadores vean todas las versiones. Añade que Googlebot suele originarse en EE. UU. y no envía Accept-Language, por lo que puede no encontrar ni rastrear todas las variantes. Y que no uses análisis de IP para adaptar contenido.

La alternativa es dar a cada versión su propia URL, enlazarlas de forma visible (un selector, un aviso que sugiera sin forzar) y declararlas con hreflang o sitemaps. Lo que sí encaja con redirección es la normalización: HTTP a HTTPS, una sola versión de host y una sola forma de barra final, tema que trato en versiones con y sin www, HTTP y HTTPS.

Mapa de redirecciones en una migración

Google es explícito: hay que mapear las URLs de la web antigua a las de la nueva, y guardar ese mapeo en una base de datos o en reglas de reescritura, con un destino para cada URL. En una migración SEO el mapa es el entregable más importante, porque es lo que luego se verifica una por una.

Antes de lanzar, rastrea el listado de URLs antiguas contra el entorno nuevo y comprueba que cada una acaba en un 200, en una sola redirección. Después del lanzamiento, vigila los 404 en Search Console y en logs: ahí aparecen las URLs que no estaban en el mapa.

Dónde configurarlas

La regla en sí es sencilla; lo difícil es el entorno. Para cada servidor tengo una guía con sus reglas y pruebas: redirecciones en .htaccess, en nginx y en Apache con la configuración del servidor. Si prefieres generar las reglas por lotes, hay un generador de redirecciones en esta web que crea el código para Apache, Nginx e IIS; solo genera configuración, no la prueba por ti. Google muestra además ejemplos con PHP header() para quien no controla el servidor.

Cómo trato las redirecciones en mi web

Esto es lo que leo en el código de cristofercruz.net y lo que mido desde fuera. No veo la configuración del hosting, así que separo ambas cosas.

• .htaccess: no tiene ninguna regla Redirect ni RewriteRule que lleve de una página a otra. Las únicas reescrituras bloquean /tools/ y .git/ con 403, y el 403 se muestra con la página de error propia.
• Formulario de contacto: send.php termina con header('Location: …', true, 303). Es el uso típico del 303: tras un POST, el navegador pide el resultado con GET.
• Artículo retirado: el de Google I/O 2025 responde 410 con noindex y un enlace de vuelta al blog. No hay destino alternativo porque no hay equivalente.
• HTTP a HTTPS y barra final: desde fuera, http://cristofercruz.net/ responde 301 a HTTPS, y /blog/cache-seo responde 301 a /blog/cache-seo/. Ninguna de las dos reglas está en mi código; vienen del servidor o del hosting y no las he podido inspeccionar.

Y dos cosas que mejorar o vigilar. La versión con www por HTTPS responde 200, sin redirigir, con un canonical hacia la versión sin www; funciona, pero una redirección 301 de host sería una señal más clara. Y /blog/cache-seo/index.php también responde 200, con canonical a la URL con barra. Son mediciones desde fuera en un momento concreto, no una auditoría del hosting.

Cómo auditar las redirecciones

1. curl -sIL URL. Muestra cada salto con su código y su Location. Para ver solo un salto, curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' URL. Comprueba que el último código es 200 y que no hay más de un salto.
2. Crawler. Un rastreo completo da las cadenas, los bucles y, sobre todo, los enlaces internos que apuntan a URLs que redirigen. Esos enlaces se corrigen en origen.
3. Search Console. Revisa errores de redirección y la inspección de URL. Según Google, sus herramientas de inspección no siguen redirecciones, así que inspecciona la URL de destino.
4. Logs. Filtra por Googlebot y por códigos 3xx. Te dice qué redirecciones siguen rastreándose de verdad y cuáles puedes retirar con seguridad.

Una redirección por JavaScript o por meta refresh no se ve con curl -I: devuelve 200 y la redirección está dentro del HTML. Para detectarlas hace falta un crawler que renderice o mirar el código a mano.

Preguntas frecuentes

Fuentes consultadas

1. Redirects and Google Search Google Search Central
2. Site moves and migrations with URL changes Google Search Central
3. HTTP status codes, and network and DNS errors Google Search Central
4. Managing multi-regional and multilingual sites Google Search Central
5. Redirections in HTTP MDN Web Docs
6. Google: Any 301, 302, 3xx Redirect Does Not Lose PageRank At All Search Engine Roundtable