Ir al contenido 
Te explicaré de forma concisa y clara cómo puedes crear un Redirect Loop WordPress y analizarlos y resolverlos de forma fiable. Le mostraré soluciones inmediatamente realizables para conflictos SSL, reglas .htaccess defectuosas, URLs incorrectas del sitio, caché/cookies, problemas de plugins y configuración del servidor, incluyendo pruebas y prevención.
Puntos centrales
La siguiente lista resume los pasos más importantes antes de que explique los pasos en detalle.
- Causa reducir rápidamente: SSL, .htaccess, URL, plugins, caché
- Estándar-Comprobar reglas: .htaccess y wp-config.php
- HTTPS configurado correctamente: Certificado, Contenido Mixto, HSTS
- Plugins Apagado a modo de prueba: a través del cuadro de mandos o FTP
- Prevención establecer: Copias de seguridad, documentación, supervisión
¿Qué significa realmente un bucle de redirección?
A Bucle de reenvío se produce cuando la URL A salta a la URL B y B salta de nuevo a A - o cuando varios saltos conducen de nuevo a la dirección de inicio al final. El navegador entonces cancela con ERR_TOO_MANY_REDIRECTS y bloquea la llamada. A menudo reconozco el bucle por el hecho de que el inicio de sesión carga de nuevo el formulario de inicio de sesión después de la entrada correcta. Para los visitantes esto parece una ronda interminable, para los motores de búsqueda un error técnico. Esto cuesta confianza, impide el inicio de sesión en el backend y consume valiosos presupuestos de rastreo.
Principales causas de los bucles en WordPress
Encuentro los desencadenantes más frecuentes en falso URL de WordPress, reglas .htaccess agresivas, doble SSL o redireccionamientos caóticos de plugins. Las cookies antiguas y las cachés duras de los navegadores también desvían las peticiones. Tras cambios de dominio o conversiones a HTTPS, los errores se producen con más frecuencia porque se mezclan http y https. En temas con redirecciones propias o plugins de seguridad, las reglas pueden bloquearse entre sí. En raras ocasiones, el malware configura deliberadamente las redirecciones para bloquear a los administradores.
Pruebas rápidas en el navegador: Cookies y caché
Empiezo con un Cliente-comprobar, porque aporta claridad en cuestión de minutos. Borro las cookies y toda la caché del dominio afectado. Una ventana privada ayuda a excluir las sesiones antiguas. Si el inicio de sesión funciona entonces, se debe a datos locales y no al servidor. Si el error sigue produciéndose, voy al nivel del servidor y de WordPress.
Compruebe .htaccess y restablezca los valores predeterminados
Aseguro el .htacceso y reajustarlas al estándar de WordPress como prueba. Así es como elimino las redirecciones conflictivas de experimentos anteriores o reglas SEO.
# BEGIN WordPress
RewriteEngine Activado
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress
Una vez que todo esté en marcha, añadiré redirecciones adicionales paso a paso. Para condiciones limpias me refiero a redirecciones htaccess con ejemplos prácticos. Importante: Nunca fuerce http→https dos veces - una vez a nivel de servidor es suficiente.
Personalizar las URL de WordPress en los ajustes y en wp-config.php
Desviaciones entre WP_HOME y WP_SITEURL a menudo desencadenan bucles interminables, especialmente después de las transferencias de dominio. Primero compruebo Configuración > General. Si no se puede acceder al backend, configuro brevemente los valores en wp-config.php:
define( 'WP_HOME', 'https://deinedomain.de' );
define( 'WP_SITEURL', 'https://deinedomain.de' );
En caso de problemas SSL del administrador, también desbloqueo temporalmente el acceso:
define('FORCE_SSL_ADMIN', false);
En cuanto estoy en el panel de control, establezco las direcciones URL correctas y vuelvo a eliminar las constantes. Las direcciones normalizadas evitan los bucles repetidos.
Resolución limpia de conflictos HTTPS/SSL
Los conflictos surgen cuando SSL se aplica en el lado del servidor y un plugin también establece las redirecciones. Primero compruebo si el certificado es válido y si las cabeceras HSTS o proxy interfieren con el reconocimiento. A continuación, me aseguro de que haya una ubicación clara que aplique https, preferiblemente a nivel de servidor. Elimino sistemáticamente los errores de contenido mixto y las cadenas de reenvío incorrectas. Para el cambio real, estas instrucciones me ayudan a Conversión HTTPS en WordPress.
Limitación de plugins y temas como fuente de errores
Enciendo sospechoso Plugins especialmente las herramientas de redirección, SEO y seguridad. Si no puedo acceder al backend, renombro la carpeta wp-content/plugins a plugins.old mediante FTP. Entonces activo cada plugin individualmente en el panel de control hasta que el error reaparece. Cambiar a un tema estándar como Twenty Twenty-Four también muestra si el tema está contribuyendo reglas. Esto me permite encontrar rápidamente la causa y crear una configuración libre de conflictos.
Fin de los bucles de inicio de sesión: Cookies, sesiones, seguridad
Si el inicio de sesión falla a pesar de ser correcto Datos salta de nuevo, compruebo el dominio de la cookie, la ruta y la bandera https. Borro las cachés a todos los niveles: Navegador, caché de WordPress, caché de objetos, CDN. Para los plugins de seguridad, compruebo las reglas que redirigen las URL de administración o restringen los inicios de sesión. Borro temporalmente los valores por defecto para el diagnóstico y luego reconstruyo la seguridad poco a poco. Objetivo: una sesión estable sin redirecciones duplicadas.
Configurar correctamente el proxy inverso, la CDN y el encabezado del servidor
Detrás de un Proxy Las aplicaciones confunden fácilmente http y https si el encabezado Forwarded o X-Forwarded-Proto falta o llega incorrectamente. Compruebo las configuraciones de Nginx/Apache, los ajustes del equilibrador de carga y el reenvío CDN. Es importante que WordPress reconozca correctamente la URL real del cliente. Para configuraciones con un proxy upstream, esta guía me ayuda a Configurar proxy inverso. Esto evita reglas contradictorias entre servidor, CDN y plugin.
El malware como última fuente de sospecha
Si el bucle aún puede cerrarse a pesar de todas las correcciones no Analizo la instalación en busca de código malicioso. Comparo los archivos principales con los originales, compruebo los administradores más recientes y los cron jobs. Expongo las redirecciones en cabeceras, archivos de plantilla o a través de JavaScript buscando window.location, meta refresh u oscuras cadenas Base64. Tras la limpieza, restablezco las contraseñas y hago una nueva copia de seguridad. La seguridad contra la reinfección ahorra mucho tiempo después.
Profilaxis y seguimiento en la vida cotidiana
Evito los bucles Cambios gestiono de forma centralizada los redireccionamientos y los pruebo en un entorno de ensayo antes de implementarlos en vivo. Creo copias de seguridad automáticamente y mantengo actualizados los plugins y los temas. Tras los cambios de dominio, compruebo las URL del sitio, SSL y las cadenas de redireccionamiento. Un pequeño sistema de monitorización me notifica los saltos de código de estado en una fase temprana. La siguiente tabla ayuda a realizar diagnósticos rápidos durante el funcionamiento.
| Síntoma | Posible causa | Medida directa | Herramienta de prueba |
|---|---|---|---|
| ERR_TOO_MANY_REDIRECTS | Doble aplicación de https | Utilice sólo una ubicación para los redireccionamientos | Comprobación del encabezado HTTP, Curl |
| El inicio de sesión vuelve a saltar | Conflicto cookie/sesión | Borrar cookies, vaciar caché | Ventana privada, DevTools |
| La página de inicio no se carga | .htaccess bucle | Activar .htaccess estándar | Registros del servidor, diff |
| Defectuoso sólo bajo poder | Cabecera Proto incorrecta | Establecer X-Forwarded-Proto correctamente | Proxy-Config, Header-Trace |
| De repente de la clasificación | Cadenas de redireccionamiento | Reducir cadenas, 301 correcto | Crawler, Rana Gritona |
Seguimiento preciso de las redirecciones: Rastreo de encabezados y curl
Antes de pasar a las configuraciones, dibujo el cadena exacta a. En el DevTools (pestaña Red) se puede ver cada salto con el código de estado y el encabezado de ubicación. En el shell es a menudo suficiente:
curl -IL https://deinedomain.de
# o detallada con visualización de cada redirección
curl -IL --max-redirs 20 https://deinedomain.de
Busco patrones como http→https→http (ida y vuelta) o www↔non-www. Un 302 que sigue a un 301 también es sospechoso. Si incluso la primera petición redirige a /wp-login.php, la causa suele estar en el plugin/tema o las cookies; si ocurre globalmente, suele ser .htaccess o el servidor.
Uso selectivo de los registros del servidor y de WordPress
Los logs ahorran horas. Activo el registro de depuración en wp-config.php sin mostrarlo a los visitantes:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);
Luego compruebo /wp-content/debug.log en busca de indicaciones (por ejemplo, "No se puede modificar la información de cabecera" antes de una redirección). Al mismo tiempo, compruebo los registros del servidor web. Para Apache: access.log y error.log, para Nginx: access.log con estado 301/302. Un vistazo al agente de usuario ayuda a determinar si sólo están afectados los bots o todos los usuarios.
WP-CLI: rescate rápido a través de la consola
Si no se puede acceder al salpicadero, resuelvo muchas cosas mediante WP-CLI:
# Comprobar y establecer URLs
wp opción get home
wp option obtener siteurl
wp option actualizar home 'https://deinedomain.de'
wp option actualizar siteurl 'https://deinedomain.de'
# "Guardar a través de" permalinks una vez
wp rewrite flush --hard
# Vaciar cachés
wp vaciar caché
wp transient delete --all
# Desactivar / probar plugins en masa
wp plugin deactivate --all
wp plugin activar classic-editor
De esta forma puedo volver al sistema sin riesgos, encontrar a los culpables y activar sólo lo realmente necesario.
www, barra y canonización sin bucle
Los bucles suelen crearse a partir de pequeñas incoherenciaswww vs. no www, falta/barra adicional o proto mixto. Me decido por una variante y sólo establezco a Cadena de reglas. Ejemplo non-www→www en Apache (sin doble https enforcement):
RewriteEngine Activado
# Sólo reenviar si el host no es ya www
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ https://www.%{HTTP_HOST}/$1 [L,R=301]
Con Nginx, establezco un reenvío de bloque de servidor claro y evito reglas mixtas en PHP/plugins. Importante: Primero la canonicalización (www/barra), luego https - y sólo a a Cargo.
Limpiar detrás de proxy/CDN: Reconocer HTTPS correctamente
Si WordPress está detrás de un balanceador de carga o CDN, el backend a menudo sólo recibe http, aunque el cliente utiliza https. WordPress entonces reconoce is_ssl() incorrectamente y genera bucles. Corrijo las variables del servidor en wp-config.php:
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
$_SERVER['HTTPS'] = 'on';
}
También configuro las cabeceras X-Forwarded-Proto y Forwarded clean en el proxy. Uso HSTS con moderación: Si HSTS está activo, puede ninguno http, de lo contrario el navegador se cuelga. Yo sólo uso precarga cuando todos los subdominios se están ejecutando de forma estable en https.
Desactivar las trampas de inicio de sesión y cookies
Una fuente común son las cookies mal configuradas. Yo suelo configurar ninguno DOMINIO_COOKIE. Si se ha definido una vez, lo cambio como prueba:
define('COOKIE_DOMAIN', false);
También compruebo si la bandera de la cookie admin "Secure" está activada en https y la ruta está establecida en "/". En caso de problemas persistentes, elimino las sesiones del servidor (por ejemplo, reiniciando php-fpm) y vacío la caché de objetos/redis para que los nonces antiguos dejen de tener efecto.
Particularidades del mapeo multisitio y de dominios
En Multisitio-configuraciones, diferentes mapeos conducen rápidamente a un bucle: Subdominio frente a modo directorio, protocolos diferentes o un antiguo plugin de mapeo de dominios con sus propias redirecciones. Compruebo las tablas del blog y del sitio, sincronizo protocolos y hosts y desactivo brevemente las redirecciones automáticas para cambiar de idioma. Un inicio de sesión "Super Admin" en el blog principal ayuda a ver las redirecciones de red de forma centralizada. Importante: Sólo una instancia decide sobre el dominio canónico.
WooCommerce, multilingüismo y "Ocultar inicio de sesión"
Las tiendas y sitios multilingües tienen lógicas de redirección adicionales: páginas SSL forzadas (checkout/cuenta), redirección de idioma a Accept-Language o funciones "Hide Login" en plugins de seguridad. Para el diagnóstico, desactivo la redirección automática de idioma y permito temporalmente /wp-login.php sin desvío. En WooCommerce, configuro "Sólo estas páginas en SSL" de forma limpia en el lado del servidor o completamente en todo el sistema para que no se produzcan estados mixtos.
Caché de objetos de coordenadas, caché de opcodes y bordes
Varias capas de caché pueden entre sí Amplifico: PHP opcode (OPcache), caché de objetos (Redis/Memcached), caché de páginas de plugins y CDN edge. Las vacío en una secuencia ordenada para que ninguna capa devuelva redirecciones antiguas. Tras los cambios de reglas, invalido completamente la caché edge. Sólo entonces una prueba tiene sentido.
Trampas típicas de Nginx
Con Nginx, se producen bucles cuando los bloques de ubicación se reescriben dos veces o /index.php vive interna y externamente. Utilizo una única configuración limpia: primero el reenvío del bloque del servidor (www/https), luego un try_files claro en /index.php. Evito sistemáticamente las mezclas de actualización add_header y 301/302.
Lista de comprobación: encuentre la causa en 10 minutos
- Borrar cookies/cache localmente, probar en modo incógnito
- ejecute curl -IL y vea la cadena
- Restablecer .htaccess/Nginx a la ruta por defecto
- Sincronizar WP_HOME/WP_SITEURL (si es necesario a través de WP-CLI)
- Sólo una instancia aplica https (servidor preferido)
- Desactivar plugins/tema, activar paso a paso
- Establecer cabecera proxy correctamente, comprobar is_ssl()
- Caché de objetos/páginas/borde vacía
- Compruebe los registros: debug.log, access/error.log
- Características especiales: Multisitio, Woo, Idiomas, Hide-Login
Patrones de error más allá de los bucles clásicos
No todos los 301/302 son bucles reales, pero Desvío costes también. Un 301 en lugar de un 404 señala a los motores de búsqueda "este recurso está aquí para siempre", pero proporciona vacío. O un 302 en lugar de 301 impide la consolidación permanente de las señales. Yo mantengo la cadena en un máximo de uno o dos niveles, establezco 301 para los casos permanentes, 302 para los temporales y evito las pérdidas de cadenas de consulta pasando las banderas QSA o los args correctamente.
Despliegues estables y documentación
Para evitar que se produzcan bucles en primer lugar, documento cada norma¿Quién dirige qué a dónde y por qué? Utilizo un entorno de ensayo, pruebo allí los cambios de reglas, registro las cabeceras y los tiempos y, a continuación, distribuyo configuraciones idénticas de servidor y plugin en producción. Una breve comprobación posterior (página de inicio, inicio de sesión, comprobación, idioma) evita fallos.
Conclusión resumida
Voy a lanzar un Bucle de reenvío Sistemático: Comprueba las cookies, restablece .htaccess a los valores predeterminados, personaliza las URL de WP, configura SSL correctamente, aísla los plugins/temas y entrega las cabeceras del servidor correctamente. Estos pasos suelen acabar con el bucle en poco tiempo. A continuación, aseguro la instalación, documento las redirecciones y mantengo las actualizaciones al día. Esto mantiene el acceso accesible, los visitantes aterrizan en las páginas correctas y los motores de búsqueda rastrean sin perder tiempo. Un enfoque estructurado evita repeticiones y ahorra nervios.
