Redirección permanente 308

TL;DR — Un 308 Permanent Redirect dice «esto se trasladó para siempre» — exactamente igual que un 301 — pero con una promesa adicional: el método de solicitud no se puede cambiar en la nueva dirección, y como el navegador repite la misma solicitud en lugar de una nueva, el resto de esta (incluidos los datos de un formulario) normalmente también viaja. Así, un envío de formulario sigue siendo un envío de formulario en lugar de convertirse silenciosamente en una simple visita a una página. Para los motores de búsqueda, ambos códigos son idénticos, por lo que para una redirección normal de «esta página se trasladó», un 301 está bien. Usa un 308 cuando estés redirigiendo algo que no es solo una página en la que alguien hace clic — como una API o un formulario — y la solicitud original tiene que llegar intacta.

Qué es realmente un 308

Cuando un servidor envía a tu navegador de una URL a otra, marca la respuesta con un número — un código de estado. Un par de esos números significan «esta página se ha trasladado de forma permanente»:

• 301 — “Moved Permanently.” El código original y más antiguo de redirección permanente. Ha existido desde los inicios de la web.
• 308 — “Permanent Redirect.” Un código más nuevo (añadido a la especificación en 2015) que cumple la misma función más una garantía que el 301 nunca ofreció.

Esa garantía es la razón principal por la que existe el 308. La mayoría de las veces, cuando visitas una página, tu navegador envía una solicitud simple llamada GET — _“please give me this page.” (traducción) «por favor, dame esta página.» Pero cuando envías un formulario o inicias sesión, tu navegador envía un POST — una solicitud que transporta datos (lo que escribiste). Con un 301 antiguo, técnicamente el navegador puede convertir tu POST en un simple GET en el camino hacia la nueva URL, lo que normalmente significa que esos datos se descartan. Un 308 no puede cambiar el método de esa manera. Como el navegador está repitiendo la misma solicitud en lugar de hacer una nueva, los datos normalmente viajan con ella, pero si eso importa para algo que estás construyendo (una llamada de API, un flujo de pago), no te fíes únicamente de lo que dice la especificación: prueba la solicitud real y confirma que el cuerpo llega a la nueva URL.

¿Un 308 perjudica al SEO?

No. La propia documentación de Google dice literalmente que un 308 es _“Equivalent to 301.” (traducción) «Equivalente a 301.» Ambas son redirecciones permanentes, y ambas transmiten las señales de posicionamiento de una página a la nueva URL de la misma manera. Bing también las trata igual. No hay ninguna bonificación de posicionamiento por usar un 308, ni ninguna penalización — la elección entre ambos se trata del comportamiento técnico anterior, no del posicionamiento en buscadores. Evidence for this claim Google treats 308 as equivalent to 301 for Search and groups both as permanent redirects. Scope: Google Search processing; the two status codes remain semantically different for HTTP clients. Confidence: high · Verified: 2026-07-14 Google: HTTP status codes and Search Google: Redirects and Google Search

Entonces, ¿cuándo deberías usar uno?

Para una página normal que se trasladó —una URL nueva, un cambio de http a https, un cambio de dominio —, una redirección 301 simple es la opción fácil y universal. Todos los navegadores, complementos y herramientas de alojamiento la entienden.

Usa un 308 específicamente cuando lo que estás redirigiendo no es una página simple:

• Una API a la que otro software llama.
• Un formulario o inicio de sesión que envía datos.
• Un webhook: una URL automatizada a la que otro servicio envía datos.

En esos casos no puedes permitirte que la solicitud se degrade silenciosamente y que los datos se pierdan, y un 308 garantiza que eso no ocurrirá.

¿Quieres el historial de la especificación, las citas exactas de Google y Bing, y fragmentos de servidor para copiar y pegar? Cambia a la pestaña Avanzado.

