Do you ask for passwords in the form?

No. The public form never requests access. Secure credentials are requested only after the scope and quote are approved.

Who reviews the incident?

The request goes to Jordi Ensenyat, founder of Code Barcelona and a WordPress specialist with more than 15 years of experience.

Is anything changed before the quote?

No. Visible symptoms and scope are reviewed first. Intervention begins after approval and with a rollback path prepared.

Do you work internationally?

Yes. WP Repair handles WordPress and WooCommerce incidents in English and Spanish through a remote service.

WordPress Admin Redirects Back to the Login Page

When valid credentials return to wp-login.php, authentication may have failed, or WordPress may have set a cookie that the next request cannot use. Domain, HTTPS, cache and security plugins often create the second pattern.

Do not keep resetting the password until you know which stage failed.

Observe the login exchange

Use a private browser and inspect Network. Record POST status, redirects, final host/scheme and whether WordPress sets authentication cookies.

Record without cookie values:
login host and HTTPS
Set-Cookie attributes
redirect Location
final response cache status
WordPress/PHP error time

Never publish cookies, nonces or the password.

Confirm credentials and account state

Look for a clear incorrect-password, blocked-user or two-factor message. Check whether the account exists and has administrator capability using WP-CLI or a protected database/WordPress tool.

Avoid creating a permanent emergency administrator when an existing account is simply affected by cookies. Any temporary account needs an audit and removal.

Check security-plugin lockout logs before disabling protection.

Align WordPress URLs

home and siteurl, plus WP_HOME/WP_SITEURL, should point to the canonical host and HTTPS path. A cookie for www may not accompany a redirect to non-www.

After proxy/SSL migration, WordPress must detect HTTPS correctly. Trust forwarded headers only from the known proxy, not arbitrary visitors.

Do not hard-code COOKIE_DOMAIN unless evidence requires it; wrong values can lock out everyone.

Exclude login and admin from cache

wp-login.php and /wp-admin/ must not be served from public full-page cache. Inspect Cloudflare, host and WordPress response headers.

Purge after fixing rules, then test after cache warm-up. A cold miss can hide the loop.

Static CSS/JS may remain cached, but login HTML and redirects are user-specific.

Check browser cookie acceptance

Inspect cookie domain, path, Secure and SameSite attributes without copying their values. Test mainstream browsers and privacy settings.

A consent tool should not remove WordPress authentication cookies when optional analytics is rejected. Test consent states in separate profiles.

Incorrect server time can also make cookies appear immediately expired; verify system/PHP time.

Isolate plugins and theme

Authentication, membership, SSO and redirect plugins can change login behaviour. Read PHP/security logs and use WP-CLI --skip-plugins or directory rename for the implicated component.

Check must-use plugins separately. Do not deactivate all protection on production without a compensating access control.

A default-theme test belongs on staging unless the login template itself is implicated.

Inspect redirect code

Search site-owned code for login_redirect, wp_login, template_redirect and forced-domain rules. Avoid redirects back to a route that requires authentication before cookies are recognised.

wp_safe_redirect( admin_url() );
exit;

Use safe local destinations and capability checks. Do not trust an arbitrary external redirect_to.

Check multisite and subdirectory cookies

In multisite, network domain/path and site paths determine cookie scope. A login at the network host can loop when a mapped domain, subdirectory or ADMIN_COOKIE_PATH no longer matches after migration.

Inventory network/site URLs and configuration constants before changing them. Test network admin and individual site admin separately. Do not copy cookie constants from another multisite; a broader domain/path can expose sessions to sites that should not receive them.

Invalidate only the necessary sessions

If one user has a corrupt/stale session, revoke that account’s sessions through WordPress or reset its password according to policy. Changing authentication salts logs out everyone and should be reserved for compromise or an explicit global reset.

Do not delete the whole usermeta table or all transients. Preserve audit logs and notify affected administrators before a planned global logout.

Verify the complete account path

Test login, admin navigation, logout, password reset, session expiry and another role. Confirm two isolated users cannot see each other’s sessions.

Monitor login 3xx/4xx and security events. Recurring care should re-test administrator access after domain, SSL, cache and SSO changes; a working homepage provides no evidence that authentication continuity is intact.