Redirecciones 301 y 302: guía SEO para rankings | Ighenatt

Hay una regla que casi nadie cumple correctamente en las migraciones web: actualizar los enlaces internos después de configurar las redirecciones. El resultado son cadenas de redirección que consumen crawl budget en silencio durante meses, a veces años, mientras el equipo de SEO se pregunta por qué las nuevas páginas tardan tanto en ganar posiciones. Las redirecciones 301 y 302 son uno de los mecanismos más básicos del SEO técnico, pero también uno donde los errores más costosos ocurren exactamente en el momento en que más daño pueden hacer: durante una migración.

Un retailer europeo lo aprendió de la manera más cara: perdió aproximadamente £3,8 millones en el primer mes después de una migración de £7,6 millones porque su equipo de IT rechazó implementar correctamente las redirecciones de URLs. El caso está documentado como referencia de lo que ocurre cuando la gestión técnica de redirecciones se trata como un detalle menor.

Esta guía cubre los cuatro tipos de redirección relevantes para SEO (301, 302, 307, 308), cómo fluye el PageRank a través de cada uno, los errores más comunes en cadenas y bucles, los riesgos específicos de las redirecciones JavaScript, y las herramientas para auditar todo antes de que cause un problema.

301 vs 302: la diferencia que define la canonicidad

La diferencia entre 301 y 302 no es administrativa. Define cómo Google decide qué URL considerar la versión canónica del contenido.

301 Moved Permanently: le dice a Google que el contenido se ha movido de forma definitiva a la nueva URL y no volverá. Google actualiza su índice para usar la URL de destino como la URL canónica. El PageRank, los enlaces entrantes y la autoridad acumulada se transfieren a la nueva ubicación.

302 Found (temporalmente movido): le dice a Google que la URL original sigue siendo la URL oficial, que el desvío es temporal. Google no actualiza su índice para usar la URL de destino como canónica. Mantiene la URL original indexada y, en teoría, el PageRank permanece anclado a la URL de origen.

El error más frecuente en la práctica: usar 302 cuando la redirección es permanente. Una tienda que migra sus URLs de producto de /producto-123 a /categoria/producto-slug y usa 302 en lugar de 301 está enviando a Google una señal contradictoria: “esta página tiene una URL nueva pero sigue siendo la anterior la que importa”. El resultado son señales canónicas confusas que pueden dilatar meses la consolidación del PageRank en la nueva URL.

Gary Illyes, miembro del equipo de Google Search, aclaró públicamente en julio de 2016 lo que muchos SEOs debatían desde años antes: “30x redirects don’t lose PageRank anymore.” La confirmación eliminó la creencia extendida de que cada salto de redirección costaba un 15% de autoridad. Hoy el flujo de PageRank a través de una redirección correctamente configurada es completo, sin pérdida por el hecho de redirigir. La advertencia es la longitud de la cadena, no el tipo de redirección.

La diferencia operativa entre 301 y 302 sí tiene impacto SEO real en un punto específico: la velocidad de actualización del índice. Con un 301, Google actualiza la URL indexada en la próxima recrawl. Con un 302, Google no tiene razón para cambiar la URL indexada porque la original es la “oficial”. Si tu objetivo es que la nueva URL aparezca en los resultados de búsqueda, solo el 301 logra ese resultado.

307 y 308: cuándo importa el método HTTP

Los códigos 307 y 308 son técnicamente más precisos que 302 y 301 respectivamente, pero su relevancia práctica para la mayoría de páginas es limitada.

John Mueller de Google lo resumió directamente: “It doesn’t matter. Use the technically correct redirect type. It can also be a 307 or 308 redirect.”

La diferencia técnica está en la preservación del método HTTP:

• 301 y 302: permiten que el navegador cambie el método de la petición de POST a GET durante la redirección. Es el comportamiento histórico, implementado así por compatibilidad con navegadores antiguos.
• 307 y 308: obligan a preservar el método HTTP original. Si la petición original fue POST, la redirección también será POST.

