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

A 403 Forbidden response means the server understood the request but refused it. The refusal might come from a security plugin, web application firewall, .htaccess rule, CDN, or file permissions. The quickest fix is to identify which layer produced the block.

Back up the site before editing server files.

Identify What Is Blocked

Test the home page, /wp-admin/, one affected file, and a private browser window. Try another network if possible. If only your IP is affected, a firewall or rate limit is more likely than damaged WordPress files.

Look at the design of the error page. A branded security or hosting page often identifies the service that denied access.

Review Firewall and Security Logs

Check your security plugin, CDN, and hosting firewall logs for the blocked URL, IP address, timestamp, and rule ID. Whitelist only the legitimate request or correct the triggering rule. Disabling the entire firewall should be a short diagnostic step, not the permanent solution.

If you cannot enter the dashboard, use the hosting file manager or SFTP to rename the suspected security plugin folder temporarily. Rename it back after testing.

Test Plugins and .htaccess

Deactivate plugins on a staging copy or use WordPress troubleshooting mode. If the error disappears, reactivate plugins individually.

For Apache sites, download a backup of .htaccess, rename the server copy, and test again. If access returns, log in and save Settings → Permalinks to generate standard WordPress rewrite rules. Reapply any necessary custom rules carefully.

Check Ownership and Permissions

WordPress files need to be readable by the web server, but making everything writable is unsafe. Common starting permissions are 755 for directories and 644 for files, although the correct ownership depends on the host. Ask the provider to repair ownership rather than using 777.

When to Contact Your Host

Send support the exact URL, time, your public IP, and any firewall request ID. Ask whether ModSecurity, malware protection, rate limiting, or a server permission rule generated the 403.

Once access returns, re-enable every protection you disabled and verify both the public site and dashboard.