¿Qué es una redirección 302 y cómo usarla correctamente?

Una redirección 302 es un código de estado HTTP (302 Found) que indica a los navegadores y motores de búsqueda que una URL ha sido movida temporalmente a una nueva ubicación. A diferencia de una redirección permanente, la URL original conserva su estado indexado y la equidad de enlace acumulada — los motores de búsqueda reciben instrucciones explícitas de continuar rastreando y posicionando la URL de origen, no el destino.

Esta distinción no es cosmética. Elegir el tipo de redirección incorrecto es uno de los errores de SEO más comunes y costosos en la gestión de infraestructura web. Si migras contenido de forma permanente pero sirves un 302, perderás señales de posicionamiento silenciosamente durante meses antes de notar el daño en Search Console.

El panorama de redirecciones HTTP: 302 vs. 301 vs. 307 vs. 308

Antes de profundizar en la implementación, es esencial entender dónde se sitúa el 302 dentro de la taxonomía más amplia de redirecciones HTTP. Muchos ingenieros confunden el 302 con el 307, y muchos propietarios de sitios confunden el 302 con el 301 — ambos errores tienen consecuencias reales.

Nota arquitectónica clave: HTTP/1.1 introdujo el 307 precisamente porque el 302 tenía un comportamiento ambiguo — los navegadores antiguos cambiaban las solicitudes POST a GET al seguir un 302. Si estás redirigiendo envíos de formularios o endpoints de API, usa 307 (temporal) o 308 (permanente), no 302 ni 301. Para redirecciones de páginas estándar, el 302 sigue siendo la opción correcta y ampliamente compatible para escenarios temporales.

Cuándo una redirección 302 es la herramienta correcta

La decisión de usar un 302 debe estar guiada por una sola pregunta: ¿Es este cambio de URL genuinamente temporal, con una fecha de finalización definida? Si la respuesta es sí, el 302 es apropiado. Si la respuesta es “probablemente” o “indefinidamente”, usa 301.

Ventanas de mantenimiento programadas

Cuando una página específica o un sitio completo se desconecta para migraciones de bases de datos, actualizaciones de servidor o parches de emergencia, una redirección 302 a una página de aviso de mantenimiento es la respuesta correcta. Los motores de búsqueda continuarán manteniendo la URL original en su índice y reanudarán el rastreo normal una vez que se elimine la redirección.

Un detalle que muchos administradores pasan por alto: para el mantenimiento de todo el sitio, combinar el 302 con un encabezado HTTP Retry-After en la página de mantenimiento proporciona a Googlebot una indicación de cuándo volver a rastrear, reduciendo los intentos de rastreo innecesarios durante la ventana de inactividad.

Pruebas A/B y experimentos multivariante

Redirigir un subconjunto de tráfico desde una URL canónica a una página variante para la optimización de la tasa de conversión debe usar un 302. Usar un 301 aquí haría que Google eventualmente consolidara las señales de posicionamiento en la variante, que podría descartarse una vez concluida la prueba. Herramientas como Google Optimize (ahora obsoleto) y alternativas modernas como VWO u Optimizely gestionan esto en la capa de JavaScript, pero las redirecciones 302 del lado del servidor ofrecen un control de rastreo más fiable.

Caso límite: Si tu prueba A/B dura más de 90 días, Googlebot puede comenzar a tratar el 302 como una redirección permanente de facto y empezar a indexar la variante. Audita las edades de las redirecciones con regularidad.

Campañas promocionales temporales

Las páginas de destino estacionales — ventas flash, registros de eventos, ofertas por tiempo limitado — deben servirse mediante 302 desde la URL principal. Cuando la campaña finalice, eliminar la redirección restaura la página original sin ningún trabajo de corrección de SEO.

Flujo de ejemplo:

https://example.com/products → 302 → https://example.com/black-friday-sale

Tras la campaña, se elimina la redirección y https://example.com/products reanuda su funcionamiento normal, sin pérdida de equidad de enlace.

Enrutamiento basado en geolocalización e idioma

Servir variantes de contenido específicas por región (p. ej., /de, /fr, /us) mediante redirecciones 302 basadas en geolocalización por IP es un caso de uso legítimo, pero requiere una implementación cuidadosa. Google indica explícitamente que las redirecciones de geolocalización no deben impedir que Googlebot (que rastrea desde IPs de EE. UU.) acceda al contenido canónico. Asegúrate siempre de que la configuración regional predeterminada sea accesible sin redirección para el rastreador.

Combina las redirecciones 302 de geolocalización con anotaciones hreflang en tu sitemap o <head> para dar a los motores de búsqueda una visión completa de tu estructura de URL internacional.

Enrutamiento de usuarios autenticados vs. no autenticados

