Saltar al contenido principal

Guías / Códigos de estado HTTP explicados

Códigos de estado de redirección 3xx

Un código de estado 3xx es una redirección: el recurso que pediste está en otro sitio, y la cabecera Location de la respuesta dice dónde. El código concreto le dice al cliente, y a cada buscador, si el traslado es permanente o temporal y si hay que conservar el método de la petición original.

Cómo funciona una redirección

Una redirección son dos peticiones, no una. El cliente pide la URL A, el servidor responde con un estado 3xx y una cabecera Location que nombra la URL B, y el cliente hace entonces una petición nueva a B. Los navegadores lo siguen automáticamente, así que un visitante solo ve la página final y la URL final en la barra de direcciones. La respuesta intermedia sigue costando una ida y vuelta completa, por eso las cadenas de redirecciones largas son lentas.

Dos propiedades separan los códigos 3xx entre sí. La primera es la permanencia: una redirección permanente le dice a los clientes y a los rastreadores que la URL antigua se ha retirado y que la nueva debería sustituirla en marcadores, enlaces e índices, mientras que una redirección temporal dice que la URL antigua sigue siendo la real y va a volver. La segunda es la conservación del método. Los códigos más antiguos dejan que un cliente convierta un POST en un GET al seguir la redirección, y los más nuevos lo prohíben, así que un POST se queda como POST. Esa es la diferencia entre el envío de un formulario que llega intacto a la URL nueva y uno que llega como un GET vacío.

Cada código 3xx y qué significa

  • 300 Multiple Choices. El recurso existe en varias representaciones y el servidor deja que elija el cliente. No hay un formato estándar legible por máquina para la lista, así que casi nada lo implementa. En la práctica no verás un 300 en la vida real. Consulta la guía de 300 Multiple Choices para ver por qué sobrevive sobre todo como término de búsqueda.
  • 301 Moved Permanently. El recurso tiene un nuevo hogar permanente. Los buscadores transfieren las señales de posicionamiento al destino, y los clientes pueden cachear la redirección, a veces de forma agresiva. Este es el código para un cambio de dominio, un paso de HTTP a HTTPS o una reestructuración permanente de URLs.
  • 302 Found. Una redirección temporal. La URL original conserva su identidad, así que los buscadores normalmente siguen indexando la original en lugar del destino. Históricamente muchos clientes cambiaban el método a GET al seguir un 302, por eso el estándar advierte contra depender de la conservación del método aquí.
  • 303 See Other. "Tu petición se procesó; ahora ve y haz GET a este otro recurso." Al cliente se le dice explícitamente que use GET para el seguimiento sin importar el método original. Esta es la respuesta correcta a un POST de formulario que debería llegar a una página de resultado.
  • 304 Not Modified. No es una redirección en absoluto. Responde a una petición condicional y significa "tu copia en caché sigue vigente, reutilízala". No hay cuerpo ni Location. Consulta 304 Not Modified.
  • 305 Use Proxy y 306 están obsoletos. El 305 se dejó de usar por motivos de seguridad y el 306 no se usa. Ignora ambos.
  • 307 Temporary Redirect. El mismo significado que el 302, pero el método y el cuerpo tienen que conservarse. Un POST que sigue un 307 llega a la URL nueva como POST.
  • 308 Permanent Redirect. El mismo significado que el 301, pero el método y el cuerpo tienen que conservarse.

Qué sale mal con las redirecciones

  • Un código temporal en un traslado permanente. El error más habitual y más caro. Los buscadores mantienen indexada la URL antigua y la nueva no hereda la posición de la antigua.
  • Un código permanente en un traslado temporal. Más difícil de deshacer, porque un 301 en caché puede seguir mandando a los visitantes recurrentes al sitio equivocado mucho después de que quites la regla.
  • Cadenas de redirecciones. De http a https, luego de sin www a con www, luego de la ruta antigua a la nueva son tres idas y vueltas antes de que llegue ningún contenido. Cada salto añade latencia y cada salto es un sitio donde la cadena se puede romper.
  • Bucles de redirección. A envía a B y B envía de vuelta a A, normalmente porque una regla a nivel de aplicación y una regla a nivel de servidor o de CDN no están de acuerdo sobre la forma canónica. Los navegadores se rinden tras un número fijo de saltos y muestran un error.
  • Todo apuntando a la página de inicio. Cuando las páginas retiradas redirigen todas a la raíz en lugar de a su equivalente más cercano, la redirección a menudo se trata como un 404 suave y el visitante se queda buscando.
  • Cuerpos de POST perdidos. Un endpoint de API o de formulario movido detrás de un 301 o un 302 puede perder su método y su carga con algunos clientes. Usa 307 u 308 para cualquier cosa que no sea un GET simple.

Cómo auditar y arreglar tus redirecciones

  1. Mira lo que devuelve una URL, sin seguirla:
    curl -sI https://example.com/old-page | grep -Ei "^(HTTP|location)"
    Eso imprime la línea de estado y el destino de una vez.
  2. Ahora sigue toda la cadena y cuenta los saltos:
    curl -sIL -o /dev/null -w "%{num_redirects} hops, final %{http_code}, %{url_effective}\n" https://example.com/old-page
  3. Reduce las cadenas a un solo salto. Apunta la URL original directamente al destino final en lugar de dejar que pase por reglas intermedias.
  4. Haz que el código coincida con la intención. Traslado permanente: 301, o 308 si el endpoint acepta peticiones que no son GET. Traslado temporal, página de mantenimiento o división A/B: 302, o 307 donde el método tenga que sobrevivir. Flujo de post-y-luego-redirige: 303.
  5. Arregla los bucles decidiendo la forma canónica una sola vez (protocolo, host y barra final) e imponiéndola en exactamente una capa. Los bucles casi siempre significan que dos capas intentan ser ambas autoritativas.
  6. Vuelve a probar con una caché fría. Un navegador que ha cacheado un 301 lo seguirá obedeciendo, así que verifica con curl o una ventana privada antes de concluir que la corrección no funcionó.

Detectar una redirección rota antes de que caiga el tráfico

Las redirecciones se rompen sin ningún síntoma visible. Una regla que empieza a entrar en bucle, o un certificado que falla en el destino de la redirección, deja igualmente respondiendo a la URL antigua, así que nada parece mal hasta que caen el tráfico y el posicionamiento. Una comprobación externa que sigue la cadena y hace una aserción sobre el estado final detecta una redirección rota en el momento en que aparece, y comprobar desde muchas redes separa un cambio de regla global de un problema regional de CDN. HostTracker ejecuta comprobaciones desde más de 300 puntos de control en 158 ciudades y avisa por correo, SMS, llamada de voz, Slack, Telegram y más. Prueba una URL y su cadena de redirecciones con la herramienta de comprobación HTTP, y lee 301 frente a 302 antes de elegir un código.

Compruébalo ahora

Ejecuta la comprobación gratuita en tu propio sitio, sin necesidad de cuenta.

HTTP check

Monitoriza esto de forma permanente

Recibe un aviso en cuanto algo falle: HostTracker comprueba desde más de 300 ubicaciones y te avisa por correo, SMS, Slack, Telegram y más.

Funciones de HostTracker

Más en esta sección: Códigos de estado HTTP explicados