HTTP 302 Found: qué significa, 302 vs 301 y por qué aparece

¿Qué es el código de estado HTTP 302?

HTTP 302 Found es una redirección temporal. El servidor responde «lo que pides está en otro sitio por ahora» e indica la otra URL en la cabecera Location. El navegador carga esa URL al instante, pero los marcadores, los enlaces y los buscadores deben seguir usando la original (RFC 9110 §15.4.3).

Ese «por ahora» es toda la diferencia con 301 Moved Permanently, que dice que la URL antigua ya no existe. HTTP/1.0 llamaba al 302 «Moved Temporarily» (RFC 1945); la RFC 2616 lo renombró «Found» en 1999, pero su significado no cambió.

Como visitante, rara vez verás uno, porque el navegador lo sigue antes de que aparezca nada en pantalla. Te lo encuentras en las DevTools, en curl, en clientes de API y en auditorías SEO.

Anatomía de una respuesta 302

Una respuesta 302 es pequeña. Sus partes:

• Línea de estado — HTTP/1.1 302 Found, o simplemente HTTP/2 302 (HTTP/2 no lleva una frase de motivo como «Found»)
• Location — la URL a la que ir. La RFC 9110 dice que el servidor DEBERÍA (SHOULD) enviarla; sin ella, el navegador no tiene adónde ir y muestra el propio cuerpo del 302, normalmente en blanco
• Cuerpo — según la RFC 9110, «normalmente contiene una breve nota de hipertexto» con un enlace. Los navegadores lo ignoran; nginx, Apache y Express envían por defecto una nota de una línea, mientras que muchos sitios grandes envían un cuerpo vacío
• Cabeceras de caché — no hacen falta. Los navegadores no guardan un 302 en caché salvo que añadas Cache-Control: max-age o Expires; en cambio, 301 y 308 se guardan en caché por defecto. Aun así, un CDN puede guardarlo (consulta «Un 302 que no desaparece» más abajo)

HTTP/1.1 302 Found
Location: https://www.example.com/login?next=%2Fdashboard
Content-Length: 0
Date: Mon, 26 Oct 2026 14:00:00 GMT

Location puede ser una URL completa o una ruta relativa como /login: la RFC 9110 permite cualquier referencia URI, y los navegadores la resuelven a partir de la URL que pidieron. En el código de una aplicación (Express, por ejemplo), una ruta relativa evita filtrar un nombre de host interno o un http:// desde detrás de un proxy; nginx y Apache la convierten igualmente en una URL absoluta, salvo que configures absolute_redirect off o RedirectRelative On.

¿Por qué recibo un 302 en vez de un 200?

Porque la página espera algo que tu solicitud no trae, o porque la URL que usas no es la que sirve el sitio. Las razones habituales:

• No has iniciado sesión — las páginas que requieren iniciar sesión responden con un 302 a la página de inicio de sesión, con la página que querías en un parámetro de retorno. Sin sesión iniciada, github.com/settings te envía a /login?return_to=…. En curl o en un cliente de API, envía la cookie de sesión o el token.
• Tu cliente no sigue redirecciones — los navegadores, fetch() y requests de Python las siguen automáticamente. curl no lo hace salvo que añadas -L: se detiene en el 302 e imprime solo su cuerpo, a menudo nada (añade -i para ver el estado y Location).
• La URL no es la que sirve el sitio — una barra final que falta o sobra, una ruta de idioma o un enlace de seguimiento que te reenvía. res.redirect() de Express, return de nginx con solo una URL y Redirect de Apache envían 302 si no les indicas otro código.
• Algo delante del servidor lo añade — si el origen responde 200 cuando lo pruebas directamente pero la URL pública da 302, quien redirige es una regla del CDN, del balanceador de carga o del proxy.

Las API suelen responder a una sesión no iniciada con un 401 Unauthorized en lugar de una redirección. Para ver cada salto y su código de estado, pasa la URL por el Verificador de redirecciones.

302 vs 301 vs 307 vs 308: ¿qué redirección usar?

Cinco códigos de redirección cubren casi todos los casos. Se diferencian en dos cosas: si el cambio es permanente y si un POST sigue siendo POST:

303 y 307 existen por culpa del 302. HTTP/1.1 añadió el 303 en 1997 y, en 1999, la RFC 2616 admitió que «la mayoría de las implementaciones de agentes de usuario existentes tratan el 302 como si fuera una respuesta 303», añadió el 307 y renombró el 302 como «Found» (RFC 2616 §10.3.3). Si una redirección temporal puede recibir un POST, usa 307 para conservarlo, o 303 para cargar la página siguiente con un GET.

¿Cuándo usar una redirección 302?

Usa un 302 cuando esperes que la redirección desaparezca. Casos típicos:

