302 vs. http 307

TL;DR — Un 302 y un 307 son, ambos, redirecciones “temporales”: envían a los visitantes a otro lugar por ahora mientras mantienen la URL original como la que cuenta. Google las procesa de la misma manera, por lo que no hay una diferencia de SEO significativa. La única diferencia real es técnica: un 307 tiene que mantener el mismo tipo de solicitud (de modo que el envío de un formulario siga siendo un envío de formulario en lugar de convertirse en una simple obtención de página), mientras que un 302 históricamente permitía que eso se cambiara. Usa un 302 simple para redirecciones normales; usa un 307 cuando estás redirigiendo algo como un formulario o una API que envía datos, y no asumas que “usar 307 por defecto en todas partes” es automáticamente gratuito.

Qué significan realmente un 302 y un 307

Tanto un 302 como un 307 son redirecciones: solicitas una URL y llegas a una diferente. El número es el código de estado HTTP que devuelve el servidor y transmite un mensaje para navegadores y motores de búsqueda.

• 302 — “Found” (temporal). La redirección temporal original. Dice “ve aquí por ahora, pero la dirección antigua sigue siendo la real; volveré”.
• 307 — “Temporary Redirect.” El mismo mensaje — temporal, la URL antigua todavía cuenta — pero con una promesa adicional: el navegador tiene que repetir tu solicitud exacta, incluso si era un GET (solo obtener una página) o un POST (enviar datos como un formulario).

Así que son hermanos. Una forma útil de decirlo: un 307 es un 302 que también garantiza que el navegador no cambiará silenciosamente el envío de tu formulario por una simple solicitud de página.

¿Importa para el SEO?

No de la forma en que la mayoría de los propietarios de sitios se preocupan. La propia documentación de Google enumera el 307 como “equivalent to 302” (traducción) «Es equivalente a 302» en cuanto a cómo sus rastreadores procesan y siguen la redirección. Ambos son señales “temporales”, por lo que, de forma predeterminada, Google no trata el destino como la página canónica solo porque redirigiste hacia él. La documentación de Google no detalla si 302 y 307 pasan cantidades idénticas o diferentes de valor de enlace — lo que dice claramente es que ninguno de los dos códigos entrega al destino las señales de la fuente de la manera en que lo hace una redirección permanente. Si alguien te dice que el 307 “pasa menos valor” que el 302, pídele su fuente — Google no ha publicado una que diga eso.

Entonces, ¿cuándo uso cada uno?

• Usa un 302 simple para redirecciones temporales cotidianas — una página de ofertas de temporada, una prueba A/B, una página de mantenimiento, enviar a alguien a una página de inicio específica de un país.
• Usa un 307 cuando lo que se redirige está enviando datos — un envío de formulario, una llamada de API, un POST de inicio de sesión o de pago. Aquí la promesa del 307 (mantener el método y los datos exactamente como estaban) sí importa, porque un 302 simple podría hacer que un navegador antiguo convierta un POST en un GET y descarte los datos.

Algo que confunde a las personas

A veces abrirás las herramientas para desarrolladores de tu navegador y verás un 307 que nunca configuraste. Por lo general, no es una redirección real del servidor, sino que tu navegador actualiza un enlace http:// a https:// por su cuenta (una función de seguridad llamada HSTS) y te lo muestra como un 307. Tu servidor nunca lo envió. Más información en la pestaña Advanced.

¿Quieres una visión completa — el historial de la especificación, exactamente lo que dicen Google y Mueller, el “307 fantasma” de HSTS y los valores predeterminados de los frameworks que sorprenden a los desarrolladores? Cambia a la pestaña Avanzado.

TL;DR — 302 y 307 son redirecciones temporales, y Google las procesa de la misma manera: su documentación dice que 307 es “equivalent to 302,” (traducción) «Es equivalente a 302», y Mueller ha dicho “for SEO, it doesn’t really matter” (traducción) «para SEO, no importa realmente» entre los pares temporales y permanentes; ninguno de los dos códigos es una señal de que el destino debería convertirse en canónico, y Google no ha publicado una división declarada de PageRank/valor de enlaces entre ellos. La diferencia real es la preservación del método: un seguimiento automático de un 307 debe mantener el mismo método de solicitud (un POST sigue siendo un POST), mientras que un 302 permite que un cliente convierta POST a GET; los bytes exactos del cuerpo, las credenciales y el comportamiento entre orígenes aún dependen del cliente, así que verifica en lugar de asumir. Usa 307 cuando perder el método rompa las cosas: APIs, formularios, flujos de POST/webhook/checkout/autenticación, pero ten cuidado con la repetición no idempotente (una llamada redirigida de pago o pedido puede reenviarse). Un 302 simple está bien para redirecciones GET ordinarias, incluida la recomendación explícita de Google para pruebas A/B. Ten cuidado con el “phantom 307” de HSTS (una etiqueta de la interfaz de Chrome, no una garantía del protocolo), los aspectos específicos de los frameworks (Next.js documenta 303 para Server Actions y 307 en otros casos: verifica tu versión en lugar de generalizar a otras plataformas), y ten en cuenta que Bing no tiene orientación distinta para 302 vs. 307. Mi propio orden preferido para redirecciones temporales es 307 / 302 / 303 sobre meta/HTTP refresh, aunque usar 307 por defecto no es gratuito, así que verifica primero las cabeceras de caché, la compatibilidad con clientes antiguos y las salvaguardas de idempotencia.

Ambos son temporales: ese es el punto de partida

