A 403 Forbidden (or “Access Denied”) error means a server received a request and refused it on purpose. It is not a broken site and it is not a crashed server. Something between the visitor and WordPress decided the request was not allowed. In this video I walk through where that decision gets made on a typical WordPress site and how to let legitimate traffic back in.
Table of Contents
A 403 is a security answer, not an error
Every 403 comes from a firewall or security layer doing its job. Most of the time that is exactly what you want: bots, scrapers and brute-force login attempts should be refused. The problem only starts when something legitimate gets caught, which is why 403 support tickets nearly always read “X has stopped working”. A payment gateway cannot reach the site, a plugin cannot call the REST API, a staff member in another country cannot log in.
So the job is never “turn the security off”. The job is to find the layer that is blocking the request and add an exclusion for the thing that should be allowed.
The three places a WordPress site blocks traffic
1. The hosting firewall
Most hosts run a web application firewall and some form of IP blocking on the server itself. If the block is here, you usually cannot fix it yourself: log a ticket with your host, give them the IP address or user agent that is being refused and ask for it to be allowed. Hosting-level blocks are common for office IPs after a few failed logins, and for third-party services that poll the site frequently.
2. A security plugin such as Wordfence
Security plugins sit inside WordPress and inspect every request. Wordfence in particular will block API calls it has not seen before, and plugins that do anything unusual trip it regularly. Check the plugin’s blocked-request log first. If you are getting a steady stream of false positives, put Wordfence back into learning mode for a week. It stops firewalling while it learns, but it builds a picture of the normal calls your plugins make and stops blocking them afterwards. It will also prompt you to allow specific requests it has blocked.
3. Cloudflare (or another edge firewall)
This is the one we deal with most. On the sites we manage, Cloudflare rules do a lot of work: challenging traffic from outside the customer’s country, filtering strange query strings, protecting the login page. Those rules are there because the site was being hammered. The video shows a real example: an Australian WooCommerce store getting hits several times a second from Brazil, India, the UAE and France, and a rule set that challenges most of it.
The side effect was that Jetpack, which the store relied on, was being refused when it called the WordPress API. The fix took two minutes once we knew where to look.
How to find and fix a Cloudflare block
- In the Cloudflare dashboard open Security, then Analytics or Events (the label depends on your plan). This is the log of everything Cloudflare challenged or blocked.
- Filter by the user agent, IP or path of the thing that is failing. In our case, user agent contains “Jetpack” showed every refused request and which rule caught it.
- Go to Security Rules and add a custom rule above the blocking ones: match the same condition and set the action to Skip the remaining custom rules. Turn on logging for that rule so you can confirm it is firing.
- Reload the events view. The next request from that service should show as allowed by your new rule.
The same approach works for any edge firewall or bot-protection service: find the event log, identify the rule, add a narrow exception. Keep exceptions as specific as you can. “Skip for user agent contains Jetpack” is fine. “Skip for everything from the United States” is not.
Quick checklist when you see a 403
- Is the thing being blocked meant to have access? If not, the 403 is correct. Leave it.
- Which layer is refusing it: host, plugin or Cloudflare? Check the logs in that order of effort: plugin log, Cloudflare events, then a ticket to the host.
- Add the narrowest exception that lets it through, then confirm in the log that the exception is matching.
- If you had to loosen something, note what and why, so the next person does not quietly tighten it again.
If 403s or other errors keep turning up on your site and you would rather someone else chased them down, start with a free site audit from the WP Speed Fix homepage or check the free Core Web Vitals report to see how the site is performing for real visitors.