WordPress Keeps Logging Me Out? Fix the Login Loop Fast

You type the right password. The screen flickers, the address bar shows wp-admin for half a second, and you land back on the login form. No error message. No "wrong password" warning. Just the same box, waiting for you again.

Quick Answer: WordPress keeps logging me out almost always means the authentication cookie in your browser no longer matches the address WordPress believes it lives at. As of August 2026, three causes cover the large majority of cases: stale browser cookies, a mismatch between the siteurl and home values in your database, and a cache or proxy layer interfering with the login page. Work through them in that order.

Our support desk resolves 20 to 30 client site issues on a normal working day, and login loops arrive in a steady trickle: after an SSL install, after a migration, after somebody flips one cache setting on a Friday afternoon. What follows is the same sequence a Hostaccent engineer runs on a live ticket, written so you can run it yourself. Nothing is held back and nothing is simplified for the sake of a sales pitch. If you fix it in four minutes without opening a ticket, that is the ideal outcome.

Why WordPress Keeps Logging Me Out, in Plain English

WordPress does not use PHP sessions for admin authentication. It uses cookies. When you log in, WordPress writes an authentication cookie tied to one exact address, valid for 48 hours by default, or 14 days if you tick "Remember Me". Every request after that has to reach the same address, over the same protocol, carrying that same cookie. Break any link in that chain and you are back at the login form.

Two cookies matter. The wordpress_logged_in_[hash] cookie identifies you across the whole site. The wordpress_sec_[hash] cookie covers the admin area over HTTPS. Both are scoped to a specific domain and path.

That scoping is the whole problem. A cookie issued for https://example.com is invisible to https://www.example.com. To you they are the same site. To your browser they are two different origins, and it will not hand a cookie from one to the other.

WordPress also stores a session token for each login in the session_tokens row of the wp_usermeta table. If that token is deleted, the cookie is worthless even when the expiry date is still weeks away. Password changes, salt rotation and "Log Out Everywhere Else" all wipe tokens instantly.

There is a grace period built in too. Your browser keeps sending the cookie for roughly 12 hours past its expiry so WordPress can recognise you and offer a clean re-login instead of a silent failure. The official WordPress cookie documentation explains exactly what each cookie carries: your username, the expiry timestamp and a hash, never your actual password. The 2-day and 14-day defaults are set in the wp_set_auth_cookie function.

Three different failures get lumped together under one complaint, and this is where most people waste an hour:

• Instant bounce. You submit valid credentials and land straight back on wp-login.php. This is the classic WordPress login redirect loop.
• Random drop. You log in fine, work for ten minutes, then find WordPress logs me out automatically halfway through writing a post.
• Session expired popup. You stay on the page, click Update, and a modal appears saying your session ended.

Different symptoms, different causes, different fixes. And none of them means your site is broken at the server level: a genuine server fault usually shows up as a 500 Internal Server Error instead, which looks nothing like this.

The 60-Second Login Triage: Match Your Symptom to Its Cause

Before you edit a single file, spend one minute identifying which of the three failures you actually have. In the tickets we handle, roughly half of all login-loop escalations arrive after the site owner has already edited wp-config.php for a problem that was living in their browser cache. Matching symptom to cause first saves you from fixing something that was never broken.

| Symptom you see | What the browser does | Most likely cause | First move | |---|---|---|---| | Instant bounce back to wp-login.php | wp-admin flashes, then reloads login | Cookie domain or protocol mismatch | Incognito test, then check siteurl | | wp-admin redirects to homepage | Login succeeds, dashboard never loads | .htaccess rewrite or redirect plugin | Regenerate permalinks | | Logged out after 5-20 minutes | Works, then drops mid-task | Server-side cache serving a logged-out page | Exclude wp-admin from cache | | "Session expired" popup while editing | Page stays, modal appears | Cached login page with a stale nonce | Purge cache, exclude wp-login.php | | Logged out on every device at once | Nobody can stay signed in | Salts rotated or session tokens cleared | Check security plugin logs |

