Cambió una redirección 301, ¿pero el navegador insiste en enviar a los visitantes a la URL antigua? Un dolor de cabeza familiar para cualquiera que haya configurado migraciones de sitios o reestructurado enlaces.

El problema no es ni el servidor ni WordPress. El navegador recuerda permanentemente una redirección permanente y no vuelve a consultar al servidor; así funciona la especificación HTTP. Hasta que la caché expire o el usuario la borre manualmente, la regla antigua sigue vigente.

A continuación, una estrategia clara: cómo probar redirecciones sin consecuencias, por qué el 302 le salva los nervios durante la depuración y qué hacer si la caché ya quedó atascada para los visitantes reales.

💡 Resumen rápido:

• Empiece siempre con 302 (temporal), pruebe y solo después cambie a 301 (permanente)
• Borre la caché del navegador cada vez que modifique reglas de redirección
• Para Chrome: DevTools → Network → Disable cache, o pestaña Application → Clear site data
• Si un 301 ya está almacenado en caché por los usuarios, solo puede esperar o cambiar la URL de destino

Cómo almacena el navegador en caché una redirección 301

Cuando el servidor responde con un estado 301 Moved Permanently, el navegador lo interpreta literalmente: «esta URL se ha movido para siempre». Almacena el par «URL antigua → URL nueva» en su propia caché de redirecciones, separada de la caché de páginas e imágenes.

La próxima vez que el usuario (o usted, el desarrollador) abre la misma dirección, el navegador no envía ninguna solicitud al servidor. Sustituye inmediatamente la URL de destino guardada desde la caché. El servidor no ve ninguna solicitud y usted no ve el comportamiento actual.

La especificación HTTP no define un período de retención estricto para esta caché. En la práctica, Chrome, Firefox y Safari mantienen el 301 en caché hasta que se borra explícitamente. La cabecera Cache-Control del servidor puede ser ignorada por el navegador específicamente para el 301, porque «permanente» significa permanente.

Este comportamiento es una característica, no un error. Ahorra un viaje de ida y vuelta en traslados permanentes legítimos (por ejemplo, un cambio de dominio). Sin embargo, durante el desarrollo se convierte en una trampa.

Por qué esto causa problemas durante la configuración

Imagine un escenario. Está configurando una redirección de la URL antigua /old-page a /new-page. Configura un 301, lo prueba en el navegador y funciona. Una hora después, se da cuenta de que cometió un error: la URL correcta es /new-page/v2.

Cambia la regla en el servidor y pulsa «actualizar» en el navegador. Llega a /new-page. Otra vez. Porque el navegador ya recordó el primer par y no le da al servidor la oportunidad de mostrar la nueva regla.

Usted piensa que la redirección no funciona. En realidad, sí funciona, solo que no la que acaba de configurar.

En un sitio de pruebas, una vez pasamos media hora iterando reglas de .htaccess antes de darnos cuenta de que el navegador mostraba la caché. Limpiamos la caché y todo funcionó inmediatamente como se esperaba.

La situación es peor con los visitantes. Si activó un 301 incorrecto en un sitio en producción, todos los que visitaron durante esos minutos recibieron la regla equivocada en la caché de su navegador. Usted corrigió el error en el servidor en 10 minutos, pero sus navegadores seguirán enviándolos a la URL antigua durante días o semanas, hasta que se borre la caché.

Nota: no puede borrar la caché de redirecciones del lado del usuario. Ningún truco de servidor puede alcanzar el navegador de otra persona.

La estrategia 302 → 301: pruebe sin consecuencias

Una regla que ahorra horas de depuración y protege contra errores en un sitio en vivo:

Empiece siempre con una redirección 302 (temporal). Cambie a 301 solo después de estar seguro de que la regla es correcta.

El navegador no almacena en caché el 302 de forma agresiva; consulta al servidor de nuevo con cada solicitud. Cambie la regla en el servidor y el navegador recoge inmediatamente el nuevo comportamiento. No necesita borrar la caché.

Enfoque paso a paso para cualquier cambio de URL:

• Configure una redirección 302 en .htaccess, configuración de Nginx o mediante un plugin de WordPress (por ejemplo, Redirection).
• Abra la URL antigua en modo incógnito o con la opción «Disable cache» activada en DevTools.
• Confirme que llega a la página de destino correcta.
• Verifique 2-3 URLs adicionales del mismo grupo.
• Solo cuando todo esté probado, reemplace 302 por 301 en las reglas.
• Haga una comprobación final en modo normal del navegador.

