A 403 Forbidden error means the server or an intermediary such as a firewall understood your request but is refusing access.

Before changing WordPress files, test the affected URL from a different network. On your phone, turn off Wi-Fi and load the same page over mobile data.

If the page works there, the problem is probably specific to your original IP address, network, location, or a security rule applied to that traffic. Your website may still be available to most visitors.

If the same URL returns 403 from multiple unrelated networks, the problem is more likely to affect the site or resource itself.

This first test helps you decide whether to investigate an IP-specific block or a broader WordPress, server, CDN, or permissions problem.

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 Forbidden Error Actually Means

An HTTP 403 response means the request was understood but access is being refused.

That refusal can come from several places, including the web server, file permissions, a WordPress security plugin, a Web Application Firewall (WAF), a CDN, an IP restriction, or an access-control rule.

A 403 is different from a 401. A 401 Unauthorized response normally means valid authentication credentials are required. A 403 Forbidden response means the request is not being allowed under the current access rules, even though the server understood it.

A 403 also does not prove that a particular file or page definitely exists. Servers can intentionally return a 403 instead of revealing information about a protected resource.

The important troubleshooting question is not simply “What does 403 mean?” It is:

Which layer is refusing the request?

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	Start by checking
Entire site	Server permissions, ownership, web-server rules, WAF/CDN
Only `/wp-admin/` or login	Security plugin, IP block, WAF or host firewall
Homepage works but inner URLs fail	Rewrite/permalink rules, Apache `.htaccess`, server routing
One page or directory	Access rule, plugin restriction, permissions, redirect rule
Images/CSS/JS only	Hotlink protection, CDN/WAF rule, permissions or ownership
Saving/publishing triggers 403	ModSecurity/WAF request-body rule, security plugin
REST API `/wp-json/` returns 403	Authentication/nonce, security plugin, WAF or server access rule
Only one IP/network is affected	IP reputation, allow/block rule, geographic/network restriction

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.

Identify Who Is Returning the 403

Before disabling plugins or editing server files, look at the 403 response itself.

If you use Cloudflare and the error page includes Cloudflare branding, a Cloudflare Ray ID, or another Cloudflare-specific message, check your Cloudflare security events before changing WordPress.

Cloudflare can return 403 responses because of:

WAF managed or custom rules
Security Level settings
Browser Integrity Check
IP or country restrictions
DDoS/security protections
other Cloudflare validation rules

If the 403 page does not appear to come from your CDN, check your hosting firewall, security plugin, and web-server logs.

In Chrome, you can also open:

DevTools → Network → click the failed request → Headers

Record the request URL, response status, time of the failure, and any request or security ID shown on the error page. This information can make a hosting or firewall investigation much faster.

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 the site works from mobile data but fails from your normal connection, a security-plugin or firewall IP block should be one of the first things you check.

Wordfence, Sucuri, iThemes Security and similar plugins block IP addresses after failed login attempts. They also sometimes add restrictive rules to .htaccess. Brute-force protection can temporarily block an administrator’s IP after repeated failed login attempts or other activity that matches a security rule.

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: Check WordPress Rewrite and `.htaccess` Rules

If your server uses Apache or LiteSpeed, a bad .htaccess rule can cause 403 errors.

If you can still access WordPress admin, start with the least invasive test:

Settings → Permalinks → Save Changes

Do not change the permalink structure. Saving the page asks WordPress to refresh its rewrite rules.

If you cannot access WordPress:

Open your hosting File Manager, SFTP, or FTP.
Find .htaccess in the WordPress root directory.
Download a backup copy before changing anything.
Rename it temporarily to .htaccess_old.
Test the affected URL again.

If the error disappears, the old file contained a rule involved in the problem.

After access is restored, regenerate the WordPress rewrite rules and carefully restore any legitimate custom redirects, security rules, or HTTPS configuration from your backup.

Important: Nginx does not use .htaccess. If your website runs on Nginx, do not spend time renaming this file. Ask your hosting provider to inspect the Nginx server configuration instead.ad 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)

On many WordPress hosting environments, directories commonly use 755 permissions and files use 644. These are useful baseline values, but the correct configuration also depends on how your hosting account and web-server processes are set up.

Before recursively changing permissions across the entire site, check your host’s recommended values or ask support to verify them.

Also ask them to check file ownership.

A file can display apparently reasonable permissions but still return a 403 if it belongs to the wrong system user or group after a migration, backup restore, or server move.

