Skip to content

How to fix WordPress when it keeps logging you out

WordPress keeps you logged in with a cookie that it checks on every page. If you are sent back to the login screen while you work, the cookie has stopped arriving or stopped passing the check. Site addresses that differ, a browser that drops it and security keys that change are the usual reasons.

By
WP Ministry
Updated
Tested on
WordPress 7.1.3, PHP 8.3.35

In short

  • Nothing is lost. Your account and your content are untouched; the cookie that proves your login has stopped counting.
  • A login lasts two days, or fourteen with "Remember Me". Without it, closing the browser ends the login.
  • Check that the WordPress Address and the Site Address are the same, including www.
  • If a private window keeps you logged in, your usual browser is dropping the cookie.
  • If everyone is logged out at the same moment, again and again, something is replacing the security keys in wp-config.php.

WordPress does not keep a note on the server that you are logged in. When you log in it gives your browser two cookies, wordpress_[hash] for the dashboard and wordpress_logged_in_[hash] for the rest of the site, and it checks them on every page. When a cookie does not arrive, or does not pass the check, your next click lands on the login screen. In the editor a box opens over your work instead: "Your session has expired. Please log in to continue where you left off."

Nothing has been lost. Your account, your password and your content are as they were, and the box is there so that you can log in without leaving the page you were editing. What has to be found is why the cookie stopped counting.

How long a login is meant to last

A login lasts two days. Tick "Remember Me" on the login screen and it lasts fourteen. Without "Remember Me" the cookie is also one the browser drops when it closes, so being asked to log in every morning is WordPress working as intended.

For a cookie to pass, four things have to hold:

  • It reaches WordPress. Its name ends in a hash of the WordPress Address, and the browser sends it only to the host that set it.
  • Its time has not run out.
  • Its signature matches. The signature is made from the security keys in wp-config.php and a few characters of your password's stored hash.
  • The session it names is still on the list WordPress keeps for your account.

Each fix below puts one of those back.

Where it goes wrong

A page request passes through each of these in turn. This one comes from WordPress itself.

  1. Browser
  2. DNS
  3. HTTPS
  4. CDN or firewall
  5. Web server
  6. PHP
  7. WordPress (this error comes from here)
  8. Database and files

What causes it

  • The browser is dropping the login cookie

    Common

    Without "Remember Me" the cookie lasts only until the browser closes. A browser set to clear cookies, or an extension that cleans them, ends the login sooner.

    Fix: Tick Remember Me, then try a private window

  • The WordPress Address and the Site Address differ

    Common

    The dashboard is served from one and the public site from the other. A cookie set on www.example.com is not sent to example.com, so you are logged in on one and a stranger on the other.

    Fix: Make the WordPress Address and the Site Address match

  • The security keys in wp-config.php keep changing

    Sometimes

    Every login cookie is signed with these keys. A plugin or a scheduled task that replaces them, or servers behind a load balancer that hold different ones, makes every cookie fail the check.

    Fix: Stop the security keys from being replaced, or Give every server the same keys

  • A plugin shortens or ends the login

    Sometimes

    WordPress lets a plugin set how long a login lasts, and a plugin can end sessions itself.

    Fix: Rule out a plugin

  • The sessions were ended from somewhere else

    Sometimes

    Someone using the same account pressed "Log Out Everywhere Else" or changed its password. Either one throws out every other browser logged in to that account.

    Fix: See who else is logged in as you

  • A cache or CDN is handling the dashboard or the cookie

    Sometimes

    A page cache or CDN that stores the dashboard or the login page, or that removes the header carrying the cookie, keeps the login from holding.

    Fix: Keep the dashboard and logged-in visitors out of the cache

How to fix it

