Redirección 303 See Other

TL;DR — Un 303 See Other es una redirección que envía al navegador a una página diferente y la obtiene con una solicitud GET (o HEAD). Su función principal es un truco de desarrollo web: después de enviar un formulario, el servidor te redirige a una página de resultados para que actualizar la página vuelva a obtener esa página de resultados en lugar de reenviar el envío original del formulario. Casi nunca es algo que configurarías a propósito para SEO — es una cosa de formularios y aplicaciones, no una cosa de “esta página se movió”. Y esta es la parte honesta: Google y Bing no publican ningún consejo especial de SEO sobre los 303, porque apenas hay algo que decir.

Qué es una redirección 303

Cuando un navegador pide una página, tu servidor responde con un código de estado HTTP de tres dígitos. 200 significa “aquí está la página”. 404 significa “no encontrado”. Un 303 significa “See Other” — no renderices lo que pediste directamente; en su lugar, obtén una URL diferente y recupérala con una solicitud GET o HEAD.

Ese cambio a GET o HEAD es la razón de ser de un 303, y es lo que lo hace diferente de sus hermanos. Más sobre eso en un segundo.

La única función real de los 303

Imagina enviar un formulario — un pedido, un comentario, un pago. Tu navegador envía eso como una solicitud POST. Si el servidor simplemente dibuja la página de confirmación ahí mismo en la respuesta POST, tienes un problema: presiona actualizar, y el navegador pregunta “¿quieres reenviar este formulario?” Recarga sin pensar y habrás realizado el pedido dos veces.

Un 303 soluciona eso. El flujo es el siguiente:

1. Envías el formulario → el navegador envía un POST.
2. El servidor lo procesa y luego responde con un 303 que apunta a una página de resultados.
3. El navegador sigue el 303 con un nuevo GET a esa página de resultados.

Ahora estás en una página de confirmación normal, accesible mediante GET. Actualízala, pulsa atrás — lo único que haces es volver a obtener esa página en lugar de reenviar el POST original. Los desarrolladores llaman a esto el patrón Post/Redirect/Get (PRG), y el 303 es la “redirección” en el medio. Vale la pena ser preciso sobre lo que esto realmente te aporta: PRG detiene la repetición por actualización del navegador, pero no es una garantía de exactamente una vez — los reintentos, los dobles clics, los tiempos de espera y las solicitudes simultáneas todavía pueden crear pedidos o cargos duplicados a menos que tu aplicación también tenga sus propias salvaguardias (claves de idempotencia, comprobaciones de transacción) en la propia escritura.

Por qué esto rara vez importa para el SEO

Un 303 es un comportamiento de aplicación web, no una herramienta de migración de páginas. Usas un 301 cuando una URL se traslada de forma permanente, un 302 cuando se traslada temporalmente — pero casi nunca recurres a un 303 para mover una página, porque no está diseñado para eso. Como lo he expresado en mis propios escritos en Ahrefs: la guía considera que una 303 rara vez aparece en SEO y que, si aparece, se trata como una 302/307.

Y esa es la realidad honesta de todo este tema: Google y Bing no publican una guía SEO dedicada para 303. Google lo menciona exactamente una vez, agrupado en el grupo de redirecciones “temporary” (traducción) «temporal» con 302 y 307 — la redirección en sí no es una señal de que el destino debería convertirse en canónica como ocurre con una redirección 301 permanente, aunque otras señales aún pueden hacer que la página de destino se indexe. No hay un comportamiento secreto de 303 que aprender. Si una herramienta de rastreo marca un 303 en tu sitio, casi siempre es un patrón deliberado de la aplicación (un flujo de formulario), no algo roto ni algo que “fix.” (traducción) «arreglar». Evidence for this claim Google groups HTTP 303 with temporary redirects, follows it, and does not use it as a signal that the destination should become canonical. Scope: Google Search canonicalization behavior for server-side temporary redirects. Confidence: high · Verified: 2026-07-14 Google: Redirects and Google Search

No lo confundas con una página rota o movida