En la práctica, este enfoque toma exactamente dos minutos extra por grupo de redirecciones y elimina por completo el riesgo de un «error almacenado en caché» para los visitantes.

Si usa el plugin Redirection para WordPress, este crea 301 por defecto. Cambie manualmente a 302 en el desplegable al crear una regla y no olvide volver a 301 después de probar.

Cómo borrar la caché de redirecciones localmente

Cuando el navegador ya ha recordado un 301 incorrecto y no puede ver el comportamiento actual, esto es lo que ayuda:

Chrome. Abra DevTools (F12), vaya a la pestaña Network y marque Disable cache. O haga un reinicio completo: Application → Clear storage → Clear site data. El método más fiable para un sitio específico es chrome://settings/clearBrowserData → Cached images and files.

Firefox. Web Developer Tools → Network → Disable Cache. Para una limpieza completa: History → Clear Recent History → Cache.

Safari. Develop → Disable Caches (el menú Develop se activa en Settings → Advanced).

El modo incógnito es una forma rápida de verificar el comportamiento nuevo sin borrar la caché principal. El navegador usa una sesión limpia sin redirecciones guardadas.

Matiz importante: cerrar el navegador NO borra la caché de redirecciones 301. A diferencia del almacenamiento de sesión, la caché de redirecciones sobrevive a los reinicios del navegador. Solo funciona el borrado explícito o el modo incógnito.

Qué hacer si la caché está atascada para los usuarios

Este es el escenario más desagradable: un 301 incorrecto estuvo activo en el sitio de producción durante algún tiempo y parte de su audiencia ahora lo lleva en la caché de sus navegadores. Usted corrigió la regla del servidor, pero estos usuarios siguen llegando al lugar equivocado.

Esto es lo que puede hacer:

• Cambie la URL de destino a una nueva. Si la antigua location apuntaba a /page-v1 y necesita /page-v2, simplemente reemplace la dirección en la misma regla. Los navegadores con la URL de destino antigua en caché seguirán yendo allí (el problema). Sin embargo, los nuevos visitantes irán al lugar correcto. Esto no resuelve el problema para los que ya están «infectados», pero detiene la propagación.

• Use un método de redirección diferente. Si el 301 está en caché, el navegador no consulta al servidor, pero la lógica del servidor sigue funcionando para los nuevos visitantes. Añada una redirección JavaScript en la página de destino como capa adicional sobre la redirección HTTP para aquellos que aún llegan a la página antigua.

• Reconozca honestamente: no hay cura directa. No puede acceder al navegador del usuario. Si la caché ya está cargada, la única forma de restablecerla es que el usuario borre la caché o visite a través de un enlace en incógnito. Afortunadamente, la caché de redirecciones no vive para siempre: la reinstalación del navegador, los cambios de dispositivo y las actualizaciones del sistema operativo eventualmente la restablecen.

En nuestra experiencia, un 301 incorrecto se vuelve crítico solo en dos casos: una migración masiva (cientos de URLs) con un error en las reglas, o una redirección de la página de inicio. En ambos casos, el daño de un error almacenado en caché supera cualquier tiempo ahorrado por saltarse las pruebas.

301, 302, 307, 308: Cuándo usar cada uno

Para evitar confusiones, tenga a mano esta tabla rápida de códigos de redirección:

Para un sitio WordPress, conocer la diferencia entre 301 y 302 es suficiente en la gran mayoría de los casos. Los códigos 307 y 308 son herramientas de nicho para situaciones donde preservar el método HTTP es crítico (por ejemplo, un formulario debe seguir siendo una solicitud POST y no convertirse en GET durante una redirección).

En resumen: 302 es su herramienta de trabajo durante el desarrollo. 301 es el sello final de «terminado».

Una trampa más: WordPress y plugins de caché

En WordPress, el problema de la caché del 301 se suma a la caché del servidor y de los plugins. Una situación típica:

Edita una redirección en el plugin Redirection, hace clic en «guardar» y no funciona. Borra la caché del navegador y sigue apareciendo la página antigua. ¿Qué está pasando? Un plugin de caché (WP Rocket, LiteSpeed Cache, W3 Total Cache) sirvió una versión cacheada de la página; el servidor ni siquiera ejecutó la regla de redirección.

Pasos para depurar redirecciones en WordPress:

• Borre la caché del plugin de caché (cada plugin tiene su propio botón «Purge All Cache»).
• Desactive la caché durante las pruebas (en WP Rocket, esto es el Modo Desarrollo).
• Borre la caché del navegador (como se describió anteriormente).
• Solo entonces pruebe la redirección.