Antes que nada: 302 y 307 están en la misma categoría. Google agrupa 302 (Found), 303 (See Other) y 307 (Temporary Redirect) como “redirecciones temporales”, y su comportamiento para todas ellas es el mismo:

• “Googlebot follows the redirect, but the indexing pipeline doesn’t use the redirect as a signal that the redirect target should be canonical.” (traducción) «Googlebot sigue la redirección, pero la canalización de indexación no usa la redirección como una señal de que el destino de la redirección debería ser canónico.» En términos sencillos, una redirección temporal conserva la URL de origen como URL principal de forma predeterminada; no transfiere al destino las señales del origen como lo hace una redirección permanente (301/308).

Esta es exactamente la comparación del nivel permanente un nivel más abajo: 301/308 son el par permanente, 302/307 son el par temporal, y la lógica de “el que tiene el número más alto conserva el método” es idéntica en ambos.

La única diferencia real: conservación del método y del cuerpo

Esta es la distinción que realmente importa, en una frase: cuando un cliente sigue automáticamente un 307, la especificación HTTP actual (RFC 9110) requiere que mantenga el mismo método de solicitud; un 302 deja al cliente en libertad de cambiar un POST a un GET. Esa es una garantía a nivel de especificación sobre el método — no es una garantía general sobre cada byte del cuerpo, las credenciales o la gestión entre orígenes, que todavía dependen del cliente específico que implementa la redirección. Verifica esos aspectos con una solicitud real en lugar de asumir que un 307 lo reproduce todo de manera idéntica en cada caso.

Por qué existía la ambigüedad es una historia sobre la especificación que vale la pena contar, porque la mayoría de los artículos afirman el hecho sin explicar por qué. En la era de HTTP/1.0, el texto de la especificación de 302 técnicamente decía que los clientes no deberían cambiar el método de solicitud al seguir la redirección — pero los primeros navegadores (Netscape, luego todos) lo ignoraron y silenciosamente convirtieron los métodos que no eran GET, especialmente POST, en GET en un 302. Ese comportamiento inconsistente pero universal se convirtió en el estándar de facto. HTTP/1.1 (RFC 2616, 1999, luego integrado en RFC 7231 y en el actual RFC 9110) formalizó la división en dos códigos explícitos para acabar con la confusión:

• 303 (See Other) — recupera el destino de la redirección con GET o HEAD (no simplemente “siempre GET” — RFC 9110 permite cualquiera de los dos métodos seguros), el comportamiento previsto para “POST, luego redirigir a una página de resultados que puedes recargar de forma segura.”
• 307 (Temporary Redirect) — método estrictamente preservado en un seguimiento automático, por especificación; RFC 9110 no obliga en absoluto a todos los clientes a seguir la redirección.

MDN expone la conclusión práctica con claridad: “The difference between 307 and 302 is that 307 guarantees that the client will not change the request method and body when the redirected request is made. With 302, older clients incorrectly changed the method to GET.” (traducción) «La diferencia entre 307 y 302 es que 307 garantiza que el cliente no cambiará el método de la solicitud ni el cuerpo cuando se realice la solicitud redirigida. Con 302, los clientes antiguos cambiaban incorrectamente el método a GET.» Por lo tanto, 307 no añadió tanto una nueva capacidad como eliminó una ambigüedad — es la versión garantizada por la especificación de lo que un 302 que se comporta correctamente se suponía que debía hacer desde el principio. Los navegadores modernos son mucho más coherentes que el caos de la era Netscape, pero 307 elimina la ambigüedad por especificación en lugar de por convención.

Lado a lado:

Dos notas de precisión que vale la pena tener claras: la disposición de la RFC que permite la conversión en un 302 menciona POST, no todos los métodos — no lo generalices como “302 always breaks PUT/DELETE” (traducción) «302 siempre rompe PUT/DELETE» sin comprobar tu cliente específico. Y ninguno de los dos códigos se puede almacenar en caché de forma predeterminada solo por su estado: RFC 9111 no enumera 302 ni 307 entre los códigos de estado que se pueden almacenar en caché heurísticamente solo a partir del estado — el almacenamiento en caché sigue dependiendo de encabezados Cache-Control/Expires explícitos, no del código de redirección que hayas elegido.

Mi propia definición de Ahrefs coincide con la parte de preservación del método: “A 307 redirect is the same as a 302 redirect, except it retains the HTTP method (POST, GET) of the original request when performing the redirect.” (traducción) «Un http 307 es lo mismo que un 302 redirect, excepto que conserva el método HTTP (POST, GET) de la solicitud original al realizar la redirección.»

¿Google trata de forma diferente los códigos 302 y 307 para el SEO?

No — y Google es inusualmente explícito al respecto. Este es un tema resuelto y de baja controversia, de la misma manera que 301 frente a 308.

En la documentación de códigos de estado HTTP de Google, la fila del 302 dice que los rastreadores de Google “follow the redirect and use it as a weak signal that the target should be processed” (traducción) «siguen la redirección y la usan como una señal débil de que el destino debería procesarse», y la fila del 307 dice, textualmente, “Equivalent to 302.” (traducción) «Es equivalente a 302.» Google luego agrega la advertencia que se aplica por igual a los pares 302/307 y 301/308: “While Google treats these status codes the same way, keep in mind that they’re semantically different. Use the status code that’s appropriate for the redirect so other clients (for example, e-readers, other search engines) may benefit from it.” (traducción) «Google los considera iguales para este tratamiento, pero advierte que su semántica no coincide por completo. Usa el código apropiado para la redirección para que también puedan aprovecharlo otros clientes, como lectores electrónicos y motores de búsqueda.»

