WordPress 403 Forbidden Error: What Causes It and How to Fix It

You open your site, or try to save a post in wp-admin, and instead of your page you get a flat, unfriendly message: “403 Forbidden. You don’t have permission to access this resource.” Nothing is broken on the surface, the server is up, and yet it’s flat-out refusing you. The WordPress 403 Forbidden error is frustrating because it looks like a lockout, but it’s usually one specific rule somewhere telling the server to say no.

The good news: a 403 is far more predictable than a 500 error. There are only a handful of things that produce it on a WordPress site, and the fastest fix comes from figuring out which layer is doing the blocking before you start changing files.

What Does a 403 Forbidden Error Mean in WordPress?

A 403 Forbidden error in WordPress means the web server received the request, understood it, and deliberately refused to serve it. The server is working; something in its configuration, a firewall, or a security plugin has decided the visitor isn’t allowed to access that URL. The fix is to find the rule that’s refusing access and correct it.

That’s the key difference from other WordPress errors. A 500 internal server error means something crashed. A 404 error means the page couldn’t be found. A 403 means the page was found and access was denied on purpose, even if that “purpose” is a misconfigured rule.

Why Am I Getting a 403 Forbidden Error on My WordPress Site?

Most WordPress 403 Forbidden errors come from one of five sources: a security plugin or firewall blocking your IP or request, a corrupted .htaccess file, wrong file or folder permissions, incorrect file ownership after a migration, or a missing index file in the directory being requested. Each one leaves slightly different clues, which is how you narrow it down fast.

Here’s the quick diagnostic map:

Step 1: Figure Out Who Is Blocking You

The first step in fixing a WordPress 403 error is identifying which layer returned it: the CDN, the server firewall, or WordPress itself. Checking the error page design and the HTTP response headers usually answers this in under a minute, and it saves you from editing files that were never the problem.

Look at the error page itself first:

• A Cloudflare-branded page with a Ray ID means Cloudflare’s firewall blocked the request before it ever reached your server.
• A plugin-branded page, such as Wordfence’s “Your access to this site has been limited by the site owner,” means a WordPress security plugin blocked you.
• A plain white page with “Forbidden” and a server signature like Apache or LiteSpeed means the web server itself refused the request, which points to .htaccess, permissions, ModSecurity, or a missing index file.

For a more precise answer, open your browser’s DevTools (F12), go to the Network tab, reload the page, and click the request that returned 403. If the response headers include server: cloudflare and a cf-mitigated header, Cloudflare blocked it. If not, the 403 came from your origin server or WordPress.

Also test from a different network, like your phone on mobile data. If the site loads fine there, your IP address is blocked, not the whole site. That points straight at a firewall or security plugin.

Step 2: Rule Out Security Plugins and Firewalls

Security plugins and web application firewalls are the most common cause of 403 errors inside wp-admin. They flag legitimate admin actions, like saving a post with embedded code or a page builder AJAX request, as an attack and block them. Temporarily disabling the security layer confirms whether it’s the culprit.

If you can still reach wp-admin, deactivate your security plugin and retry the action that failed. If you’re locked out entirely, connect via FTP or your host’s file manager, go to wp-content/plugins/, and rename the security plugin’s folder (for example, wordfence to wordfence-off). WordPress deactivates any plugin whose folder it can’t find.

If that fixes it, rename the folder back, log in, and whitelist your IP or loosen the specific rule instead of leaving the site unprotected. If you’re not sure which plugin is responsible, the same folder-renaming method works for all of them; the full process is in this guide on finding which WordPress plugin is causing a problem.

Why Do I Get a 403 Only on wp-admin or When Saving Posts?

A 403 that appears only in wp-admin, on admin-ajax.php, or when clicking “Update” is almost always a web application firewall false positive. ModSecurity on Apache servers and Cloudflare’s WAF both inspect request content, and a post containing script tags, iframes, or SQL-looking text can trip a rule.

For Cloudflare, check Security > Events in the dashboard, find the blocked request, and note which rule fired. You can then create a skip rule for your IP or for /wp-admin/ paths. For ModSecurity, most cPanel hosts have a ModSecurity toggle per domain; switch it off briefly to confirm, then ask your host to whitelist the specific rule ID rather than leaving it disabled.

Step 3: Regenerate a Corrupted .htaccess File

A corrupted or overly restrictive .htaccess file is the most common cause of a site-wide 403 Forbidden error on Apache and LiteSpeed servers. Renaming the file and letting WordPress generate a fresh one takes about two minutes and is completely reversible.

