¿Qué es una redirección 302?

El código 302 comunica que el recurso solicitado se encuentra de forma temporal en otra dirección y que la original sigue siendo la referencia válida. La especificación lo dice sin rodeos: el cliente debe seguir usando la URL de origen para las peticiones futuras, porque el desvío puede desaparecer en cualquier momento. Ahí está toda la distancia con el 301, que declara la mudanza definitiva.

Hay un segundo código temporal que casi nadie usa y que en algunos casos es el correcto: el 307. La diferencia no tiene que ver con el buscador sino con el método de la petición. Por razones históricas, un navegador puede convertir en GET una petición POST que recibe un 302, es decir, puede llegar al destino habiendo perdido los datos que llevaba. El 307 prohíbe ese cambio de método de forma explícita. En una página normal, que se pide con GET, ambos códigos se comportan igual y Google los trata igual. En un formulario, en una pasarela de pago o en un extremo de API, esa misma diferencia decide si la petición llega entera o llega vacía.

Googlebot sigue la redirección y llega al destino, pero el sistema de indexación no la usa como señal de que ese destino deba convertirse en la versión canónica. El resultado visible es el que casi todo el mundo espera: en los resultados de búsqueda se sigue mostrando la URL de origen mientras el desvío esté activo.

Lo que suele malinterpretarse es el alcance de esa regla. Que la 302 no cuente como señal de canonicalización no significa que sea una protección. La documentación añade una frase que cambia el panorama: la página de destino puede acabar indexada igualmente si existen otras señales de canonicalización. Esas señales son las de siempre, y ninguna depende del código de estado: enlaces internos que apuntan al destino, su presencia en el sitemap, una etiqueta canonical, o sencillamente que ambas páginas sean casi el mismo contenido.

De ahí sale la respuesta al caso que más se repite, el de la 302 que lleva meses puesta. Google no la convierte en permanente por antigüedad, y tampoco hay un plazo publicado a partir del cual cambie de criterio. Lo que ocurre es más sencillo y menos tranquilizador: cuanto más tiempo pasa, más señales acumula el destino, y en algún momento esas señales pueden pesar más que la ausencia de la señal que la 302 nunca aportó. Quien deja un desvío temporal indefinido no congela nada, solo renuncia a decidir cuál de las dos direcciones quiere que gane.

curl -I https://ejemplo.com/pagina
HTTP/1.1 302 Found
Location: https://ejemplo.com/destino

Tres situaciones concentran casi todos los problemas.

El mantenimiento es la primera. Una página en obras no se ha mudado, sigue en su sitio y volverá en unas horas, así que redirigir al visitante deja al rastreador sin contenido que leer en esa dirección justo cuando pasa por ahí. Para la indisponibilidad pasajera la especificación reserva un código propio, el 503, definido para sobrecargas puntuales y mantenimiento programado, con una cabecera Retry-After que indica cuándo tiene sentido volver a pedir la página.

La segunda es la detección de país o idioma. La mayoría de los rastreos de Google salen de direcciones IP estadounidenses y el rastreador no envía preferencia de idioma en la cabecera Accept-Language. Un sitio que redirige de forma automática según la IP acaba enseñándole siempre la misma versión, y las demás quedan sin rastrear. Google desaconseja esa redirección automática y propone lo contrario: anotaciones hreflang, todas las versiones accesibles por su propia URL y un selector visible.

La tercera es el test A/B, y es el caso donde la 302 encaja sin discusión. Google recomienda ese código para las variantes precisamente porque mantiene la URL original en el índice mientras dura el experimento. La condición es desmontarlo al terminar: URL alternativas, scripts de prueba y marcado, todo fuera.

• Usa 302 solo si la URL de origen va a volver a servir contenido, y anota cuándo. Un desvío temporal sin fecha prevista es una decisión aplazada, no una decisión.
• Elige 307 cuando la petición no pueda cambiar de método: formularios, pasarelas de pago y extremos de API.
• Cubre el mantenimiento con 503 y una cabecera Retry-After en lugar de una redirección, porque la página no se ha mudado, solo está cerrada un rato.
• En tests A/B, acompaña la 302 de una etiqueta canonical hacia la URL original en la variante, y retira ambas cosas al cerrar el experimento.
• Para país e idioma, ofrece un selector visible y anotaciones hreflang en vez de redirigir por IP.
• Después de cada migración o cambio de plantilla, revisa el inventario de redirecciones con un rastreo propio y comprueba el código servido, sin fiarte de lo que muestra el panel del CMS.

• Dar por hecho que una 302 protege la posición de la URL de origen. Lo único que garantiza es que el desvío no cuenta como señal a favor del destino.
• Tapar un mantenimiento con una redirección en vez de responder 503, dejando la dirección sin contenido para el rastreador justo en la visita que importaba.
• Redirigir de forma automática según la IP del visitante, con el resultado de que Google ve siempre la misma versión de idioma y las demás no se rastrean nunca.
• Usar 302 donde la petición transporta datos, sin contar con que puede llegar al destino convertida en GET.
• Terminar un test A/B y dejar montadas las URL de prueba, la redirección y el marcado del experimento.