Esa es la respuesta sobre el procesamiento del rastreador. Google los trata de la misma manera en cuanto a cómo Googlebot obtiene y sigue la redirección, y solo pide que elijas el código semánticamente correcto para que los clientes que no son de Google se comporten correctamente. Evidence for this claim Google treats 307 as equivalent to 302 for Search while noting that the two status codes are semantically different. Scope: Google Search redirect handling; HTTP clients still need the appropriate status code. Confidence: high · Verified: 2026-07-14 Google: HTTP status codes and Search

Un matiz sobre el que vale la pena ser preciso, porque es una brecha real en mucha de la cobertura de otros: la equivalencia de procesamiento por parte del rastreador es una afirmación separada del resultado de indexación. El documento sobre redirecciones y Google Search de Google agrupa 302, 303 y 307 como “temporary redirects” (traducción) «redirecciones temporales» y afirma que “the indexing pipeline doesn’t use the redirect as a signal that the redirect target should be canonical.” (traducción) «el pipeline de indexación no usa la redirección como una señal de que el destino de la redirección debería ser canónico». Esa es una garantía real y útil, pero no es una promesa de que tu URL de origen siga posicionando, o de que el destino nunca pueda indexarse mediante otras señales. Trata “302 and 307 are processed the same way” (traducción) «302 y 307 se procesan de la misma manera» y “neither is a canonical signal to the target” (traducción) «ninguna es una señal de canonicalización hacia el destino» como dos afirmaciones separadas y ambas verdaderas, no como una afirmación de que los dos códigos transmiten PageRank o valor de enlace idénticos, algo que los documentos de Google no afirman en ningún sentido.

John Mueller dice lo mismo con sus propias palabras. En el episodio “Let’s talk redirects” de Search Off the Record, Martin Splitt preguntó directamente por qué 307 y 308 siquiera existen junto a 301 y 302. Mueller: “I had to look this up recently. And usually, with a 301 and 302, what is forwarded are GET requests.” (traducción) «Tuve que consultar esto hace poco. Por lo general, un 301 o un 302 reenvía solicitudes GET». … “And with 307, 308, it also forwards POST requests.” (traducción) «Y con 307, 308, también reenvía solicitudes POST». Luego la cita destacada que resuelve la pregunta de SEO: “I think for SEO, it doesn’t really matter. It’s more like, I don’t know… Does it work for APIs or not? And usually, APIs are not something that you need to have indexed directly in Search.” (traducción) «Creo que, para SEO, la elección no cambia mucho. La pregunta práctica es si funciona con APIs; normalmente no necesitas indexar sus endpoints directamente en Search».

Observa el planteamiento: el único motivo para optar por 307 en lugar de 302 es una cuestión de funcionalidad (“¿funciona para las API?”), no una cuestión de posicionamiento. No existe ninguna fuente primaria creíble que afirme una ventaja de SEO en ningún sentido.

¿Trata Bing de manera diferente 302 y 307?

Honestamente: Bing no lo ha dicho. Su guía pública sobre redirecciones (la publicación de 2011 «Gestión de redirecciones — 301s, 302s y canónicas» y la publicación de 2020 «Migración de sitios con Bing») solo analiza la división entre permanentes y temporales de 301 frente a 302 y nunca menciona 307 o 308 por su nombre. A diferencia del tema de 301 frente a 308 —donde Fabrice Canel hizo una declaración directa—, no pude encontrar ninguna declaración de un representante de Bing específicamente sobre 302 frente a 307.

Así que lo diré sin rodeos en lugar de asumir paridad: ninguna declaración de Bing diferencia específicamente 302 y 307. Existe un comportamiento documentado de Bing que vale la pena conocer para la discusión sobre redirecciones temporales en general —si Bingbot ve el mismo 302 suficientes veces seguidas, comenzará a tratarlo como un 301 y consolidará hacia adelante—, pero Bing no ha confirmado públicamente que ese comportamiento se extienda a 307 repetidos. Considera eso como un vacío genuino en la documentación, no como un hecho sobre 307.

Cuando 307 es la opción técnicamente correcta

Cualquier redirección en la que perder el método o el cuerpo original rompería algo:

• API y endpoints de webhook — un POST/PUT/DELETE que debe llegar a la nueva URL con el método y el payload intactos.
• Envíos de formularios (flujos POST) — como lo expresó Mueller: “if you have a— I’d almost say like a broken setup, that you have a form on one domain and the results are forwarded to a different one, then you would use the 307, 308.” (traducción) «si tienes una— casi diría como una configuración rota, que tienes un formulario en un dominio y los resultados se reenvían a uno diferente, entonces usarías 307, 308.»
• Traspasos POST de checkout, pago e inicio de sesión/autenticación — cualquier punto en el que descartar el cuerpo haga que la transacción falle silenciosamente.

Una nota de seguridad que vale la pena señalar: la garantía de preservación del método de 307 tiene dos caras. Si la solicitud original no era idempotente —un cargo de pago, el envío de un pedido, cualquier cosa con un efecto secundario— un seguimiento automático de un 307 reproduce esa solicitud exacta en la nueva URL. Por lo general, eso es lo que quieres, pero también significa que un reintento del cliente o una cadena de redirecciones puede reenviar una llamada no idempotente más de una vez. Coloca controles de idempotencia (una clave de idempotencia, una comprobación de envío duplicado) en el endpoint receptor en lugar de asumir que la redirección por sí sola hace que la reproducción sea segura.

