Código de Estado HTTP 302 (302 Found): Significado y Cuándo Usarlo

Advertisement
¿Qué Es el Código de Estado HTTP 302?
El código de estado HTTP 302 — oficialmente llamado 302 Found — es un código de respuesta HTTP que indica al cliente (normalmente un navegador) que el recurso solicitado ha sido movido temporalmente a otra URL. La nueva URL se proporciona en la cabecera Location de la respuesta, y el cliente debe obtener el recurso desde allí solo para esta solicitud.
Como el cambio es temporal, el cliente debe seguir usando la URL original para futuras solicitudes. Los motores de búsqueda, navegadores y marcadores no deben reemplazar la URL original con la URL de destino. Esta es la diferencia clave entre HTTP 302 y 301 Moved Permanently.
El código 302 pertenece a la clase 3xx de redirección de los códigos de estado HTTP, definida en RFC 9110. A pesar del nombre histórico 'Found', el cuerpo de la respuesta casi nunca se usa — los navegadores modernos siguen inmediatamente la cabecera Location sin renderizarlo.
Anatomía de una Respuesta 302
Una respuesta de código de estado HTTP 302 siempre contiene dos elementos esenciales: la línea de estado en sí y una cabecera Location que apunta a la nueva URL. Sin una cabecera Location válida, el cliente no puede seguir la redirección.
Línea de estado —
HTTP/1.1 302 Found(oHTTP/2 302en HTTP/2)Cabecera Location — la URL de destino que el cliente debe seguir (obligatoria)
Cache-Control — normalmente
no-cachepara que los navegadores no almacenen el destino permanentementeCuerpo — típicamente vacío, aunque los servidores pueden incluir una pequeña página HTML para clientes legacy (
<html><body><a href="...">Haz clic aquí</a></body></html>)
HTTP/1.1 302 Found
Location: https://www.example.com/new-page
Content-Type: text/html; charset=UTF-8
Content-Length: 0
Cache-Control: no-cache, no-store
Date: Mon, 27 Apr 2026 14:00:00 GMTLa cabecera Location puede ser una URL absoluta (https://example.com/path) o relativa al path (/path). Los clientes HTTP modernos aceptan ambas, aunque las URLs absolutas se recomiendan por claridad.
302 vs 301 vs 307 vs 308: ¿Qué Redirección Usar?
HTTP define cinco códigos de redirección comunes, y elegir el correcto importa para caché, SEO y preservación del método de solicitud. Usa esta tabla como matriz de decisión:
| Código | Permanencia | ¿Método Preservado? | ¿Cacheado por Navegadores? | Mejor Para |
|---|---|---|---|---|
| 301 Moved Permanently | Permanente | Puede cambiar POST→GET | Sí (agresivamente) | Cambios permanentes de URL, migraciones de dominio |
| 302 Found | Temporal | A menudo cambia POST→GET | No | Flujos de login, A/B testing, mantenimiento |
| 303 See Other | Temporal | Siempre cambia a GET | No | Patrón POST/Redirect/GET tras envío de formulario |
| 307 Temporary Redirect | Temporal | Sí — preservada | No | Redirecciones temporales que deben mantener POST/PUT |
| 308 Permanent Redirect | Permanente | Sí — preservada | Sí | Redirecciones permanentes que deben mantener POST/PUT |
La recomendación moderna: si necesitas una redirección temporal y quieres ser inequívoco sobre el manejo del método, usa 307 en lugar de 302. El código 307 se añadió en HTTP/1.1 precisamente porque los navegadores históricamente violaron la especificación al cambiar POST por GET en un 302 — y ese comportamiento incorrecto se hizo tan extendido que se convirtió en el estándar de facto.
¿Cuándo Usar una Redirección 302?
Usa el código de estado HTTP 302 siempre que la redirección sea genuinamente temporal — es decir, cuando esperas eliminar o cambiar el destino de la redirección en el futuro. Casos de uso legítimos comunes:
Redirecciones de login — Enviar a un usuario no autenticado de
/dashboarda/login, y de vuelta tras iniciar sesiónA/B testing — Enrutar al 50% de usuarios a una variante sin cambiar la URL canónica
Páginas de mantenimiento — Redirigir todo el tráfico temporalmente a
/maintenancemientras parchas el servidorEnrutamiento por geolocalización — Enviar visitantes de
/a/eso/ussegún su país, manteniendo/como entrada canónicaRedirecciones móviles — Redirigir a usuarios de smartphone de
example.comam.example.com(aunque hoy se prefiere diseño responsivo)Páginas de productos sin stock — Enviar compradores a la categoría hasta que el producto vuelva al stock
URLs promocionales de corta duración —
/black-fridayredirigiendo a la landing solo durante la promoción
Si alguno de estos se vuelve permanente, cambia a 301. Los motores de búsqueda esperan varios meses antes de tratar una 302 duradera como 301, así que dejar un cambio permanente en 302 cuesta señales de ranking durante ese período.
Advertisement
Cómo Enviar un Código de Estado 302
La mayoría de servidores web y frameworks tienen helpers integrados para enviar una redirección 302. Abajo los patrones más comunes. Cada uno emite HTTP 302 Found con una cabecera Location — las únicas dos cosas que una respuesta 302 estrictamente necesita.
Nginx
En Nginx, usa la directiva return con el código 302 (el predeterminado si omites el código también es 302):
server {
listen 80;
server_name example.com;
# Redirección temporal (302 Found)
location /old-page {
return 302 https://example.com/new-page;
}
}Apache (.htaccess)
En Apache, usa Redirect con el código 302 o RewriteRule con el flag [R=302,L]:
# Redirección temporal simple
Redirect 302 /old-page https://example.com/new-page
# O con mod_rewrite para coincidencia de patrones
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 proporciona código:
// Redirección temporal (302 Found por defecto)
app.get('/dashboard', (req, res) => {
if (!req.user) {
return res.redirect('/login') // envía 302
}
// ...renderizar dashboard
})
// O sé explícito:
res.redirect(302, '/login')Cómo Probar un Código de Estado 302
Después de implementar una redirección 302, verifica que funciona correctamente. La forma más rápida es curl desde tu terminal — muestra el código de estado exacto y la cabecera Location sin interferencia del caché del navegador.
# Mostrar solo cabeceras de respuesta (-I) sin seguir la redirección
curl -I https://example.com/old-page
# Salida esperada:
# HTTP/2 302
# location: https://example.com/new-page
# cache-control: no-cache
# date: Mon, 27 Apr 2026 14:00:00 GMT
# Seguir toda la cadena (-L) y mostrar cada salto
curl -ILs https://example.com/old-page | grep -i 'HTTP/\|location:'Si no tienes acceso a la terminal, usa el Comprobador de Redirecciones gratuito de DNS Robot para rastrear toda la cadena desde una ubicación neutral, o el Comprobador de Cabeceras HTTP para inspeccionar las cabeceras crudas — ambos eluden el caché del navegador.
Redirecciones 302 y SEO
Un código de estado HTTP 302 dice a los motores de búsqueda: 'este cambio es temporal, mantén la URL original en el índice.' Eso tiene consecuencias directas para las señales de ranking.
Según Google Search Central, una 302 no transfiere las señales de ranking de la URL original al destino de la redirección como lo hace una 301. La URL original se mantiene canónica. Google aún puede indexar la página de destino si otras señales de canonicalización (enlaces internos, sitemap, hreflang) apuntan a ella — pero la 302 en sí no es una señal canónica.
Usa 301 para cambios permanentes — Cambios de dominio, cambios de estructura URL, consolidación de páginas
Usa 302 para cambios temporales — Flujos de login, A/B testing, mantenimiento, enrutamiento regional
No dejes un cambio permanente en 302 — Google espera meses antes de tratar una 302 duradera como 301, costándote equity de ranking
Evita cadenas —
A → 302 → B → 302 → Cdiluye señales y ralentiza la carga. Cada salto añade latencia
Por Qué un 302 Cambia las Solicitudes POST a GET
Este es el comportamiento más sorprendente de HTTP 302. La RFC original decía que los clientes debían preservar el método al seguir una redirección. Pero los navegadores tempranos — Mosaic, Netscape, IE — todos cambiaron POST a GET en una 302, y ese comportamiento incorrecto se hizo tan extendido que se estandarizó en el WHATWG Fetch Standard.
Hoy, cuando un navegador envía un POST /login y el servidor responde con 302 Found, el navegador automáticamente emite un GET /next-page contra el destino. Los datos del formulario se descartan. Esto rara vez es lo que pretenden los desarrolladores del servidor.
# Lo que envías:
POST /submit-form HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
name=Alice&email=alice@example.com
# El servidor responde con 302:
HTTP/1.1 302 Found
Location: /thank-you
# El navegador sigue con GET (¡datos del formulario descartados!):
GET /thank-you HTTP/1.1
Host: example.comSi la redirección necesita preservar el método original (POST sigue siendo POST, PUT sigue siendo PUT), usa 307 Temporary Redirect en lugar de 302. Si quieres descartar intencionalmente el cuerpo y cambiar a GET — el patrón clásico POST/Redirect/GET — usa 303 See Other. Ambos son inequívocos; 302 no lo es.
Advertisement
Errores 302 Comunes y Cómo Solucionarlos
Cuando HTTP 302 va mal, suele aparecer como uno de estos síntomas. La mayoría tiene soluciones sencillas:
`Recibir 302 en lugar de 200` — El servidor está redirigiendo cuando no debería. Verifica
.htaccess, configuración de Nginx o middleware del framework`302 sin cabecera Location` — Respuesta inválida. Los navegadores mostrarán página en blanco. Asegúrate de que tu código establece la cabecera
Locationantes de enviar el estado`302 redirigiendo a sí misma` — Bucle de redirección. La URL
Locationcoincide con la URL de solicitud. Verifica la regla por condiciones faltantes`302 descartando datos del formulario` — POST → 302 → GET descarta el cuerpo. Cambia a
307 Temporary Redirectpara preservar el POST`302 cacheada por el navegador` — Servidor con bug estableció
Cache-Control: max-age=...en la redirección. AñadeCache-Control: no-cachey limpia el caché`302 en producción pero no en local` — Generalmente un CDN o load balancer añadiendo redirecciones. Prueba directamente contra el origin para aislar
Bucles de Redirección 302: Cómo Diagnosticar
Un bucle de redirección ocurre cuando la URL A devuelve un 302 a la URL B, y la URL B devuelve un 302 a A. Tras 20 saltos (en Chrome y Firefox), el navegador muestra ERR_TOO_MANY_REDIRECTS y se rinde.
La causa más común es un conflicto SSL/HTTPS entre un CDN (como Cloudflare) y el servidor de origen: el CDN se conecta al origin por HTTP, el origin redirige HTTP→HTTPS, el CDN quita HTTPS y se conecta por HTTP de nuevo — bucle infinito.
# Rastrear toda la cadena (limitar a 10 saltos para evitar bucles infinitos)
curl -ILs --max-redirs 10 https://example.com 2>&1 | grep -i 'HTTP/\|location:'
# Ejemplo de un bucle:
# HTTP/2 302
# location: http://example.com/
# HTTP/1.1 302 Found
# Location: https://example.com/
# HTTP/2 302
# location: http://example.com/ <-- bucle confirmadoSi ves dos URLs alternándose en las cabeceras Location, has confirmado un bucle de 302. Para una guía completa, ve nuestro post de ERR_TOO_MANY_REDIRECTS. El Comprobador de Redirecciones de DNS Robot rastrea toda la cadena desde una ubicación neutral y se detiene en el punto del bucle.
Mejores Prácticas para el Código de Estado 302
Enviar 302 Found correctamente evita la mayoría de los bugs que los desarrolladores enfrentan al implementar redirecciones:
Siempre incluir cabecera Location — Una
302sinLocationes inválida y se renderiza como página en blancoSiempre establecer Cache-Control: no-cache — De lo contrario algunos navegadores cachean la redirección durante la sesión, rompiendo el contrato 'temporal'
Usar URLs absolutas en Location —
https://example.com/newes inequívoco;/newfunciona pero puede romperse detrás de proxies que cambian el hostMantener redirecciones a un salto —
A → 302 → Bestá bien;A → 302 → B → 302 → Cralentiza carga y diluye señalesNo redirigir desde POST a otra página con 302 — Usar
303(GET intencional) o307(preservar POST)Auditar redirecciones mensualmente — Las redirecciones temporales antiguas suelen sobrevivir a su razón. Verificar con Redirect Checker
Cambiar a 301 cuando el cambio se vuelve permanente — No dejar un cambio permanente en
302más de unas semanas
Comportamiento del Navegador y la Caché
Diferentes navegadores e intermediarios manejan HTTP 302 de forma ligeramente diferente. Conocer las peculiaridades ahorra tiempo de depuración:
| Cliente | Comportamiento por Defecto en 302 | Caché por Defecto |
|---|---|---|
| Chrome / Edge | Auto-sigue, cambia POST→GET | No cacheada salvo que las cabeceras lo digan |
| Firefox | Auto-sigue, cambia POST→GET | No cacheada salvo que las cabeceras lo digan |
| Safari | Auto-sigue, cambia POST→GET | Caché de redirecciones algo más agresiva |
| curl (predeterminado) | NO sigue — muestra 302 + Location | Sin caché |
| curl -L | Sigue hasta --max-redirs (predeterminado 50) | Sin caché |
| wget (predeterminado) | Auto-sigue hasta --max-redirect=20 | Sin caché |
| Googlebot | Sigue, trata como señal temporal | Re-rastrea la URL original |
Para verificar comportamientos en casos límite (métodos POST, bucles infinitos, presencia de cabeceras), el Comprobador de Cabeceras HTTP de DNS Robot muestra la respuesta cruda sin reescritura de método del lado del navegador. Lee más sobre redirecciones temporales en la documentación de MDN y la especificación RFC 9110.
Advertisement
Rastrea cualquier cadena de redirección en segundos
Usa el Comprobador de Redirecciones gratuito de DNS Robot para inspeccionar cada salto en una cadena de redirecciones — códigos de estado, cabeceras Location y destino final desde un servidor neutral (sin caché del navegador).
Probar Comprobador de RedireccionesAdvertisement
Preguntas Frecuentes
El código de estado 302 (HTTP 302 Found) significa que el recurso solicitado está temporalmente en una URL diferente indicada por la cabecera Location de la respuesta. El cliente debe seguir la redirección para esta solicitud pero seguir usando la URL original para futuras solicitudes. Es el equivalente temporal de 301 Moved Permanently.