1. Connect via FTP or your host’s file manager and open the WordPress root folder (the one containing wp-config.php).
2. Rename .htaccess to .htaccess-old. If you don’t see it, enable “show hidden files.”
3. Reload your site. If the 403 is gone, the .htaccess file was the problem.
4. Log in to wp-admin, go to Settings > Permalinks, and click “Save Changes” without changing anything. WordPress writes a clean .htaccess file.
5. Open .htaccess-old and copy back only the custom rules you actually need, such as caching or security directives, one block at a time, testing after each.

Watch for rules like Deny from all, Require all denied, or IP allow-lists that were meant for a single folder but ended up in the root file. Those are classic 403 triggers. If you’ve added hardening rules to protect wp-login.php, like the ones in this guide to securing the WordPress login page without a plugin, double-check that your current IP is still on the allowed list.

Running Nginx? Nginx doesn’t use .htaccess at all. A 403 on Nginx usually means a deny directive in the server block or a missing index file, and you’ll need your host or server panel to check the config.

Step 4: Fix WordPress File Permissions and Ownership

WordPress file permissions should be 755 for folders and 644 for files, which is the standard recommended in the official WordPress documentation on file permissions. If permissions are stricter than that, the web server can’t read the files and returns 403 Forbidden. Wrong permissions most often appear after a migration, a backup restore, or a manual upload.

On a small site, you can fix this in your host’s file manager or an FTP client like FileZilla: right-click the WordPress root folder, choose “File permissions,” set 755 and apply it to directories only, then repeat with 644 for files only. If you have SSH access, it’s two commands, run from the WordPress root:

find . -type d -exec chmod 755 {} +
find . -type f -exec chmod 644 {} +

For wp-config.php, the WordPress documentation suggests tightening further to 440 or 400 so other users on the server can’t read your database credentials. If a plugin needs to write to wp-config.php, 640 is a reasonable middle ground.

Never “fix” a 403 by setting everything to 777. It makes the error go away by letting anyone on the server write to your files, which is a much bigger problem than the one you started with.

When Permissions Look Right but the 403 Remains

File ownership is the next suspect when permissions are correct and the 403 persists. If files were uploaded or restored as the root user, the web server user may not own them and still can’t read them properly. This is common after a WordPress migration to a new host. On managed and cPanel hosting, ask support to reset ownership for your account; on a VPS, chown the files back to the web server or site user.

Step 5: Check for a Missing Index File or Wrong Document Root

If the 403 appears on your homepage or a folder URL, the server may not be finding an index file to load. Most servers are configured to refuse directory listings, so a folder without index.php or index.html returns 403 Forbidden instead of showing its contents.

Confirm that index.php exists in your WordPress root. Then check your domain’s document root in the hosting panel. After migrations or addon-domain setups, the domain sometimes points at an empty folder, or at public_html while WordPress lives in a subfolder. Pointing the document root at the correct folder fixes the 403 immediately.

Is a 403 Forbidden Error Bad for SEO?

Yes, a 403 Forbidden error hurts SEO if it lasts. According to Google Search Central’s documentation on HTTP status codes, Google doesn’t consider URLs returning a 4xx status code for indexing, and URLs that are already indexed get removed if they keep returning a 4xx error. A 403 that blocks Googlebot for days can quietly drop pages from search.

The sneaky version is a firewall that blocks bots but not you. The site looks fine in your browser while Googlebot gets 403 on every request. Check the Pages report in Google Search Console for “Blocked due to access forbidden (403),” and use the URL Inspection tool’s live test to see what Google actually receives. If you’re already seeing pages fall out of the index, this guide on fixing a WordPress page that isn’t indexed covers the rest of the checks.

When to Contact Your Host

Contact your hosting provider when the 403 persists after you’ve ruled out plugins, .htaccess, permissions, and the index file. At that point the block is almost certainly at the server level: a ModSecurity rule, a server firewall like fail2ban or Imunify360 banning your IP, or a hosting account restriction.

Give support the exact URL, the time the error happened, and your public IP address. That lets them search the server logs for the specific block instead of guessing, and it usually turns a multi-day ticket into a quick fix.

The Bottom Line

A WordPress 403 Forbidden error is a permission problem, not a crash, and the fastest fix is to identify the blocking layer before touching anything. Check the error page and headers, rule out firewalls and security plugins, regenerate .htaccess, then correct permissions and ownership. Work through them in that order and most 403 errors are fixed well within an hour, without weakening your site’s security in the process.

Frequently Asked Questions