En un sitio de pruebas, mantenemos el plugin de caché desactivado hasta que todas las redirecciones están completamente listas y lo activamos solo después del cambio final de 302 a 301.

Este breve video en inglés demuestra visualmente la diferencia entre 301 y 302 en la práctica y explica por qué la elección del código de redirección afecta al SEO:

⁉️🤔 Preguntas frecuentes

¿Por qué el navegador almacena en caché el 301 en lugar de consultar al servidor cada vez?

La especificación HTTP define el 301 como «el recurso se ha movido permanentemente». Consultar al servidor cada vez que se abre la URL contradiría el significado de «permanentemente» y crearía una carga innecesaria. Almacenar en caché la redirección ahorra una solicitud HTTP por visitante. A una escala de decenas de miles de visitas, esto acelera notablemente la navegación. El navegador almacena en caché el hecho de la redirección en sí (el par «de → a»), no el contenido de la página. Este es un tipo de caché separado llamado caché de redirecciones. Chrome lo almacena en el perfil de usuario; Firefox lo almacena en el archivo places.sqlite junto con el historial de navegación. Por eso, borrar la caché de imágenes y scripts no siempre restablece las redirecciones; necesita una limpieza completa o borrar los datos del sitio.

¿Se puede evitar que el navegador almacene en caché el 301 desde el lado del servidor?

Formalmente, no. Los navegadores pueden ignorar la cabecera Cache-Control: no-store para redirecciones permanentes. La especificación no exige que los navegadores respeten Cache-Control para 301/308, ya que una redirección permanente implica que la regla no cambiará. Algunas versiones de Chrome y Firefox respetan Cache-Control para 301, pero no puede confiar en esto en producción; el comportamiento no está garantizado y varía entre versiones. La única forma fiable de «deshacer» el almacenamiento en caché del navegador de un 301 es usar inicialmente 302 durante las pruebas. Si un 301 ya está en caché del usuario, el servidor no puede hacer nada.

¿En qué se diferencia el 302 del 307 en la práctica?

Ambos son redirecciones temporales y ninguno es almacenado en caché por el navegador. La diferencia radica en el manejo del método HTTP. Con 302, el navegador puede cambiar una solicitud POST a GET durante la redirección (esto ocurrió históricamente y muchos navegadores todavía lo hacen). Con 307, se garantiza que el método se preserva: POST sigue siendo POST, PUT sigue siendo PUT. Para WordPress y prácticamente cualquier sitio, la diferencia es insignificante ya que las redirecciones casi siempre implican solicitudes GET (apertura de página). El 307 solo es necesario si formularios, APIs o cargas de archivos pasan por una URL que está redirigiendo temporalmente.

¿Cómo puedo comprobar qué redirección está almacenada en caché en mi navegador?

Abra DevTools (F12) → pestaña Network y marque «Disable cache» (esto es OBLIGATORIO, de lo contrario el navegador no hará una solicitud al servidor y no verá la respuesta actual). Luego abra la URL antigua. En la columna Status, verá el código de respuesta real del servidor (301, 302, etc.) y la cabecera Location con la URL de destino. Sin «Disable cache», DevTools mostrará un estado 200 o (disk cache), lo que significa que el navegador sirvió desde caché y no se consultó al servidor.

¿Es necesario mantener una redirección 301 para siempre?

Google recomienda mantener las redirecciones permanentes durante al menos un año después de un traslado. En la práctica, si la URL antigua ya no se promociona, no tiene enlaces externos y no está indexada, la redirección se puede eliminar después de 6-12 meses. Sin embargo, si otros sitios enlazaban a la URL antigua o está presente en los índices de los motores de búsqueda, debe mantener la redirección permanentemente. Eliminar un 301 con una regla almacenada en caché por los usuarios no resolverá el problema; sus navegadores seguirán usando el par en caché hasta que borren la caché.

¿Debería tener miedo de las redirecciones 301?

No, si sigue la regla de «302 primero». Una redirección permanente es una herramienta fiable para mover contenido, cambiar dominios y limpiar duplicados. Los problemas solo surgen cuando el 301 se configura sin probar.

Recuerde el punto clave: el 301 es una promesa al navegador de que «no cambiaré de opinión». No haga esa promesa hasta que esté seguro. Diez minutos probando una redirección 302 en incógnito le ahorrarán días de limpiar errores almacenados en caché para su audiencia real.