Verás que algunos sitios describen un 303 como lo que ocurre cuando “the page has moved” (traducción) «la página se ha movido» o “the browser can’t find the URL.” (traducción) «el navegador no puede encontrar la URL». Eso es confundirlo con un 301/302 o con un error. Un 303 no es una señal de que algo falle — es una respuesta deliberada que tu aplicación devuelve a propósito, normalmente justo después de que se envía un formulario.

¿Quieres la comparación técnica con 302 y 307, lo que realmente dicen los documentos de Google (y el comentario directo de una línea de John Mueller al respecto), y la perspectiva del desarrollador sobre cuándo devolver uno? Cambia a la pestaña Avanzada.

TL;DR — Un 303 (HTTP “303 See Other”) es una redirección temporal cuyo comportamiento definitorio es que dirige al cliente para que recupere otro recurso con GET o HEAD, independientemente de lo que usara la solicitud original. Eso es lo que impulsa el patrón Post/Redirección/Get (PRG): POST → 303 → página de resultado GET, por lo que una actualización vuelve a obtener la página en lugar de reenviar el formulario. Difiere de 307 (que siempre preserva el método) y de 302 (cuyo manejo del método fue históricamente ambiguo). Es realmente raro como redirección SEO de página a página: es un mecanismo de aplicación web, no una herramienta de migración de URL. Google documenta 303 solo como un miembro del grupo genérico de 3xx “temporales” con 302 y 307 — una señal de canonicalización débil — y no publica orientación específica sobre 303; Bing tampoco publica ninguna que yo haya podido encontrar. No inventes autoridad que no existe: di claramente que hay poco que decir.

Qué es realmente un 303

Un 303 es un código de estado HTTP devuelto en las cabeceras de respuesta, antes de cualquier cuerpo, con una cabecera Location que apunta a la URL que el cliente debería obtener a continuación. La semántica es estrecha y específica: la respuesta a tu solicitud está en otro lugar, y deberías recuperarla con GET o HEAD. Evidence for this claim RFC 9110 defines 303 See Other as directing the client to retrieve another resource identified by Location using GET or HEAD. Scope: HTTP semantics for 303 responses. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.4.4 — 303 See Other

Ese comportamiento de recuperación con GET o HEAD es la razón completa por la que 303 existe como un código distinto, y es el eje en el que difieren las tres redirecciones más o menos temporales.

303 vs 302 vs 307: la cuestión del método

Los tres son “temporales” desde el punto de vista del SEO — Google los agrupa como señales débiles. Sin embargo, técnicamente, responden a una pregunta de forma diferente: cuando el cliente sigue la redirección, ¿qué método HTTP usa?

303 y 307 se introdujeron en parte para desambiguar la confusión alrededor de 302. Si quieres forzar el método a GET después del envío de un formulario, eso es un 303. Si necesitas que el método original se mantenga (por ejemplo, volver a emitir un POST a un nuevo endpoint), eso es un 307. Un 302 es el punto medio histórico laxo que ninguno de los dos define con precisión.

Una diferencia práctica más: las respuestas 303 no son almacenables en caché de forma predeterminada, mientras que una 301 sí. Esto importa si te preocupa que un navegador o un CDN almacene en caché el destino de la redirección de forma inadecuada — con un 303 no tienes esa preocupación.

El patrón Post/Redirect/Get, con precisión

PRG es el uso canónico de un 303, y es un patrón de diseño deliberado y correcto — no un estado de error:

1. El cliente envía un formulario como POST (crear un pedido, publicar un comentario, ejecutar un pago).
2. El servidor procesa el efecto secundario y luego devuelve 303 See Other con un encabezado Location que apunta a una URL de resultado accesible mediante GET (un recibo, una confirmación, una vista actualizada del recurso).
3. El cliente continúa con un GET (o HEAD) a esa URL. El historial del navegador y el botón de actualización ahora apuntan a una recuperación segura e idempotente —recargar o volver atrás vuelve a obtener la página de resultado en lugar de repetir el POST.