Las aplicaciones web frecuentemente redirigen a los usuarios no autenticados desde recursos protegidos a una página de inicio de sesión. Esto es un 302 por definición — el recurso existe y será accesible una vez que el usuario se autentique. Servir un 301 aquí sería semánticamente incorrecto y podría hacer que los navegadores almacenen en caché la redirección, rompiendo el flujo de autenticación para los usuarios recurrentes.

Cómo implementar una redirección 302: todos los métodos principales

Apache: configuración de .htaccess

En entornos de alojamiento basados en Apache, el archivo .htaccess en la raíz de tu documento es el punto de configuración estándar. Asegúrate de que mod_rewrite o mod_alias esté habilitado.

Redirección simple usando mod_alias:

Redirect 302 /old-page https://example.com/new-page

Redirección basada en patrones usando mod_rewrite:

RewriteEngine On
RewriteRule ^old-page/?$ https://example.com/new-page [R=302,L]

Los indicadores [R=302,L] establecen explícitamente el código de respuesta y marcan la regla como la última a procesar. Omitir el código de estado tiene como valor predeterminado 302 en mod_rewrite de Apache, pero ser explícito evita ambigüedades cuando otros ingenieros lean la configuración.

Importante: Evita colocar reglas 302 dentro de un bloque <IfModule mod_rewrite.c> sin verificar que el módulo esté cargado. Un fallo silencioso aquí significa que no se activa ninguna redirección y no se registra ningún error en el nivel de registro predeterminado.

Nginx: configuración del bloque de servidor

Nginx gestiona las redirecciones mediante la directiva return, que es más eficiente que rewrite para redirecciones de URL simples porque no invoca el motor de expresiones regulares.

server {
    listen 80;
    server_name example.com;

    location = /old-page {
        return 302 https://example.com/new-page;
    }
}

Para redirecciones temporales basadas en patrones:

server {
    listen 443 ssl;
    server_name example.com;

    location ~* ^/promo/(.+)$ {
        return 302 https://example.com/campaigns/$1;
    }
}

Después de editar la configuración, prueba siempre la sintaxis antes de recargar:

sudo nginx -t && sudo systemctl reload nginx

Omitir nginx -t es una causa común de interrupciones del servicio — un error de sintaxis en el archivo de configuración impedirá que Nginx se recargue y puede hacer que falle en el próximo reinicio.

En un entorno de VPS Hosting donde tienes acceso root completo, puedes colocar estas directivas directamente en /etc/nginx/sites-available/your-site.conf y crear un enlace simbólico a sites-enabled/.

PHP: redirección basada en encabezados

Para redirecciones a nivel de aplicación donde el acceso a la configuración del servidor es limitado, la función header() de PHP proporciona un mecanismo fiable. Debe llamarse antes de que se envíe cualquier salida al navegador — incluidos los espacios en blanco antes de la etiqueta de apertura <?php.

<?php
header("Location: https://example.com/new-page", true, 302);
exit();

La llamada exit() es obligatoria. Sin ella, PHP continúa ejecutando el resto del script, lo que puede exponer contenido parcial de la página, activar consultas a la base de datos innecesariamente o crear vulnerabilidades de seguridad si el script realiza operaciones privilegiadas después de la redirección.

Nota sobre frameworks: En Laravel, usa return redirect()->to('/new-page', 302);. En Symfony, usa return new RedirectResponse('/new-page', 302);. En WordPress fuera de plugins, usa wp_redirect( $url, 302 ); exit;.

WordPress: gestión mediante plugins

Para sitios WordPress, editar archivos manualmente no siempre es práctico ni seguro, especialmente en entornos gestionados. El plugin Redirection (de John Godley) es la solución más utilizada y proporciona un registro completo de redirecciones, reglas de redirección condicionales y funcionalidad de importación/exportación.

Flujo de configuración:

