WordPress wp-admin infinite redirect loop after login while frontend still works normally - ilustracion

Cómo arreglar el loop de redirección en wp-admin de WordPress

Entrás a tu WordPress, ponés usuario y contraseña, le das clic a «Acceder» y el navegador te tira ERR_TOO_MANY_REDIRECTS. El frontend del sitio carga perfecto, pero el wp-admin entró en un loop sin fin. En el 40-50% de los casos la causa es un mismatch entre la URL guardada en WordPress y la que sirve el servidor (HTTP vs HTTPS, www vs no-www). Se arregla en 10-15 minutos.

El bucle de redirección infinita en wp-admin de WordPress es un error en el que el servidor genera una cadena interminable de redirecciones HTTP 301/302 al intentar cargar el panel de administración. El navegador corta la conexión tras varios saltos y muestra ERR_TOO_MANY_REDIRECTS. Suele dispararse por desajustes de URL, conflictos de plugins, cookies corruptas, configuración de SSL o el modo Flexible de Cloudflare.

En 30 segundos

  • Causa más común: WP_HOME y WP_SITEURL no coinciden con el protocolo real (40-50% de los casos).
  • Primer paso siempre: borrar cookies del dominio y probar en ventana de incógnito.
  • Si no entrás al admin: definí las URLs a mano en wp-config.php y desactivá plugins renombrando la carpeta por FTP.
  • Sospechoso frecuente: Cloudflare en modo «Flexible» forzando HTTPS contra un servidor que responde HTTP.
  • Tiempo de resolución: entre 10 y 30 minutos según la causa, casi siempre sin tocar la base de datos.

WordPress es un sistema de gestión de contenidos (CMS) de código abierto para crear y administrar sitios web, desarrollado originalmente por Matt Mullenweg. Facilita la publicación de contenido mediante una interfaz intuitiva, sin requerir conocimientos técnicos avanzados.

¿Cuáles son las causas del bucle de redirección infinita en WordPress?

El loop pasa cuando el sitio te manda de la URL A a la B, y la B te devuelve a la A, sin parar. WordPress hace este salto en cada carga del admin, y como nunca llega a un destino estable, el navegador tira la toalla.

Lo curioso es que el frontend siga andando. Eso pasa porque la home no fuerza el protocolo de la misma forma que lo hace wp-admin, que es más estricto con HTTPS. Estas son las causas que vas a ver una y otra vez:

  • Mismatch de URL: «WordPress Address» en HTTP y «Site Address» en HTTPS, o uno con www y el otro sin www. Es el origen más habitual.
  • Conflictos de plugins: los de SSL forzado, redirecciones y login son los que más rompen. Really Simple SSL y Redirection encabezan la lista.
  • Cookies corruptas: el navegador guarda una cookie de sesión vieja que ya no matchea con la configuración actual.
  • .htaccess dañado: reglas mal escritas por un plugin que se desinstaló a medias.
  • FORCE_SSL_ADMIN mal puesto: forzás HTTPS en el admin cuando el servidor ya lo fuerza por su cuenta.
  • Cloudflare en modo Flexible: Cloudflare habla HTTPS con el visitante pero HTTP con tu servidor, y ahí se arma el loop.

¿Cómo identificar el ERR_TOO_MANY_REDIRECTS en el navegador?

El mensaje cambia según el navegador. En Chrome vas a ver «ERR_TOO_MANY_REDIRECTS» con el texto «Esta página no funciona». En Firefox aparece «La página no está redirigiendo correctamente» o «Redirect Loop Detected». En ambos casos el síntoma es el mismo: escribís la contraseña correcta, hacés clic y nunca llegás al dashboard. Cubrimos ese tema en detalle en configuración de usuarios y comunidad.

¿Querés confirmar que es un loop y no otra cosa? Abrí las DevTools de Chrome (F12), andá a la pestaña Network y recargá el login. Si ves una catarata de respuestas 301 o 302 repitiéndose contra wp-login.php o wp-admin, ahí tenés el diagnóstico.

Ojo con una distinción importante. No es lo mismo que el loop pase en wp-login.php (antes de entrar) que después del login (cuando ya validó la contraseña y trata de llevarte al panel). El segundo caso casi siempre apunta a cookies o a un mismatch de URL en el área de administración.

Verificar y corregir la configuración de URLs de WordPress

Esta es la solución del 40-50% de los casos, así que arrancá por acá.

Si todavía podés entrar al admin

Andá a Ajustes > Generales y revisá que «Dirección de WordPress (URL)» y «Dirección del sitio (URL)» sean idénticas. Mismo protocolo en las dos (las dos en https) y la misma decisión sobre el www (o las dos con www, o ninguna). Si una dice https://ejemplo.com.ar y la otra https://www.ejemplo.com.ar, ahí está tu loop.

Si no podés entrar (lo más común en este escenario)

