WordPress Keeps Logging You Out: Cookie Lifetime, Heartbeat, URL Fixes

This article is a localized edition of the Japanese original. Read the Japanese original

This article explains the causes of, and fixes for, symptoms such as being sent back to the login screen after a short break in the WordPress admin, or seeing a pop-up while editing a post that says "Your session has expired. Please log in to continue where you left off."

Before fixing anything, it helps to know how WordPress keeps you logged in. That makes it easier to narrow down the cause.

How WordPress login works

WordPress login does not use PHP sessions (session_start() and session.gc_maxlifetime). It relies on two things.

• Login cookies: when you log in, the browser stores wordpress_logged_in_… and, for the admin, wordpress_sec_… (on HTTPS; wordpress_… on HTTP). The cookie holds the username, the expiration time, the session token, and a signature made with the security keys in wp-config.php
• Session tokens: a token for each login is stored in the database as user metadata (session_tokens). If the token in the cookie is not there, the login is invalid

How long a login lasts depends on whether you checked "Remember Me" on the login screen (checked on WordPress 7.1 as of October 2026).

So raising session.gc_maxlifetime in php.ini, or sharing PHP sessions through Redis, has no effect on WordPress logins.

Common causes and how to check them

The sections below cover how to check and fix each cause.

1. “Remember Me” and the login lifetime

First, try again with "Remember Me" checked on the login screen. When it is not checked, the login cookies disappear when the browser closes.

If 14 days is still too short, you can change the lifetime with the auth_cookie_expiration filter. So that it keeps working after a theme change, save it as wp-content/mu-plugins/login-cookie-lifetime.php (create the mu-plugins directory if it does not exist).

<?php
/**
 * Plugin Name: Login cookie lifetime
 * Description: Sets the login lifetime to 30 days when "Remember Me" is checked.
 */
add_filter(
	'auth_cookie_expiration',
	function ( $length, $user_id, $remember ) {
		if ( $remember ) {
			return 30 * DAY_IN_SECONDS;
		}
		return $length; // Without the checkbox, keep the default 2 days
	},
	10,
	3
);

• The change applies from your next login. It does not affect the current login
• Extending the value used without "Remember Me" ($remember is false) does not stop the cookie itself from being deleted when the browser closes
• The longer the lifetime, the higher the risk that a login stays open on a shared computer or a lost device. Do not make it too long for administrator accounts

2. If you get logged out while editing, check Heartbeat

The admin uses the Heartbeat API (periodic requests to admin-ajax.php) to check whether your login has expired, and on the post edit screen it swaps in fresh nonces (temporary tokens) used for saving. If your login expires, a pop-up lets you log back in without leaving the screen.

Some speed or server-load plugins have settings that disable Heartbeat or stretch its interval a lot. If Heartbeat is disabled in the admin or on the post edit screen, the following happens.

• No pop-up appears when your login expires, so you only notice when saving fails
• Nonces are not refreshed, so saving from a screen left open for a long time (a nonce lasts roughly 12 to 24 hours) shows "The link you followed has expired."

If you have such a setting, change it so that Heartbeat is not disabled at least on the post edit screen.

3. Check the site URLs and cookie settings

Login cookies are stored for the host name (for example, www.example.com) and path you logged in on. If the URLs in the WordPress settings do not match the URL you actually visit, the cookies are not sent even though you just logged in, and you are sent back to the login screen.

Check the current values of "WordPress Address (URL)" and "Site Address (URL)" under "Settings" → "General", or with WP-CLI.

wp option get siteurl
wp option get home

• Do www/no-www and http/https match the URL you actually use?
• Do the web server redirects (unifying www/no-www, forcing HTTPS) point the same way as the WordPress settings?
• Does wp-config.php still contain definitions such as COOKIE_DOMAIN or COOKIEPATH from a previous environment?

A normal site does not need cookie constants such as COOKIE_DOMAIN. WordPress works them out from the URL settings. If you find definitions you do not recognize, take a backup and try removing them.

4. Check whether the security keys changed

AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY and the matching _SALT values in wp-config.php are used to sign login cookies. When they change, every existing cookie becomes invalid and everyone is logged out.

• Automatic rotation: some security plugins can change the security keys automatically on a schedule (for example, "Activate Automatic Secret Keys Updater" in Sucuri Security). If that is on, everyone is logged out each time the keys change
• Multiple servers: if several web servers sit behind a load balancer, set the same security keys in wp-config.php on every server. If they differ, the cookie is judged invalid when you are routed to a different server. Login data is stored in the database, so as long as all servers use the same database, you do not need to share PHP sessions

5. Check plugins for automatic logout features

Some plugins log users out after a period of inactivity or limit how many logins can be active at once. If you use security or membership plugins, check their settings.

If you cannot tell which plugin is responsible, the troubleshooting mode of the "Health Check & Troubleshooting" plugin from WordPress.org lets you test with plugins temporarily disabled for your login only. It does not affect what other visitors see.

6. Check cache and CDN settings

If a page cache plugin or a CDN (such as Cloudflare) is set to cache every page, logged-in users may get the logged-out version of pages, or responses from the login screen may be cached. Exclude the following from caching.

• Everything under /wp-admin/, and /wp-login.php
• Requests that carry a cookie starting with wordpress_logged_in_

Most cache plugins have a setting that stops them from serving cached pages to logged-in users. If you created your own caching rules on the CDN, review them.

7. Check the server clock

Login expiration is judged by the server's clock. If the server clock is far off, the expiration check is off too.

timedatectl

If it shows System clock synchronized: yes, the clock is set automatically. If it shows no, enable NTP time sync (sudo timedatectl set-ntp true).

Check active login sessions

You can see how many of your logins are still active in the "Sessions" section at the bottom of "Users" → "Profile", and end all logins except the current one with "Log Out Everywhere Else". With WP-CLI, you can list and remove them as follows.

# List sessions for user admin (login time, expiration, IP address)
wp user session list admin --fields=login_time,expiration_time,ip

# End all sessions for user admin
wp user session destroy admin --all

Summary

• WordPress keeps you logged in with cookies and session tokens in the database. It does not use PHP sessions
• A login lasts 2 days without "Remember Me" and 14 days with it. You can change this with the auth_cookie_expiration filter
• If you get logged out while editing, check whether Heartbeat has been disabled
• If you keep having to log in, check for mismatched site URLs (www, https) and COOKIE_DOMAIN
• If everyone is logged out at once, or you run multiple servers, check for changed or mismatched security keys

Related articles:

• How to change the WordPress auto-logout time
• Fixing the "cookies are blocked" error on the WordPress login screen
• How to fix not being able to log in to WordPress (complete guide)

Questions about WordPress? The publisher of this site is based in Japan and replies in Japanese. Contact (Japanese)