1. Instala y activa el plugin Redirection desde el repositorio de plugins de WordPress.
2. Ve a Herramientas > Redirection.
3. En la pestaña Redirects, haz clic en Add New.
4. Introduce la URL de origen (p. ej., /old-page) y la URL de destino (p. ej., https://example.com/new-page).
5. Establece el Código HTTP en 302.
6. Guarda y verifica usando el comprobador de redirecciones integrado.

En un entorno de VPS con cPanel, también puedes gestionar las redirecciones directamente a través de la interfaz de Redirects de cPanel en la sección Domains, que escribe automáticamente las reglas .htaccess apropiadas.

JavaScript: redirección del lado del cliente (usar solo como último recurso)

Las redirecciones JavaScript no son redirecciones HTTP. Se ejecutan después de que la página se ha cargado parcialmente en el navegador y son invisibles para los rastreadores del lado del servidor a menos que el renderizado de JavaScript sea explícitamente compatible.

window.location.replace("https://example.com/new-page");

replace() es preferible a assign() para escenarios de redirección porque no añade la URL de origen al historial del navegador, evitando que los usuarios naveguen de vuelta a una página que no debería ser accesible.

Cuándo es aceptable: Aplicaciones de una sola página (SPAs) del lado del cliente donde el enrutamiento se gestiona completamente en JavaScript, o como alternativa para entornos donde el acceso a la configuración del lado del servidor es completamente inaccesible. Nunca uses redirecciones JavaScript como sustituto de las redirecciones 302 del lado del servidor en contextos críticos para el SEO.

Mecánica SEO: qué ocurre realmente cuando Googlebot encuentra un 302

Comprender el comportamiento del rastreador a nivel técnico previene configuraciones incorrectas costosas.

Cuando Googlebot encuentra un 302:

1. Registra la URL original como la URL canónica y continúa indexándola.
2. Sigue la redirección a la URL de destino y también la rastrea.
3. No consolida el PageRank ni las señales de enlace del origen al destino.
4. Revisita la URL original en su calendario de rastreo normal para comprobar si la redirección sigue vigente.

La vulnerabilidad de secuestro mediante 302: A principios de los años 2000, actores maliciosos explotaban las redirecciones 302 para redirigir temporalmente páginas de alta autoridad hacia su propio contenido, tomando prestadas efectivamente señales de posicionamiento. Los algoritmos de Google se han reforzado desde entonces contra esto, pero ilustra por qué el motor trata los destinos de 302 con menor confianza.

Encadenamiento de redirecciones: Un 302 que apunta a una URL que a su vez emite otra redirección (301 o 302) crea una cadena de redirecciones. Cada salto añade latencia (~100–300ms por salto según la geografía del servidor) y diluye el presupuesto de rastreo. Mantén las cadenas a un máximo de un salto. Usa Servidores Dedicados para sitios de alto tráfico donde la latencia de redirección se acumula en millones de solicitudes diarias.

Interacción con Cache-Control: Los navegadores pueden almacenar en caché las respuestas 302 si la respuesta incluye un encabezado Cache-Control: max-age o Expires. Esto rara vez es intencional para redirecciones temporales. Establece explícitamente Cache-Control: no-store en las respuestas 302 para evitar que los navegadores almacenen en caché una redirección que pretendes eliminar.

location = /promo {
    add_header Cache-Control "no-store";
    return 302 https://example.com/summer-sale;
}

Verificar que tu redirección 302 funciona correctamente

Usando curl en la línea de comandos

El método de verificación más fiable para los administradores de servidor es una solicitud HTTP directa con encabezados detallados:

curl -I -L https://example.com/old-page

El indicador -I solicita solo los encabezados, y -L sigue la cadena de redirecciones. Busca HTTP/2 302 (o HTTP/1.1 302 Found) en el primer bloque de respuesta, seguido del encabezado Location: que apunta al destino.

Para inspeccionar la cadena completa sin seguirla:

curl -I --max-redirs 0 https://example.com/old-page

Usando Google Search Console

En Search Console, la herramienta de Inspección de URL muestra cómo rastreó Googlebot una URL por última vez, incluida cualquier redirección que encontró. Si un 302 ha estado vigente durante un período prolongado y Google ha comenzado a tratarlo como permanente (indexando el destino en lugar del origen), esta herramienta mostrará ese comportamiento.

Usando Screaming Frog SEO Spider

El rastreador de Screaming Frog identifica todos los tipos de redirección en un rastreo completo del sitio, señala las cadenas de redirección y exporta un mapa completo de redirecciones. Esta es la herramienta estándar para auditorías de redirección previas al lanzamiento y verificación posterior a la migración.

Usando las herramientas de desarrollo del navegador

En Chrome o Firefox, abre DevTools (F12), ve a la pestaña Network, desactiva la caché (Ctrl+Shift+R para una recarga forzada) e inspecciona la primera solicitud. La columna Status mostrará 302 y el encabezado de respuesta Location mostrará la URL de destino.

Errores comunes y cómo evitarlos

Usar 302 cuando se quiere decir 301: El error más frecuente. Si una página ha sido retirada permanentemente o fusionada con otra URL, un 302 impedirá indefinidamente la consolidación de la equidad de enlace. Audita tu inventario de redirecciones trimestralmente.

Olvidar eliminar los 302 temporales: Establece recordatorios en el calendario al desplegar un 302 para una campaña o ventana de mantenimiento. Las redirecciones 302 huérfanas se acumulan con el tiempo y generan desperdicio de presupuesto de rastreo y confusión para los usuarios.

Bucles de redirección: A redirige a B, B redirige de vuelta a A. Esto bloquea el navegador con un error de “Demasiadas redirecciones” e impide que Googlebot rastree cualquiera de las dos URL. Prueba siempre las nuevas redirecciones con curl antes de desplegarlas en producción.

Redirigir todo el sitio durante el mantenimiento en lugar de páginas específicas: Un 302 para todo el sitio hacia una página de mantenimiento indica a los motores de búsqueda que cada URL del sitio se ha movido temporalmente. Para escenarios de mantenimiento, un 503 Service Unavailable con un encabezado Retry-After es semánticamente más correcto para la inactividad de todo el sitio.

Aplicar 302 al contenido paginado: Redirigir /page/2 a /page/1 durante una reorganización de contenido usando un 302 puede generar señales de contenido duplicado. Usa etiquetas canónicas junto con las redirecciones o en su lugar para la gestión de la paginación.

Si gestionas la terminación SSL junto con las redirecciones, asegúrate de que tus reglas de redirección se activen en el listener correcto. Un 302 configurado en el puerto 80 que redirige a una URL HTTPS no debe entrar en conflicto con tus reglas de redirección de HTTPS a HTTP. La configuración adecuada de Certificados SSL es un requisito previo para cadenas de redirección limpias en sitios HTTPS.

Para sitios alojados en Alojamiento Web Compartido, la gestión de redirecciones se realiza normalmente a través de .htaccess o la interfaz de redirecciones del panel de control de alojamiento, ya que el acceso directo a los archivos de configuración de Nginx o Apache suele estar restringido.

Matriz de decisión: 302 vs. otros tipos de redirección

Usa esta matriz para seleccionar el tipo de redirección correcto para tu escenario específico:

Lista de verificación técnica de puntos clave

• Confirma que la redirección es genuinamente temporal antes de elegir 302 en lugar de 301.
• Establece Cache-Control: no-store en las respuestas 302 para evitar el almacenamiento en caché no deseado por parte del navegador.
• Usa curl -I para verificar el código de estado correcto y el encabezado Location antes de pasar a producción.
• Audita las cadenas de redirección — mantenlas a un máximo de un solo salto.
• Añade encabezados Retry-After cuando uses 302 para redirecciones relacionadas con el mantenimiento.
• Usa 307 en lugar de 302 cuando el método HTTP original (POST, PUT, PATCH) deba preservarse.
• Elimina las redirecciones 302 temporales según un calendario definido; establece recordatorios en el momento del despliegue.
• Supervisa mensualmente las URL afectadas por redirecciones en la herramienta de Inspección de URL de Google Search Console.
• Para entornos WordPress, usa el plugin Redirection con el registro habilitado para rastrear el número de visitas a las redirecciones e identificar reglas huérfanas.
• Nunca uses redirecciones JavaScript en lugar de redirecciones 302 del lado del servidor para páginas críticas para el SEO.

Preguntas frecuentes

¿Una redirección 302 transfiere algún PageRank o equidad de enlace a la URL de destino?

No. Google trata el 302 como una señal temporal y retiene toda la autoridad de posicionamiento en la URL original. La equidad de enlace solo se transfiere mediante redirecciones permanentes 301 (o 308).

¿Cuánto tiempo puede permanecer una redirección 302 antes de que Google la trate como permanente?

No existe un umbral codificado, pero John Mueller de Google ha indicado que las redirecciones vigentes durante varios meses pueden comenzar a tratarse como permanentes. En la práctica, cualquier 302 con más de 90 días de antigüedad debe revisarse y convertirse a 301 si el cambio ya no es temporal.

¿Cuál es la diferencia entre una redirección 302 y una 307?

Ambas son redirecciones temporales, pero un 302 permite al navegador cambiar el método HTTP a GET al seguir la redirección (comportamiento heredado), mientras que un 307 preserva estrictamente el método HTTP original. Usa 307 para endpoints de API o envíos de formularios donde se requiere la preservación del método.

¿Puede una redirección 302 causar un bucle de redirección y cómo se soluciona?

Sí. Un bucle ocurre cuando la URL A redirige a la URL B, que redirige de vuelta a A (o a través de una cadena que vuelve a A). Soluciónalo auditando tus reglas de redirección con curl --max-redirs 0 en cada URL de la cadena sospechosa, y luego eliminando o corrigiendo la regla conflictiva. El informe de cadenas de redirección de Screaming Frog automatiza esta detección en todo un sitio.

¿Debo usar una redirección 302 o una etiqueta de actualización <meta> para redirecciones temporales?

Usa siempre una redirección 302 del lado del servidor. Las etiquetas meta refresh se ejecutan del lado del cliente después de que la página comienza a cargarse, no son procesadas de forma fiable por todos los rastreadores y añaden latencia innecesaria en la carga de la página. Son un último recurso aceptable solo cuando el acceso a la configuración del lado del servidor es completamente inaccesible.