Para páginas web estándar (que reciben peticiones GET), esta diferencia no existe en la práctica. Importa en tres escenarios específicos:

1. Formularios de múltiples pasos: si un formulario POST redirige a otra URL durante el proceso, usar 308 (permanente) o 307 (temporal) asegura que los datos del formulario no se pierdan al cambiar a GET.
2. APIs REST: los endpoints de API que procesan PUT, POST o DELETE necesitan preservar el método al redirigir.
3. Flujos de checkout en e-commerce: cualquier proceso que transmita datos en el body de la petición HTTP.

Para redirecciones de contenido editorial, blog posts, páginas de servicios o URLs de landing page, el par 301/302 es correcto y suficiente. La decisión de usar 307/308 solo debe tomarse cuando el método HTTP del cliente importa para el funcionamiento del destino.

Cómo fluye el PageRank a través de redirecciones

El PageRank no es una puntuación que “viaja” de una URL a otra de forma instantánea. Es el resultado del grafo de enlaces que Google calcula de forma periódica. Una redirección modifica ese grafo: le dice a Google que los enlaces que apuntan a URL-A deben ahora contabilizarse para URL-B.

Con la confirmación de Gary Illyes en 2016, el modelo actual es: el flujo de PageRank a través de redirecciones 30x es completo. Un enlace externo que apunta a una URL con 301 transfiere su valor de autoridad íntegramente a la URL de destino. No hay descuento por el hecho de usar una redirección en lugar de mantener la URL original.

Lo que sí genera pérdida de PageRank son dos patrones específicos:

Cadenas largas: cada salto adicional en una cadena de redirección introduce latencia y, cuando la cadena supera 5 saltos, Google puede dejar de seguirla en esa sesión de rastreo. El resultado es que los enlaces que apuntan al inicio de una cadena muy larga pueden no llegar a transferir su PageRank hasta que la cadena se consolida. John Mueller recomienda no superar 2 saltos en ninguna cadena de redirección activa.

Bucles de redirección: cuando URL-A redirige a URL-B y URL-B redirige de vuelta a URL-A, o en variantes más complejas con 3 o más URLs. Los bucles hacen que Googlebot abandone la secuencia, la URL nunca se indexa, y cualquier PageRank que llegara a esas URLs queda atrapado en el bucle. Son errores que Search Console reporta en el informe de Cobertura.

El escenario de mayor impacto ocurre en migraciones web: cuando un sitio cambia cientos o miles de URLs simultáneamente y algunas redirecciones apuntan a otras URLs que a su vez también están redirigiendo (porque hubo una migración anterior). La cadena resultante puede ser URL vieja 2020 → URL vieja 2023 → URL nueva 2026, tres saltos acumulados que deberían resolverse en uno.

Cadenas de redirección: detección y corrección

Una cadena de redirección existe cuando la URL-A no apunta directamente a la URL final, sino a una URL intermedia que a su vez redirige. En sitios con historial de migraciones o reestructuraciones de contenido, estas cadenas se acumulan de forma silenciosa.

El estudio de Ahrefs sobre más de un millón de dominios identificó las redirecciones 3XX como el problema técnico más frecuente, presente en el 95,2% de los dominios analizados. No todas son cadenas problemáticas, pero el porcentaje ilustra cuántos sitios tienen redirecciones sin auditar.

Por qué son dañinas:

• Crawl budget: cada salto extra es una petición HTTP adicional que Googlebot tiene que hacer. En sitios grandes, las cadenas de redirección pueden consumir una fracción significativa del crawl budget que debería usarse para descubrir contenido nuevo.
• Latencia de carga: cada salto añade tiempo de respuesta del servidor. Una cadena de 3 saltos puede sumar 300-500ms adicionales de tiempo de carga, lo que tiene impacto directo en Core Web Vitals y señales de experiencia de usuario.
• Señales canónicas debilitadas: cuando hay múltiples URLs en la cadena, Google tiene que decidir cuál es la URL canónica real. Aunque generalmente lo resuelve correctamente, el proceso es más lento y puede generar errores de indexación temporales.

