Short answer: the server received your request, understood it, and deliberately refused to serve it. That refusal comes from a permission, a security rule or an ownership problem — not from missing content.
Which 403 are you seeing?
- Whole site: usually file permissions, ownership, or a server-level rule.
- wp-admin only: typically a security plugin, an IP restriction, or a firewall.
- One action only: often a bot-protection or mod_security rule misreading a legitimate request.
- Uploads or assets: directory permissions or a hotlink-protection rule.
Narrowing this first saves time, because each variant has a different owner: your files, your plugins, or your host.
Check permissions and ownership
After a migration or a manual upload, wrong permissions or ownership are the classic cause. The safe baseline is directories 755, files 644, and wp-config.php at 640. Files must be owned by the web server’s user. Do not fix a 403 by setting anything to 777 — it usually works and leaves the site materially less safe.
Read the server log
The server error log normally states which rule or path caused the refusal — a mod_security rule ID, a denied directory, a blocked user-agent. That single line usually turns guesswork into a specific fix. If a security plugin is blocking your IP, look for its allowlist or a temporary-disable route (rename its folder in /wp-content/plugins) rather than deleting it.
Test from another network
Confirm whether other people or networks see the same 403; an IP-specific block affects only you and points at a firewall or security plugin, not the files. Re-test the exact URL and action from more than one network, and confirm the admin, media uploads and front end all behave normally before calling it fixed.
WP REPAIR INCIDENT STANDARD
How to narrow the fault without guessing
A 403 is an intentional refusal by one layer. Scope, server logs and the rule identifier distinguish filesystem ownership from firewall, security-plugin or application authorization failures.
Determine whether the refusal affects one IP, route, method or the whole site.
Read the web-server, WAF or security-plugin log for the exact rule.
Verify effective owner, group, ACL and PHP user before changing permissions.
Test from another network and with a controlled request body.
What must be verified
- The exact legitimate request succeeds from intended networks.
- Unrelated security controls still block invalid requests.
- Ownership and permissions survive the next deployment.
Official technical sources
This guide explains the diagnosis. If the site is affected now, the intervention should preserve a rollback path and verify the real business journey.
See the emergency repair service →