Skip to content
Rescue 404
Rescue

WordPress Admin Problems

WordPress Keeps Logging Me Out (WordPress Repair)

Intermediate Risk: medium

Last reviewed

Hosting access may not be needed Database access usually not needed

Direct answer

WordPress repeatedly logs you out when its authentication cookie is missing, rejected, or invalidated between requests—commonly from changing security salts, mismatched HTTPS or hostnames, forced cookie settings, security-plugin session limits, or a CDN caching personalized admin responses. Use one canonical HTTPS URL, clear old cookies, verify stable keys and salts, and bypass login/admin traffic from caching.

This problem is different from a login redirect loop: you can reach wp-admin and work briefly, but a later click, save, or refresh asks you to sign in again. The timing is useful evidence—instant logout suggests cookie scope or proxy handling, predictable logout suggests expiration policy, and logout after deployments suggests changing salts or environment configuration. This guide traces those patterns without weakening authentication.

Intermediate

Key facts

Verifiable numbers and definitions — each claim links to its source.

What the error means

After a successful login, WordPress gives the browser authentication cookies that contain an expiration, session token, and cryptographic hash. The browser sends those cookies back on later requests, and WordPress validates them using the user session and the keys and salts loaded from `wp-config.php`. If the site alternates between HTTP and HTTPS, www and non-www, or multiple servers with different salts, the next request may be unable to validate the cookie and WordPress sends you back to login. Password changes and salt rotation intentionally invalidate existing cookies. Security plugins can shorten or revoke sessions, while a CDN or full-page cache can serve a stale anonymous or login response where personalized admin traffic should bypass cache.

Common symptoms

  • Login succeeds and wp-admin opens, but the next click or save asks for credentials again
  • The logout happens only on one hostname, protocol, browser, network, or device
  • Editors are logged out at a repeatable interval shorter than expected
  • All users are forced to sign in again after a deployment or configuration change
  • The issue appears randomly on a load-balanced site while some requests stay authenticated
  • A security plugin records session termination, idle timeout, or concurrent-login enforcement
  • Public pages show the admin bar inconsistently or cached pages appear to mix logged-in and logged-out state

Most likely causes

  1. 01 Authentication keys or salts change between requests, deployments, containers, or web servers
  2. 02 WordPress switches between HTTP/HTTPS or www/non-www so cookies do not match the next request
  3. 03 A custom `COOKIE_DOMAIN`, `COOKIEPATH`, or admin cookie setting is stale after a migration
  4. 04 Security plugin, SSO integration, or membership plugin shortens sessions or revokes concurrent logins
  5. 05 CDN, reverse proxy, or page cache does not bypass wp-login, wp-admin, or logged-in cookies
  6. 06 Browser privacy settings, extensions, antivirus, or clock errors remove or reject cookies
  7. 07 User password or session tokens are being reset by another administrator, automation, or suspected attacker

What changed before the problem started

  • Site migrated, domain changed, HTTPS enabled, or www preference switched
  • Security keys and salts were rotated or moved into environment variables
  • A CDN, reverse proxy, host cache, or aggressive page-cache rule was enabled
  • Security, SSO, membership, or limit-login plugin was installed or updated
  • The site moved to multiple web servers, containers, or autoscaling infrastructure
  • A password reset, malware cleanup, or account-security action invalidated sessions

Troubleshooting steps

  1. 01

    Measure when and where the logout happens

    Sign in from a private window at the exact canonical HTTPS URL and note whether logout occurs on the first click, after a fixed number of minutes, or only on a particular admin action. Test one second browser without extensions. This separates cookie scope, expiration policy, and action-specific failures.

  2. 02

    Clear site cookies and stop switching hostnames

    Remove cookies for the domain, close all related tabs, and sign in at one URL such as `https://example.com/wp-login.php`. Keep every test on the same HTTPS and www/non-www form. If that fixes one browser only, inspect browser privacy or extension behavior before changing WordPress.

  3. 03

    Confirm WordPress Address and Site Address agree

    In Settings → General or `wp_options`, verify `siteurl` and `home` use the same intended HTTPS hostname. Check `WP_HOME` and `WP_SITEURL` in `wp-config.php` for overrides. Fix a mismatch before adding cookie constants or redirect rules.

  4. 04

    Verify keys and salts stay stable

    Inspect the eight authentication key and salt definitions in `wp-config.php` or the environment that supplies them. They must be unique but remain identical across requests and all web nodes. Do not rotate them as a casual test because rotation deliberately logs out every user.

  5. 05

    Bypass login and authenticated traffic from caching

    Exclude `/wp-login.php`, `/wp-admin/`, AJAX requests, and requests carrying WordPress logged-in cookies from CDN and full-page cache. Purge existing cached responses after changing rules. Keep static asset caching enabled; the goal is a targeted bypass, not turning off the CDN.

  6. 06

    Temporarily isolate session-control plugins

    Review security, SSO, membership, and cache plugins for idle timeout, absolute timeout, concurrent session, cookie hardening, or forced logout settings. Disable the most likely plugin briefly on staging or during a controlled window and retest the same timeline.