Avoid using 777 as a troubleshooting shortcut. It grants extremely broad access and can create a serious security risk. If making permissions more permissive causes the 403 to disappear, treat that as evidence that permissions or ownership need to be configured correctly rather than leaving the insecure setting in place.

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 images or static assets return 403, hotlink protection is one of the first things to check, but it is not the only possible cause. CDN rules, ownership, file permissions and WAF policies can produce the same symptom.

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.

If the 403 appears only when you save a post, submit a form, upload certain content, or make a specific API request, a Web Application Firewall may be rejecting the request body.

Record:

the exact URL
what action triggered the error
the time and timezone
your IP address
any rule ID, Ray ID, or error reference shown

Then check your security or CDN logs if you have access.

For host-managed ModSecurity rules, contact your hosting provider and ask them to identify the exact rule that triggered. If it is a false positive, they can determine whether a narrow rule exception is appropriate.

Do not disable ModSecurity or your entire WAF permanently just to make the request work.

What If Only the WordPress REST API Returns 403?

If the website loads normally but requests under:

/wp-json/

return 403, do not start by changing general file permissions.

REST API requests can be rejected because of:

expired or invalid WordPress nonces
authentication problems
security-plugin REST API restrictions
WAF or ModSecurity rules
IP allow/block rules
custom code restricting REST endpoints

Open Chrome DevTools → Network, reproduce the failed action, and inspect the exact /wp-json/ request and response.

This is especially important when the visible symptom appears inside the Block Editor, WooCommerce, Elementor, or another plugin that communicates through the REST API.

If temporarily disabling a security rule fixes the request, re-enable the protection and create the narrowest appropriate exception rather than leaving REST API protection disabled site-wide.

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.

Can a 403 Forbidden Error Hurt SEO?

Yes, if Googlebot receives the 403 on a URL that should be publicly indexable.

Google requires accessible pages to return a successful HTTP response for normal indexing. Persistent 4xx responses, including 403, can eventually cause affected content to disappear from Google Search.

This is different from intentionally adding a noindex directive or blocking crawling with robots.txt. A 403 is an HTTP access error, not an SEO indexing directive.

A particularly difficult problem occurs when normal visitors receive 200 OK while Googlebot is blocked by a firewall, bot-protection rule, or CDN configuration. The website may appear completely normal to you while search-engine crawlers cannot access it.

After fixing the problem:

Open Google Search Console → URL Inspection.
Inspect an affected URL.
Run Test Live URL.
Confirm Google can retrieve the page successfully.
Review the Page indexing and Crawl stats reports for wider access problems.

If important URLs were removed from the index, request reindexing only after you have confirmed that Google receives the correct successful response.

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. Security rules and file/server access problems are both common enough that they are worth checking early. Which one is responsible varies by site and hosting environment.

Anyone telling you there is one dominant cause is simplifying something that genuinely varies by site.

WordPress 403 Forbidden Error: Quick Checklist

Test the same URL from a different network.
Note whether the entire site or only one resource returns 403.
Check whether the error comes from Cloudflare, another CDN/WAF, or your origin server.
Record the URL, time, IP address, and any error or Ray ID.
Check your security plugin’s block and lockout logs.
If you use Apache or LiteSpeed, review .htaccess and WordPress rewrite rules.
If you use Nginx, ask your host to inspect the Nginx configuration instead.
Verify file permissions and ownership.
Test plugins if WordPress itself appears to be generating the restriction.
Check hotlink/CDN settings when only images or static files fail.
Inspect ModSecurity or WAF logs when POST, publish, form, or API requests fail.
Check /wp-json/ separately if the REST API returns 403.
Investigate malware only when there are additional signs of compromise or unexplained recurring changes.
After the fix, confirm affected public pages return 200 OK.
Test important URLs in Google Search Console.

Preventing the next one

Three habits stop most repeat 403s.

If you use a stable office IP and your security setup supports trusted-IP rules, consider allowlisting it. Avoid broad or permanent allowlists for changing residential/mobile IP ranges, and never weaken security controls more than necessary.

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.

WordPress 403 Error Still Not Fixed?

If you have checked your security rules, plugins, file permissions, .htaccess, CDN, and hosting firewall but the 403 error keeps returning, Survyc can trace the request through your WordPress and server setup to identify where access is being denied.

We can investigate plugin conflicts, WAF rules, file ownership, server configuration, REST API failures, and other access-control issues without blindly disabling security across your live website.

Button text: Fix My WordPress 403 Error

Fix the WordPress 403 Forbidden Error

In this article