Tick Remember Me, then try a private window

  • Easy
  • No risk
  • About 10 minutes

  1. Step 1: Log in with "Remember Me" ticked

    If you were only being logged out when the browser closed, this ends it.

  2. Step 2: Log in from a private window

    Open a private or incognito window, log in, and work for as long as it usually takes to be thrown out. A private window is a separate session: it starts without the cookies your usual window holds.

  3. Step 3: If you stay logged in there

    The site is fine and your usual browser is dropping the cookie. Delete the cookies stored for your site's address and log in again. If the logouts come back, look for a browser setting that clears cookies when the browser closes, and switch off privacy and cleaning extensions for the site.

  4. Step 4: If the private window throws you out too

    The browser is not the cause. Go to the next fix.

Make the WordPress Address and the Site Address match

  • Takes care
  • Back up first
  • About 15 minutes
  • Steps tested on WordPress 7.1.3

WordPress serves the dashboard from the WordPress Address and the public site from the Site Address. When one says www.example.com and the other example.com, the cookie set on one is not sent to the other. You are logged in on the dashboard and a stranger on the site. Open the dashboard through the other address and you are sent to the login screen, which clears the login you had.

  1. Step 1: Compare the two

    Go to Settings, then General, and read "WordPress Address (URL)" and "Site Address (URL)". With WP-CLI:

    bash
    wp option get siteurl
wp option get home

  2. Step 2: Set both to the address visitors use

    Unless WordPress was deliberately installed in a folder of its own, the two are identical: the same https, and the same www or none. Replace https://example.com with your address, with no slash at the end.

    bash
    wp option update home 'https://example.com'
wp option update siteurl 'https://example.com'

  3. Step 3: Log in once more

    A new WordPress Address gives the cookie a new name, so everyone has to log in one more time. After that the login holds on the dashboard and on the site alike.

To undo it: Set the two old values again with the same commands.

Stop the security keys from being replaced

  • Takes care
  • Low risk
  • About 20 minutes
  • Steps tested on WordPress 7.1.3

WordPress's documentation says of the keys in wp-config.php that you can change them at any time to invalidate all existing cookies, and that all users then have to log in again. That is worth doing once, after a break-in. There are plugins that do it on a schedule, and then everyone is logged out each time it comes round.

  1. Step 1: See whether the keys are changing

    This prints a fingerprint of the keys that sign login cookies without showing the keys. Run it now, and again the next time you are thrown out.

    Two different answers mean the keys were replaced in between. Without WP-CLI, look in your host's file manager at when wp-config.php was last changed.

    bash
    wp eval 'echo md5( wp_salt( "auth" ) . wp_salt( "secure_auth" ) . wp_salt( "logged_in" ) ), "\n";'

  2. Step 2: Find what replaces them

    Look in your security plugin's settings for an option that changes the salts or security keys on a schedule. The list of scheduled jobs can point to it: look for one whose name mentions salts or keys.

    A cron job on the server that runs wp config shuffle-salts does the same thing and is not in this list.

    bash
    wp cron event list --fields=hook,next_run_relative,recurrence

  3. Step 3: Switch it off

    Turn the schedule off in the plugin's settings. If there is no such setting, deactivate the plugin. Replace plugin-name with the name of its folder.

    Log in again. This time the login lasts.

    bash
    wp plugin deactivate plugin-name

To undo it: Activate the plugin again.

Give every server the same keys

  • Advanced
  • Back up first
  • About 30 minutes

On a site served by several servers behind a load balancer, each server has its own copy of wp-config.php. If their key lines differ, a cookie signed by one server fails on the next, and you are thrown out whenever a request lands there.

  1. Step 1: Run the fingerprint command on each server

    It is the first command in the fix above. Every server should give the same answer.

  2. Step 2: If the answers differ, copy the keys across

    Copy the eight lines from AUTH_KEY to NONCE_SALT out of one server's wp-config.php into the others, and make whatever deploys the site keep them the same. To start from a fresh set, the salt and security key generator makes eight in your browser.

To undo it: Put each server's own copy of wp-config.php back.

