WordPress Keeps Logging You Out? Here's the Real Fix

You log in, land on the dashboard for a second, and then you're staring at the login screen again. Or maybe it's worse - every link you click kicks you back out, like WordPress just doesn't want you signed in. The site works fine for visitors, which is what makes this one so annoying to diagnose. Here's what's actually causing it and how to fix each cause for good.

Symptom: Logged Out Immediately After Signing In

You enter your credentials, WordPress accepts them, and within a second or two you're redirected right back to wp-login.php. No error message, no warning - just a loop.

Cause: Cookie domain mismatch

WordPress sets its authentication cookie against a specific domain - whatever is stored in Settings > General as your WordPress Address and Site Address. If your browser loads the site at https://example.com but WordPress thinks its address is https://www.example.com (or vice versa), the cookie gets written for one host and checked against another. It never matches, so you get bounced straight back to login.

Fix:

• Go to Settings > General in wp-admin and confirm WordPress Address and Site Address use the exact same protocol and subdomain you actually type in the browser.
• If wp-admin is unreachable because of the loop, set it directly in wp-config.php instead:

define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );

Add both lines above the /* That's all, stop editing! */ line, then clear your browser cookies for the domain and log in again.

Cause: A redirect is silently changing the URL

If a plugin, CDN, or an old .htaccess rule redirects https://example.com to https://www.example.com (or drops HTTPS mid-request), the browser follows the redirect before the auth cookie finishes being read on the new host. WordPress technically logged you in - just on a URL your cookie doesn't cover.

Fix: pick one canonical version of your domain (www or non-www, always HTTPS) and make sure DNS, WordPress Address/Site Address, and any CDN or reverse proxy in front of the site (Cloudflare, Nginx) all agree on it. Mixed canonical settings are one of the most common causes of this exact loop.

Symptom: You're Logged In, Then Kicked Out a Few Minutes Later

This one's less about the login form and more about the session not sticking - you're working fine, then suddenly you're back at the login screen mid-edit.

Cause: Server time is wrong

WordPress auth cookies carry an expiration timestamp generated by the server. If the VPS clock has drifted - not uncommon after a reboot, a stopped NTP service, or a container restore - WordPress can generate cookies that look already expired, or reject valid ones as "from the future."

Fix: check the server time over SSH and compare it to the real time:

date -u
timedatectl status   # confirm NTP sync is active

If it's off, re-enable time sync (timedatectl set-ntp true on most modern Linux distros) rather than setting the clock manually - manual fixes drift again after the next reboot.

Cause: Security keys and salts were regenerated

The AUTH_KEY, AUTH_SALT, and related constants in wp-config.php are what WordPress uses to sign auth cookies. If something rewrote these - a migration script, a security plugin "hardening" step, or you manually refreshed them from the WordPress.org secret-key generator - every cookie issued before that moment becomes invalid instantly. Everyone, including you, gets logged out at once.

Fix: this isn't actually a bug, just an unannounced side effect. If it happens repeatedly, check whether a security plugin is set to auto-rotate salts on a schedule and turn that off unless you specifically want forced logouts as a security measure.

Cause: Only one login session is allowed

WordPress caps how many valid auth cookies a user can hold at once by default. If you're logged in on your laptop, then log in again from your phone or a second browser, the older session can get invalidated depending on plugins and cookie settings in play - it can look like a random logout when it's really a second login somewhere else.

Fix: if you routinely work from multiple devices, log out of ones you're not using instead of leaving sessions open everywhere, and check for a "limit login sessions" or "concurrent sessions" setting in any security plugin you've installed (Wordfence, iThemes Security, and similar plugins all have one).

Symptom: Logged Out Only on Some Pages or Devices

Cause: Mixed HTTP/HTTPS content on part of the site

If some pages load resources over plain HTTP while the site is otherwise on HTTPS, browsers can refuse to send secure cookies on the insecure request. That silently breaks the auth check on just those pages.

Fix: force the whole site to HTTPS, not just the login page. In wp-config.php, add:

define( 'FORCE_SSL_ADMIN', true );

Then run a mixed-content scan (browser dev tools' Console tab will flag any HTTP resource on an HTTPS page) and fix the handful of hardcoded http:// links it turns up.

Cause: Browser blocking third-party or SameSite cookies

If your site is loaded inside an iframe (page builders, some staging preview tools) or your admin URL differs from the front-end domain, modern browsers' SameSite cookie rules can silently drop the WordPress auth cookie. This shows up as "works in Chrome, fails in Safari" or "works direct, fails when embedded."

Fix: avoid loading wp-admin inside an iframe, and make sure you're accessing the real domain rather than a staging subdomain that doesn't match your production cookie domain.

Quick Diagnostic Table

Prevention

• Pick one canonical domain (protocol + www/non-www) early and keep DNS, WordPress settings, and any CDN in agreement.
• Leave NTP time sync enabled on the server - never set VPS time by hand.
• Avoid plugins that auto-rotate security keys on a schedule unless you understand the logout side effect.
• Run the whole site over HTTPS, including every embedded resource, not just the admin area.

If you've checked all of the above and the loop persists, it's worth deactivating plugins one at a time (security and caching plugins first) - a caching layer serving a stale, cookie-less version of wp-admin can produce the exact same symptom without touching WordPress's login logic at all.