A 403 is the server refusing, politely but firmly. On an Apache or LiteSpeed server the page usually just says “Forbidden. You don’t have permission to access this resource.” On Nginx it is a bare “403 Forbidden” with “nginx” printed below it. Behind Cloudflare or a hosting firewall you may get a branded block page instead, often mentioning that a security service has protected the site.
The important word is refusing. A 403 is not the server failing. The server is working, has read your request, and has decided you shouldn’t have it. Something in the setup made that decision, and the fix is to find that something and correct it, rather than to reinstall WordPress.
First, pin down where the 403 appears
A forbidden error on the homepage and one that only appears when you press “Update” on a post have completely different causes. Write down which of these fits:
- The entire site, for everyone. Think file permissions, ownership, a broken
.htaccess, or a missing index file. - Only
/wp-admin/or/wp-login.php. Think security plugin, a host-level password or IP rule, or a firewall that has flagged your IP address. - Only one action, such as saving a post, uploading a file or submitting a form. Think web application firewall rules, very often ModSecurity on shared hosting, reacting to what you sent.
- Only for you, while others load the site normally. Think IP or country blocking, or a VPN whose address range is blocked.
- Only images or files, especially when viewed from another site. Think hotlink protection.
Also check whether the page is a WordPress-styled grey screen saying “Sorry, you are not allowed to access this page.” That is WordPress’s own permission check, not the server, and it has its own explanation in our post about the “Sorry, you are not allowed” message.
What usually causes it
Security rules and firewalls
On shared hosting this is the cause we’d check first. Hosts run a web application firewall in front of PHP, commonly ModSecurity with a rule set designed to block attack patterns. Editing a post that contains a block of code, a long URL, or certain words can look like an attack to those rules. So can a page builder saving a large chunk of HTML in one request. The result is a 403 on that one action while the rest of the site is fine. Our explainer on how a website firewall decides what to block gives the background.
WordPress security plugins add a second layer. Wordfence, Sucuri, iThemes/Solid Security and similar tools can block IP addresses after failed logins, restrict access to wp-admin by country, or block particular URL patterns. Cloudflare’s own firewall rules can do the same, and they are easy to forget once set.
File and folder permissions
The web server needs permission to read your files. The usual safe pattern on most Linux hosting is 644 for files and 755 for folders, with wp-config.php often set tighter. If a migration, a restore or an overly enthusiastic “harden everything” step leaves folders at 600 or files at 000, the server can’t read them and returns 403. Ownership matters too: if files belong to the wrong user account, the permissions may look right and still fail. We cover the numbers and what they mean in WordPress file permissions explained.
Rules in .htaccess
On Apache and LiteSpeed, the .htaccess file in your site’s root (and sometimes in wp-admin or wp-content/uploads) can contain lines like Deny from all or Require all denied. Security plugins write rules like these to protect sensitive files, and occasionally they protect a little too much. A corrupted file, or one edited by hand without testing, can block the whole site.
No index file, and directory listing turned off
If WordPress’s index.php is missing from the root, or the server isn’t configured to treat it as the default page, visiting the bare domain asks the server to list the folder’s contents. Most hosts disable listing, so the answer is 403.
Background requests being blocked
Not every 403 shows up as a full page. The block editor, page builders and many plugins talk to the server in the background, through /wp-json/ (the REST API) and /wp-admin/admin-ajax.php. If a firewall or security plugin blocks those addresses, you never see “Forbidden” on screen. Instead the editor says saving failed, a spinner never stops, or a button seems to do nothing. Opening your browser’s developer tools and watching the Network tab while you repeat the action will usually show the request returning 403. In the block editor this often surfaces as the message described in our post on “not a valid JSON response” when updating.
Host-level restrictions
Some hosting panels let you password-protect directories or allow only certain IPs into wp-admin. If a previous developer set that up, a new office IP address or working from home can suddenly hit a 403.
Hotlink protection
Hotlink protection blocks other sites from embedding your images. If it is set up with your old domain, or without both the www and non-www versions, it can block your own pages from loading your own images.
Fixing it step by step
Each step here can be reversed if you keep a copy of what you change. Before editing files, download .htaccess and note the current permissions. Make sure there is a recent backup of files and database, stored away from the server, so a misstep isn’t permanent.
1. Try a different connection
Load the site on your phone using mobile data, with Wi-Fi turned off. If it works there but not in the office, your IP address is being blocked somewhere: by the host’s firewall, Cloudflare, or a security plugin. That narrows the search a great deal before you open a single file.
2. Look in the server error log
Your hosting panel usually has an error log or access log viewer. A 403 caused by a firewall rule often leaves a line mentioning ModSecurity, an “access denied” reason and a rule ID. A permissions problem typically mentions “permission denied” and a file path. If you find a ModSecurity rule ID, send it to the host; they can whitelist that single rule for your site rather than switching the firewall off. Our guide on finding and reading WordPress error logs shows where these files tend to live.
3. Rename .htaccess
Rename .htaccess in the root to .htaccess-backup and reload. If the site comes back, a rule in that file was the problem. Log in, open Settings → Permalinks and click Save Changes so WordPress writes a fresh default file. Then compare the old file with the new one and add back only the rules you understand and need. Check for extra .htaccess files in wp-admin and wp-content too, as these sometimes hold blocking rules.
4. Deactivate the security plugin
Rename the security plugin’s folder in wp-content/plugins/. If that clears the 403, reactivate it and look at its blocked IPs list, country restrictions and firewall settings. Unblock your own address and reduce any rule that is clearly too broad. Leaving the plugin off permanently isn’t the answer.
5. Check permissions and ownership
Most file managers show permissions in a column. Folders should generally be 755 and files 644. If you see something very different on whole directories, ask your host to reset permissions and ownership for your account; many hosts have a one-click tool. Avoid setting anything to 777, which can make the site easier to attack without fixing the real issue.
6. Confirm the index file
Make sure index.php is present in the site root and hasn’t been renamed during a restore. If it’s missing, that is also a sign to check whether other core files are missing.
7. Review CDN and host rules
Look through Cloudflare’s firewall or WAF events and your hosting panel’s directory privacy, IP blocker and hotlink settings. A rule added years ago and forgotten is a frequent find.
When a 403 is a warning sign
Sometimes a 403 appears because the host has restricted the account after detecting malware, or because unfamiliar .htaccess rules were added by an intruder to hide malicious files. If you see rules you didn’t write, PHP files in odd places, or a notice from your host about suspicious activity, treat it as a possible compromise rather than a settings issue. If the host has already locked the account, our page on hosting suspended for malware explains what happens next.
Keeping 403s away
- Keep one security plugin, not two, and know where its block lists live.
- When the host’s firewall blocks a legitimate action, ask for that one rule to be relaxed for your site instead of turning the firewall off.
- After a migration or restore, check permissions and ownership before declaring the job done.
- Write down any IP restrictions on wp-admin so the next person on the site knows they exist.
When to hand it over
If the block is in the host’s firewall and they won’t explain it, or you can’t tell whether an .htaccess rule was written by a plugin or by an attacker, it’s worth getting a second pair of eyes. You’ll find related server errors in our WordPress errors and fixes guide.
For a 403 that won’t clear, our WordPress bug fixing service is where this kind of problem belongs. Send us the exact URL, what you were doing when it appeared and, if you have it, the log line; we’ll look before changing anything and explain what we find.
Next in this series: WordPress 502, 503 and 504 Errors Explained