La ventaja es que una simple actualización del navegador deja de reenviar el formulario: no más diálogo “confirm form resubmission”. Sé preciso acerca de lo que eso es y lo que no: PRG evita esa ruta de repetición específica, no todas las escrituras duplicadas. No garantiza un procesamiento exactamente una vez. Los reintentos, los tiempos de espera, los dobles clics y las solicitudes concurrentes aún pueden disparar el POST original dos veces, por lo que cualquier operación que cambie el estado — pedidos, pagos, envíos de comentarios — aún necesita sus propios controles a nivel de aplicación (claves de idempotencia, límites de transacción, detección de solicitudes duplicadas) si la duplicación es un riesgo real. En las API RESTful también verás 303 después de un PUT o DELETE para enviar al cliente a una representación del recurso afectado.

Cómo trata Google el 303 (y por qué hay tan poco que tratar)

Este es el hallazgo central y honesto para este tema: Google no tiene orientación de SEO específica para 303. Aparece en la documentación de redirecciones de Google solo como una fila en la tabla de redirecciones “temporales”, junto a 302 y 307. El propio encuadre de Google de todo ese grupo es preciso: el rastreador sigue la redirección, pero el flujo de indexación no usa la redirección en sí como una señal de que el destino debería ser canónico — aunque otras señales aún pueden llevar a Google a indexar el destino de todos modos. Eso es diferente de — y más estrecho que — la canonicalización fuerte que proporciona una 301 permanente. Evidence for this claim Google groups HTTP 303 with temporary redirects, follows it, and does not use it as a signal that the destination should become canonical. Scope: Google Search canonicalization behavior for server-side temporary redirects. Confidence: high · Verified: 2026-07-14 Google: Redirects and Google Search

El propio escrito informal de John Mueller sobre los tipos de redirección es aún más revelador. Después de recorrer en detalle 301, 302 y 307, descarta 303 en un único aparte:

• “What about 303? 304.5? If you have strong feelings about one of the other kinds of redirects, feel free to use them.” (traducción) «¿Qué pasa con 303? ¿304.5? Si tienes opiniones fuertes sobre uno de los otros tipos de redirecciones, siéntete libre de usarlas.» La conclusión práctica que añade es la parte útil:
• “We’ll have to figure out which URL to index the content under, so if you have strong feelings about that too, make sure to follow up with other canonicalization signals.” (traducción) «Tendremos que averiguar bajo qué URL indexar el contenido, así que si también tienes opiniones fuertes sobre eso, asegúrate de hacer seguimiento con otras señales de canonicalización.» En otras palabras — si de alguna manera usas una 303 y te importa qué URL indexa, no dependas del tipo de redirección; respáldalo con rel="canonical", enlaces internos y sitemaps.

La documentación de Google también añade una nota que vale la pena interiorizar en todos estos códigos: aunque los trata igual, te pide: “keep in mind that they’re semantically different. Use the status code that’s appropriate for the redirect.” (traducción) «ten en cuenta que son semánticamente diferentes. Usa el código de estado que sea apropiado para la redirección.» Así que la realidad de que “al SEO no le importa” no es una licencia para poner un 303 en un movimiento permanente — usa el código que realmente coincida con tu intención para que otros clientes se comporten correctamente.

Cómo trata Bing el 303

En pocas palabras: no pude encontrar ninguna orientación pública específica de Bing sobre el tratamiento del 303, más allá de referencias genéricas a códigos de estado HTTP en la ayuda de Bing Webmaster Tools. No hay ninguna declaración verificada de Fabrice Canel ni de ninguna otra persona de Microsoft que mencione específicamente el 303. Este es un punto de datos legítimo de “no tenemos documentación sobre esto”, no una laguna que disimular — y no voy a llenarla asumiendo que Bing simplemente replica el comportamiento declarado de Google. La ausencia de documentación no es evidencia de que el tratamiento sea idéntico; si necesitas una respuesta definitiva para Bing específicamente, esa es una pregunta abierta y no una cuestión resuelta.

¿Importa el 303 para el SEO? Rara vez.

