WordPress 403 Forbidden Error: Why Your Pages Are Blocked and How to Fix It

The error that locks your visitors out while you think everything is fine

A 403 Forbidden is different from most WordPress errors. Your server is not overloaded. PHP is not crashing. Your database is connected and healthy. Everything looks normal from the inside.

But from the outside — from the perspective of your visitors, your customers, Google's crawler — your site is refusing to let them in. They see a stark error page:

"403 Forbidden — You don't have permission to access this resource."

There is no helpful message. No suggestion to try again. Just a door slammed shut. And because the 403 is a server-level block, it can affect one page, a section of your site, or every single URL. If Google's crawler hits a 403 on your pages, it stops indexing them. Your rankings do not just drop — your pages get removed from search results entirely.

What makes this error particularly frustrating is that you might be able to access your site perfectly well from your own computer. The 403 might only affect certain IP addresses, certain countries, or certain types of requests. You log into wp-admin, everything works, and you have no idea that half your traffic is being turned away.

What actually causes 403 Forbidden on WordPress

A 403 is not a bug — it is a deliberate access denial. Something on your server is deciding that a particular request should not be served. The challenge is figuring out which layer is doing the blocking.

1. Incorrect file permissions

Every file and directory on your server has permissions that control who can read, write, and execute it. WordPress needs specific permission settings to function. If these get changed — during a migration, a hosting move, a backup restore, or a poorly written plugin — your server cannot read the files it needs to serve your pages.

The correct permissions for WordPress are documented in the WordPress file permissions documentation:

• Directories: 755 — owner reads, writes, executes. Group and public read and execute only.
• Files: 644 — owner reads and writes. Group and public read only.
• wp-config.php: 600 or 640 — owner reads and writes. Nobody else gets access.

If a directory is set to 700, the web server user (usually www-data or apache) cannot read it, and every file in that directory returns a 403. If a file is set to 600 and the web server runs as a different user than the file owner, same result.

How to fix it: Connect via SSH or FTP. For SSH, run these commands from your WordPress root directory:

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

This resets all directory permissions to 755 and all file permissions to 644. Then lock down wp-config.php separately:

chmod 640 wp-config.php

If you only have FTP access, most FTP clients let you right-click a file or directory and set permissions manually. It is tedious for hundreds of files but works for targeted fixes.

2. .htaccess deny rules blocking access

The .htaccessfile in your WordPress root directory is Apache's configuration file. It controls URL rewriting, redirects, and — critically — access control. A single misplaced rule can lock out your entire site.

Common scenarios where .htaccess causes 403 errors:

• A security tutorial told you to add deny from all to protect wp-includes, but you put it in the wrong section and it blocks all access
• You added IP-based restrictions to wp-admin but accidentally restricted the entire site
• A security plugin wrote deny rules into .htaccess and then was deactivated, leaving the rules behind
• A corrupt or duplicate .htaccess file confuses Apache

How to fix it: Download your current .htaccess file via FTP and review it. Look for any deny from all, Require all denied, or order deny,allow directives that should not be there. If you are unsure, rename the file to .htaccess-backup and create a new one with the default WordPress rules:

# BEGIN WordPress
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{{REQUEST_FILENAME}} !-f
RewriteCond %{{REQUEST_FILENAME}} !-d
RewriteRule . /index.php [L]
# END WordPress

If the 403 disappears with the clean .htaccess, the problem was in the old file. Compare the two line by line to find the offending rule.

3. mod_security false positives

mod_security is a web application firewall that runs on your server. Many shared hosting providers enable it by default. It scans every incoming request and blocks anything that matches its rule set — SQL injection patterns, cross-site scripting attempts, and other known attack signatures.

The problem is that legitimate WordPress activity often looks like an attack to mod_security. Saving a long blog post with code snippets can trigger SQL injection rules. Uploading certain file types can trigger file inclusion rules. Even submitting a contact form with certain words can be flagged.

When mod_security blocks a request, it returns a 403 Forbidden. No WordPress error page. No helpful message. Just a flat denial that looks identical to a permissions error.

How to fix it: Check your server error logs for mod_security entries. On Apache, these are typically in /var/log/apache2/error.log or /var/log/httpd/error_log. The log entry will include the specific rule ID that triggered the block. You can then either:

• Contact your hosting provider and ask them to whitelist the specific rule ID
• If you have server access, disable the specific rule in your mod_security configuration
• Add a SecRuleRemoveById directive for the problematic rule

Never disable mod_security entirely. It protects your site from real attacks. Only whitelist the specific rules causing false positives.

4. Security plugin IP banning

Security plugins like Wordfence, Sucuri, and iThemes Security protect your site by monitoring login attempts, scanning for malware, and blocking suspicious IP addresses. They are valuable tools. But they can also lock out legitimate visitors — and even lock you out of your own site.

Common ways security plugins cause 403 errors:

• Aggressive rate limiting: A visitor browses several pages quickly and the plugin decides they are a bot
• Country blocking: You enabled geo-blocking for certain countries and did not realise some of your customers are there
• IP blacklist updates: The plugin downloads a blocklist that includes a shared IP range, blocking innocent users on the same network
• Failed login lockout: Someone tries to brute-force your login from a shared IP, and the plugin blocks the entire IP — including you

How to fix it: If you are locked out, connect via FTP and rename the security plugin's folder in /wp-content/plugins/ to deactivate it. Log into wp-admin, then reactivate the plugin and review its blocklist. Whitelist your own IP address and any known-good IP ranges. If you are using country blocking, verify that you are not blocking countries where you have actual customers.

5. Hotlink protection or directory index restrictions

Some hosting providers enable hotlink protection by default, which prevents other sites from embedding your images. If misconfigured, it can block your own site from loading its own assets — images, CSS, and JavaScript files all return 403. Your pages technically load, but they look broken because none of the assets are accessible.