Step 1: The incognito test (10 seconds, tells you almost everything)

Open a private window and log in. If it works there, the fault is in your normal browser's stored cookies and nothing on the server needs touching. If the loop follows you into incognito, the cause is server-side and you can skip straight to the site URL section below.

Test a second device on mobile data too. Same result on a different network and browser means the problem is definitely not local.

Step 2: Clear cookies for one domain only

Do not wipe every cookie you own. In Chrome, open Settings, then Privacy and security, then Third-party cookies, then "See all site data and permissions", search for your domain and delete only that entry. Firefox and Safari have equivalent per-site controls. Close the browser fully afterwards, because some cookies persist until the process ends.

Pro Tip: Browser extensions cause more of these than people expect. Privacy blockers, script blockers and aggressive cookie-consent tools can strip the WordPress authentication cookie before it is ever stored. Disable extensions for one test before you touch the server.

From the Hostaccent ticket queue (2026): WordPress issues account for about 30% of the support tickets we handle each month, and cookie or URL mismatches are the single most common reason inside that group. Almost none of them are hacks. Nearly all are configuration.

Fix the Site URL Mismatch That Breaks the Cookie

If the loop survives an incognito window, check your site addresses next. This is the fix in a large share of cases: WordPress issues a cookie for one address, then redirects you to a slightly different one, and the browser refuses to hand the cookie over. The difference can be as small as a missing "s" in https or an extra "www". Both values must match your real canonical address exactly.

If you can still reach the dashboard, look at Settings, then General. The WordPress Address (URL) and Site Address (URL) fields must be identical unless you deliberately run WordPress in a subdirectory.

Locked out completely? Override both values in wp-config.php instead. Connect over SFTP or your control panel file manager, open the file in your site root, and add these two lines just above the line that reads /* That's all, stop editing! Happy publishing. */:

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

Replace example.com with your real domain, and keep the protocol and any www prefix exactly as your site actually resolves. Save, upload, and try logging in.

Do I actually need to edit the database to fix this?

Usually not. The wp-config.php constants above override the database values at runtime, which makes them the safer first move because you can undo the change by deleting two lines. Go into the database only when you want the change to be permanent, or when an object cache is holding a stale value that the constants cannot reach.

When you do need it, open phpMyAdmin from your control panel, select your database, open the wp_options table and edit the siteurl and home rows. Take a database backup first. If you have SSH access, WP-CLI is faster and harder to get wrong:

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

Across the 4,000+ site migrations our team has handled since 2012, a stale siteurl left pointing at the old host or a staging subdomain is the most common reason a freshly moved site refuses to keep anyone signed in. It is worth checking the moment a move completes, before you hand the site back to a client.

Live site and no time to experiment? Our engineers fix this exact login loop for a small one-time fee, and you see the exact quote before anyone touches your files. Hosted with Hostaccent? Then issues like this are simply covered by support, at no charge. Have an engineer fix it

Caching, Cloudflare and the Reverse Proxy Trap

If your addresses are correct and the loop continues, the cache or proxy layer in front of WordPress is the next suspect. A cached copy of wp-login.php carries a nonce that expired hours ago, which produces the "wordpress session expired" popup. A cached wp-admin page serves another visitor's logged-out view back to you. Both look like an authentication failure and neither has anything to do with your password.

Start with three cache exclusions that every WordPress site needs, whether the caching happens at the CDN, in Nginx, or in a plugin:

1. Bypass cache for /wp-admin/*
2. Bypass cache for /wp-login.php
3. Bypass cache whenever a wp- or wordpress_logged_in cookie is present

A "Cache Everything" rule applied to the whole site without those exclusions is one of the most reliable ways to lock yourself out of your own dashboard. Purge the full cache after changing any rule, then test again in a fresh private window.

Now the cause almost nobody writes about. If your CDN terminates HTTPS but forwards the request to your origin server over plain HTTP, PHP sees an insecure request. WordPress then decides the secure admin cookie should not be set, or issues a redirect to the HTTPS version, which comes back over HTTP again. That is an infinite loop with no error message anywhere. Cloudflare's Flexible SSL mode does exactly this, and Cloudflare's own SSL explainer makes the encryption gap clear. Switch to Full (strict) with a valid certificate on the origin, then tell WordPress to trust the proxy header by adding this to wp-config.php:

phpCopy
if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] )
     && 'https' === $_SERVER['HTTP_X_FORWARDED_PROTO'] ) {
    $_SERVER['HTTPS'] = 'on';
}

Insider Insight: On a Cloudflare to Nginx to Apache stack like the one we run in production, we place that snippet before anything else loads. Skip it and every plugin that checks is_ssl() gets the wrong answer, which breaks logins, mixed content and canonical URLs all at once.

One more layer to clear. If you use Redis or Memcached, the object cache stores the entire alloptions array, siteurl included. Change the value in the database and the cache may keep serving the old one. Run wp cache flush, and restart PHP-FPM if you edited wp-config.php and OPcache is holding the previous version. Aggressive caching that fights your login is often the same misconfiguration that shows up in a high TTFB investigation.

Plugins, Themes, Salts and Server-Side Session Killers

Still looping? Now rule out code and server state. Rename your plugins folder over SFTP to plugins-off, which deactivates everything at once without touching the database. If login works, rename it back and reactivate plugins one at a time until the loop returns. The culprit is usually a security plugin, a login-page customiser, a two-factor tool or a cookie-consent banner that blocks cookies before consent is given.

Security plugins deserve a closer look. Several of them rotate the authentication salts in wp-config.php on a schedule, and every rotation invalidates every session on the site instantly. If your whole team gets logged out at the same moment, check that plugin's log before blaming anything else.

Themes matter too. A fatal error or a stray redirect in functions.php can break the login flow while the front end still loads normally. Rename your active theme folder and WordPress falls back to a default theme automatically.

If sessions themselves are corrupted, clear the tokens directly. This logs out every user, so warn your team first:

sqlCopy
DELETE FROM wp_usermeta WHERE meta_key = 'session_tokens';

Then there is the cause that fools even experienced developers. Check your server clock. Authentication cookies carry an absolute expiry timestamp, so if the server clock has drifted behind the browser clock by more than the cookie lifetime, the browser treats a brand-new cookie as already expired and discards it. You log in successfully and get bounced anyway. Our team hits this on unmanaged boxes where NTP was never enabled. Run timedatectl over SSH, and if sync is off, enable it with sudo timedatectl set-ntp true.

Pro Tip: Before you assume a plugin is at fault, check whether your account is simply running out of resources. On shared plans, PHP processes killed mid-request can drop the session write, which looks identical to a login loop. A 508 resource limit error in your logs at the same timestamp is the giveaway.

Confirm the Fix and Keep Your Login Stable

Do not declare victory on one successful login. A cookie fix can appear to work simply because your browser has a fresh session, then fail again tomorrow when the cache repopulates. Run all five of these checks before you close the tab, and the fix will hold.

1. Log in from a private window on a different device or network.
2. Click through to Posts, Plugins and Settings, then reload each page.
3. Save a draft, wait ten minutes, then click Update again to test for nonce failures.
4. Purge every cache layer once more and repeat check one.
5. Log out deliberately, close the browser, reopen and log back in.

Prevention is mostly discipline about when you re-test. Log out and back in immediately after installing an SSL certificate, changing your domain, editing cache rules or moving hosts. Those four events cause most of the loops we see, and catching a broken login in the same session you caused it turns a two-hour panic into a two-minute correction.

If the default 48-hour session genuinely annoys you, extend it with the auth_cookie_expiration filter in a small site-specific plugin rather than in your theme, so a theme update cannot wipe it. Be honest about the trade-off: a year-long session on a site with several contributors and shared laptops is a real security risk, not a convenience. Thirty days is a sensible ceiling for most teams.

The takeaways worth keeping:

• The loop is a cookie address mismatch far more often than it is a hack.
• Run the incognito test first, because it separates browser problems from server problems in ten seconds.
• siteurl and home must match your canonical address exactly, protocol and www included.
• Never let a cache layer touch wp-admin or wp-login.php.
• Re-test your login after every SSL, domain, cache or hosting change.

Login stability, delivery problems like emails going to spam, and Core Web Vitals failures traced back to hosting tend to share the same root cause: a stack where nobody owns the configuration. If you want the full picture on your own site, our WordPress slow site diagnosis guide covers the rest of the layers.

Your Next Step: A Login That Stays Put

Now that you know the loop is a cookie and address mismatch rather than a bad password, there are two sensible paths.

Fixed it yourself? Keep the five-check list above and re-test after every SSL or cache change. On a properly managed stack this class of problem belongs to support, not to you: the engineers who wrote this guide answer the Hostaccent support line, backed by a 99.9% uptime guarantee and 30 days to change your mind. Start on Managed WordPress Hosting at Basic — $22.99/yr. One honest caveat: Basic suits a single site, so a busy multi-site agency setup fits Business better.

Still locked out? Open a ticket and have an engineer fix it. You get the exact quote before any work starts. Either way, "wordpress keeps logging me out" should be a one-time annoyance, not a monthly ritual.

Frequently Asked Questions About WordPress Login Loops

Why does WordPress log me out after just two days?

That is the default, not a fault. WordPress sets authentication cookies to expire after 48 hours, extending to 14 days when you tick the "Remember Me" box at login. Your browser keeps sending the cookie for about 12 extra hours so WordPress can offer a clean re-login. If you want longer sessions, use the auth_cookie_expiration filter in a site-specific plugin, and cap it at 30 days on any site with multiple contributors.

WordPress keeps logging me out on one device only. Why?

Because the fault is local, not on your server. A single affected browser points to corrupted stored cookies, an extension stripping the authentication cookie, or a browser setting that clears cookies on close. Delete the cookies for that one domain, fully quit the browser, disable extensions and test again. If every other device and network signs in normally, stop editing server files. Fixing the browser is the entire job here.

Is a login loop a sign my WordPress site was hacked?

Rarely. In the sites Hostaccent cleans after a real compromise, the symptoms look different: unfamiliar admin accounts, modified core files, outbound spam or unexpected redirects for logged-out visitors. A pure login loop with an otherwise healthy front end is almost always a configuration problem with cookies, URLs or caching. Check your user list and file timestamps to be certain, but work through the configuration causes first.

Can I make WordPress keep me logged in permanently?

You can extend the session, though "permanently" is a bad goal. Add the auth_cookie_expiration filter through a small site-specific plugin and return a value in seconds, for example 30 days. Avoid year-long sessions on shared or multi-author sites, because a stolen laptop then keeps admin access for months. Ticking "Remember Me" already gives you 14 days, which is enough for most people without weakening account security.

Why does the "session expired" popup appear while I'm editing a post?

That modal means the security nonce on the page went stale before you clicked Update, usually because a cache layer served you a copy of the editor or login page that was generated earlier. Exclude wp-admin and wp-login.php from every cache, including your CDN, and purge everything. Your draft is normally recoverable: log in through the popup, then return to the tab and save again.

Will clearing cookies log out my visitors and customers too?

Clearing your own browser cookies affects only your browser and nobody else. Deleting the session_tokens rows in the database is different, because that ends every active session on the site at once, including logged-in customers on a membership or WooCommerce store. Rotating your authentication salts has the same effect. Schedule either action for a quiet period and tell your team beforehand, so nobody loses unsaved work.