Esta es mi conclusión honesta, y coincide con lo que he escrito públicamente. Un 303 no es una herramienta de migración de páginas. En 11 Types Of Redirects & Their SEO Impact lo resumo así: es una redirección temporal para un recurso similar y, si aparece en un contexto de SEO, se trata como una 302/307.

Señalaré una tensión honesta en mi propio catálogo anterior. En Códigos de estado HTTP y su impacto en el SEO describí el tratamiento de los 303 como “undefined… They may be treated as 301 or 302, depending on how they function.” (traducción) «indefinido… Pueden tratarse como 301 o 302, dependiendo de cómo funcionen.» Hoy lo plantearía con mayor precisión: la documentación de Google confía en que el 303 se encuentra en el grupo temporal/débil con 302 y 307. La razón por la que “undefined” alguna vez pareció cierto en la práctica es que los 303 son tan raros en la naturaleza que Google nunca ha tenido motivos para aclarar públicamente los casos límite, no porque haya un comportamiento oculto más fuerte. Comienza con el valor predeterminado documentado (débil/temporal, agrupado con 302/307); trata cualquier sorpresa como una consecuencia de la rareza, no una regla secreta.

¿Cuándo podría importar en absoluto? Realmente solo en sitios con flujos intensivos de formulario/pago o aplicaciones controladas por API donde los 303 aparecen en un rastreo de códigos de estado. Incluso entonces, la respuesta normalmente es “that’s working as intended, leave it alone.” (traducción) «eso está funcionando según lo previsto, déjalo como está». Si estás moviendo deliberadamente una URL, no uses un 303 — usa un 301 (permanente) o un 302 (temporal), y usa un 308/307 si necesitas específicamente preservación del método.

303 vs 201, 202 y 204: elegir el estado correcto para una operación de escritura

303 no es la única opción después de una solicitud que cambia el estado, y es fácil recurrir a este por costumbre. En una API (a diferencia de un flujo de formulario en el navegador), tres códigos 2xx suelen encajar mejor:

• 201 Created — la solicitud creó uno o más recursos de forma síncrona y la respuesta debería identificar el principal, en Location si se proporciona; de lo contrario, la propia URI de destino. Usa esto cuando la creación terminó y quieres que el cliente tenga el nuevo recurso directamente, no una ida y vuelta GET independiente.
• 202 Accepted — la solicitud fue aceptada, pero el procesamiento aún no terminó (trabajo en cola, trabajos asíncronos). La respuesta es deliberadamente neutra: describe el estado actual e idealmente dirige al cliente a un monitor de estado que pueda consultar.
• 204 No Content — la acción se realizó correctamente y no hay nada más que devolver: sin cuerpo, sin necesidad de redirección. La respuesta termina en la sección de encabezados.

303 encaja en una forma distinta a los tres: es para cuando el cliente debería recuperar un recurso de resultado identificado por separado después de la escritura — con mayor frecuencia el patrón PRG en un navegador. No es un reemplazo directo de la creación síncrona (201), la aceptación asíncrona (202) o una operación nula simple y exitosa (204); cada uno de esos comunica un resultado distinto que una redirección no comunica.

Mitos comunes

• “Una 303 significa que la página se movió o está rota.” No. Es una respuesta deliberada, que cambia el método — generalmente después de POST/PUT/DELETE — no una señal de “content relocated” (traducción) «contenido reubicado» o de error. Los sitios que la describen como “the browser can’t find the URL because the page moved” (traducción) «el navegador no puede encontrar la URL porque la página se movió» la están confundiendo con una 301/302 o con un 404.
• “Una 303 transmite valor SEO como una 301.” No lo transmite. Es temporal/débil, en el mismo grupo que 302 y 307 según la propia documentación de Google.
• “Los SEO deberían recurrir a 303 como una redirección general.” No está diseñada para eso. Es un patrón estrecho de formularios/API; usarla para migraciones de URL ordinarias es atípico.
• “Google tiene reglas detalladas específicas de 303.” No las tiene. Una mención agrupada, y el encogimiento de hombros de Mueller de “feel free to use them” (traducción) «puedes usarlos libremente». Ese es todo el registro.
• “303 y 302 son técnicamente idénticos.” Son equivalentes para SEO, pero no técnicamente iguales: una 303 cambia la solicitud posterior a GET o HEAD, mientras que la gestión del método de 302 fue históricamente inconsistente — que es exactamente la razón por la que se introdujeron 303 y 307 para disambiguarlo.