Similarly, if directory indexing is disabled (which it should be for security) but your index file is missing or misnamed, Apache returns a 403 instead of listing the directory contents.

How to fix it: Check your hosting control panel for hotlink protection settings and make sure your own domain is whitelisted. For directory indexing issues, make sure every directory that needs to be served has a proper index file (index.php or index.html).

Why you might not know your visitors are getting 403 errors

Here is what makes 403 Forbidden errors so treacherous for WordPress site owners. The error can be selective.

If the 403 is caused by a security plugin banning specific IP addresses or countries, you will never see it from your own connection. You log in, browse your pages, check your checkout — everything looks perfect. But visitors from certain networks or regions are being turned away with no explanation.

If the 403 is caused by mod_security, it might only trigger on specific types of requests. Your homepage loads fine. Your blog loads fine. But when someone submits a contact form or tries to place a WooCommerce order with certain product names, the POST request gets blocked. The visitor sees a 403 error or a blank response, and you see a drop in conversions that you cannot explain.

If the 403 is caused by an .htaccess rule that protects wp-admin, it might accidentally block access to /wp-admin/admin-ajax.php — a file that many plugins use for frontend functionality. Your public-facing pages break in subtle ways because JavaScript requests to admin-ajax are being denied, but you only notice if you open the browser developer console.

The only reliable way to know that your visitors can access your site is to check from outside, continuously, the way a visitor would.

How to detect 403 errors with Uptrue

Uptrue's HTTP monitoring catches 403 Forbidden errors instantly because the server returns a clear 403 status code. Unlike errors that hide behind a 200 response, a 403 is unambiguous.

Step 1: Set up an HTTP monitor for your key pages

1. Sign up at uptrue.io/signup (free plan available)
2. Click Add Monitor from your dashboard
3. Select HTTP/HTTPS as the monitor type
4. Enter the URL of your homepage
5. Set expected status to 200
6. Set the check interval to 1 minute
7. Configure alerts — Slack, email, or Microsoft Teams

If your page returns a 403 instead of a 200, Uptrue alerts you within 60 seconds. But do not stop at the homepage — 403 errors often affect specific pages while the homepage is fine.

Step 2: Monitor your most critical pages individually

Add separate HTTP monitors for each of these:

• Homepage — your front door
• Contact page — where your leads come from
• Checkout page — where your revenue comes from (if WooCommerce)
• Login page — wp-login.php, so you know if you are locked out
• Any landing page receiving paid traffic — a 403 here means you are paying for clicks that hit a wall

Step 3: Add keyword monitoring for error detection

1. Add a Keyword monitor for your homepage
2. Set the keyword to your site name or tagline
3. Set the check type to "Page must contain"
4. Set the interval to 1 minute

Some server configurations return a 200 status code with a custom 403 error page. The HTTP monitor would miss this, but keyword monitoring catches it — if your expected content is replaced by an error page, you know immediately.

Step 4: Monitor from multiple perspectives

Because 403 errors can be IP-specific or region-specific, monitoring from a single location might not catch blocks that affect other regions. Uptrue's monitoring infrastructure checks from outside your network, seeing your site the way a real visitor would — not the way it looks from your office on your whitelisted IP.

Step 5: Configure alerts that reach you fast

A 403 on your checkout page is a revenue emergency. Configure your alerts to reach you where you will act on them immediately:

• Slack — instant notification in a dedicated channel
• Microsoft Teams — same speed, different platform
• Email — good as a backup record
• Webhook — integrate with PagerDuty, Opsgenie, or your incident management system

Preventing 403 errors before they happen

Monitoring catches the problem fast. But these practices reduce the chances of a 403 hitting your site in the first place.

Audit your .htaccess after every security change

Every time you install a security plugin, change a security setting, or follow a hardening tutorial, check your .htaccess file afterwards. Download a copy and read it line by line. Understand what each rule does. If you do not understand a rule, do not add it. A single misplaced deny from all can take down your entire site.

Whitelist your own IP in security plugins

Before you enable any IP-based blocking or rate limiting in a security plugin, add your own IP address (and your team's IPs) to the whitelist. This prevents the plugin from locking you out of your own site when you are testing or making rapid changes.

Test file permissions after migrations

Server migrations, hosting moves, and backup restores are the most common times file permissions get scrambled. After any migration, run a permissions check. Many managed WordPress hosts offer a permissions reset tool in their dashboard. Use it.

Keep mod_security rules updated

If you have access to your mod_security configuration, keep the rules updated to the latest version. Newer rule sets have fewer false positives because they better understand modern web application patterns. Ask your hosting provider what rule set they use and when it was last updated.

Never set permissions to 777

When troubleshooting, it is tempting to set file or directory permissions to 777 (everyone can read, write, and execute) to see if permissions are the issue. If the 403 goes away, you have your answer — but leaving 777 in place is a critical security vulnerability. Any script on your server can modify those files. Fix the permissions properly and never leave 777 in production.

Stop losing visitors to a door you accidentally closed

A 403 Forbidden is your server actively rejecting the people you are trying to attract. Your content is there. Your database is working. Your server is healthy. But somewhere in the chain — file permissions, .htaccess rules, a firewall, a security plugin — a gate is closed.

And the most dangerous part is that you might not be affected yourself. You browse your site from your office, everything works, and you have no idea that visitors from certain IPs, certain countries, or certain devices are being turned away.

Uptrue checks your pages every 60 seconds from outside your network. If any page returns a 403 instead of the expected 200, you know in under a minute. Before your ad spend goes to waste. Before Google deindexes your pages. Before a customer gives up and goes to a competitor.

Frequently asked questions