Rule out a plugin

  • Takes care
  • Low risk
  • About 20 minutes
  • Steps tested on WordPress 7.1.3

  1. Step 1: Switch every plugin off

    Do it on the Plugins screen, or with WP-CLI:

    If you are thrown out before you can finish, the guide to deactivating plugins when you are locked out has ways that need no dashboard.

    bash
    wp plugin deactivate --all

  2. Step 2: Log in and work for as long as it used to take

    If you stay logged in, a plugin was ending the login.

  3. Step 3: Activate them one at a time

    Start with security, login and membership plugins. When the logouts return, open that plugin's settings, look for a session length or an idle time, and raise it or turn it off.

To undo it: Activate the plugins again from the Plugins screen.

See who else is logged in as you

  • Easy
  • Low risk
  • About 10 minutes
  • Steps tested on WordPress 7.1.3

Any browser logged in to an account can end the others. The "Log Out Everywhere Else" button on your profile ends every session but the one that pressed it, and a new password stops every cookie made with the old one.

  1. Step 1: Open Users, then Profile, and find "Sessions"

    If the "Log Out Everywhere Else" button can be pressed, the account is logged in somewhere else as well. If it cannot, the screen says "You are only logged in at this location." With WP-CLI, replacing admin with your username:

    bash
    wp user session list admin --fields=login_time,ip,ua

  2. Step 2: If you share the login

    Whoever presses that button or changes the password throws the others out. Give each person an account of their own under Users, then Add User.

  3. Step 3: If nobody else should be logged in

    Press "Set New Password" on the same screen, then "Update Profile". You stay logged in where you are, and every other browser is out. A session you cannot account for is also a reason to check the site for signs of a break-in. With WP-CLI, after which you log in again too. Keep the single quotes around the password. Without them the shell reads a $ and the letters after it as a variable and drops them, and the command can answer "Success" while the old password stays in place.

    bash
    wp user update admin --user_pass='a-new-long-password'

Keep the dashboard and logged-in visitors out of the cache

  • Takes care
  • Low risk
  • About 30 minutes

  1. Step 1: Switch the cache off as a trial

    Deactivate the caching plugin, or turn the cache off in your host's or CDN's panel. Then log in and work as usual. If the logouts stop, the cache is the cause.

  2. Step 2: Set the exclusions

    There are three, whatever your cache calls them. Store nothing under /wp-admin/, and not wp-login.php. Serve no stored page to a request that carries a cookie whose name begins wordpress_logged_in. Remove no Set-Cookie header from a response. WordPress's own nginx examples leave the first two out of the cache.

  3. Step 3: Look hardest at a rule that caches everything

    Cloudflare's documentation, for one, says that when a Cache Everything rule also sets an edge cache TTL, Cloudflare removes Set-Cookie and stores the response. Put a rule that bypasses the cache for the dashboard and the login page above it. If the cache is your host's, ask them to make the exclusions.

When to get help

If the two addresses match, a private window makes no difference, the keys stay the same and every plugin is off, whatever ends the login sits in front of WordPress. It can be a cache, a CDN, a proxy or a load balancer. Finding it means reading the headers each of them sends, and that takes access to how the site is served.

Common questions

I cannot log in at all. Is this the same problem?

No. A login form that comes straight back, or a login screen that says "Cookies are blocked or not supported by your browser.", is covered on the page about a login that keeps refreshing or redirecting. A wrong COOKIE_DOMAIN line in wp-config.php belongs there too: it stops you logging in at all.

Everyone was logged out at the same moment. What happened?

Either the security keys in wp-config.php were replaced or the WordPress Address was changed. Both make every existing cookie useless at once. Done once and on purpose, such as after a cleanup or a move to https, it needs no fix. If it keeps happening, see the third fix.

Can I make a login last longer than fourteen days?

Yes. The length passes through a filter named auth_cookie_expiration, so a plugin or a few lines of code can set it. A longer login is a trade: a lost or borrowed laptop stays logged in for just as long.

More on this subject

Would you rather we fixed it?

Quick Fix is $49. One issue, one site, up to about an hour. No fix, no fee. 30-day warranty. It starts with a free diagnosis.

Get a free diagnosis