If WordPress keeps logging you out, start with when it happens. A return to the login screen immediately after signing in is different from a session that ends after you close the browser. Treating both as a bad password can waste time and leave the actual fault untouched.
Before clearing anything, protect work that has not saved. Copy unfinished text into a private local document. Do not assume an expired-session message means the editor saved your latest changes. Then note the time, the page you were using, and whether another authorized user has the same problem.
This guide concerns a login that succeeds but does not stay usable. A rejected password, an invalid password-reset link, and a 403 access block need different investigations. Repeatedly resetting a working password is not the first test for a session problem.
Use the logout pattern to choose the first check
The following matrix is a diagnostic order, not a promise that one symptom proves one cause. Keep the original timing evidence before trying a new browser or removing site data.
| Logout pattern | First comparison | What to do next |
|---|---|---|
| The dashboard returns to login immediately | Compare the approved login address with the final dashboard address, including HTTPS and hostname | Check address, cookie and redirect handling with the maintainer before changing URLs |
| Only one browser profile loses access | Try the same approved account and address in a separate trusted browser profile | Review that profile’s site-cookie permissions and extensions; keep protections enabled elsewhere |
| Access ends after closing the browser | Note whether Remember Me was selected on a private, trusted device | Compare normal session behavior with the site’s actual login policy |
| Several users lose access at the same time | Match the time to approved deployments, session invalidation or authentication-policy changes | Ask the administrator for a change record; a browser-only fix is unlikely to explain all users |
| The editor reports an expired session after sitting idle | Check whether a new dashboard tab also requires login | Preserve the draft, authenticate through the legitimate page, then verify the saved revision |
Do not ask colleagues to share credentials for these comparisons. Each authorized person should use their own account. One controlled observation is more useful than everyone trying unrelated fixes at once.
A normal session ending is not always a fault
WordPress authentication depends on browser cookies. The official authentication-cookie reference describes two-day authentication validity without Remember Me, using a browser-session cookie. Selecting Remember Me normally creates a persistent cookie with fourteen-day validity. Site code can change these durations, and browser session handling also matters.
Those defaults do not guarantee continuous access for the full period. A site can invalidate a session, and a browser can discard the cookie. Remember Me therefore cannot repair an immediate logout or override an intentional administrator policy. Use it only on a private, trusted device, not a shared reception computer.
Ask whether the behavior is new. If it started immediately after a migration or an authentication change, record that association. It gives the maintainer a starting point, but it does not establish that the last update caused the problem.
Check one browser without weakening the whole site
The WordPress cookies handbook explains that missing, expired or invalid cookies require a new login. A cookie warning is therefore useful evidence, not a reason to make passwords easier or remove two-factor authentication.
First open the owner-approved login address directly in another trusted browser profile. Confirm that it belongs to the right website and uses HTTPS. A private window can be useful, but its cookie rules may differ from your usual profile, so record which environment you used.
If the second profile works reliably, return to the affected profile and check its cookie permissions for that specific site. After protecting unfinished work, removing only that site’s stored cookies can clear a stale session. Expect to sign in again. Do not clear every site’s data or globally allow third-party cookies just to make this test.
Where an extension appears relevant, compare it in a controlled profile instead of broadly disabling browser protection. Stop if the browser reports a certificate or unsafe-site warning. A secure connection problem needs investigation, not a click-through.
Why WordPress keeps logging you out after a move
A change between HTTP and HTTPS, or between hostnames, can send the browser through a different authentication path. The official login troubleshooting guide identifies cookie configuration, stored URLs, redirects and login-page caching as checks for repeated login problems.
Record the starting and finishing addresses without copying sensitive query parameters. Then ask the person responsible for hosting and WordPress to compare the saved URL configuration with the real installation. WordPress Address and Site Address can legitimately differ when WordPress lives in its own directory. Making them identical blindly can create another outage.
Similarly, a changed login slug can be intentional. Use the address supplied by the site owner rather than guessing routes or removing the plugin that protects them. A redirect loop also has its own diagnostic path; do not pile another redirect on top.
Keep URL corrections and database replacements out of a casual browser experiment. They need an exact backup, an understood configuration and a reversible plan. If access is unstable, the host or maintainer should establish a secure recovery route before changing anything.
Separate session policy from cached login pages
When several accounts fail in the same window, ask whether an administrator intentionally ended sessions. WordPress’s session-management reference includes invalidating individual sessions and groups of sessions. Such an action can be legitimate, so a logout alone does not prove compromise.
Unexpected account changes or unrecognized administrators are different evidence. Preserve them and follow the unknown-admin investigation instead of treating every logout as harmless browser behavior.
For caching, the question is whether the login or authenticated response follows the intended private-session rules. A cached public homepage is not proof that the dashboard is cached. Ask the maintainer to inspect the affected path and response, including any custom login route, using the cache-exclusion decision guide. Do not disable the CDN or cache everything under a new rule as a test.
Give support evidence it can use safely
A good handoff separates observed facts from guesses. Use this small record when requesting help. It avoids sending a full browser session or making support reproduce the fault with your credentials.
| Record | Useful detail | Leave out |
|---|---|---|
| Timing | Login time, logout time, time zone and action immediately before failure | Unrelated browsing history |
| Scope | One profile, one account or several authorized users; browser name and device type | Other people’s passwords or private account details |
| Address | Approved hostname, HTTPS and affected path without sensitive query values | Reset links, authentication tokens and cookie values |
| Change history | Known migration, deployment or policy change and its time | An unsupported claim that the latest plugin is responsible |
| Retest | Which comparison worked, how long it remained usable and whether the same action failed again | Raw network exports containing session credentials |
A repair must survive the action that used to fail
After one scoped change, repeat the original failure path with harmless content. If logout followed navigation, visit the same dashboard screen. If it followed a browser restart, test that behavior using the agreed login policy. For an idle-session complaint, wait for the relevant interval instead of calling a fresh login a permanent fix.
Check that a harmless draft saves and remains present after reopening it. Do not change customer records, submit a live order or trigger subscriber notifications for this test. Where multiple users were affected, verify the agreed scope with their own accounts.
Stop and restore the last reversible change if access worsens, a new redirect appears or private content becomes visible anonymously. Avoid stacking URL, cache and security changes: you would lose the ability to tell which one helped.
Paid help becomes appropriate when the problem crosses browsers or accounts, follows a migration, involves hosting/proxy rules, or repeatedly interrupts essential editing. Webless can investigate that path through its existing WordPress development and repair support. A recurring monitoring gap may instead belong in ongoing maintenance. Neither route should require you to post credentials in a general enquiry.