You are actively working in the WordPress admin — writing a post, configuring a plugin, editing theme settings — and WordPress suddenly logs you out and shows “Your session has expired. Please log in again.” Or you are redirected to the login screen after clicking any admin link. Or you can log in but are immediately redirected back to the login page. WordPress session expired errors interrupt work and, in their persistent forms, completely lock you out of the admin. Each symptom pattern has a specific cause and direct fix. This fits into the wider topic we cover in our WordPress Errors Complete Guide.
WordPress Session Expired — Why Sessions Expire
WordPress session expired messages appear when the authentication cookie WordPress stores in the browser becomes invalid. This happens for several reasons: the cookie’s lifetime reached its expiry (WordPress login sessions last 2 days for standard logins and 14 days when “Remember Me” is checked), the WordPress security keys and salts in wp-config.php were changed (which invalidates all active sessions immediately), or the cookie is being blocked or cleared by the browser, extensions, or security software.
The most common benign cause of a WordPress session expired notice is a simple expiry — the user has been logged in for longer than the cookie’s validity period and WordPress automatically terminates the session. Log in again, check “Remember Me,” and the session persists for 14 days. For users who regularly work in the WordPress admin without closing the browser, the 2-day default login duration is too short. Extend the login duration by adding to functions.php: add_filter('auth_cookie_expiration', function($seconds) { return 30 * DAY_IN_SECONDS; }, 99, 1); — this extends all sessions (including those without “Remember Me”) to 30 days. The value can be adjusted to any duration appropriate for the site’s security requirements.
Security key changes are the most disruptive cause of a simultaneous WordPress session expired event for all users at once. The security keys in wp-config.php (AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY, and their salt equivalents) are used to sign all authentication cookies — changing any of them invalidates every active login session site-wide. Changes happen when: a security plugin runs an automatic key rotation, the site migrates to a new server and the wp-config.php is replaced, or the site owner manually regenerates keys from the WordPress secret key generator. After the keys change, all logged-in users must log in again. If the WordPress session expired recurs repeatedly without any key changes, a plugin is intentionally clearing sessions as a security measure — check security plugin settings for session management features. According to the WordPress developer documentation, the auth_cookie_expiration filter and the login-by-cookie mechanism are the primary controls for session lifetime, with security keys providing the cryptographic foundation for all session validation.
Persistent Session Expired — Login Loop Fixes
A WordPress session expired that triggers immediately after every login attempt — where the user logs in, WordPress shows “Login successful,” and then immediately redirects back to the login page with a session expired message — is a login redirect loop caused by cookie or URL configuration issues.
The most common cause of a persistent login loop is a WordPress URL mismatch: the WordPress Address (URL) and Site Address (URL) in Settings → General do not match the actual URL being used to access the site. If WordPress Address is set to http://example.com but the site is being accessed via https://example.com, the authentication cookie is set for the HTTP domain and rejected for the HTTPS URL — causing immediate apparent session expiry on every login. Fix: Settings → General → update both URLs to use the exact protocol and domain being accessed. If the admin is inaccessible due to the loop, update the values in wp-config.php: define('WP_HOME','https://example.com'); define('WP_SITEURL','https://example.com');. After matching the URLs, the WordPress session expired login loop stops immediately.
Cookie domain mismatches on sites with www and non-www versions cause the same login loop: a cookie set for example.com is not valid for www.example.com and vice versa. WordPress sets its auth cookies for the domain in WP_HOME — if some pages redirect to www while WordPress is configured for non-www (or vice versa), the cookie domain mismatch triggers a WordPress session expired on every page transition that crosses the www boundary. Fix by consistently using either www or non-www everywhere: the WordPress URL settings, the .htaccess redirects, and the Cloudflare/CDN configuration must all consistently point to one canonical domain version. Our guide on fixing WordPress 404 errors covers the URL consistency configuration that also resolves cookie domain mismatches causing persistent login issues.
Browser and Cookie Issues
When the WordPress session expired error affects only specific browsers or specific devices while working correctly on others, the issue is in the browser’s cookie storage rather than in WordPress’s configuration.
Browser cookie restrictions: Chrome, Firefox, and Safari all have settings that control third-party cookie blocking and cookie storage duration. On browsers with strict privacy settings, WordPress authentication cookies may be blocked or cleared more aggressively than intended. The WordPress admin uses first-party cookies (cookies for the site’s own domain, not third-party tracking cookies), so standard privacy settings should not affect login — but some privacy extensions and browser security modes block all cookies or have overly aggressive clearing schedules. Test in an Incognito/Private window (where extensions are disabled and cookie storage starts fresh) — if login works correctly in a private window but fails in normal browsing, a browser extension is interfering with cookie storage. Disabling extensions one at a time identifies the specific extension causing the WordPress session expired symptoms.
Clearing the browser’s cookies for the specific WordPress site domain fixes WordPress session expired errors caused by corrupted or conflicting cookie data: Chrome → Settings → Privacy and security → Third-party cookies → See all site data and permissions → search for the WordPress site domain → delete all cookies. This clears any corrupted authentication cookies and forces a fresh login that creates valid new cookies. For Safari: Preferences → Privacy → Manage Website Data → find and remove the WordPress site’s cookies. After clearing site-specific cookies, log in again — the login creates fresh valid cookies and the session expiry error should not recur unless an underlying configuration issue remains. Our guide on creating a custom WordPress login page covers the login session and cookie configuration that intersects with WordPress session expired issues when custom login implementations modify the standard cookie handling.
Server-Side Session and Security Plugin Causes
WordPress session expired errors caused by server configuration are less common than cookie or URL issues but more difficult to diagnose because they affect all users simultaneously and produce no obvious client-side symptoms.
PHP session garbage collection is a server-level process that periodically deletes old PHP session files. On some shared hosting configurations, the GC interval is set aggressively short, clearing PHP sessions during active usage and producing WordPress session expired errors at unpredictable intervals for all users. Check whether this is the cause: the session_gc_maxlifetime ini setting determines how long PHP sessions persist. By default it is 1440 seconds (24 minutes) — on servers where this is set lower, sessions expire rapidly. WordPress’s session handling is cookie-based rather than PHP session-based for most functionality, but plugins that use PHP sessions (some WooCommerce payment gateways, membership plugins) are affected. Contact the hosting provider to increase session.gc_maxlifetime to at least 3600 seconds.
Security plugins with session management features can deliberately expire sessions as a security policy — Wordfence’s “Limit sessions per user” setting invalidates older sessions when a user logs in from a new device, iThemes Security’s session timeout forces relogin after a configured idle period, and some membership plugins expire sessions after inactivity. Check each active security and membership plugin for session management settings before blaming server or WordPress configuration. For sites where WordPress session expired errors are caused by deliberate security plugin session limits, the solution is either adjusting the plugin’s session timeout settings to match the team’s working patterns or communicating to affected users that the security policy requires re-authentication after a period of inactivity. Reviews from the WordPress support community confirm that WordPress URL mismatches and security key changes together cause the majority of WordPress session expired events that are not explained by simple login duration expiry.
WordPress Session Expired After Migration
A WordPress session expired that appears specifically after migrating a site to a new server, new domain, or from HTTP to HTTPS is a migration-specific configuration issue rather than a general session problem — all active sessions become invalid and new logins fail due to residual configuration from the old environment.
After migration, update all URL references and regenerate security keys. Update URLs: Settings → General → verify both URLs reflect the new domain and protocol exactly. Run Better Search Replace to update all database-stored URLs from the old domain to the new domain. Regenerate security keys: visit wordpress.org/support/article/editing-wp-config-php/#security-keys → use the generator link to create new key values → replace all eight DEFINE lines in wp-config.php. New keys invalidate all sessions from the old environment, and the regenerated keys are unique to the new installation. After completing these steps, log in fresh — the login creates a valid session authenticated with the new security keys for the new domain, and the WordPress session expired error specific to the migration environment no longer occurs. Also verify that no .htaccess redirect rules from the old environment are redirecting login page requests or cookie-setting responses to unexpected URLs, as post-migration .htaccess configuration is a common source of session handling failures that produce the same symptoms as session expiry. Our guide on diagnosing WordPress site down events covers the full migration health check process that should be completed after any server migration to catch URL configuration issues including those that cause session handling failures.
WordPress REST API authentication uses a separate mechanism from the standard cookie-based admin session — application passwords (added in WordPress 5.6) rather than cookies. A WordPress session expired error in the WordPress admin does not affect application password authentication for REST API integrations. However, if a plugin uses the REST API with cookie-based authentication (nonce-based API requests from the admin interface, such as the block editor’s save mechanism), an expired admin session causes those API requests to fail with 401 Unauthorized responses — which the block editor displays as save failures rather than session expired messages. When save failures occur after a period of inactivity in the block editor, refreshing the page renews the session and the nonce, allowing successful saves to resume. The relationship between admin session validity, nonce expiry, and REST API authentication explains why some block editor failures are actually WordPress session expired symptoms in disguise rather than genuine REST API configuration problems.
Two-factor authentication plugins change the WordPress session expired interaction: after entering the username and password, the session is not fully established until the 2FA code is verified. If the 2FA code entry page shows a “session expired” message, the interim session created after password verification has expired before the 2FA code was entered — typically because the user took more than 10 minutes between entering the password and entering the TOTP code (some 2FA plugins have a short interim session window). The fix: enter the username, password, and 2FA code promptly in sequence without extended delays between steps. If the 2FA session window is consistently too short for the team’s workflow (for example, where users might need to retrieve their authenticator app from a physical device), increase the 2FA plugin’s interim session timeout in its settings. WP 2FA allows configuring the TOTP validity window which also affects how long the interim session stays active while waiting for code entry. Our guide on setting up WordPress two factor authentication covers the session flow and timing considerations that intersect with these post-password interim session expiry scenarios.
Logging out all sessions across all devices is a security measure available in WordPress when a device is lost or a credential compromise is suspected — and it deliberately produces the WordPress session expired experience for all active sessions simultaneously. From the WordPress profile: Users → Your Profile → scroll to “Sessions” → “Log Out Everywhere Else.” This terminates all other active sessions site-wide for that user account, requiring re-authentication on any device where the admin was previously open. For Super Admins on WordPress multisite networks, the Terminate All Sessions option can be used to force re-authentication for all users on all sites simultaneously as a security response to a suspected breach — this intentionally creates a mass session expiry event across the entire network. Informing team members before triggering a mass session termination prevents confusion and support requests from users unexpectedly encountering the session expired message during active work sessions.