Cómo detectar cadenas con Screaming Frog:

Screaming Frog SEO Spider es la herramienta de referencia para auditorías de redirección. El proceso es directo:

1. Rastrear el sitio con la opción “Always Follow Redirects” activada
2. En el menú principal: Reports → Redirect Chains
3. El informe “Redirect Chains” muestra todas las URLs con 2 o más saltos en la cadena
4. El informe “All Redirects” lista cada redirección individual con su código, URL de origen y URL de destino

La corrección de cada cadena detectada sigue el mismo principio: actualizar la redirección de origen para que apunte directamente a la URL final. Si URL-A → URL-B → URL-C, cambiar URL-A para que apunte directamente a URL-C. Nunca es suficiente eliminar el salto intermedio sin verificar que el destino final es una URL con 200 OK.

Dónde se generan las cadenas sin que nadie lo note: el caso más común es la coexistencia de reglas de redirección en capas diferentes. Las reglas en .htaccess o la configuración del servidor web se ejecutan primero, pero si el sitio también corre detrás de un CDN como Cloudflare, el CDN puede tener sus propias reglas de redirección que se ejecutan antes de llegar al servidor de origen. El resultado son cadenas que no son visibles en el código del servidor porque una parte ocurre en la capa del CDN.

Redirecciones JavaScript: los riesgos que la mayoría ignora

Las redirecciones implementadas con JavaScript (via window.location.href, window.location.replace() o <meta http-equiv="refresh">) son el peor escenario para SEO, y la documentación oficial de Google es explícita al respecto.

Google Search Central afirma en su documentación: “Google strongly prefers server-side redirects, since they can be processed immediately after crawling the initial URL.” La recomendación para JavaScript redirects es directa: “Only use JavaScript redirects if you can’t do server-side or meta refresh redirects.”

El problema técnico es el proceso de rendering de Googlebot. Cuando Google rastrea una URL con un redirect de servidor (301, 302), obtiene el código HTTP y la cabecera Location en la misma respuesta HTTP. El proceso es inmediato. Cuando la URL usa un redirect JavaScript, Googlebot debe:

1. Descargar el HTML de la página
2. Encolar la URL para el proceso de rendering (JavaScript)
3. Ejecutar el JavaScript en el renderizador
4. Detectar el redirect
5. Seguir la nueva URL

Ese proceso de rendering ocurre en una cola diferente al rastreo. Googlebot procesa aproximadamente el 95% de los redirects JavaScript correctamente, pero el tiempo entre el rastreo inicial y la resolución final de la redirect puede ser de días o semanas. Durante ese tiempo, la URL original puede quedar indexada o, si ya estaba indexada, permanecer en el índice con contenido desactualizado.

El riesgo aumenta cuando el rendering falla. Puede fallar por errores de JavaScript no relacionados con la redirección, por límites de tiempo en la ejecución del renderizador, o por recursos bloqueados por robots.txt que son necesarios para ejecutar el script de redirección. En esos casos, Google nunca detecta la redirección.

Los redirects <meta http-equiv="refresh"> son un caso intermedio: no requieren JavaScript pero tampoco son señales HTTP directas. Google los sigue, pero con menor velocidad y fiabilidad que los redirects de servidor.

Situaciones donde los JavaScript redirects son inevitables: aplicaciones de una sola página (SPA) donde toda la navegación ocurre en JavaScript, sistemas de gestión de contenido headless donde la capa de presentación no controla los headers HTTP, o plataformas de terceros donde no hay acceso al servidor.

En esos contextos, la práctica recomendada es usar server-side rendering (SSR) o static site generation para las páginas críticas de SEO, de forma que los redirects se gestionen a nivel de servidor para esas URLs específicas.

