¿Qué es un Redirect 301?

El número no es un detalle técnico sin importancia: 301 significa "movido de forma permanente" y 302 significa "movido de forma temporal", y Google trata cada uno de forma distinta. Con un 301, la URL de destino pasa a ser la versión canónica y es la que Google muestra en los resultados de búsqueda. Con un 302, Google sigue mostrando la URL de origen en los resultados mientras dure la redirección, porque asume que en algún momento volverá a estar activa por sí misma.

El error más caro es dejar un 302 puesto en un cambio que en realidad es definitivo. Pasa mucho en migraciones de dominio: el CMS o la plataforma nueva aplica un 302 por defecto, nadie lo revisa, y durante semanas o meses Google sigue mostrando en resultados la URL del dominio antiguo en vez de consolidar el valor en el nuevo. El dominio nuevo tarda más en heredar el historial de rastreo y de clics porque, para Google, la redirección todavía puede revertirse en cualquier momento.

La regla práctica es simple: si hay alguna posibilidad de que la URL antigua vuelva a estar activa, es un 302. Si esa posibilidad no existe, es un 301.

Comprobar el código real es fácil desde la línea de comandos, sin depender de lo que diga el CMS o el plugin de turno:

curl -I https://ejemplo.com/página-antigua

HTTP/1.1 301 Moved Permanently
Location: https://ejemplo.com/página-nueva

Los cambios de protocolo o de subdominio también son 301 aunque a veces no se piensen como una "migración": pasar de http a https, o de una versión sin www a una con www (o al revés), consolida de forma permanente en una única dirección y debería llevar siempre este código, no un 302 temporal ni, peor todavía, dejar ambas versiones sin ningún tipo de redirección.

En la práctica, el error casi nunca es una decisión consciente por el 302, es la configuración por defecto del software. Muchos plugins de redirección y configuraciones de proxy inverso aplican un 302 sin preguntar, porque es la opción por defecto más prudente: una redirección marcada por error como permanente es más difícil de deshacer que una marcada por error como temporal. Quien no lo revisa después de una migración suele arrastrar el código equivocado durante meses sin darse cuenta, porque para quien visita el sitio todo sigue funcionando con normalidad. Solo el buscador percibe la diferencia.

Un canonical y un redirect 301 resuelven el mismo tipo de problema (contenido duplicado o repartido entre varias URL) de dos formas opuestas. El canonical deja las dos URL accesibles: quien entra a la antigua puede seguir viéndola, y solo se le indica a Google cuál de las dos prefiere que se posicione. El redirect 301, en cambio, hace que la URL antigua deje de responder por su cuenta: quien entra a ella, sea persona o rastreador, llega automáticamente a la nueva dirección sin poder elegir quedarse en la anterior.

Esa diferencia decide cuál usar en cada caso. Si las dos versiones tienen que seguir existiendo (una ficha de producto con y sin parámetro de color, por ejemplo), un canonical basta y sobra: redirigir ahí rompería la navegación de quien quiere ver esa variante en concreto. Si la URL antigua ya no tiene ninguna razón para seguir siendo visitable (un cambio de dominio, un cambio de estructura de categorías, una página que se fusiona con otra), el redirect 301 es la herramienta correcta y el canonical se queda corto: seguiría dejando accesible una URL que en realidad debería desaparecer.

El error típico va en los dos sentidos. Usar solo un canonical cuando la URL antigua debería eliminarse la deja viva sin motivo, generando duplicados de baja calidad que un rastreador sigue visitando de forma innecesaria. Usar un redirect 301 cuando ambas versiones necesitan coexistir rompe el acceso a una de ellas: quien busca esa variante concreta ya no puede llegar a ella por su cuenta.

Hay además una diferencia práctica de cara al usuario. Un canonical es invisible para quien visita el sitio, nadie nota que existe, mientras que un redirect 301 interviene de forma activa en la navegación: un marcador guardado o una captura antigua con la URL original lleva automáticamente a otro sitio. Eso es lo que se busca en una migración real, pero sería una ruptura innecesaria de las expectativas del usuario si solo se trata de una variante con parámetros.

Un error 404 dice "aquí no hay nada". Un redirect 301 dice "esto se movió, aquí está lo nuevo". La diferencia parece obvia hasta que hay que decidir qué hacer con una URL concreta que dejó de existir, y ahí es donde se comete el error con más frecuencia.

Cuando el contenido tiene un equivalente real en otra URL, el redirect 301 es casi siempre la opción correcta: se lleva consigo tanto a las personas que llegaban por un enlace antiguo o un marcador guardado como las señales de posicionamiento acumuladas en esa dirección. Dejarlo en 404 en ese caso desperdicia ambas cosas sin necesidad.

El 404 sigue siendo la respuesta correcta cuando no hay ningún equivalente al que redirigir. Forzar un redirect hacia una página que no tiene relación real con el contenido desaparecido, empezando por la home usada como cajón de sastre, no arregla el problema: confunde a quien buscaba algo concreto y le hace desconfiar del resto del sitio, y Google puede acabar tratando esa redirección como poco relevante para la consulta original. En ese escenario, un 404 bien diseñado, con navegación y buscador propios, es más honesto y más útil que un redirect forzado.

Quien elimina contenido a propósito y tiene la certeza de que no habrá ningún sustituto puede usar, en lugar de un 404, el código 410, menos habitual. Comunica «eliminado de forma deliberada y definitiva» en vez del mensaje más ambiguo de «aquí no hay nada» que también da un 404 cuando un enlace se rompe por accidente. En la práctica Google trata ambos de forma parecida; la diferencia importa sobre todo para quien revisa los logs del servidor.

• Evita las cadenas de redirects: si la URL A redirige a la B, que la B sea ya la versión final, no otro salto hacia una C. Cada salto adicional cuesta presupuesto de rastreo y retrasa la transferencia de señales.
• Redirige siempre a una página con contenido equivalente, nunca de forma genérica a la home.
• Usa 301 para cualquier cambio que consideres definitivo, aunque en el momento de implementarlo tengas alguna duda: es más fácil corregir un 301 que quitar demasiado tarde un 302 que llevaba meses frenando el traspaso de señales.
• Actualiza los enlaces internos que apuntaban a la URL antigua para que apunten directamente a la nueva, en vez de dejar que pasen por la redirección.
• Antes de cualquier migración de dominio o de estructura, prepara un mapa completo de redirecciones URL por URL; improvisarlas sobre la marcha es la causa más habitual de redirects genéricos hacia la home.
• Comprueba con una herramienta de línea de comandos (curl -I es suficiente) que la redirección devuelve realmente el código 301 y no un 302 puesto por defecto por el CMS.
• Vigila en Search Console y en la analítica el tráfico de la URL nueva durante las semanas posteriores a la migración; una caída sostenida suele señalar redirects mal mapeados, no un problema del 301 en sí.

• Dejar un 302 en un cambio permanente porque es el código que aplica el CMS por defecto, sin revisarlo nunca.
• Redirigir todas las URL antiguas de una migración a la página de inicio en lugar de a su equivalente real.
• Crear cadenas de varios saltos que nadie revisa hasta que alguien nota que el sitio va más lento de lo esperado durante el rastreo.
• Dejar los enlaces internos apuntando a la URL antigua después de haber puesto el redirect, en vez de actualizarlos a la nueva dirección.
• Mezclar señales contradictorias: una URL con un canonical que apunta a un sitio, mientras el enlazado interno la redirige a otro.
• Usar un redirect 301 para "esconder" contenido con problemas en vez de mejorarlo o eliminarlo con criterio.