Editá wp-config.php por FTP o desde el administrador de archivos de tu hosting, y agregá estas dos líneas antes de la frase «That’s all, stop editing!»:

  • define(‘WP_HOME’,’https://ejemplo.com.ar’);
  • define(‘WP_SITEURL’,’https://ejemplo.com.ar’);

Estas líneas según la documentación oficial de WordPress pisan lo que esté guardado en la base de datos y no se pueden cambiar desde el panel mientras estén ahí (lo cual, en este caso, es justo lo que querés). Si preferís ir a la base, los campos siteurl y home viven en la tabla wp_options.

Limpiar cookies, caché del navegador y del servidor

Antes de tocar archivos, hacé esto. Toma dos minutos y a veces resuelve todo.

Borrá las cookies del dominio en tu navegador y limpiá la caché. ¿La forma más rápida de descartar que sea un tema de cookies? Abrí una ventana de incógnito y probá el login ahí. Si entrás sin drama, el problema era una cookie vieja en tu sesión normal.

Después limpiá la caché del lado del sitio. Si usás un plugin de caché (WP Super Cache, W3 Total Cache, LiteSpeed Cache), purgalo. Y si tenés Cloudflare adelante, entrá al panel y hacé «Purge Everything». El orden importa: primero el origen, después el CDN.

Desactivar plugins y cambiar el tema sin acceso al panel

Si las URLs ya están bien y el loop sigue, el culpable es un plugin en 8 de cada 10 casos.

Conectate por FTP, andá a /wp-content/ y renombrá la carpeta plugins a plugins-disabled. Eso desactiva todos los plugins de una. Probá el login. Si entrás, volvé a renombrar la carpeta a plugins y andá activando uno por uno desde el panel hasta que el loop reaparezca. Ese es tu culpable.

Los reincidentes son los de SSL forzado (Really Simple SSL, WP Force SSL), los de redirecciones (Redirection) y los de personalización de login (LoginPress). Para descartar el tema, renombrá la carpeta del theme activo en /wp-content/themes/ y WordPress va a hacer fallback a un theme por defecto.

Solucionar problemas de SSL, FORCE_SSL_ADMIN y Cloudflare

Acá viene el clásico que confunde a todo el mundo. FORCE_SSL_ADMIN obliga a que el wp-admin se sirva por HTTPS. El problema es cuando lo activás y, al mismo tiempo, el servidor o Cloudflare también fuerzan HTTPS por su lado. Resultado: dos capas peleándose y un loop. En prueba el problema en un staging profundizamos sobre esto.

La regla práctica: si tu hosting ya sirve todo por HTTPS, no agregues define('FORCE_SSL_ADMIN',true); en wp-config.php. Es redundante y suele ser justo lo que dispara el bucle.

El caso de Cloudflare merece párrafo aparte. Si tenés el SSL en modo «Flexible», Cloudflare le habla HTTPS al visitante pero HTTP a tu servidor. Tu WordPress recibe la conexión como HTTP, intenta forzar HTTPS, y se arma el ida y vuelta infinito. La solución es cambiar el modo SSL de Cloudflare a Full o Full (Strict), siempre que tu servidor tenga un certificado válido instalado. Si vas a usar Full (Strict), asegurate de que tu proveedor de hosting WordPress te dé un certificado SSL real (un hosting WordPress como el de Donweb ya viene con Let’s Encrypt incluido, por ejemplo).

Reparar y regenerar el archivo .htaccess

Un .htaccess con reglas de redirección rotas también genera loops. La buena noticia es que regenerarlo es trivial.

Entrá por FTP al directorio raíz, descargá el .htaccess como backup y después borralo del servidor. WordPress crea uno nuevo automáticamente cuando entrás a Ajustes > Enlaces permanentes y guardás (no hace falta cambiar nada, con apretar «Guardar cambios» alcanza). Si no podés entrar al admin todavía, creá el archivo a mano con las reglas estándar de WordPress que figuran en la documentación de htaccess de WordPress.org.

Corregir cookies en WordPress Multisite

Si tu instalación es Multisite con subdominios (blog1.ejemplo.com, blog2.ejemplo.com), el loop puede venir de cookies con el mismo nombre pero rutas distintas, que terminan deslogueándote en bucle.

La solución es agregar estas líneas en wp-config.php, antes de «That’s all, stop editing!»:

  • define(‘ADMIN_COOKIE_PATH’, ‘/’); normaliza la ruta de la cookie de admin.
  • define(‘COOKIE_DOMAIN’, »); deja que cada subdominio maneje su propio dominio de cookie.
  • define(‘COOKIEPATH’, »); y define(‘SITECOOKIEPATH’, »); limpian las rutas heredadas.

Esto fuerza a WordPress a manejar las cookies por dominio de forma consistente. Es una corrección específica de Multisite: si tu sitio es una instalación simple, no toques estas líneas. Lo explicamos a fondo en redirecciones y problemas de enlaces.

Tabla: causa, dónde se arregla y tiempo estimado

CausaDónde se corrigeFrecuenciaTiempo
Mismatch de URL (HTTP/HTTPS, www)wp-config.php o Ajustes > Generales40-50%10 min
Cookies corruptasNavegador (incógnito)Frecuente2 min
Conflicto de pluginRenombrar carpeta por FTPFrecuente15 min
Cloudflare modo FlexiblePanel SSL de CloudflareComún con CDN5 min
FORCE_SSL_ADMIN redundantewp-config.phpOcasional5 min
.htaccess dañadoFTP + Enlaces permanentesOcasional10 min
Cookies en Multisitewp-config.phpSolo Multisite10 min
bucle redirección wp-admin diagrama explicativo

Qué está confirmado y qué depende de tu setup

Confirmado:

  • Definir WP_HOME y WP_SITEURL en wp-config.php pisa la base de datos. Está documentado en el reference oficial de WordPress y funciona en cualquier versión.
  • El modo Flexible de Cloudflare genera loops contra servidores que fuerzan HTTPS. Es un comportamiento conocido y reproducible.
  • Renombrar /wp-content/plugins/ desactiva todos los plugins sin perder configuraciones. WordPress los reconoce de vuelta apenas restaurás el nombre.

Depende de tu caso:

Si querés saber cuánto sale un error así, mirá este análisis sobre WordPress wp-admin infinite redirect loop after login while.

  • El tiempo de resolución. Si es cookies, son dos minutos. Si tenés que ir plugin por plugin en un sitio con 40 plugins, puede llevarte media hora.
  • Si necesitás tocar la base de datos. En la mayoría de los casos no hace falta, pero en algunos Multisite viejos sí.

Errores comunes al resolver el loop

  • Activar Really Simple SSL «para arreglar» sin revisar Cloudflare primero. Si el loop viene del modo Flexible, el plugin lo empeora porque agrega otra capa de forzado HTTPS. Corregí Cloudflare antes.
  • Poner FORCE_SSL_ADMIN en true cuando el servidor ya sirve HTTPS. Es la causa que más gente se autoinflige tratando de «asegurar» el admin. Si ya estás en HTTPS, no lo agregues.
  • Editar la base de datos sin backup. Tocar wp_options a mano sin exportar antes es jugar con fuego. Hacé un dump primero, siempre.
  • Olvidarse de purgar la caché después de corregir. Arreglás las URLs pero seguís viendo el loop porque el CDN te sirve la versión vieja. Purgá Cloudflare y el plugin de caché al terminar.

Preguntas Frecuentes

¿Cuál es la causa más común del bucle de redirección en wp-admin?

El desajuste entre la URL de WordPress y la del sitio, presente en el 40-50% de los casos. Pasa cuando «WordPress Address» y «Site Address» no usan el mismo protocolo (una en HTTP y otra en HTTPS) o difieren en el www. Igualá las dos y el loop desaparece.

¿Cómo soluciono el ERR_TOO_MANY_REDIRECTS si no puedo entrar al admin?

Editá wp-config.php por FTP y agregá define(‘WP_HOME’,’https://tudominio.com’); y define(‘WP_SITEURL’,’https://tudominio.com’); con tu URL correcta. Estas líneas pisan lo que haya en la base de datos y restauran el acceso sin necesidad de loguearte al panel.

¿Por qué el frontend funciona pero el wp-admin no?

Porque el área de administración fuerza HTTPS de forma más estricta que la home. Cuando hay un conflicto de protocolo (por ejemplo Cloudflare en modo Flexible o un FORCE_SSL_ADMIN mal puesto), el frontend tolera la inconsistencia pero wp-admin entra en bucle al intentar imponer la conexión segura.

¿Cómo sé si el problema es de URL, de plugin o de SSL?

Probá en orden: primero incógnito (descarta cookies), después revisá las URLs en wp-config.php (descarta mismatch), luego renombrá la carpeta de plugins por FTP (descarta plugin). Si entrás al desactivar plugins, era uno de ellos; si seguía fallando con las URLs corregidas, mirá Cloudflare y FORCE_SSL_ADMIN.

¿Cuánto tarda en resolverse un loop de redirección?

Entre 2 y 30 minutos según la causa. Las cookies se arreglan en dos minutos con una ventana de incógnito; un mismatch de URL toma unos 10; aislar un plugin conflictivo en un sitio cargado puede llevar media hora. Casi nunca hace falta tocar la base de datos.

Conclusión

El bucle de redirección infinita en wp-admin asusta más de lo que cuesta resolverlo. El frontend sigue andando, así que tu sitio no está caído: solo perdiste la puerta de entrada al panel.

Atacalo en orden y vas a ahorrar tiempo. Primero incógnito para descartar cookies, después las URLs en wp-config.php (que resuelven casi la mitad de los casos), luego los plugins por FTP y, si tenés Cloudflare, revisá que no esté en modo Flexible. Dejá la base de datos y el .htaccess para el final, cuando ya descartaste lo obvio.

Si el problema arrancó justo después de migrar de hosting o de activar un SSL nuevo, el sospechoso casi siempre es el protocolo: revisá que el certificado esté bien instalado y que tu proveedor no esté forzando HTTPS por duplicado. Con eso cubrís el 90% de los escenarios.

Fuentes

Volver a

Novedades

Publicaciones relacionadas