Una razón importante por la que los desarrolladores se encuentran con 307 sin elegirlo: algunos frameworks y plataformas de borde usan de forma predeterminada un código que preserva el método para solicitudes que no son GET. Next.js es el ejemplo documentado más claro: su función redirect() devuelve un 303 cuando se llama desde una Server Action y un 307 en otros contextos admitidos, según su referencia de API actual, así que comprueba la documentación de tu versión de Next.js en lugar de asumir que un solo código se aplica en todo el framework. Otros frameworks, CDN y balanceadores de carga varían según el producto y la versión: verifica el código de estado real que devuelve tu plataforma en lugar de asumir que coincide con lo que hace una plataforma de aspecto similar. Ver un 307 o 303 inesperado a menudo es la plataforma haciendo algo que tiene en cuenta el método a propósito, no una mala configuración, pero confírmalo para tu configuración específica.

Cuando 302 es el valor predeterminado pragmático

Redirecciones temporales estándar en solicitudes GET simples: no hay ningún método que preservar, por lo que la garantía de 307 no te aporta nada:

• Redirecciones geográficas/de idioma (con la advertencia habitual de no bloquear completamente el contenido por región).
• Pruebas A/B y divididas — La propia orientación sobre pruebas de sitios web de Google indica explícitamente que uses un 302, no un 301, para las variantes de prueba redirigidas, precisamente porque la redirección es temporal.
• Redirecciones de modo de mantenimiento / “volvemos pronto” — pero solo cuando hay un recurso real al que enviar a los visitantes; si todo el sitio no está disponible, la propia orientación de Google apunta hacia un 503 (servicio no disponible) en lugar de cualquier redirección. Y si lo que se redirige es una solicitud que no es GET — un proceso de pago o una llamada de API que accede a tu página de mantenimiento — un 307 repetirá esa solicitud en la nueva URL, lo cual no es automáticamente seguro si la llamada tiene efectos secundarios, así que no recurras al 307 por costumbre ahí sin comprobarlo.
• Redirecciones móvil↔escritorio (m-dot) — El propio ejemplo de Mueller de cuándo 302 es específicamente el código correcto: “a 302 redirect would be the right one because next time someone goes there, you don’t really know if they want to go to the mobile version or the desktop version.” (traducción) «un 302 redirect sería el correcto porque la próxima vez que alguien vaya allí, no sabes realmente si quiere ir a la versión móvil o a la versión de escritorio.» El destino correcto depende del visitante, así que no es un traslado permanente.

El “307 fantasma” de HSTS — un 307 que tu servidor nunca envió

Esto merece su propia sección porque es un tema completamente diferente de elegir un código de redirección, y confundir ambos causa una confusión real cuando las personas depuran cadenas de redirecciones.

Si un sitio envía el encabezado HSTS (Strict-Transport-Security) a través de HTTPS, el navegador lo recuerda y, en cualquier intento posterior de acceder a la versión http://, actualiza la solicitud a https:// por sí mismo — el URI se reescribe antes de que la solicitud llegue a la red. Las versiones actuales de Chrome muestran esa actualización interna en DevTools como un 307, pero nada en el servidor lo emitió, y la etiqueta exacta, el recuento de bytes o la presentación del encabezado son comportamientos de la interfaz de usuario específicos de la versión de Chrome, no requisitos de la especificación de HTTP o HSTS — no trates “307” como una etiqueta garantizada en todos los navegadores o en todas las versiones futuras. John Mueller explicó esto en su sitio personal: “After seeing the HTTPS URL with the HSTS header (for example, with any redirect from the HTTP version), Chrome will act like it’s seeing a 307 redirect the next time you try to access the HTTP page.” (traducción) «Después de ver la URL HTTPS con el encabezado HSTS (por ejemplo, con cualquier redirección desde la versión HTTP), Chrome actuará como si estuviera viendo una redirección http 307 la próxima vez que intentes acceder a la página HTTP.» Y la aclaración clave: “Your server’s not returning a 307, Chrome is just showing it to you as such to explain that it’s doing the redirect for you.” (traducción) «Tu servidor no está devolviendo un http 307; Chrome solo te lo muestra como tal para explicar que está haciendo la redirección por ti.»

He señalado lo mismo en mis propios textos sobre códigos de estado: incluso existe un significado distinto de “307 HSTS Policy” (“forces the client to use HTTPS” (traducción) «obliga al cliente a usar HTTPS») separado de “307 Temporary Redirect.” El matiz de SEO: “When web servers require clients to only use HTTPS connections (HSTS policy), Google won’t see the 307 because it’s cached in the browser.” (traducción) «Cuando los servidores web requieren que los clientes solo usen conexiones HTTPS (política HSTS), Google no verá el 307 porque está almacenado en caché en el navegador». Así que si ves un 307 en tu pestaña de red que nunca configuraste, antes de buscar una regla de redirección mal configurada, comprueba si simplemente es HSTS haciendo una actualización de HTTP→HTTPS por ti.

Mitos comunes