• Redirecciones de inicio de sesión — enviar a un usuario sin sesión de /dashboard a /login y devolverlo después de iniciar sesión
• Pruebas A/B — enviar a parte de los visitantes a una variante; la propia guía de Google sobre pruebas pide usar aquí 302, no 301 (Google Search Central)
• Páginas en reparación — enviar a los visitantes a una página de aviso durante los pocos días en que se rehace una página
• URLs de campaña de corta duración — /black-friday apuntando a la página de ofertas de este año solo mientras dura la campaña
• Mantenimiento — solo para visitantes; para los buscadores, un 503 con Retry-After es la mejor respuesta durante una parada planificada

Si alguno de estos casos se vuelve permanente, cámbialo a 301.

Cómo enviar un código de estado 302

La mayoría de servidores y frameworks permiten enviar un 302 en una línea. Cada uno de estos ejemplos envía 302 Found con una cabecera Location, que es todo lo que un 302 necesita.

Nginx

En nginx, usa return con el código. return con solo una URL también envía un 302 (documentación de nginx):

server {
    listen 80;
    server_name example.com;

    # Temporary redirect (302 Found)
    location /old-page {
        return 302 https://example.com/new-page;
    }
}

Apache (.htaccess)

En Apache, usa Redirect (302 es su valor por defecto si no indicas un estado) o una RewriteRule con [R=302,L]:

# Simple temporary redirect
Redirect 302 /old-page https://example.com/new-page

# Or with mod_rewrite for pattern matching
RewriteEngine On
RewriteRule ^maintenance$ /maintenance.html [R=302,L]

Node.js (Express)

El método res.redirect() de Express usa 302 por defecto cuando no se indica un código de estado:

// Temporary redirect (302 Found by default)
app.get('/dashboard', (req, res) => {
  if (!req.user) {
    return res.redirect('/login') // sends 302
  }
  // ...render dashboard
})

// Or be explicit:
res.redirect(302, '/login')

Cómo probar un código de estado 302

Lo más rápido es curl en una terminal: muestra el código de estado y la cabecera Location sin que la caché del navegador se interponga.

# Status and headers, without following the redirect
curl -sI https://example.com/old-page

# -I sends HEAD, which some servers answer differently; this sends a real GET
curl -s -o /dev/null -D - https://example.com/old-page

# Expected:
# HTTP/2 302
# location: https://example.com/new-page

# Follow the whole chain and print each hop's status and Location
curl -sL -o /dev/null -D - https://example.com/old-page | grep -iE '^(HTTP/|location:)'

¿Sin terminal? El Verificador de redirecciones de DNS Robot sigue cada salto (301, 302, 303, 307, 308 y meta refresh) desde nuestro servidor y muestra cada código de estado y la URL final, y el Verificador de encabezados HTTP muestra las cabeceras sin procesar de cada salto en la pestaña Redirecciones.

Redirecciones 302 y SEO

Google trata los dos tipos de redirección como instrucciones distintas. Con una redirección temporal (302, 303, 307), el robot de Google la sigue, pero Google no la usa como señal de que la página de destino deba ser la canónica, así que la página de origen suele seguir en los resultados de búsqueda. La de destino puede indexarse igualmente si otras señales apuntan a ella (Google Search Central).

Una redirección permanente (301, 308) dice lo contrario: muestra la URL nueva. Así que la pregunta real no es «¿un 302 transmite PageRank?», sino «¿qué URL quiero en los resultados de búsqueda?». Tu etiqueta rel=canonical es una de esas otras señales; el Verificador de meta tags muestra qué URL declara una página.

• Usa 301 o 308 para cambios permanentes — dominio nuevo, nueva estructura de URLs, páginas fusionadas
• Usa 302 para los temporales — inicios de sesión, pruebas A/B, campañas
• No dejes un cambio permanente en 302 — Google puede seguir mostrando la URL antigua
• Mantén las cadenas cortas — cada salto cuesta un viaje de ida y vuelta, y el robot de Google hace por defecto hasta 10 saltos de redirección (Google)

Por qué un 302 cambia las solicitudes POST a GET

Es lo más sorprendente del 302. Las primeras especificaciones nunca permitieron a los clientes cambiar el método, pero los navegadores convertían igualmente un POST en GET ante un 302. Hoy, el Fetch Standard que implementan los navegadores deja por escrito esa costumbre: ante un 301 o un 302, un POST pasa a ser un GET y su cuerpo se descarta (Fetch Standard).

Así, cuando un navegador envía POST /submit-form y el servidor responde 302 Found, el navegador continúa con GET /thank-you y los datos del formulario se pierden. Los navegadores mantienen PUT y DELETE tal cual; otros clientes varían: requests de Python convierte cualquier método salvo HEAD en GET ante un 302, y curl -L convierte un POST en GET ante 301, 302 y 303 (--post302 conserva el POST en un 302).