When to stop troubleshooting

Stop if keys or salts differ across production nodes and you cannot coordinate a safe deployment, if logout events coincide with unknown password changes or unfamiliar administrators, or if cached authenticated content may have reached other visitors. Treat those as infrastructure or security incidents. Also escalate before editing cookie constants on a multisite, SSO, membership, or commerce installation where a broad change can lock out many users.

Information to collect before requesting help

  • 01 Exact login URL and canonical site URL, including HTTPS and www choice
  • 02 Time between successful login and logout, plus the action that triggers it
  • 03 Whether all users, one role, one browser, or one network is affected
  • 04 Recent domain, SSL, migration, deployment, CDN, or proxy changes
  • 05 Security, SSO, membership, and caching plugins with session settings
  • 06 Whether authentication keys and salts are stable across every web node
  • 07 Cookie domain, path, Secure flag, and expiration from browser storage tools
  • 08 Security audit entries, password resets, and server logs at the logout time

How a professional repairs the problem

A pro records the logout timeline and cookie attributes, verifies canonical URL and trusted-proxy HTTPS handling, then compares authentication configuration across deployments and nodes. We identify who invalidates the session—WordPress policy, plugin hooks, password or salt rotation, cache behavior, or infrastructure drift—apply the narrow repair, purge unsafe cache entries, and test saves and idle periods with multiple roles without extending sessions beyond the site’s security needs.

Frequently asked questions

How is this different from a WordPress login redirect loop? +
A redirect loop prevents the browser from settling after login and often ends with “too many redirects.” Here, wp-admin loads successfully, but a later request loses or rejects an established session.
Will replacing WordPress salts fix repeated logouts? +
Not by itself. Replacing salts immediately invalidates every existing cookie. It only helps when the old secrets are compromised; the actual fix for this symptom is keeping valid secrets stable and consistent across requests.
Can a CDN log me out even if wp-admin is not cached? +
Yes, if login responses, redirects, AJAX calls, or pages carrying logged-in cookies are cached incorrectly. Verify bypass rules by path and cookie, not just a single wp-admin toggle.
Why does the problem happen only on one browser? +
That points toward stale cookies, privacy controls, extensions, antivirus filtering, or a bad device clock. A clean private-window and second-browser comparison is more useful than changing server settings first.
Can a security plugin intentionally shorten my session? +
Yes. Idle limits, absolute session limits, concurrent-login rules, IP-change checks, and forced password resets can all revoke a valid session. Review audit logs before disabling protection.
Should I make login cookies last forever? +
No. Longer sessions increase risk on shared or stolen devices and hide the underlying invalidation. Restore normal, predictable sessions and choose a documented timeout that matches the site’s security policy.

Repair dispatch

Still Need Help Fixing Your Website?

If you are not comfortable editing website files, changing server settings, repairing a database, or troubleshooting a live website, professional help may prevent additional damage or downtime. We will review the problem before accepting the repair.

  • You will receive a clear explanation of the likely cause.
  • We will tell you if the issue falls outside our repair scope.
  • No additional work will be performed without approval.
  • A backup should be created whenever access and website condition allow it.
Emergency repair Request diagnosis

Do not share passwords through an unencrypted contact form — use Password Pusher (self-destructing link). Prefer a dedicated Rescue 404 admin account, not your personal owner login; if you cannot create one yet, we will add ours after repair.

Written by Josh

Last reviewed

Platform note: Full rescue available for WordPress and self-hosted sites. Wix, Squarespace, Webflow, Weebly, and similar closed builders have very limited backend access — fixes may not be possible. I will tell you honestly before we start.