• “307 no pasa el mismo valor SEO que 302.” Sin respaldo — los propios documentos de Google dicen que 307 es “Equivalent to 302” (traducción) «Es equivalente a 302» para la forma en que se procesa la redirección, y ninguno de los códigos se trata como una señal de que el destino deba ser canónico. Pero Google no ha publicado una fórmula exacta de PageRank/valor de enlaces para ninguno de los dos códigos, así que no afirmes una transferencia de valor precisa, igual (o desigual), en ninguna dirección — la afirmación precisa es que Google los procesa de la misma manera, no que haya cuantificado el valor que se pasa.
• “302 es la opción más segura/recomendada porque está más claro cómo lo tratan los motores de búsqueda.” Exagerado. El tratamiento de 307 por parte de Google está igualmente documentado (“Equivalent to 302” (traducción) «Es equivalente a 302») — este no es un caso en el que un código sea mejor entendido por los motores de búsqueda. En todo caso, 307 ofrece una garantía de funcionalidad (preservación del método/cuerpo) que 302 no. (Algunas guías de terceros afirman lo contrario; consulta la nota en la pestaña de recursos.)
• “Un 307 en la pestaña Network de mi navegador significa que mi servidor configuró incorrectamente una redirección.” A menudo falso — si HSTS está activado y previamente cargaste la versión HTTPS, ese 307 es la propia actualización HTTP→HTTPS de Chrome, no una respuesta del servidor.
• “Los 302 siempre convierten POST a GET, así que nunca uses un 302 para un formulario.” Exagerado para los navegadores modernos. La conversión POST→GET fue un problema real y bien documentado con clientes antiguos — es la razón por la que 307 existe como la opción garantizada, no una prueba de que todos los 302 actuales descarten los datos POST. 302 es ambiguo, no está universalmente roto.
• “Cambia todas tus redirecciones temporales a 307 para mejorar las posiciones.” Falso y cambios innecesarios — no hay ninguna ventaja en las posiciones. La única razón válida para preferir 307 es una necesidad real de preservación del método/cuerpo (o preparación general para el futuro).
• “303 y 307 son básicamente lo mismo.” No — 303 fuerza explícitamente el método a GET (diseñado para patrones de POST y luego redirección a una página de resultados), lo opuesto funcionalmente a la garantía de preservación de 307. Son fáciles de confundir porque aparecen juntos en la lista.

Mi recomendación

Para las redirecciones temporales, mi orden de implementación preferido es 307 / 302 / 303, por encima de meta refresh (0) y HTTP refresh (0). Observa que de hecho sitúo 307 por encima de 302 — no porque ayude al SEO (no lo hace), sino porque si siempre usas el código que conserva el método, rara vez tienes que recordar cambiarlo después: una redirección GET simple funciona bien como http 307, y el día que redirijas un formulario o una API ya estarás cubierto. Se trata de un argumento de exhaustividad, no uno gratuito — una verdadera política de http 307 por defecto aún necesita la misma disciplina de control de caché que cualquier redirección, aún necesita funcionar para cualquier cliente heredado que realmente admitas, y aún necesita salvaguardas de idempotencia en cualquier destino de redirección que no sea una solicitud GET simple. Mueller hizo el mismo punto sobre la exhaustividad: “if you always use them, then you’re always safe.” (traducción) «si siempre los usas, entonces siempre estás a salvo». Dicho esto, un 302 simple es perfectamente válido, y para el caso específico de m-dot, 302 es técnicamente la opción más correcta.

Dónde encaja esto

302 y 307 son dos de los códigos de redirección temporal 3xx, y cada uno tiene su propio análisis detallado en este clúster, junto con el par permanente (301, 308), el código hermano siempre GET 303, y las comparaciones entre códigos hermanos —301 vs. 308 de nivel permanente (misma lógica de preservación del método, un nivel superior) y 301 vs. 302 permanente frente a temporal—, además de los riesgos operativos, las cadenas de redirecciones y los bucles de redirección. Para toda la familia de respuestas del servidor, consulta el centro de códigos de estado HTTP; el tipo de redirección también es una de las señales de canonicalización tratadas en canonicalización.

Resumen de IA

Una versión condensada de la versión Advanced:

• Ambas son redirecciones temporales. 302 y 307 mantienen la URL de origen como canónica de forma predeterminada — ninguno entrega al destino las señales del origen como lo hace una redirección 301/308 permanente.
• Google las procesa de la misma manera. Su documentación dice que 307 es “equivalent to 302,” (traducción) «equivalente a 302,» y Mueller: “for SEO, it doesn’t really matter.” (traducción) «para SEO, no importa realmente.» Pero esa es una afirmación sobre el procesamiento del rastreador, no una fórmula declarada de PageRank/valor de enlace — Google no ha publicado una para ninguno de los dos códigos, así que no afirmes una transferencia de valor exactamente igual (o desigual), y no asumas que “processed the same” (traducción) «procesado de la misma manera» garantice que el origen mantenga su posicionamiento o que el destino nunca pueda indexarse mediante otras señales.
• La única diferencia real es la preservación del método. Un seguimiento automático de un 307 debe mantener el mismo método (un POST sigue siendo un POST); un 302 permite que un cliente convierta POST a GET. 307 se añadió en HTTP/1.1 (RFC 2616 → 7231 → 9110) específicamente para cerrar esa ambigüedad — pero los bytes exactos del cuerpo, las credenciales y el comportamiento entre orígenes siguen dependiendo del cliente, y el permiso de conversión del RFC nombra específicamente a POST, no a todos los métodos que no sean GET.
• Usa 307 para APIs, formularios, flujos de POST/webhook/pago/autenticación — pero ten cuidado con la repetición no idempotente (una llamada de pago o pedido puede reenviarse en una redirección; añade salvaguardas de idempotencia). Usa 302 para redirecciones GET simples — geo/idioma, la propia recomendación explícita de Google para las pruebas A/B, y (ejemplo de Mueller) móvil↔escritorio. Las redirecciones de mantenimiento dependen de si hay un recurso real al que enviar a los visitantes; una caída completa a menudo se gestiona mejor con un 503.
• Los valores predeterminados de los frameworks son específicos de versión/contexto, no universales. Next.js documenta 303 para Server Actions y 307 en otros contextos — comprueba tu versión en lugar de asumir que otros frameworks o CDN se comportan de la misma manera.
• El “307 fantasma” de HSTS: un 307 en la pestaña Network de tu navegador a menudo es Chrome actualizando HTTP→HTTPS por sí mismo (HSTS), no una respuesta del servidor — y la etiqueta exacta “307” es una elección de interfaz específica de la versión de Chrome, no un requisito de la especificación HTTP/HSTS. Mueller: “Your server’s not returning a 307, Chrome is just showing it to you as such.” (traducción) «Tu servidor no está devolviendo un 307, Chrome simplemente te lo muestra como tal.»
• Bing: no existe orientación diferenciada sobre 302 vs 307 — no asumas paridad, y no asumas que su comportamiento de “repeated 302 → treated as 301” (traducción) «302 repetido → tratado como 301» se aplique a 307.
• Ninguno de los dos códigos se puede almacenar en caché de forma predeterminada solo por su estado (RFC 9111) — el almacenamiento en caché sigue dependiendo de los encabezados Cache-Control/Expires explícitos.
• El orden preferido de Patrick para las redirecciones temporales: 307 / 302 / 303 por encima de meta/HTTP refresh — aunque usar 307 de forma predeterminada en todas partes no es automáticamente gratuito; comprueba primero los encabezados de caché, la compatibilidad con clientes antiguos y las salvaguardas de idempotencia.