.htaccess, server-side y CDN: qué capa implementa el redirect

La elección de dónde implementar una redirección determina su fiabilidad, velocidad y capacidad de mantenimiento. Hay tres capas principales:

Apache .htaccess: el método más común en alojamientos compartidos y servidores Apache. Las reglas se escriben en el archivo .htaccess en la raíz del sitio y se procesan en cada petición HTTP. La ventaja es la flexibilidad: permite reglas complejas con expresiones regulares, redirecciones condicionales por user-agent, y soporte para diferentes tipos de redirect. La desventaja es el rendimiento: Apache lee el archivo .htaccess en cada petición, lo que añade latencia en sitios con miles de reglas.

# Redirect permanente de URL individual
Redirect 301 /pagina-vieja/ /pagina-nueva/

# Redirect con RewriteRule para patrones complejos
RewriteRule ^blog/([^/]+)/$ /articulos/$1/ [R=301,L]

Configuración de servidor (nginx.conf o Apache VirtualHost): la opción más eficiente para sitios de producción. Las reglas se cargan en memoria al iniciar el servidor y no requieren acceso a disco en cada petición. Para nginx, la directiva return 301 es la recomendada:

# Nginx - redirect simple
location /pagina-vieja/ {
    return 301 /pagina-nueva/;
}

CDN (Cloudflare, Fastly, Akamai): los CDNs modernos permiten configurar reglas de redirección en la capa edge, antes de que la petición llegue al servidor de origen. Esto reduce la latencia al máximo porque la redirección se sirve desde el nodo CDN más cercano al usuario. La desventaja es que crea una capa adicional de gestión: si el CDN tiene una regla de redirección y el servidor de origen también, pueden crear cadenas que solo son visibles monitorizando el tráfico en la capa CDN.

La regla práctica para elegir la capa correcta: para redirecciones críticas de SEO (migraciones de URLs, cambios de dominio), implementar en la configuración del servidor (no en .htaccess) para máxima fiabilidad. Para redirecciones de campaña o temporales, el CDN permite activarlas y desactivarlas sin despliegues de código.

Errores comunes en migraciones web

Las migraciones web concentran el mayor riesgo de errores de redirección porque muchos cambios de URL ocurren simultáneamente. Estos son los cinco errores más frecuentes:

1. Mapeo incompleto de URLs: redirigir solo las páginas del sitemap actual y olvidar URLs que han generado enlaces externos históricos, páginas indexadas pero no enlazadas internamente, y variantes de URL con parámetros UTM o de sesión que aparecen en los logs del servidor.

2. Redirecciones a la homepage como fallback: cuando no hay una URL equivalente clara en el nuevo sitio, redirigir a la homepage parece una solución razonable. No lo es. Google trata las redirecciones genéricas a la homepage como señales de que el contenido ya no existe, y las interpreta como un 404 blando (soft 404). El PageRank de la URL original no se transfiere.

3. Olvidar actualizar los enlaces internos: configurar las redirecciones y no actualizar los enlaces internos que apuntan a las URLs antiguas. El resultado es un sitio donde cada enlace interno crea un salto de redirección innecesario, multiplicando el consumo de crawl budget.

4. No verificar el tiempo de respuesta post-migración: algunas redirecciones funcionan correctamente pero introducen latencia de servidor que aumenta el TTFB (Time to First Byte). Una auditoría de velocidad post-migración con Google Search Console y herramientas como WebPageTest debe ser parte del proceso estándar.

5. Eliminar las redirecciones demasiado pronto: Google recomienda mantener las redirecciones permanentes activas durante al menos un año después de la migración para garantizar que todos los crawlers externos y buscadores hayan actualizado sus índices. Eliminarlas antes puede hacer que enlaces externos que aún apuntan a las URLs antiguas generen 404s en lugar de redirigir correctamente.

