A 403 Forbidden error means your server understood the request and refused it. Before changing any settings, open your site on your phone with wifi turned off. If it loads on mobile data, your site is fine and your IP address is simply blocked. If it fails there too, the problem is on the server.
Most guides to this error open by telling you to change your file permissions. That is fine advice for about half of readers and completely wasted on the other half, because their site is not broken at all. It is working perfectly for every customer, and refusing to let in exactly one person: them.
So let us find out which situation you are in first. It takes ten seconds.
What a 403 actually means
A 403 is your server saying “I know what you want, I found it, and I am not giving it to you.”
That distinction matters, because it rules things out immediately. A 404 means the page does not exist. A 401 means you need to log in. A 403 means it exists, and you are being refused. Nothing is missing and nothing is deleted. Something has decided you are not allowed.
The whole job is working out what made that decision.
Test 1: Is your site broken, or is it just blocking you?
Take your phone, turn off wifi so you are on mobile data, and load your site.
If it loads on mobile data: your site is completely fine. Your customers can see it right now. Your own IP address has been blocked, almost always by your own security plugin after a few failed login attempts, or by your host’s firewall. This is a lockout, not an outage. Skip ahead to the security plugin section.
If it shows 403 on mobile data too: the problem is genuinely on the server, and everyone is affected. Keep reading.
That single test tells you whether you are dealing with an emergency or an inconvenience, and it is the difference between a calm ten minutes and a panicked afternoon.
Test 2: What exactly is returning the 403?
A 403 can be issued by five different layers: WordPress itself, a plugin, your .htaccess file, a server firewall, or your host’s own rules. Each one is fixed in a different place, and sometimes by a different person.
The good news is that what breaks tells you which layer broke it. Find your row:
| What returns 403 | Where to look |
| Every page, including your homepage | File permissions, a bad .htaccess rule, or a server-level block |
| Only wp-admin or the login page | A security plugin blocking your IP, or a firewall rule aimed at the admin area |
| Homepage works, all other pages 403 | Broken rewrite rules in .htaccess, or a permalinks problem |
| Only certain pages or posts | A plugin conflict, or a bad redirect rule |
| Only images or CSS files | Hotlink protection, set too aggressively |
| Only when you save or publish a post | ModSecurity or your host’s firewall blocking the submission |
| Only the REST API or XML-RPC | A security plugin blocking automated requests |
That second-to-last row deserves a mention because it confuses people badly. Your site works. You can browse it. You just cannot publish anything, and there is no obvious reason why. That is almost always your host’s firewall reading a normal post submission as an attack.
If you are locked out of wp-admin
Most fixes assume you can log in, which is unhelpful when the 403 is on your login page. Here is the way in.
Use your host’s File Manager. It works regardless of what your site is doing, because it talks to your files directly rather than through WordPress. FTP or SFTP works too if you prefer.
Once you are in, in your site’s root folder:
- Rename .htaccess to .htaccess_old. Reload your site.
- Still broken? Go to wp-content and rename the plugins folder to plugins_disabled. This switches off every plugin at once. Reload again.
- If the site comes back, rename plugins to its proper name (they stay deactivated), then reactivate them one at a time until the 403 returns. The last one you switched on is your culprit.
If none of that helps, contact your host, and ask them for the actual server error log entry, not just a general “my site shows 403”. The log names the specific rule that blocked the request, which turns a guessing game into a one-line answer.
Fix 1: Your security plugin locked you out
If Test 1 showed your site loading on mobile data, this is almost certainly your answer, and the fix takes two minutes.
Wordfence, Sucuri, iThemes Security and similar plugins block IP addresses after failed login attempts. They also sometimes add restrictive rules to .htaccess. Their brute force protection cannot tell the difference between an attacker and you mistyping your own password three times.
Check the plugin’s lockout log first. Every one of these plugins keeps a record of blocked IPs, and your address will be sitting in it with a timestamp. That is a definitive answer in seconds, faster than any other method in this guide.
To get back in, either wait out the lockout period, remove your IP from the blocked list (you can reach the dashboard from a different network, or from your phone’s mobile data), or ask your host to whitelist you.
Then prevent it happening again. Add your office IP address to the plugin’s permanent allowlist. While you are there, add the server IPs of your backup and monitoring services too, because those get blocked surprisingly often and it stops your backups running without any obvious sign.
Fix 2: Reset your .htaccess file
Your .htaccess file tells your server how to handle requests. One bad line, and everything after it can break. Sometimes malware puts a Deny from all rule in there deliberately.
The reset takes a minute and is safe:
- Connect via File Manager or FTP and find .htaccess in your site’s root folder, where wp-config.php lives. Enable “show hidden files” if you cannot see it.
- Download a copy first, so you have the original if you need it.
- Rename it to .htaccess_old and reload your site.
- If the site works, go to Settings, then Permalinks, and click Save Changes without changing anything. WordPress writes a fresh, clean file.
One thing to watch: if you had custom rules in there (forcing HTTPS, redirects from an old site structure, anything a developer added), those are now gone. Open your downloaded copy and add them back carefully, one at a time, testing as you go.
A habit worth building: before you ever edit .htaccess, download it and rename the copy with today’s date. It takes five seconds and it has saved a lot of afternoons.
Fix 3: File permissions (and the number you must never use)
Permissions control who can read, write and run each file on your server. Set them too tight and your own server cannot read your site.
The correct values are 755 for folders and 644 for files. Most FTP programs let you apply this to a folder and everything inside it in one action, and your host’s support can set it for you in about a minute if you would rather not.
Now the important part. Never set anything to 777.
You will find forum posts recommending it as a quick fix, and it does often make a 403 disappear. It also gives every user on that server permission to read, write and execute your files. It is a genuine security hole, and it is one of the most common ways a site ends up compromised by a “fix” someone found online. If 777 makes your 403 go away, that only confirms the problem is permissions. Set it to 755 or 644 properly instead.
A separate thing that looks identical: on Linux and VPS servers, files also have an owner. Permissions can read perfectly while the files belong to the wrong system user, and your web server still cannot touch them. This produces a 403 that survives every permissions fix you try, and it is only fixable at the server level. If your permissions are correct and the 403 will not budge, ask your host to check file ownership specifically. Mentioning that phrase will save you a long support conversation.
WordPress publishes its own file permissions documentation if you want the full reference.
Fix 4: A plugin is causing it
If your permissions and .htaccess are clean, test for a plugin conflict using the folder-rename method above, or by deactivating plugins in bulk if you still have dashboard access.
Security plugins are the usual suspects here, but they are not the only ones. Anything that touches redirects, membership rules, or content restriction can produce a 403 by design when it is misconfigured. The full isolation method is in our guide to finding the plugin that is breaking your site, and it works the same way here.
Fix 5: Hotlink protection is blocking your own site
If only your images or stylesheets return 403 while pages load fine, this is your cause.
Hotlink protection stops other websites embedding your images and using your bandwidth. It is a reasonable thing to have. Set too aggressively, or configured with the wrong domain, it also blocks your own site and your own CDN.
Turn it off temporarily in your hosting panel or CDN settings and reload. If the images come back, reconfigure it properly rather than leaving it off. This is also worth checking if you are working through product images that will not display, since it produces exactly that symptom.
Fix 6: When it is your host’s job, not yours
Some 403s are not yours to fix, and knowing that saves days of pointless troubleshooting.
ModSecurity is a firewall running at the server level, before your request ever reaches WordPress. It scans requests for attack patterns, and it produces false positives. The classic one is flagging a normal post submission (with quotes, code snippets, or unusual characters in it) as an SQL injection attempt, which is why you get the “works fine but cannot publish” symptom.
You cannot fix this from your dashboard. Contact your host, tell them the exact action that triggers the 403, and ask them to check the ModSecurity log and whitelist the rule if it is a false positive. Hosts do this routinely.
The same applies to your CDN, such as Cloudflare, which has its own firewall rules that can block requests before they reach your server at all.
When a 403 means something worse
A 403 that keeps coming back after you have properly fixed it is a warning sign, not a stubborn bug.
Malware commonly rewrites .htaccess and changes file permissions specifically to keep its access open. If you clean those up and they revert, something on your site is putting them back.
At that point, stop treating it as a 403 and start treating it as a compromise. Work through the signs of a hacked site and, if they match, follow the full malware cleanup process. A cleanup that does not close the entry point just means the same 403 next week.
Once it is clean: reset .htaccess, fix permissions, change every password (WordPress admin, FTP, hosting panel), turn on two-factor authentication, and update everything.
The part nobody mentions: a 403 can cost you rankings
Here is the consequence most guides leave out entirely, and it is the reason not to leave a 403 sitting for a few days until you get round to it.
When Googlebot hits a 403, Google treats that page as blocked, in much the same way it treats a noindex tag or a robots.txt disallow. If the 403 persists, Google can drop the page from its index.
The uncomfortable version of this: a 403 affecting only bots is invisible to you. You browse your site, everything looks perfect, and meanwhile Google is being turned away at the door. A firewall rule that blocks crawler traffic can quietly cost you search visibility for weeks before anyone notices the traffic drop.
So after you fix a 403, verify what Google can see. Open Google Search Console, run the URL Inspection tool on an affected page, and use “Test live URL” to confirm Google can now fetch it. Then check the Pages report for anything newly reported as blocked. If pages did drop out, our guide to fixing page indexing issues covers getting them back.
An honest note on what causes this most often
You will read confident claims that file permissions are the number one cause of 403 errors in WordPress. You will also read equally confident claims that security plugin and firewall false positives are number one.
Both are widely reported, and the honest answer is that experienced practitioners disagree. So rather than picking one and trusting it, check both early: look at your security plugin’s lockout log, and check your permissions. Between them they account for the large majority of 403 errors, and both checks take under five minutes.
Anyone telling you there is one dominant cause is simplifying something that genuinely varies by site.
Your quick checklist
- Load the site on mobile data. If it works, your IP is blocked, not your site
- Note exactly what returns 403 and match it to the table above
- Check your security plugin’s lockout log
- Get in via File Manager or FTP if wp-admin is unreachable
- Download .htaccess, then rename it and re-save permalinks
- Check permissions: 755 folders, 644 files, never 777
- Rename the plugins folder to test for a conflict
- Turn off hotlink protection temporarily if only images fail
- Ask your host about ModSecurity, and request the error log entry
- Test in a private window before deciding a fix failed
- Check Search Console once it is fixed
Preventing the next one
Three habits stop most repeat 403s.
Allowlist yourself. Add your regular IP to your security plugin’s permanent allowlist, along with your backup and monitoring services. Most 403 lockouts are self-inflicted.
Version your .htaccess. Download and date-stamp a copy before every change. It costs five seconds and turns a broken site into a thirty-second restore.
Check permissions after anything big. Migrations, restores and host changes all reset them. If you are moving a site, add a permissions check to your post-launch list, and take a backup before editing server files at all.
Key takeaways
Start by loading your site on mobile data, because a surprising share of 403 emergencies are one blocked IP address while the site works perfectly for everyone else. If it really is down for everyone, let the symptom tell you the layer: site-wide points at permissions or .htaccess, wp-admin only points at a security plugin, images only points at hotlink protection, and “cannot publish” points at your host’s firewall.
Use 755 and 644, never 777, and if permissions look right but the 403 persists, ask your host about file ownership. A 403 that returns after a proper fix usually means malware. And once it is resolved, check Search Console, because Google treats a 403 as a closed door and will eventually stop knocking.
Frequently Asked Questions
What does the 403 Forbidden error mean in WordPress?
It means your server found what you asked for and refused to serve it. Unlike a 404, nothing is missing, and unlike a 401, logging in will not help. Something decided you are not allowed: usually file permissions, an .htaccess rule, a security plugin, or a server firewall.
Why am I getting a 403 error on wp-admin only?
Almost always your own IP being blocked, usually by a security plugin after failed login attempts. Test it by loading your site on mobile data with wifi off. If it works there, you are locked out rather than broken. Check your security plugin’s lockout log to confirm.
Should I set my file permissions to 777 to fix a 403?
No. It often makes the error disappear, which is exactly why the advice spreads, but it gives everyone on the server permission to read, write and run your files. That is a serious security risk. Use 755 for folders and 644 for files instead.
Is a 403 error the same as a 404?
No. A 404 means the page does not exist. A 403 means it exists and access is being refused. That difference matters for troubleshooting and for SEO, because search engines treat a missing page and a blocked page as two different situations.
Does a 403 error hurt my SEO?
It can. When Googlebot receives a 403, it treats the page as blocked, similar to a noindex tag. If the error persists, Google may remove the page from its index. After fixing a 403, check Google Search Console to confirm Google can fetch your pages again.
How do I fix a 403 error if I cannot log in to WordPress?
Use your host’s File Manager or FTP, which work independently of WordPress. Rename .htaccess to .htaccess_old, then rename wp-content/plugins to plugins_disabled to switch off all plugins. Reload after each step to see which one restores access.
Why do I only get a 403 when publishing a post?
Your host’s firewall, usually ModSecurity, is reading your submission as an attack, often because of code, quotes or unusual characters in the content. You cannot fix this yourself. Contact your host, describe exactly what triggers it, and ask them to check the log and whitelist the rule.