Documentación oficial

Documentación y especificaciones de fuentes primarias.

Google

• Códigos de estado HTTP, errores de red y DNS, y Google Search — la fila de 302 “weak signal” (traducción) «señal débil», la fila de 307 “Equivalent to 302” (traducción) «Es equivalente a 302» y la advertencia “semantically different — use the appropriate code” (traducción) «semánticamente diferente — usa el código apropiado».
• Redirecciones y Google Search — agrupa 302, 303 y 307 como “temporary redirects” (traducción) «redirecciones temporales» y explica cómo afecta cada una a la canonicalización.
• Search Off the Record, episodio 51 — “Hablemos de redirecciones” (John Mueller + Martin Splitt) — la conversación pública sobre por qué existen 307/308 y cuándo son importantes.
• John Mueller — Guía para motores de búsqueda sobre 301, 302, 307 y otras redirecciones — el comportamiento de indexación de 302 (la URL de origen “R” tiende a indexarse; la redirección no se almacena en caché).
• John Mueller — 307s — la explicación de HSTS “phantom 307” (traducción) «307 fantasma».

Bing / Microsoft

• Gestión de redirecciones — 301s, 302s y canónicas (oct. 2011) — el enfoque de Bing de 301 para permanentes y 302 para temporales (sin mención de 307).
• Migración de sitios con Bing (dic. 2020) — orientación general sobre el traslado de sitios (de nuevo, sin una declaración específica sobre 307).

Especificaciones

• MDN — Redirección temporal 307 — la definición de preservación del método y del cuerpo, y la nota histórica sobre los clientes antiguos que cambian el método a GET.
• RFC 9110 — Semántica HTTP — §15.4.8 “307 Temporary Redirect” y §15.4.3 “302 Found,” el texto actual de la especificación para ambos códigos.

Citas de la fuente

Declaraciones oficiales de Google, además de la especificación. Cuando la página de origen lo permite, cada enlace es un enlace profundo que salta al fragmento citado.

Documentación de Google — 307 es equivalente a 302

• “Equivalent to 302.” (traducción) «Es equivalente a 302.» (la fila de 307) — Google Search Central. Ir a la cita
• “While Google treats these status codes the same way, keep in mind that they’re semantically different. Use the status code that’s appropriate for the redirect so other clients (for example, e-readers, other search engines) may benefit from it.” (traducción) «Aunque Google trata estos códigos de estado de la misma manera, ten en cuenta que son semánticamente diferentes. Usa el código de estado apropiado para la redirección para que otros clientes (por ejemplo, lectores de libros electrónicos, otros motores de búsqueda) puedan beneficiarse de ello.» Ir a la cita
• “Googlebot follows the redirect, but the indexing pipeline doesn’t use the redirect as a signal that the redirect target should be canonical.” (traducción) «Googlebot sigue la redirección, pero la canalización de indexación no usa la redirección como una señal de que el destino de la redirección debería ser canónico.» (redirecciones temporales, que incluyen 302/303/307) Ir a la cita