Herramientas para auditar redirecciones SEO

Screaming Frog SEO Spider es la herramienta estándar para auditorías de redirección. La versión gratuita rastrea hasta 500 URLs; la versión de pago cubre sitios de cualquier tamaño. Los informes relevantes son: “All Redirects” (lista completa), “Redirect Chains” (2+ saltos), y “Redirect & Canonical Chains” (combinación de redirects y señales canónicas).

Ahrefs Site Audit complementa a Screaming Frog con análisis de redirecciones en el perfil de backlinks: detecta cadenas que incluyen URLs externas con redirecciones, lo que es crítico para evaluar si los enlaces que apuntan a tu sitio están llegando correctamente a las URLs finales.

curl en terminal: para verificar redirecciones individuales rápidamente, curl -I [URL] devuelve los headers HTTP con el código de respuesta y la cabecera Location. Es la forma más directa de confirmar que una redirección responde con el código correcto.

# Verificar tipo de redirección
curl -I https://ejemplo.com/url-vieja/

# Seguir toda la cadena de redirección
curl -IL https://ejemplo.com/url-vieja/

Google Search Console: el informe de Cobertura bajo “Excluidas” muestra las URLs que Google no está indexando. Las categorías “Redireccionada” y “Error de redirección” identifican páginas con problemas de redirección activos. El informe de “Páginas indexadas” muestra si las nuevas URLs post-migración están siendo indexadas o si Google sigue usando las antiguas.

Chrome DevTools (Network): para inspeccionar redirecciones a nivel de navegador. En la pestaña Network, activar “Preserve log” y navegar a la URL de origen. La cadena completa de peticiones y respuestas aparece con sus códigos HTTP y tiempos de respuesta.

Cómo Googlebot gestiona las redirecciones

Googlebot tiene reglas específicas de comportamiento ante redirecciones que afectan directamente al rastreo e indexación:

Límite de saltos por sesión: Googlebot sigue hasta 5 saltos de redirección en una sola sesión de rastreo. Si una cadena supera ese límite, abandona en ese punto y la URL final no se rastrea ni indexa en esa sesión. La página puede aparecer en Search Console como “No rastreada - descubierta pero no rastreada todavía”.

Actualización de URLs en el índice: cuando Googlebot encuentra una redirección 301, programa actualizar la URL en el índice en el próximo recrawl. El proceso no es inmediato: para sitios grandes con muchas redirecciones, puede tomar semanas hasta que todas las URLs del índice reflejen las nuevas ubicaciones.

Tratamiento de soft 404s: si Googlebot detecta que una redirección lleva a una página con código 200 OK pero cuyo contenido es significativamente diferente al de la URL original (por ejemplo, la homepage de un sitio), puede clasificarla como soft 404. Las redirecciones genéricas a páginas de inicio o páginas de categoría muy amplias son el caso más frecuente.

Robots.txt y redirects: si la URL de destino de una redirección está bloqueada en robots.txt, Googlebot no podrá rastrearla después de seguir el redirect. El resultado es una URL de origen con 301 pero cuyo destino es inaccesible para el crawler. Es un error común en migraciones donde las URLs nuevas se añaden a robots.txt durante el desarrollo pero no se eliminan antes del lanzamiento.

Las redirecciones son infraestructura SEO crítica que la mayoría de los sitios gestiona reactivamente en lugar de proactivamente. El patrón habitual es configurarlas durante una migración y no auditarlas hasta que aparece un problema de posicionamiento. Para proyectos donde la arquitectura de URLs es parte de la estrategia SEO, como los que trabajan con enlazado interno avanzado o contenido programático a escala, una auditoría de redirecciones trimestral con Screaming Frog es parte del mantenimiento técnico básico.

Si quieres revisar el estado de las redirecciones de tu sitio antes de una migración o después de detectar pérdidas de tráfico inexplicadas, lo hacemos como parte de una auditoría SEO técnica.