Dónde encaja esto

Un 303 es un código dentro del ámbito de las redirecciones temporales. Sus parientes más cercanos son el 302 (la redirección temporal laxa con la que suele agruparse) y el 307 (su contraparte que preserva el método: el 307 mantiene el método, el 303 cambia a GET o HEAD). Se diferencia del 301, la redirección permanente que sí consolida señales de posicionamiento y realiza el trabajo de migración de URL para el que un 303 nunca fue diseñado. Para ver la familia completa —301/308 permanentes, 302/303/307 temporales, 404/410 desaparecidos, errores 5xx—, consulta el clúster de códigos de estado HTTP al que pertenece esta página.

Validación segura de un flujo 303

Antes de confiar en un 303 en el entorno real, compruébalo sin seguirlo automáticamente a ciegas: inspecciona el propio valor de Location (¿es absoluto, relativo, resoluble?), presta atención a los bucles de redirección o a las cadenas innecesarias, confirma que la solicitud de seguimiento real usa GET o HEAD, y verifica el estado y el contenido de la respuesta final. Para un flujo de formulario o de API, revisa también los registros de tu aplicación para confirmar que la escritura original no se repitió.

Una advertencia: no generalices el comportamiento de un solo cliente como si fuera una regla universal. El comportamiento de seguimiento automático de navegadores, clientes HTTP y frameworks varía según el producto, la versión y la configuración: un informe sobre un cliente/versión específico no sirve como evidencia para todos ellos. Además, un verificador a nivel de URL puede confirmar la redirección y la estructura del destino, pero no puede validar por ti la idempotencia, el manejo de credenciales ni la seguridad entre orígenes; eso todavía requiere probar el flujo de envío real.

Resumen de IA

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

• 303 = HTTP “303 See Other” — una redirección temporal cuyo comportamiento definitorio es que dirige al cliente a recuperar otro recurso con GET o HEAD, sea cual sea el método de la solicitud original.
• Existe para el patrón Post/Redirect/Get (PRG): POST (envío de formulario) → 303 → página de resultado GET/HEAD. Al actualizar o volver atrás, se vuelve a obtener la página de resultado en lugar de reenviar el POST original. Eso detiene específicamente la repetición por actualización del navegador; no es una garantía de exactamente una vez; los reintentos, los tiempos de espera, los dobles clics y las solicitudes concurrentes aún pueden duplicar una escritura a menos que la aplicación tenga sus propios controles (claves de idempotencia, comprobaciones de transacción).
• El método es el eje de diferenciación: 303 cambia a GET/HEAD; 307 siempre preserva el método; 302 era históricamente ambiguo. 303 y 307 se introdujeron para desambiguar 302.
• No es almacenable en caché de forma heurística solo por el estado (a diferencia de una 301) — el recurso de resultado recuperado por separado tiene su propia política de caché, independiente.
• No es un sustituto de 201/202/204: 303 encaja cuando el cliente debería recuperar un recurso de resultado separado; no reemplaza la creación síncrona (201), la aceptación asíncrona (202), ni un éxito simple sin contenido (204).
• Realidad SEO — dilo claramente: Google documenta 303 solo como una fila en el grupo de redirecciones “temporales” con 302 y 307. La redirección en sí no es una señal de que el destino deba ser canónico, aunque otras señales aún pueden conseguir la indexación del destino — eso es más limitado que la canonicalización que proporciona una 301 permanente. No hay una guía dedicada de Google sobre 303, y tampoco se encontró ninguna de Bing (la ausencia de documentación de Bing no es evidencia de que Bing lo trate de forma idéntica a Google). El propio artículo de John Mueller lo descarta: “What about 303? … feel free to use them,” (traducción) «¿Qué pasa con 303? … siéntete libre de usarlas», y añade que, si te importa qué URL se indexa, respáldala con otras señales de canonicalización.
• Rara vez es relevante para SEO: es un patrón de aplicación web, no una herramienta de migración de URL. La propia guía de Patrick en Ahrefs lo descarta: una 303 rara vez se usa para SEO y, cuando aparece, se trata como una 302/307.
• No lo confundas con una página rota/movida — una 303 es deliberada, no un error. Para mover realmente una URL, usa una 301 (permanente) o una 302 (temporal), no una 303.