# What you send:
POST /submit-form HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded

name=Alice&email=alice@example.com

# Server responds with 302:
HTTP/1.1 302 Found
Location: /thank-you

# Browser follows with GET (form data dropped!):
GET /thank-you HTTP/1.1
Host: example.com

Si la redirección debe conservar el método original (POST sigue siendo POST, PUT sigue siendo PUT), usa 307 Temporary Redirect. Si quieres descartar el cuerpo a propósito y pasar a GET (el clásico patrón POST/Redirect/GET), usa 303 See Other. Ambos son inequívocos; 302 no lo es.

Errores 302 comunes y cómo solucionarlos

Cuando un 302 falla, suele ser uno de estos casos:

• Un 302 en vez de un 200 — una página que exige iniciar sesión, un cliente que no sigue redirecciones o una variante de la URL (consulta «¿Por qué recibo un 302 en vez de un 200?» más arriba)
• Un 302 sin cabecera Location — nada puede seguirlo, y el navegador muestra el propio cuerpo del 302, normalmente en blanco. Define Location antes de enviar el estado
• Un 302 que apunta a sí mismo — un bucle de redirección: la regla se activa también en su propio destino. Añade la condición que falta
• Un formulario que pierde sus datos — POST → 302 → GET descarta el cuerpo. Usa 303 para mostrar a propósito una página de resultado, o 307 para conservar el POST
• Un 302 que no desaparece — el servidor lo envió con Cache-Control: max-age o Expires y los navegadores lo guardaron en caché, o lo guardó tu CDN (en el contenido que Cloudflare almacena en caché, conserva un 302 durante 20 minutos salvo que las cabeceras digan otra cosa; documentación de Cloudflare). Quita esas cabeceras, purga el CDN y borra la caché del navegador
• Un 302 en producción pero no en local — a menudo, una regla del CDN, del balanceador de carga o del proxy que añade redirecciones. Prueba directamente el origen para salir de dudas

Bucles de redirección 302: cómo diagnosticarlos

Un bucle de redirección es una URL A que te envía a B, y B que te devuelve a A. Tras 20 redirecciones, el límite del Fetch Standard, Chrome se rinde con ERR_TOO_MANY_REDIRECTS y Firefox con «La página no está redirigiendo adecuadamente».

Una causa clásica es el modo de cifrado Flexible de Cloudflare: Cloudflare llega a tu servidor por HTTP simple, tu servidor redirige de HTTP a HTTPS y Cloudflare vuelve a pedir por HTTP (documentación de Cloudflare).

# Trace the full redirect chain (limit to 10 hops to avoid infinite loops)
curl -ILs --max-redirs 10 https://example.com 2>&1 | grep -i 'HTTP/\|location:'

# Example of a loop:
# HTTP/2 302
# location: http://example.com/
# HTTP/1.1 302 Found
# Location: https://example.com/
# HTTP/2 302
# location: http://example.com/  <-- loop confirmed

Si la misma URL vuelve una y otra vez en Location, ya sea apuntando a sí misma o con dos URLs que se turnan, tienes un bucle (con el modo Flexible de Cloudflare, https://example.com/ redirige a sí misma). Para la solución completa, consulta nuestra guía de ERR_TOO_MANY_REDIRECTS. El Verificador de redirecciones de DNS Robot rastrea la cadena desde nuestro servidor y se detiene donde entra en bucle.

Mejores prácticas para el código de estado 302

Unos pocos hábitos evitan la mayoría de los problemas con el 302:

• Envía siempre una cabecera Location — sin ella, nada sigue la redirección
• No añadas cabeceras de caché — un 302 sin max-age ni Expires no se guarda en caché, que es lo que quieres
• Cuidado con las URLs absolutas detrás de un proxy — en el código de la aplicación, un /login relativo evita filtrar un nombre de host interno o un http:// en Location; nginx y Apache construyen las URLs absolutas a partir de su propia configuración
• Que sea un solo salto — A → B está bien; A → B → C añade un viaje de ida y vuelta para cada visitante
• Nunca redirijas un POST a otra página con un 302 — usa 303 para mostrar una página de resultado, o 307 para conservar el POST
• Revisa las redirecciones temporales antiguas — a menudo sobreviven a su motivo. Compruébalas con el Verificador de redirecciones
• Cambia a 301 en cuanto un cambio sea permanente

Cómo tratan un 302 los navegadores y las herramientas

Todos los clientes siguen un 302, pero difieren en los límites y en lo que pasa con el método:

Para la redacción exacta, consulta la definición de 302 en la RFC 9110 y la página de MDN sobre el 302.