Locked Out of Your WordPress Website: Six Causes and the Way Back In for Each

If your website's login page will not let you in, you are almost certainly dealing with one of six things. Each has a different fix. Some of the fixes contradict each other, and the most common response, typing the password again with more force, turns a five-minute conflict into a half-day one.

This is a reference guide. Find the symptom that matches yours in the table below, go to that section, and work through it in order. I have written it from the operations side, where lockout calls follow a remarkably consistent pattern: the owner needs to change one thing on the site today, the login page refuses, and the protections that keep bots out turn out to work just as well against the person who pays the bills.

Before Anything Else, Stop Retrying

Stop entering the password. Most WordPress sites now sit behind some form of attempt limiting, either a security plugin or protection at server level. Both work the same basic way. They count failed attempts from your connection and, past a threshold, block it for a period.

Neither can tell a bot from an owner who has forgotten whether the capital letter goes at the start or the end.

So every retry costs you something. Three wrong guesses may be harmless, while eight may mean your premises' broadband is now on a timed ban and the original cause, whatever it was, is buried under a second one. Then verify two basics:

1. You are on the right address. Bookmarks go stale, especially after a rebuild or a move from http to https.
2. You are using the right identity. WordPress accepts either the username or the email address on your profile. A username created by whoever first set the site up (often "admin", or that person's own name) is rarely the one you would guess.

If both are correct and you are still refused, match the symptom.

The Six Causes at a Glance

What you see	Likely cause	First move
The reset email never arrives	Mail from your site is filtered, or goes to an old address	Check spam, then question which address is on your profile
The login page shows "not found" or redirects to the homepage	Someone changed the login address	Find the custom address before deleting anything
A lockout message, or the whole site will not load for you	Too many failed attempts	Wait, or switch your phone to mobile data
A request for a code from a phone you no longer have	Two-factor authentication without saved backup codes	Use a backup code, or ask another administrator
"Cookies are blocked or not supported by your browser"	A browser or site address mismatch	Clear cookies for your site and try a private window
Your password worked last week and the account email is not yours	Someone else has changed your account	Treat it as a security incident, not a login problem

Cause 1: The Password Reset Email Never Arrives

The WordPress documentation ^[1] describes the "Lost your password?" link as normally the easiest way back in. You enter your username or email, the site sends a reset link, and a minute later you are in. The same page adds a caveat that matters here: if your email is not working correctly, you may have to take different steps.

When the email does not come, it is usually one of two reasons.

Your website's own email is being filtered

The reset email is sent by your website, not by Gmail or Outlook. A lot of WordPress installations send mail without proper authentication, and the large inbox providers have stopped tolerating it. Google's email sender guidelines ^[2] have required everyone sending to personal Gmail accounts to authenticate their mail since February 2024, and warn that unauthenticated messages "might be marked as spam or rejected".

Check spam, junk and any promotions tab first. Then request a single new link and wait several minutes. Requesting five in a row does not speed anything up, and only the newest link will work.

There is a wider consequence worth facing. If your reset emails are being filtered, your contact form notifications almost certainly are too. A lockout is often the first time an owner discovers that enquiries have been landing in a spam folder for months, with every one of those customers assuming you simply never replied.

The link goes to an address you no longer use

The reset link goes to the email address on your WordPress user profile, not to the site's administration email and not to the address on your hosting invoice. If whoever set the site up used their own address, or you closed an old business mailbox when you changed provider, the link is going somewhere you cannot see.

That cannot be fixed from the login page. It needs a route in that does not depend on the login page at all, which is covered further down.

Cause 2: The Login Address Was Changed

A popular piece of security advice is to move the login page away from the standard address so that bots cannot find it. The WPS Hide Login plugin, which its directory listing puts at over two million active installations ^[3], does exactly that. Its own description is explicit that once it is active, the standard admin and login addresses become inaccessible, "so you need to remember the new URL".

The person who set it up remembers. That may be a relative, a former employee or a freelancer who moved on two years ago.

The symptom is distinctive: visiting /wp-admin shows a "page not found" error or bounces you to the homepage, while the rest of the site works perfectly. Nothing is broken. The door has simply been moved.

• Search your email for the original handover message from whoever built or last changed the site. Custom login addresses are often sitting in it.
• Check your browser history on the computer you used to log in from, filtering for "login" on your domain.
• Go outside WordPress if neither works. The plugin's own FAQ gives two routes: read the stored setting from the database, or remove the plugin's folder so the standard login page returns. Both need your hosting account rather than WordPress.

Being fair to the technique, hiding the login page does cut down the noise from automated scripts. It does not stop a determined attacker, though, and the recovery step it adds lands on you, not on the bots.

Cause 3: Too Many Failed Attempts

If the advice at the top came too late, this is probably where you are. The reflex is universal. Attempt limiting comes in two forms, and they behave differently enough that it is worth knowing which one has caught you.

A plugin lockout

A security plugin shows a message on the login page saying further attempts are blocked for a period, while the rest of the site carries on working. Limit Login Attempts Reloaded, listed at over a million active installations ^[4], suggests in its FAQ that a locked-out owner try a different connection, such as a phone's mobile data. Failing that, renaming the plugin's folder through your hosting file manager disables it long enough to log in, after which you rename it back.

A server-level ban

Server-level intrusion prevention watches for repeated failures and blocks the offending connection before it ever reaches WordPress. When it catches you, the whole website can look down from your premises while customers on their phones see it perfectly.

That disconnect is the giveaway. Switch your phone off Wi-Fi and load the site. If it appears on mobile data, the site is healthy and your connection is on a timed ban, which also means every staff member on the same broadband is locked out with you, including whoever was about to update this week's opening hours.

Waiting resolves both kinds, because the block expires. If the change cannot wait, your host can lift a server-level ban early. Only your host, mind: no plugin setting reaches that layer.

Cause 4: The Two-Factor Code Is on a Phone You No Longer Have

Two-factor authentication is the strongest single protection a login can have. A Microsoft Research study of accounts on Microsoft's own platform found it cut the risk of compromise by roughly 98% to 99%, the lower end applying where the password had already leaked ^[6]. Those figures come from a large corporate identity platform rather than small WordPress sites, so treat them as an indication of scale, not a promise. I would still not talk anyone out of switching it on, and our guide to two-factor authentication for WordPress accounts walks through the setup.

It does create a new way to lock yourself out, though. Phones get lost, broken, traded in and reset. If the authenticator app lived only on that phone, the codes went with it.

The fix is put in place in advance. The official Two Factor plugin ^[5] generates ten one-time backup codes during setup and states plainly: "Always enable backup codes to prevent being locked out of your account." If you have none:

• Another administrator on the site can switch off two-factor on your account from your user profile, and you set it up again on the new phone.
• If you are the only administrator, the plugin enforcing two-factor has to be disabled from outside WordPress, through the hosting account.

I made the textbook version of this mistake myself, years ago. I kept my backup codes in a notes app on the same phone that generated the codes, and when that phone died, both went together. The codes have lived on paper, in a drawer, away from the device they protect, ever since.

Cause 5: "Cookies Are Blocked or Not Supported by Your Browser"

This error appears on the login page itself, usually after you have typed the correct password. WordPress sets a small test cookie when the login page loads and checks for it when you submit. If the browser does not hand it back, the login is refused, perfect password or not.

The usual causes, in order of likelihood:

1. Stale or corrupted cookies for your site in that browser. Clear cookies for your domain only, not your whole browser, and retry.
2. A privacy extension or strict browser setting blocking cookies on that site. Try a private window with extensions switched off.
3. An address mismatch between what you typed and where the site thinks it lives, such as www against no www, or http against https. Use the exact address the site normally shows in the address bar.

A close relative is the login loop: the password is accepted, the screen flickers, and you land back on the login page. Same family of cause. If a private window in a completely different browser also loops, the conflict sits in the site's configuration rather than on your computer, and it becomes a job for your host.

Cause 6: Somebody Else Changed Your Account

This is the one to take seriously. If the password worked last week, you have not touched it, and the reset now goes to an address you do not recognise, someone has changed your account. Occasionally that is innocent, such as a former designer tidying up who removed or downgraded your user. Sometimes it is not. An attacker's first job after getting in is to lock the real owner out.

Do not treat this as a login problem. Treat it as an incident.

• Stop requesting resets, because they may now be going to the attacker.
• Contact your host and say plainly that you suspect the account has been taken over.
• Change the password on your own email account, in case that is how they got in.
• Assume content may have changed. Before anything is restored, someone needs to verify what changed and when.

The way back usually runs through backups. A clean copy from before the takeover lets you rollback the production site to a known-good state, while a copy from after it restores the attacker's changes along with everything else. That is why backup history matters as much as backup frequency, and why our complete guide to WordPress security and backups treats the two as one subject.

The Way In That Does Not Use the Login Page

Look back across causes 1, 2, 4 and 6. In every one, the fix lives outside WordPress: in the database where your user email and the custom login address are stored, or in the plugin folder that needs disabling. The WordPress documentation lists database, file and command-line methods for exactly this reason ^[1], and warns that the database route is taken "at your own risk".

Which means a lockout is the moment you find out whether you actually hold the keys to your own website.

Consider a composite scenario of a kind that comes up in some form every spring. A boat-tour skipper in Clare needs to post the season's sailing times before the Easter enquiries start. A relative set the site up years ago. The login address was changed, the reset email goes to the relative's old college address, and the hosting account is in the relative's name too. All week, the enquiries that do arrive ask whether the business is still running, because the website still shows last year's dates. Nothing was hacked. The site simply has no owner who can get in.

A setup that does not leave you there has a few properties, regardless of provider:

• A hosting account in your own name, separate from WordPress, with its own login and recovery.
• A file manager, so a misbehaving security plugin can be disabled without installing FTP software.
• A database tool, so a user's email address can be corrected and a stored login address read.
• A person to ring who can verify you are the owner and help, rather than a ticket queue in another time zone.
• Backup history, so a takeover can be rolled back to before it began.

How Web60 Handles It

Web60 meets that list. Every site has a built-in file manager and a phpMyAdmin-style database manager in the dashboard, so the outside-WordPress route exists from day one instead of being something you arrange after you need it. Support is handled by an Irish-based team of real people, not an outsourced queue. Automatic nightly backups come with one-click restore, and safety snapshots are taken before updates and restores.

Underneath sit server-level hardening and fail2ban intrusion prevention, the part of Web60's Irish-hosted infrastructure most owners never notice until the day it matters. And because the AI Website Builder creates the site from your own description in under a minute, the site is in your name from the first login, with no relative or agency holding the account.

One honest limitation. Intrusion prevention cannot tell an owner from an attacker. Mistype your password enough times and the same protection that blocks bots will block you, so the advice about stopping early and switching to mobile data still applies on our platform as much as anywhere.

When a Different Setup Suits Better

There is a kind of business this is not the best fit for. If you have an IT department managing every staff login through Microsoft or Google single sign-on, with joiners and leavers handled from one console, enterprise managed hosts with single sign-on integrations genuinely suit that better, and lockouts there belong to your IT team rather than your host. Most businesses with one to five people logging in have no such system, and do not need one.

Lockout-Proofing Your Website in Four Steps

The best time to deal with a lockout is while you can still log in. Ten minutes covers it.

1. Verify your profile email. Open your own user profile and confirm the address on it is one you read every day.
2. Record the login address. If your site uses anything other than the standard one, write it down somewhere that is not the website.
3. Store backup codes offline. If two-factor is switched on, print the codes and keep them away from the phone.
4. Deploy a second administrator. A trusted second account means one lost phone or one forgotten password is never the end of access.

Getting Back In, and Staying In

Every lockout falls into one of six patterns, and only one of them is a security incident. The other five are protections working as designed against the wrong person. Recognising which one you are facing tells you whether to wait, switch connections, clear a cookie, or pick up the phone to your host.

If you are setting up a new website, or taking back one that someone else built, start it somewhere the hosting account, the file access and the support line all answer to you. Web60's AI Website Builder will have that in place in under a minute. Then the next time the login page refuses you, you will know exactly which door you are standing at, and where the other key is kept.

Frequently Asked Questions

How do I get into WordPress if the password reset email never arrives?

Check spam, junk and any promotions tab first, then request one new link and wait several minutes, because only the newest link works. If nothing arrives, the reset is probably going to an old or unfamiliar address on your user profile. That cannot be fixed from the login page. You need access through your hosting account, where the email on your user record can be corrected in the database, or your host's support team can help you do it.

What is the normal WordPress login address?

By default it is your domain followed by /wp-login.php, and /wp-admin redirects there when you are logged out. If both show a page not found error or send you to the homepage, a security plugin has probably moved the login page to a custom address. Look for it in old handover emails and your browser history before disabling anything.

How long does a WordPress login lockout last?

It depends on whoever set the rule, either a security plugin or your host's server-level protection, and repeat lockouts usually last longer than the first. Stop retrying, wait, and in the meantime try the site on your phone's mobile data. If it loads there, the website is fine and only your connection is blocked. Your host can lift a server-level ban early if the update is urgent.

I lost my phone and cannot get my two-factor code. What now?

Use one of the backup codes you saved when you set up two-factor authentication; each one works once. If you have none, another administrator on the site can switch off two-factor on your account so you can set it up again on the new phone. If you are the only administrator, the plugin that enforces two-factor has to be disabled from outside WordPress through your hosting account, ideally with your host's help.

Why does WordPress say cookies are blocked when I try to log in?

WordPress sets a small test cookie when the login page loads and checks for it when you submit. If your browser does not send it back, the login is refused even with the right password. Clear cookies for your site only, try a private window with extensions switched off, and make sure you are using the exact address the site normally shows. If a different browser also fails, ask your host to verify the site's address settings.

Can my hosting provider reset my WordPress password for me?

Where the host gives you, or its support team, access to your site's database and files, yes, after verifying you are the account owner. That route works even when the reset email goes to the wrong address or a plugin has hidden the login page. If the hosting account is in someone else's name, such as a former designer, you will need that person or proof of ownership first.

Sources