Documentación oficial

Hay muy poca documentación de SEO de fuentes primarias sobre 303 específicamente: solo se menciona de pasada, agrupada con otras redirecciones temporales. Estas son las referencias relevantes.

Google

• Redirecciones y Google Search — enumera HTTP 303 (see other) en el grupo de redirecciones “temporary” “temporary” (traducción) «temporal» junto con 302 y 307; no hay notas de manejo específicas de 303.
• Cómo los códigos de estado HTTP, los errores de red y de DNS afectan a Google Search — enumera 303 (see other) en la sección 3xx y establece la regla general de que Google trata estos códigos temporales como una señal débil, a la vez que recuerda que son “semantically different.” “semantically different.” (traducción) «semánticamente diferentes.»

Bing / Microsoft

• No se localizó guía específica de 303. La ayuda de Bing Webmaster Tools cubre los códigos de estado HTTP de manera genérica, pero no destaca 303.

Referencia técnica (no es una fuente de SEO)

• MDN — 303 See Other — una referencia rápida y útil para los casos de uso de PUT/POST/DELETE y PRG, aunque su frase “always GET” “always GET” (traducción) «siempre GET» es más laxa que la especificación actual (consulta a continuación).
• RFC 9110 — Semántica HTTP, §15.4.4 — la definición técnica vinculante: el destino de Location no es equivalente al destino original, y el agente de usuario (user-agent) lo recupera con GET o HEAD, no siempre GET.

Citas de la fuente

Declaraciones públicas relacionadas con 303. Solo hay unas pocas —esa escasez es la historia de este tema, así que estas constituyen honestamente toda su extensión, en lugar de una lista inflada. Cada enlace enlaza directamente al pasaje citado.

Google / John Mueller — el registro (muy breve) sobre 303

• “What about 303? 304.5? If you have strong feelings about one of the other kinds of redirects, feel free to use them. We’ll have to figure out which URL to index the content under, so if you have strong feelings about that too, make sure to follow up with other canonicalization signals.” (traducción) «¿Qué pasa con 303? ¿304.5? Si tienes fuertes opiniones sobre uno de los otros tipos de redirecciones, siéntete libre de usarlas. Tendremos que averiguar bajo qué URL indexar el contenido, así que si también tienes fuertes opiniones sobre eso, asegúrate de proporcionar otras señales de canonicalización.» — John Mueller, blog personal, A search-engine guide to 301, 302, 307…. Esta es la declaración más directa sobre 303 de alguien de Google, y es un encogimiento de hombros deliberado. Ir a la cita

Google — el tratamiento de “cubo temporal” que 303 hereda

