Evaluación inicial sin contraseñas Presupuesto antes de intervenir Especialista responsable de principio a fin

Administrador Medios Frontend

El administrador de WordPress redirige de nuevo a la página de acceso

Corrige el bucle de acceso a WordPress revisando cookies, dominio y HTTPS, caché, plugins de seguridad y sesiones del usuario.

Cuando unas credenciales válidas regresan a wp-login.php, la autenticación puede haber fallado o WordPress puede haber creado una cookie que la siguiente petición no consigue utilizar. El dominio, HTTPS, caché y los plugins de seguridad suelen provocar el segundo caso.

No sigas cambiando la contraseña hasta saber en qué fase falla.

Observa el intercambio de acceso

Usa un navegador privado y abre Red. Anota el estado del POST, las redirecciones, el host y protocolo finales y si WordPress crea cookies de autenticación.

Registra sin los valores de cookie:
host de acceso y HTTPS
atributos Set-Cookie
cabecera Location
estado de caché de la respuesta final
hora del error de WordPress o PHP

No publiques cookies, nonces ni la contraseña.

Confirma las credenciales y la cuenta

Busca un mensaje claro de contraseña incorrecta, usuario bloqueado o segundo factor. Comprueba que la cuenta existe y tiene capacidad de administrador mediante WP-CLI o una herramienta protegida.

No crees un administrador permanente de emergencia si el usuario actual solo tiene un problema de cookies. Toda cuenta temporal necesita registro y eliminación.

Consulta los bloqueos del plugin de seguridad antes de desactivarlo.

Alinea las URLs de WordPress

home, siteurl, WP_HOME y WP_SITEURL deben usar el host y ruta HTTPS canónicos. Una cookie para www puede no acompañar una redirección sin www.

Después de migrar proxy o SSL, WordPress debe detectar HTTPS correctamente. Confía en cabeceras reenviadas solo desde el proxy conocido.

No fijes COOKIE_DOMAIN salvo que las pruebas lo exijan; un valor erróneo bloquea a todos.

Excluye acceso y administración de la caché

wp-login.php y /wp-admin/ no deben servirse desde una caché pública de página. Revisa cabeceras de Cloudflare, hosting y plugins.

Purga después de corregir las reglas y prueba de nuevo con caché caliente. Un primer MISS puede esconder el bucle.

Los CSS y JavaScript pueden estar en caché, pero el HTML y las redirecciones de acceso son específicos de cada usuario.

Comprueba la aceptación de cookies

Revisa dominio, ruta, Secure y SameSite sin copiar valores. Prueba navegadores habituales y configuraciones de privacidad.

Una herramienta de consentimiento no debe eliminar las cookies de autenticación cuando se rechazan analíticas. Prueba cada estado en perfiles separados.

Una hora incorrecta del servidor puede hacer que caduquen inmediatamente.

Aísla plugins y tema

Plugins de autenticación, membresía, SSO y redirección pueden cambiar el acceso. Lee registros y usa WP-CLI --skip-plugins o renombra el componente señalado.

Revisa por separado los plugins obligatorios. No desactives toda la protección en producción sin otro control compensatorio.

Prueba un tema predeterminado en staging salvo que esté implicada la propia plantilla de acceso.

Inspecciona el código de redirección

Busca en código propio login_redirect, wp_login, template_redirect y reglas de dominio forzado. Evita volver a una ruta que exige autenticación antes de reconocer la cookie.

wp_safe_redirect( admin_url() );
exit;

Usa destinos locales seguros y comprueba capacidades. No aceptes un redirect_to externo arbitrario.

Revisa cookies de multisitio y subdirectorios

En multisitio, dominio y ruta de red o sitio determinan el alcance. Un dominio mapeado, subdirectorio o ADMIN_COOKIE_PATH antiguo puede provocar el bucle tras migrar.

Inventaría URLs y constantes antes de cambiar. Prueba administración de red y de cada sitio por separado. No copies constantes de otra red: un alcance más amplio puede compartir sesiones con sitios indebidos.

Invalida solo las sesiones necesarias

Si un usuario tiene una sesión corrupta, revoca sus sesiones mediante WordPress o cambia su contraseña según la política. Cambiar las salts cierra todas las sesiones y debe reservarse para una brecha o cierre global intencionado.

No borres toda la tabla usermeta ni todos los transients. Conserva auditoría y avisa antes de una desconexión general.

Verifica todo el recorrido de la cuenta

Prueba acceso, navegación administrativa, salida, recuperación de contraseña, caducidad de sesión y otro rol. Confirma que dos usuarios aislados no comparten sesiones.

Vigila respuestas 3xx o 4xx y eventos de seguridad. El mantenimiento recurrente debe probar el acceso tras cambiar dominio, SSL, caché o SSO; que funcione la portada no demuestra continuidad de autenticación.

ANTES DE ENVIAR LA SOLICITUD

Preguntas frecuentes.

¿Pedís contraseñas en el formulario?+

No. El formulario público nunca solicita accesos. Los datos seguros se piden únicamente después de aprobar el alcance y el presupuesto.

¿Quién revisa la incidencia?+

La solicitud llega a Jordi Ensenyat, fundador de Code Barcelona y especialista WordPress con más de 15 años de experiencia.

¿Se cambia algo antes del presupuesto?+

No. Primero se revisan los síntomas visibles y se define el alcance. La intervención empieza tras la aprobación y con una vía de vuelta preparada.

¿Trabajáis con webs en inglés y fuera de España?+

Sí. WP Repair atiende incidencias WordPress y WooCommerce en inglés y español, con servicio remoto.

Evaluar mi incidencia