John Mueller (Google) (programa «Fuera de registro de la Búsqueda», episodio 51; PDF de la transcripción oficial, citado por fragmento — no hay ninguna página HTML con un texto de anclaje coincidente, por lo que no es posible un enlace profundo #:~:text= para estos)

• “I had to look this up recently. And usually, with a 301 and 302, what is forwarded are GET requests.” (traducción) «Tuve que buscar esto recientemente. Y normalmente, con una 301 y una 302, lo que se reenvía son solicitudes GET». … “And with 307, 308, it also forwards POST requests.” (traducción) «Y con 307, 308, también se reenvían solicitudes POST».
• “If you have some kind of an API that uses POST requests, or if you have a— I’d almost say like a broken setup, that you have a form on one domain and the results are forwarded to a different one, then you would use the 307, 308.” (traducción) «Si tienes algún tipo de API que usa solicitudes POST, o si tienes una— casi diría como una configuración rota, en la que tienes un formulario en un dominio y los resultados se reenvían a otro diferente, entonces usarías las 307, 308».
• “I guess from a completeness point of view, if you always use them, then you’re always safe. But that’s the difference there. I think for SEO, it doesn’t really matter. It’s more like, I don’t know… Does it work for APIs or not? And usually, APIs are not something that you need to have indexed directly in Search.” (traducción) «Supongo que desde un punto de vista de exhaustividad, si siempre las usas, entonces siempre estás a salvo. Pero esa es la diferencia ahí. Creo que para SEO, realmente no importa. Es más como, no sé… ¿Funciona para APIs o no? Y normalmente, las APIs no son algo que necesites tener indexado directamente en Search».
• “And for that kind of redirect [mobile/desktop], from a technical point of view, a 302 redirect would be the right one because next time someone goes there, you don’t really know if they want to go to the mobile version or the desktop version.” (traducción) «Y para ese tipo de redirección [móvil/escritorio], desde un punto de vista técnico, un 302 redirect sería el adecuado porque la próxima vez que alguien vaya allí, realmente no sabes si quiere ir a la versión móvil o a la versión de escritorio». Transcripción PDF

John Mueller (Google) (sitio johnmu.com — el «307 fantasma» de HSTS)

• “After seeing the HTTPS URL with the HSTS header (for example, with any redirect from the HTTP version), Chrome will act like it’s seeing a 307 redirect the next time you try to access the HTTP page.” (traducción) «Después de ver la URL HTTPS con el encabezado HSTS (por ejemplo, con cualquier redirección desde la versión HTTP), Chrome actuará como si viera un HTTP 307 la próxima vez que intentes acceder a la página HTTP.»
• “Your server’s not returning a 307, Chrome is just showing it to you as such to explain that it’s doing the redirect for you.” (traducción) «Tu servidor no está devolviendo un HTTP 307; Chrome simplemente te lo muestra como tal para explicar que está realizando la redirección por ti.» Leer la publicación

MDN — la diferencia de preservación del método

• “The difference between 307 and 302 is that 307 guarantees that the client will not change the request method and body when the redirected request is made. With 302, older clients incorrectly changed the method to GET.” (traducción) «La diferencia entre 307 y 302 es que 307 garantiza que el cliente no cambiará el método de solicitud y el cuerpo cuando se realice la solicitud redirigida. Con 302, los clientes antiguos cambiaban incorrectamente el método a GET.» Ir a la cita

¿Qué redirección temporal: 302 o 307?

Dado que ambos son temporales y equivalentes para SEO, toda la decisión se reduce a una pregunta: ¿la solicitud incluye un método o un cuerpo que debes preservar?

Una nota sobre la ruta “not sure”: Google procesa 307 de la misma manera que 302 y también funciona bien para redirecciones GET simples, por lo que usarlo por defecto no es incorrecto, pero tampoco es automáticamente gratuito. Confirma tus encabezados de caché, comprueba que los clientes antiguos que aún admitas manejen 307 de manera predecible y, si la solicitud redirigida tiene efectos secundarios (una llamada que no sea GET a una API), no permitas que un 307 automático la replique sin salvaguardas de idempotencia.

Errores de redirecciones temporales que debes evitar

Elige 302 porque supuestamente 307 transmite menos valor

Google documenta 307 como equivalente a 302 para la búsqueda. Elige entre ellos por el comportamiento de la solicitud, no por el posicionamiento.

Asume que el 302 siempre es más seguro porque es más antiguo

Los clientes antiguos hacían ambiguo el manejo del método en 302. Si un POST, PUT, DELETE, webhook o cuerpo de API debe conservarse, usa 307 para la garantía explícita de preservación.

Trata cada 307 de DevTools como una regla del servidor

Chrome puede mostrar una actualización interna de HSTS como 307 aunque el servidor nunca haya devuelto una. Reproduce la solicitud con una herramienta de comprobación del lado del servidor o curl antes de editar la configuración de redirección.

Afirmación: cada 302 convierte POST en GET

El comportamiento histórico está permitido y es ambiguo, no está garantizado en todos los clientes modernos. Usa 307 cuando necesites certeza; no describas todas las implementaciones de 302 como rotas.

Reemplaza cada 302 por un 307 para obtener una ganancia de SEO

No hay ninguna ventaja de posicionamiento. Cambia el código solo en los casos en que preservar el método/cuerpo mejore la corrección o en los que un valor predeterminado más seguro del framework sea apropiado.

Confundir 303 con 307

Son opuestos funcionales en la gestión del método: 303 cambia deliberadamente la solicitud de seguimiento a GET; 307 preserva el método y el cuerpo originales.

Diagnostica un 307 inesperado o un flujo de 302 roto

DevTools muestra un Internal Redirect / 307 inexplicable

Síntoma: Una navegación http:// aparece como http 307 en Chrome, pero no existe ninguna regla de redirección.

Causa probable: HSTS actualizó la solicitud dentro del navegador antes de que llegara al servidor.

Solución: Comprueba el iniciador y las cabeceras de la entrada, y luego envía una solicitud que no siga automáticamente las redirecciones directamente a la URL HTTP con una herramienta del lado del servidor, no con tu navegador, ya que incluso una ventana de incógnito nueva puede aplicar el estado HSTS precargado. Tampoco trates curl como una línea base automáticamente neutral: puede tener su propio almacén HSTS configurado, así que anota cómo lo invocaste. Si la respuesta sin procesar del servidor difiere de lo que mostró DevTools, no «corrijas» el http 307 fantasma; audita por separado la redirección real del servidor de HTTP→HTTPS y reproduce cualquier solicitud que no sea GET como su propia prueba controlada: una solicitud HEAD que sigue automáticamente no puede demostrar el comportamiento de POST/cuerpo.

Un POST pierde su cuerpo después de una redirección temporal

Síntoma: Un formulario, webhook, inicio de sesión o llamada de API llega al destino como GET o sin su carga útil.

Causa probable: El origen usó 302, lo que permite al cliente cambiar el método, o un intermediario reescribió la respuesta.

Solución: Usa 307 para el traslado temporal, luego vuelve a enviar una solicitud de prueba segura y confirma en los registros de destino que el método, el tipo de contenido y el cuerpo llegaron intactos.

La plataforma emite 307 aunque seleccionaste una redirección genérica

Síntoma: Un framework o plataforma de edge devuelve 307 en lugar del 302 esperado.

Causa probable: La plataforma eligió el código temporal que preserva el método, a menudo para una solicitud que no es GET.

Solución: Verifica que el traslado sea realmente temporal y que preservar la solicitud sea correcto. Si es así, mantenlo: Google trata los códigos igual. Cámbialo solo cuando la semántica de la aplicación o la compatibilidad del cliente requieran una respuesta diferente.

302 vs. 307 de un vistazo

Regla general: un GET ordinario para una página temporal → cualquiera de los dos funciona; una solicitud temporal que no sea GET que deba llegar intacta → 307.

Herramientas para identificar la redirección que realmente recibiste

Herramienta gratuita de Patrick

• Comprobador masivo de códigos de estado HTTP — realiza solicitudes del lado del servidor para hasta 500 URL y revisa los códigos y las cadenas de redirecciones reales. Es especialmente útil para separar las respuestas del servidor de la visualización interna de 307 de Chrome basada solo en HSTS.

Inspecciona el comportamiento de la solicitud

• Redirect Checker — rastrea una única fuente a través de cada salto y confirma si el servidor comienza con 302 o 307.
• Panel Network de las DevTools del navegador — inspecciona el iniciador y si Chrome etiqueta una entrada como redirección interna; no trates eso por sí solo como prueba de una respuesta del servidor.
• curl más registros de la aplicación — envía un POST seguro a staging y confirma que el destino recibe el mismo método y cuerpo; si configuraste curl con su propio almacén HSTS (--hsts), tenlo en cuenta al interpretar el resultado. Las herramientas que solo muestran el estado no pueden probar la llegada de la carga útil.

Ponte a prueba: 302 vs. 307

Cinco preguntas sobre las dos redirecciones temporales y lo que realmente las diferencia. Elige una respuesta para cada una y luego comprueba.

Recursos que valen tu tiempo

Mis artículos relacionados

• 11 tipos de redirecciones y su impacto en SEO (Ahrefs, con Joshua Hardwick) — mi repaso completo de cada tipo de redirección. Allí expongo mi orden preferido de implementación para las redirecciones temporales — 307 / 302 / 303 por encima de meta refresh 0 / actualización HTTP 0 — y dejo claro el veredicto de SEO: “For SEO, it’s the same, but if you have data being sent through forms that redirect, then you don’t want to be swapping between GET and POST.” (traducción) «Para SEO, es lo mismo, pero si tienes datos que se envían a través de formularios que redirigen, entonces no quieres estar alternando entre GET y POST.»
• Códigos de estado HTTP y su impacto en SEO (Ahrefs) — mi referencia para cada código de estado, incluidos los dos significados distintos de 307 (redirección temporal frente a la política HSTS 307) y la nota de que con HSTS, “Google won’t see the 307 because it’s cached in the browser.” (traducción) «Google no verá el 307 porque está almacenado en caché en el navegador.»
• La guía para principiantes de SEO técnico — dónde encajan las redirecciones en el panorama general.

Mis ponencias

• Patrick Stox en SlideShare y Speaker Deck — mis charlas de SEO técnico, varias de las cuales tratan sobre redirecciones y canonicalización. (Se aplica mi descargo de responsabilidad habitual: “This is my understanding of systems… not going to be 100% complete or accurate.” (traducción) «Esta es mi comprensión de los sistemas… no va a ser 100% completa ni precisa.»)

Oficial

• Google — Códigos de estado HTTP, errores de red y DNS — la línea “Equivalent to 302” (traducción) «Es equivalente a 302» y la advertencia “semantically different, use the right code” (traducción) «semánticamente diferentes, usa el código correcto».
• Google — Redirecciones y Google Search — agrupa 302/303/307 como redirecciones temporales.
• Search Off the Record — “Hablemos de redirecciones” (Google Search Relations, ep. 51) — la discusión de Mueller/Splitt de la que proceden las citas anteriores.

De la industria

• John Mueller — 307s — la explicación más clara que existe sobre el “phantom 307” (traducción) «307 fantasma» de HSTS: el 307 que tu navegador muestra pero que tu servidor nunca envió.
• MDN — 307 Temporary Redirect — la definición clara de preservación del método y del cuerpo, y la nota histórica sobre clientes antiguos.
• Una guía de redirecciones para SEO (Helen Pollitt; publicación Search Engine Land) — una visión general sólida de la familia de redirecciones.
• Redirecciones de URL para SEO: una guía técnica (Search Engine Journal) — otro buen resumen técnico.
• Un mito por corregir: la página “302 vs 307” de Conductor recomienda usar 302 en lugar de 307 porque “it’s clear how search engines treat the 302 redirect.” (traducción) «está claro cómo tratan los motores de búsqueda la redirección 302». Ese consejo contradice la propia documentación de Google, que explícitamente describe 307 como “Equivalent to 302” (traducción) «Es equivalente a 302» — el tratamiento de 307 está igualmente documentado. No trates como autorizada “302 is the safer SEO choice” (traducción) «302 es la opción de SEO más segura»; el único factor de decisión real es si necesitas preservar el método y el cuerpo.
• r/TechSEO — la comunidad para la depuración de redirecciones y de canonicalización.

Registro de cambios