• “By default, Google’s crawlers follow the redirect… Google systems use the redirect as a weak signal that the redirect target should be processed.” (traducción) «Por defecto, los rastreadores de Google siguen la redirección… Los sistemas de Google utilizan la redirección como una señal débil de que el destino de la redirección debería procesarse.» (Manejo declarado por Google de las redirecciones temporales, grupo al que pertenece 303.) — Google Search Central, How HTTP status codes… affect Google Search. 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…” (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…» Ir a la cita

MDN — una formulación común que vale la pena corregir

• “The method used to display this redirected page is always GET.” (traducción) «El método utilizado para mostrar esta página redirigida siempre es GET.» — MDN, 303 See Other. Ir a la cita — Vale la pena señalarlo en lugar de repetirlo sin análisis crítico: la especificación actual es más permisiva que “always GET”. RFC 9110 §15.4.4 define la recuperación posterior como GET or HEAD, y el destino de Location como un recurso diferente, no equivalente — ese es el hecho técnico que realmente distingue 303 de 307 (preserva el método) y 302 (históricamente ambiguo).

Patrick (Ahrefs) — la conclusión práctica de SEO

• “A 303 redirect forwards the user to a resource similar to the one requested and is a temporary form of redirect. It’s typically used for things like preventing form resubmissions when a user hits the ‘back’ button in their browser. You won’t typically see 303 redirects used for SEO purposes, but if you do then it will be treated just like a 302/307.” (traducción) «Una redirección 303 reenvía al usuario a un recurso similar al solicitado y es una forma temporal de redirección. Normalmente se usa para cosas como evitar reenvíos de formularios cuando un usuario pulsa el botón ‘atrás’ de su navegador. Normalmente no verás redirecciones 303 usadas con fines de SEO, pero si las ves, se tratarán igual que una 302/307.» — Patrick Stox, 11 tipos de redirecciones y su impacto en el SEO (Ahrefs). Ir a la cita

Uso incorrecto de 303 See Other

Tratar 303 como un código genérico de “página movida”

Un 303 está diseñado para enviar al cliente a otro recurso con GET o HEAD, normalmente después de una solicitud que cambia el estado. Usa 301 para un traslado permanente de página y 302 para una redirección temporal normal de página.

Usar 303 cuando el método original debe conservarse

El código descarta deliberadamente el método original para la solicitud de seguimiento. Si una solicitud POST, PUT, DELETE, un webhook o una carga útil de API debe llegar intacta al destino, usa 307 (temporal) o 308 (permanente).

Describir 303 como una señal SEO permanente y fuerte

Google agrupa 303 con las redirecciones temporales, no con 301/308. No lo uses para consolidar una migración de URL ni afirmes que se comporta como un traslado permanente.

Asumir que Google o Bing publican reglas detalladas sobre 303

Google solo proporciona un tratamiento agrupado de redirecciones temporales, y Bing no tiene una guía pública dedicada identificada en este artículo. Mantén las conclusiones limitadas en lugar de llenar el vacío de documentación con certeza.

Considerar que 302 y 303 son técnicamente idénticos

Su tratamiento en la búsqueda puede agruparse, pero la semántica de sus métodos no es la misma. Un 303 da seguimiento con GET o HEAD; 302 históricamente ha permitido un comportamiento ambiguo de POST a GET.

Afirmar un comportamiento universal del cliente, de las credenciales o entre orígenes

No afirmes como hecho cómo los “navegadores” o “clientes” manejan los cuerpos de solicitud, los encabezados, las cookies, o las credenciales en un 303 sin nombrar específicamente el cliente, la versión y la configuración. El comportamiento de seguimiento automático y de reenvío de credenciales varía; un único hilo de incidencia o una anécdota no es evidencia para todos los clientes, y no sustituye tu propia revisión de seguridad del flujo real.

Post/Redirección/Get en HTTP sin procesar

Este flujo simplificado muestra la tarea específica que un 303 hace bien.

1. El navegador envía un formulario

POST /orders HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded

item=book&quantity=1

2. El servidor lo procesa y apunta al resultado

HTTP/1.1 303 See Other
Location: /orders/confirmation

El 303 no repite el POST en la nueva URL. Indica explícitamente al cliente que obtenga el otro recurso con GET (o HEAD); un navegador que sigue el enlace lo hace con GET.

3. El navegador recupera una página de resultado segura

GET /orders/confirmation HTTP/1.1
Host: example.com

HTTP/1.1 200 OK
Content-Type: text/html

<h1>Order received</h1>

Recargar ahora repite el GET, no el POST que crea el pedido. En cambio, un 307 preservaría el POST y su cuerpo; es útil para mover una solicitud de API, pero incorrecto para este resultado de PRG.

Ponte a prueba: 303 See Other

Cinco preguntas rápidas sobre la redirección 303. Elige una respuesta para cada una y luego verifica.

Registro de cambios