TL;DR — Un 308 es la redirección permanente que preserva estrictamente el método: la misma señal de canonicalización que un 301 (los documentos de Google dicen “Equivalent to 301” (traducción) «Equivalente a `301»*/), pero garantiza que el cliente no cambie el método en la nueva URL — y, dado que un cliente conforme repite la misma solicitud en lugar de una nueva, el cuerpo viaja junto con ella. Existe porque HTTP tenía un código temporal que preservaba el método (307) años antes de que tuviera uno permanente — RFC 7538 (2015) llenó ese vacío, y RFC 9110 ahora apunta a 308 directamente desde su propia definición de 301. Para SEO, ambos son intercambiables (Illyes: Google “merges” (traducción) «fusiona» 308 con 301; Canel, de Bing, confirma la paridad). Recurre a 308 cuando una solicitud que no sea GET debe sobrevivir: migraciones de API/versión, URL de webhook, flujos de POST de autenticación/formulario — pero verifica la preservación del método y del cuerpo con tu propio cliente en lugar de asumirlo solo por la especificación. De lo contrario, 301 sigue siendo la opción predeterminada — la compatibilidad de los navegadores con 308 es sólida en 2026 (caniuse actualmente registra ~96,5 % o más), pero el propio RFC 9110 todavía señala 308 como más reciente y no universalmente reconocido, y algunos plugins de CMS, las interfaces de reglas de edge y los proxies heredados todavía solo exponen 301/302/307.

Qué significa 308, mecánicamente

Un 308 Permanent Redirect transmite el mismo mensaje que un 301 —este recurso ahora reside en una nueva URL, de forma permanente— con un añadido que el 301 nunca garantizó: el cliente no debe cambiar el método de solicitud en el destino. Como el cliente está repitiendo la misma solicitud en lugar de emitir una nueva, el cuerpo viaja junto con ella en un cliente compatible con la especificación — eso es una consecuencia de la garantía del método, no una promesa certificada por separado, así que trátalo como algo que debes verificar de extremo a extremo para tu propio cliente y servidor en lugar de asumirlo sin más. MDN describe 308 como el código que mantiene el método de solicitud (y, en la práctica, el cuerpo) sin cambios a través de la redirección, mientras que un 301 puede que no.

La versión en lenguaje sencillo que uso en la guía de redirecciones de Ahrefs: “A 308 redirect is the same as a 301 redirect, except it retains the HTTP method of the original request, GET or POST, when performing the redirect.” (traducción) «Una redirección 308 es igual que una redirección 301, excepto que conserva el método HTTP de la solicitud original, GET o POST, al realizar la redirección.» O, aún más breve, en la guía de códigos de estado HTTP: “308 Permanent Redirect – Has the same functionality as a 301 redirect, except you can’t switch between POST and GET.” (traducción) «308 Permanent Redirect – Tiene la misma funcionalidad que una redirección 301, excepto que no puedes alternar entre POST y GET.» Evidence for this claim RFC 7538 defines 308 Permanent Redirect as a permanent move whose redirect follow-up must not change the request method. Scope: HTTP semantics for 308 responses. Confidence: high · Verified: 2026-07-14 IETF: RFC 7538 §3 — 308 Permanent Redirect

Esta es la diferencia de forma concreta. Supongamos que un cliente envía un pedido mediante POST a /api/orders con un cuerpo JSON:

POST /api/orders HTTP/1.1
Host: shop.example.com
Content-Type: application/json

{ "sku": "A-100", "qty": 2 }

Si ese endpoint responde con un 301 y el cliente respeta el permiso heredado de «puedes cambiar a GET», la solicitud puede llegar a la nueva URL como un GET vacío — el cuerpo desaparece, la orden se pierde. Responde con un 308 y el cliente debe repetir el POST en la nueva URL; un cliente compatible lleva el cuerpo consigo, por lo que la orden se completa — confírmalo en tus propios registros de cliente y servidor (consulta la pestaña Scripts) en lugar de asumirlo universalmente. Esa es toda la distinción práctica: solo surge cuando la solicitud original no era un GET simple.

Por qué existe 308 — la historia de la especificación

Esta es la parte que la mayoría de las explicaciones omiten, y es la forma más clara de entender el código.

El 307 fue primero. HTTP ya tenía una redirección temporal que preserva el método — el 307 — mucho antes de tener un equivalente permanente. La especificación principal original (RFC 7231) nunca definió una contraparte permanente del 307. Así que existía un código temporal de «conservar el método» y un código permanente de «puedes cambiar el método» (301), pero ningún código permanente de «conservar el método».

RFC 7538 llenó el vacío. El 308 se añadió específicamente para ser el 307 permanente que faltaba — primero como experimental RFC 7238 (junio de 2014), luego estandarizado como RFC 7538 (abril de 2015). Es un parche para un hueco real, no un reemplazo de 301.

La especificación actual apunta directamente a ello. RFC 9110, la especificación de semántica HTTP actual, todavía documenta la ambigüedad integrada de 301 — y luego nombra a 308 como la solución, dentro de su propia definición de 301: un agente de usuario “MAY change the request method from POST to GET for the subsequent request… If this behavior is undesired, the 308 (Permanent Redirect) status code can be used instead.” (traducción) «PUEDE cambiar el método de solicitud de POST a GET para la solicitud posterior… Si este comportamiento no se desea, se puede usar en su lugar el código de estado 308 (Permanent Redirect).» Esa única oración es la razón completa por la que existe 308, directamente de la especificación autoritativa. Y en su propia sección de 308, RFC 9110 añade la única advertencia honesta: este código “is much younger (June 2014) than its sibling codes and thus might not be recognized everywhere.” (traducción) «es mucho más joven (junio de 2014) que sus códigos hermanos y, por lo tanto, podría no ser reconocido en todas partes.»

Así que el comportamiento de POST a GET de 301 no es un error — es una concesión documentada “for historical reasons” (traducción) «por razones históricas» integrada en la especificación, y 308 es la forma oficialmente aprobada de excluirse de él.

301 vs 308 — la diferencia práctica en una tabla

Conclusión: para la gran mayoría de las redirecciones —que son GET simples—, un 301 y un 308 hacen exactamente lo mismo. La garantía solo vale la pena cuando hay en juego un método que no es GET con un cuerpo. (Para ver la comparación completa, consulta la comparación dedicada entre 301 y 308.)

¿Google trata el 308 igual que el 301 para el SEO?

Sí, sin ambigüedades, y está documentado. El documento sobre códigos de estado HTTP de Google enumera 301 como una redirección que Google “use[s]… as a strong signal that the redirect target should be processed,” (traducción) «utiliza… como una señal fuerte de que el destino de la redirección debería procesarse», y enumera 308 simplemente como “Equivalent to 301.” (traducción) «Equivalente a 301.» Añade una advertencia razonable: “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 procesa igual, pero siguen teniendo semánticas distintas; elige el estado adecuado para que también puedan aprovecharlo otros clientes, como lectores electrónicos y motores de búsqueda.» En términos sencillos: Google no te penalizará por usar el «equivocado», pero aun así deberías usar el que es correcto para la solicitud, porque otro software depende de la distinción.

La documentación de redirecciones de Google sitúa ambos códigos en el mismo nivel recomendado: “The 301 and 308 status codes mean that a page has permanently moved to a new location.” (traducción) «Los códigos de estado 301 y 308 significan que una página se ha trasladado permanentemente a una nueva ubicación.» Y su guía de migración web menciona explícitamente el 308 en lugar de tratarlo como una consideración posterior al 301: la recomendación es usar redirecciones HTTP permanentes “such as 301 and 308” (traducción) «como 301 y 308» al realizar una migración permanente.

Vale la pena saberlo: esta paridad no siempre estuvo documentada. Gary Illyes ha dicho que Google fusiona 308 con 301 internamente, y la cobertura de Search Engine Roundtable presenta el momento en que apareció en la documentación oficial como el punto en que un comentario informal finalmente se convirtió en algo en lo que podías confiar — los propietarios de sitios que preguntaron “is this actually documented?” (traducción) «¿está esto realmente documentado?» hace unos años tenían razón al ser cautelosos aunque el comportamiento subyacente nunca cambió. Si quieres la redacción exacta de Google y sus representantes, la pestaña Citas tiene citas destacadas verificadas y enlaces profundos.

¿Bing trata el 308 igual que el 301?

Sí. Bing no tiene una página de documentación dedicada que detalle el 308 de la forma en que lo hace Google, pero Fabrice Canel de Microsoft lo confirmó directamente en X en septiembre de 2024, según informó Search Engine Roundtable: Bing trata las redirecciones 308 igual que las redirecciones 301. Esa es la declaración autorizada de Bing; consulta la pestaña Citas para ver la línea textual.

Cuándo usar realmente un 308

Aquí es donde reside el caso independiente de 308, y casi siempre es una solicitud que no es GET.

Migraciones de endpoints y versiones de API. Mover /v1/ a /v2/, o reubicar un host de API, es el caso de libro. Los clientes acceden a estos endpoints con POST/PUT/PATCH/DELETE y cuerpos reales. Un 308 garantiza que el método y la carga útil sobrevivan al salto; un 301 entraña el riesgo de una degradación silenciosa que deja varada la solicitud.

Migraciones web con mucho uso de POST. Los flujos de pago, los endpoints de inicio de sesión/autenticación y los destinos de acción de formulario envían datos por POST. Si alguna de esas URL se mueve durante una migración, un 308 mantiene intacto el envío, mientras que un 301 podría no hacerlo.

Cambios de URL de webhook. Cuando otro servicio envía por POST a una URL de webhook que estás reubicando, un 308 le indica a su cliente HTTP que vuelva a enviar por POST a la nueva dirección con el cuerpo intacto, exactamente lo que un consumidor de webhook necesita.

El hilo conductor: usa un 308 en cualquier lugar donde perder el cuerpo o que el método cambie silenciosamente a GET rompería la funcionalidad, no solo redistribuiría un poco de valor de SEO.

Antes de activar cualquiera de estos, pruébalo como una integración, no solo como un código de estado:

• Reenvía el método real y la carga útil contra una copia de staging del nuevo endpoint.
• Confirma si los encabezados de autorización o las cookies deberían conservarse y comprueba que realmente se conservan.
• Si la solicitud original no es idempotente (un POST que crea un pedido, por ejemplo), vigila los efectos secundarios duplicados durante el salto de redirección.
• Confirma que la cadena de consulta y el encabezado Content-Type se conserven, no solo el cuerpo.
• Verifica que el cliente real —el remitente del webhook, el SDK de API, el navegador— siga automáticamente un 308 antes de retirar el endpoint antiguo. No todos los clientes HTTP lo hacen de forma predeterminada.

Cuando 301 sigue siendo la opción predeterminada pragmática

Para todo lo que sea un GET simple, 301 sigue siendo la opción predeterminada sensata:

• Cambios ordinarios de URL de contenido/página.
• Migraciones de HTTP → HTTPS.
• Cambios de dominio y migraciones web estándar.
• Normalización de Trailing-slash y de www/sin www.

Aquí la solicitud es un GET simple, por lo que la garantía de 308 no te aporta nada — y 301 gana en universalidad. Ninguna de las dos opciones tiene un costo de SEO. No migres masivamente los 301 existentes a 308 buscando un aumento de posiciones; esa ventaja no existe. Ten en cuenta que, en la jerarquía de preferencia de redirección de la guía de redirecciones de Ahrefs, 308 y 301 están juntos en el nivel más alto (por delante de meta refresh, JavaScript y otras soluciones alternativas) — son equivalentes, no una escalera.

Advertencias sobre adopción y compatibilidad — qué es realmente un riesgo en 2026

La compatibilidad de los navegadores ya no es el riesgo práctico que era antes. Según el seguimiento actual de caniuse, 308 se sitúa alrededor de 96,5 % o más de compatibilidad global —consulta la tabla en vivo para ver la cifra de hoy, ya que cambia— y las brechas visibles se concentran en navegadores que llevan años muertos: anteriores a IE11, Chrome/Firefox/Safari antiguos, Android Browser antiguo. Si aún ves flotando por ahí la antigua advertencia “IE11 fails on 308” (traducción) «IE11 falla en 308» está desactualizada para el tráfico mayoritario.

Las herramientas son la salvedad más actual. La brecha honesta, vigente en 2026, es que no todas las capas exponen una opción 308. Algunos plugins de redirección de CMS, algunas interfaces de reglas de redirección de CDN/edge y algunos proxies inversos o balanceadores de carga más antiguos todavía solo te permiten elegir 301/302/307. Antes de optar por 308, verifica que la capa que realmente sirve la redirección pueda emitirla en lugar de degradarla silenciosamente — la pestaña Scripts tiene una línea de código para confirmar el código de estado HTTP real en la red. La nota del propio RFC 9110 “much younger… might not be recognized everywhere” (traducción) «mucho más joven… podría no ser reconocido en todas partes» no se limita solo a los navegadores — es la cautela general de despliegue de la especificación para 308. En 2026, el impacto práctico de esa cautela se manifiesta principalmente en las herramientas en lugar de los navegadores mayoritarios, pero vale la pena leerla como la salvedad de base de la especificación en lugar de como algo completamente retirado.

Una nota al pie no estándar: “308 Resume Incomplete”

Una peculiaridad que subraya lo joven que es todavía este código: 308 no es solo un código de redirección en el mundo real. La API de subida de Google Drive reutiliza 308 con un significado completamente diferente — “Resume Incomplete”, que señala que una subida por fragmentos se detuvo y el cliente debería reanudarla. John Mueller lo señaló él mismo (consulta la pestaña Citas), y MDN documenta el mismo uso no estándar. Esto no cambia nada sobre 308 como redirección, pero es una buena ilustración de que 308 es un código de estado más nuevo y menos “asentado” culturalmente que el venerable 301.

Las cadenas de redirecciones y los saltos se aplican igual en ambos casos

Nada de lo anterior cambia cómo funcionan las cadenas de redirecciones. Los rastreadores de Google siguen hasta 10 saltos de redirección de forma predeterminada — aunque ese es el valor predeterminado, no una constante universal; la propia documentación de Google señala que productos específicos pueden diferir (su herramienta de inspección de url, por ejemplo, no sigue redirecciones en absoluto), así que comprueba la cifra actual en la documentación de Google en lugar de tratar 10 como fijo para siempre. Ese límite predeterminado es idéntico ya sea que los saltos sean redirecciones 301s o 308s. Si estás acumulando redirecciones (por ejemplo, una ruta de API antigua que da dos saltos antes de aterrizar), se aplica la misma higiene de cadenas de redirecciones y bucles de redirección: contrae las cadenas a un solo salto donde puedas. Consulta el artículo dedicado a las cadenas de redirecciones para ver la mecánica.

Resumen de IA

Una visión condensada de la versión avanzada:

• 308 = permanente + conservación estricta del método. El mismo mensaje “moved permanently” (traducción) «movido permanentemente» que un 301, más una garantía que el 301 nunca hizo: el cliente no debe cambiar el método de solicitud en la nueva URL. Un cliente conforme repite la misma solicitud, por lo que el cuerpo viaja junto con ella; verifica eso de extremo a extremo para tu propio cliente en lugar de asumirlo solo a partir de la especificación.
• Equivalente en SEO a 301. La documentación de Google dice que 308 es “Equivalent to 301” (traducción) «Equivalente a 301»; Gary Illyes dice que Google fusiona 308 en 301; Fabrice Canel de Bing confirma que Bing los trata de la misma manera. No hay ventaja ni penalización de posicionamiento en ningún sentido. (Atribución: esas declaraciones de Illyes/Mueller/ Canel se transmiten a través de Search Engine Roundtable; confírmalas con el original antes de tratarlas como definitivas).
• Por qué existe: HTTP tuvo una redirección temporal que conserva el método (307) años antes de tener una permanente. RFC 7538 (2015) llenó ese vacío. RFC 9110 apunta a 308 desde su propia definición de 301: un 301 “MAY change the request method from POST to GET… for historical reasons,” (traducción) «PUEDE cambiar el método de solicitud de POST a GET… por razones históricas», y “if this behavior is undesired, the 308… can be used instead.” (traducción) «si este comportamiento no es deseado, se puede usar el 308… en su lugar».
• Usa 308 para: migraciones de API/versión, cambios de URL de webhook, flujos POST de formulario/autenticación — en cualquier lugar donde la pérdida del método/cuerpo rompería la funcionalidad. Antes de cambiar, reproduce el método real y la carga útil en un entorno de staging y confirma las cabeceras de autenticación, la idempotencia y el comportamiento real del cliente al seguir redirecciones.
• Usa 301 para: movimientos de página ordinarios, HTTP→HTTPS, cambios de dominio, normalización — todas solicitudes GET simples, donde la garantía de 308 no aporta nada y 301 gana en soporte universal.
• Adopción: el soporte en navegadores es sólido (caniuse actualmente registra ~96,5%+, con brechas principalmente en navegadores desaparecidos hace mucho tiempo), pero RFC 9110 todavía incluye una advertencia general “younger, might not be recognized everywhere” (traducción) «más joven, podría no ser reconocido en todas partes» para 308; en 2026 eso se manifiesta principalmente como una brecha de herramientas (algunos plugins de CMS, interfaces de CDN/edge y proxies heredados solo exponen 301/302/307). Verifica que la capa de redirección realmente pueda emitir 308 y ten en cuenta que 308 es almacenable en caché de forma heurística, por lo que un 308 erróneo o revertido puede persistir en las cachés.
• Nota al pie: Google Drive reutiliza “308 Resume Incomplete” para subidas interrumpidas — un uso que no es de redirección y que muestra lo joven que todavía es el código.

Documentación oficial

Documentación de fuentes primarias sobre 308 de los motores de búsqueda y la especificación HTTP.

Google

• Códigos de estado HTTP, errores de red y de DNS, y Google Search — enumera 308 como “Equivalent to 301,” (traducción) «Equivalente a 301,» con la advertencia “semantically different, treated the same” (traducción) «semánticamente diferente, tratado igual» y el límite de redirecciones de 10 saltos.
• Redirecciones y Google Search — “The 301 and 308 status codes mean that a page has permanently moved to a new location.” (traducción) «Los códigos de estado 301 y 308 significan que una página se ha trasladado permanentemente a una nueva ubicación.»
• Traslados de sitio con cambios de URL — recomienda redirecciones HTTP permanentes “such as 301 and 308” (traducción) «como 301 y 308» para un traslado permanente.

Especificación HTTP

• RFC 9110 — Semántica HTTP — la especificación actual. §15.4.9 define 308 (y la advertencia “much younger… might not be recognized everywhere” (traducción) «mucho más reciente… podría no ser reconocido en todas partes»); §15.4.2 define 301 y señala a 308 como la solución para la conversión no deseada de POST a GET.
• RFC 7538 — Código de estado HTTP 308 (Permanent Redirect) — el estándar que introdujo 308 (abril de 2015) y que dejó obsoleto al RFC experimental 7238 (junio de 2014).

Referencia

• MDN — 308 Permanent Redirect — semántica de preservación del método y del cuerpo, y el uso no estándar de Google Drive “Resume Incomplete”.
• caniuse — código de estado HTTP 308 — la tabla de compatibilidad de navegadores (~96,5 % o más mundial).

Citas de la fuente

Declaraciones oficiales de Google, Bing y la especificación HTTP. Cada enlace enlaza directamente al pasaje citado en la página de origen.

Google — la equivalencia principal

• “301 (moved permanently): Google follows the redirect, and Google systems use the redirect as a strong signal that the redirect target should be processed.” (traducción) «301 (movido permanentemente): Google sigue la redirección, y los sistemas de Google usan la redirección como una señal fuerte de que el destino de la redirección debería procesarse.» — Documentación de Google Search Central. Ir a la cita
• “308 (moved permanently): Equivalent to 301.” (traducción) «308 (movido permanentemente): Equivalente a 301.» 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 que sea apropiado para la redirección para que otros clientes (por ejemplo, lectores electrónicos, otros motores de búsqueda) puedan beneficiarse de ello.» Ir a la cita
• “The 301 and 308 status codes mean that a page has permanently moved to a new location.” (traducción) «Los códigos de estado 301 y 308 significan que una página se ha movido permanentemente a una nueva ubicación.» Ir a la cita

Gary Illyes, Google

• Sobre cómo Google maneja un 308: “we just merge that with 301 so we really don’t care iirc.” (traducción) «simplemente fusionamos eso con 301, así que realmente no nos importa, si recuerdo bien.» Difundido a través de la cobertura textual de Search Engine Roundtable, Google Officially Treats 308 Redirects As 301 Redirects (julio de 2021) — verifica con el original antes de considerarlo definitivo.

John Mueller, Google

• Sobre el uso no estándar: “Google Drive uses a 308 redirect as a Resume Incomplete response to indicate to the client when an incomplete upload stalled. So that is a bit different. But you can use it as a normal redirect.” (traducción) «Google Drive usa una redirección 308 como respuesta Resume Incomplete para indicar al cliente cuándo se detuvo una carga incompleta. Así que eso es un poco diferente. Pero puedes usarla como una redirección normal.» Difundido a través de Search Engine Roundtable, Google puede tratar las redirecciones 308 como redirecciones 301 (mayo de 2018) — verifica con el original antes de considerarlo definitivo.

Fabrice Canel, Microsoft Bing

• “I accidentally deleted my reply, so confirming again: Bing treats 308 redirects the same as 301 redirects.” (traducción) «Eliminé accidentalmente mi respuesta, así que confirmo de nuevo: Bing trata las redirecciones 308 igual que las redirecciones 301.» Fabrice Canel en X (septiembre de 2024), difundido a través de Search Engine Roundtable, Bing trata las redirecciones 308 igual que las redirecciones 301 — confírmalo con el original antes de considerarlo definitivo.

RFC 9110 — la especificación de semántica de HTTP

• Sobre por qué existe 308, de la propia definición de 301 en la especificación: “For historical reasons, a user agent MAY change the request method from POST to GET for the subsequent request. If this behavior is undesired, the 308 (Permanent Redirect) status code can be used instead.” (traducción) «Por razones históricas, un agente de usuario puede cambiar el método de solicitud de POST a GET para la solicitud posterior. Si este comportamiento no es deseado, se puede usar en su lugar el código de estado 308 (Permanent Redirect).» Leer RFC 9110
• Sobre la adopción: 308 “is much younger (June 2014) than its sibling codes and thus might not be recognized everywhere.” (traducción) «es mucho más reciente (junio de 2014) que sus códigos hermanos y, por lo tanto, podría no ser reconocido en todas partes.» Leer RFC 9110

¿Debería esta redirección ser un 308?

Dado que 301 y 308 son equivalentes en SEO, esta no es una decisión de posiciones — se reduce a una pregunta: ¿está en juego una solicitud que no es GET con un cuerpo, y puede tu capa de redirección realmente emitir un 308? Analízalo paso a paso.

La versión corta: GET simple → 301; una solicitud que no sea GET y que debes preservar (y que tu stack puede emitirla) → 308. Para SEO, ambos son intercambiables, así que la cuestión del método — además de una comprobación rápida de “¿mi herramienta realmente puede hacerlo?” — es lo único que lo decide.

Mitos y errores sobre 308

Extraído directamente de los modos de fallo que veo con más frecuencia.

“308 es mejor para SEO que 301.” Falso. La documentación de Google dice “Equivalent to 301,” (traducción) «Equivalente a 301,» y Illyes, Mueller y Canel de Bing confirman la paridad. Ningún motor trata 308 como superior para SEO. Elegirlo tiene que ver con la corrección del método/cuerpo, nunca con una ventaja en los rankings.

“You should migrate all your existing 301s to 308s.” (traducción) «Deberías migrar todas tus redirecciones existentes de tipo 301s a 308s». Pura agitación sin ningún beneficio en los rankings. Si las solicitudes redirigidas son GET simples — la abrumadora mayoría de las redirecciones de página a página — una redirección 301 ya se comporta de manera idéntica en la práctica. Reserva el cambio para las redirecciones que realmente conllevan métodos que no son GET.

“308 no es seguro porque es más nuevo.” Está exagerado en el caso de los navegadores específicamente: RFC 7538 tiene más de una década, tanto Google como Bing confirman soporte a nivel de motor, y caniuse muestra actualmente un soporte de navegador de ~96,5 % o más con brechas principalmente en versiones obsoletas desde hace mucho tiempo. RFC 9110 todavía incluye una advertencia general para 308: “younger, might not be recognized everywhere” (traducción) «más reciente, puede que no se reconozca en todas partes» — en 2026 eso se manifiesta principalmente como una brecha de herramientas (no todos los plugins de CMS, las interfaces de reglas de redirección de CDN o los proxies heredados exponen una opción 308) en lugar de una brecha de cliente o de motor de búsqueda, pero no es una advertencia que esté completamente retirada.

“Una 301 siempre alterará mi solicitud POST/API.” Exagerado. Muchos clientes modernos conservan el comportamiento razonablemente bien; el riesgo real, documentado en la especificación, es la conversión específica de POST a GET que RFC 9110 permite “por razones históricas”, lo cual causa problemas cuando un cliente respeta esa concesión heredada. 308 elimina el riesgo por completo — no corrige un fallo garantizado y universal.

“Un 308 es únicamente un código de redirección.” No exactamente. El “308 Resume Incomplete” no estándar de Google Drive reutiliza el código para una subida detenida — un significado completamente diferente. Es un buen recordatorio de que el uso real de 308 es más reciente y menos consolidado que el de 301.

Contraste adicional — “permanent redirects lose PageRank.” (traducción) «las redirecciones permanentes hacen perder valor de posicionamiento». No es el tema central de este artículo, pero merece una frase: la propia orientación de Google agrupa 301 y 308 como redirecciones permanentes que utiliza como señal para procesar la nueva URL como el objetivo de referencia — eso se interpreta como continuidad, no como una pérdida de valor. Trátalo como el comportamiento de procesamiento documentado de Google más que como una garantía general de que nunca se pierde valor de clasificación; el encuadre más estrecho, de señal de referencia, es el que realmente respalda la fuente actual.

Confirma e implementa un 308

Lo más útil que puedes hacer con 308 es verificar el código de estado real en la red — porque el fallo más común no es un problema del navegador, es una capa de herramientas que degrada silenciosamente tu 308 previsto a un 301 (o no emite ninguna redirección).

Comprueba el código de estado con curl

# Show only the response headers; -I sends a HEAD request.
curl -sI https://example.com/old-path | head -n 1
# → HTTP/1.1 308 Permanent Redirect     (what you want)
# → HTTP/1.1 301 Moved Permanently      (your layer downgraded it)

Para confirmar que el método realmente se conserva en una solicitud POST (el objetivo principal de un 308), sigue la redirección con -L y observa qué llega — -X POST más --data solo seguirá siendo un POST a través del salto si el servidor devolvió un 308/307:

curl -sIL -X POST --data '{"sku":"A-100"}' \
  -H 'Content-Type: application/json' \
  https://api.example.com/v1/orders
# Inspect each hop's request line; a 308 keeps it "POST", a 301 may show "GET".

Rastrea una cadena completa

Si la ruta da más de un salto, imprime cada código de estado de la cadena para que puedas detectar una degradación o un salto adicional no previsto:

curl -sIL https://example.com/old-path \
  | grep -iE '^HTTP/'
# Each line is one hop. Collapse chains to a single hop where you can.

Comprueba si un 308 está almacenado en caché antes de revertirlo

RFC 9110 hace que un 308 sea almacenable en caché de forma heurística — un cliente o intermediario puede decidir almacenarlo en caché incluso sin un encabezado Cache-Control explícito. Eso significa que un 308 erróneo (o uno que necesitas revertir) puede seguir sirviéndose desde una caché mucho después de que corrijas la regla de origen. Antes de concluir que una redirección está “atascada”:

• Prueba tanto con un cliente nuevo (privado/incógnito, sin visita previa) como con uno que ya haya accedido a la URL antigua — los clientes con caché y sin caché pueden comportarse de manera diferente.
• Comprueba en la respuesta los encabezados Cache-Control, Expires y Age con curl -sI.
• Prueba por separado un GET simple y una solicitud representativa que no sea GET; el comportamiento del almacenamiento en caché puede diferir según el método.
• Si necesitas revertir un 308, purga explícitamente la caché del edge/CDN — no des por sentado que eliminar la regla de origen es suficiente, y espera que algunos clientes que ya almacenaron en caché la redirección antigua no la vuelvan a solicitar por sí solos.

Consola de Chrome DevTools — comprueba una redirección desde el navegador

Pega esto en la consola de DevTools (F12 → Console) para ver la URL final y el estado sin salir de la página. Una llamada fetch con redirección manual informa directamente el estado de la primera respuesta:

// Reports the status of the first response (the redirect itself), not the target.
fetch('https://example.com/old-path', { method: 'HEAD', redirect: 'manual' })
  .then(r => console.log('type:', r.type, 'status:', r.status || '(opaqueredirect)'));

// Follow the chain and log where it lands:
fetch('https://example.com/old-path', { method: 'HEAD', redirect: 'follow' })
  .then(r => console.log('final URL:', r.url, 'final status:', r.status));

Bookmarklet — “¿qué devuelve esta URL?” con un clic

Arrastra un marcador con esta URL y luego haz clic en él en cualquier página para solicitar una URL y mostrar una alerta con su estado final y su URL de destino:

javascript:(function(){var u=prompt('URL to check:',location.href);if(!u)return;fetch(u,{method:'HEAD',redirect:'follow'}).then(function(r){alert('Final status: '+r.status+'\nLanded on: '+r.url);}).catch(function(e){alert('Error: '+e);});})();

Implementar un 308 en el servidor

Apache (.htaccess) — mod_rewrite con un R=308 explícito:

RewriteEngine On
RewriteRule ^old-path/?$ /new-path [R=308,L]

nginx — return 308 es exacto y no ambiguo:

location = /old-path {
    return 308 https://example.com/new-path;
}

Express.js (Node) — pasa el código de estado a redirect():

app.all('/api/v1/orders', (req, res) => {
  // 308 keeps the POST body intact on the way to /api/v2/orders
  res.redirect(308, '/api/v2/orders');
});

Next.js — establece permanent: true y emite un 308 (las redirecciones permanentes de Next son 308):

// next.config.js
module.exports = {
  async redirects() {
    return [
      { source: '/api/v1/:path*', destination: '/api/v2/:path*', permanent: true },
    ];
  },
};

El comportamiento del framework y de la capa de alojamiento no está fijo entre versiones. El manejo de redirecciones de Next.js, por ejemplo, puede diferir según la versión y según dónde se active la redirección: una entrada de redirects() en next.config.js, una llamada a permanentRedirect() en una Server Action, o una respuesta en streaming no necesariamente se resuelven todas al mismo código de estado. La misma precaución se aplica a las versiones de los módulos de Apache/nginx y a cualquier CDN o capa de proxy delante de tu origen. Trata cada fragmento anterior como un punto de partida, no como una garantía, y confirma la documentación actual de tu propia versión.

Después de implementar cualquiera de estos, vuelve a ejecutar la comprobación curl -sI anterior para confirmar que la red realmente transporta un 308; ese paso de verificación es el que las personas omiten y luego lamentan.

Herramientas para confirmar un 308 en la red

Herramientas gratuitas de Patrick

• Comprobador de redirecciones — rastrea una URL o un lote rápido y confirma que la primera respuesta es 308, que el destino es correcto y que la cadena de redirecciones termina en una respuesta final saludable.
• Comprobador masivo de códigos de estado HTTP — comprueba hasta 500 URL migradas, filtra respuestas 301/302/307 inesperadas y exporta cadenas de redirecciones o bucles de redirección para su corrección.

Demuestra el comportamiento estricto cuando es importante

• curl con una carga útil de prueba segura — reproduce el método real contra un endpoint de staging o no destructivo y sigue la redirección. Confirma que el origen emite 308.
• Registros de la aplicación/puerta de enlace de API — verifica que el destino recibió el mismo método, el mismo tipo de contenido y el mismo cuerpo. Un comprobador de redirecciones demuestra el estado y el destino; los registros de recepción demuestran que la preservación del método funcionó de extremo a extremo.
• Panel Red de DevTools del navegador — útil para flujos de formularios y autenticación, pero prueba por separado los clientes de webhook y API porque la interoperabilidad es la razón para elegir 308 en lugar de 301.
• Inspección de URL de Google Search Console — para URL de páginas indexables, confirma que el traslado permanente se procesa como una redirección 301 y que el destino es la canónica seleccionada.

Ponte a prueba: 308 Permanent Redirect

Cinco preguntas rápidas sobre qué es un 308, por qué existe y cómo lo tratan los motores de búsqueda. Elige una respuesta para cada una y luego compruébalo.

Recursos que valen tu tiempo

Mis escritos

• 11 tipos de redirecciones y su impacto en el SEO (con Joshua Hardwick) — mi definición de 308, el encuadre “for SEO purposes they’re the same, but forms” (traducción) «con fines de SEO, son lo mismo, pero los formularios», y la jerarquía de preferencia de redirecciones donde 308 y 301 comparten el nivel superior.
• Códigos de estado HTTP y su impacto en el SEO — donde lo expreso claramente: 308 “has the same functionality as a 301… except you can’t switch between POST and GET,” (traducción) «tiene la misma funcionalidad que una 301… excepto que no se puede alternar entre POST y GET», y las 308 “are treated the same as 301s and consolidate forward.” (traducción) «se tratan igual que las 301 y consolidan hacia adelante».
• Una migración web requiere más que una lista de verificación para tener éxito — por qué recurro a una redirección 301 o 308 (no a una 302/307) en un traslado permanente.
• Guía para principiantes de SEO técnico — dónde encajan las redirecciones en el panorama general.

Desde la industria

• Redirecciones y Google Search — la guía oficial de redirecciones de Google, que menciona 301 y 308 juntos como las opciones permanentes.
• Códigos de estado HTTP, errores de red y DNS, y Google Search — el documento que llama a 308 “Equivalent to 301” (traducción) «Equivalente a 301» con la salvedad de “semantically different” (traducción) «semánticamente diferente».
• RFC 9110 — Semántica HTTP — la especificación actual; su definición de 301 señala a 308 como la solución para la conversión no deseada de POST a GET.
• RFC 7538 — código de estado HTTP 308 (Permanent Redirect) — el estándar que introdujo 308.
• MDN — 308 Permanent Redirect — la semántica del método y del cuerpo y la nota de Google Drive “Resume Incomplete” (traducción) «Reanudar incompleto».
• caniuse — código de estado HTTP 308 — la tabla de compatibilidad de navegadores que desmiente el mito de “308 is fragile” (traducción) «308 es frágil».
• Bing trata las redirecciones 308 igual que las redirecciones 301 (Search Engine Roundtable) — la confirmación de Fabrice Canel en 2024 para Bing.
• Google trata oficialmente las redirecciones 308 como redirecciones 301 (Search Engine Roundtable) — el contexto de Gary Illyes “we just merge that with 301” (traducción) «simplemente lo fusionamos con 301» y el momento de documentación de “now it’s official” (traducción) «ahora es oficial».

Registro de cambios