Resolving the WordPress 403 forbidden error

Common causes of the 403 forbidden error in WordPress and how to fix them, including file permissions, .htaccess corruption, security plugin lockouts and server-level blocks.

Resolving the WordPress 403 forbidden error

A 403 forbidden error means the server understood your request but is refusing to grant access. Instead of loading the page, you see an "access denied" or "forbidden" message. This can affect a single page, your entire site or just the WordPress admin area.

In WordPress, a 403 is almost always caused by one of a handful of things: incorrect file permissions, a corrupted .htaccess file, a security plugin blocking your IP or an overly aggressive server firewall rule. The fix depends on which of these is the cause, so it's worth working through each possibility methodically.

Start with the basics

Before diving into configuration changes, rule out the simple things first.

Refresh the page and clear your browser cache for the domain, or try loading the page in an incognito or private browsing window. Stale cookies or cached redirects can sometimes produce a 403 that isn't actually present on the server.

Also check that you're requesting a valid URL. If you're trying to access a directory that doesn't contain an index.php or index.html file, the server will return a 403 by design. This is normal server behaviour rather than a WordPress problem.

Reset .htaccess

The .htaccess file sits in the root of your WordPress installation and controls how the server handles URL rewriting, redirects and access rules. If this file has become corrupted or contains overly restrictive rules (often left behind by plugins), it can trigger a 403 on part or all of your site.

Connect to your site via FTP, SFTP or your hosting file manager and rename .htaccess to .htaccess_old. Then try loading your site again. If the 403 is gone, the file was the problem.

To regenerate a clean .htaccess, log into your WordPress dashboard and go to Settings → Permalinks, then click Save Changes without changing anything. WordPress will create a new .htaccess with the default rewrite rules.

If you can't access the dashboard, create a new .htaccess file manually with the default WordPress rewrite rules.

Note: if your server runs Nginx rather than Apache, there is no .htaccess file. Nginx uses its own configuration files, and you'll need to check those with your hosting provider instead.

Fix file and directory permissions

WordPress expects specific file and directory permissions to function correctly. The standard setup is 644 for files (owner can read and write, everyone else can read) and 755 for directories (owner can read, write and execute, everyone else can read and execute).

If permissions have been changed, whether by a plugin, a migration tool or manual editing, the server may refuse to serve files and return a 403 instead.

You can check and correct permissions using your hosting file manager or an FTP client. Apply 644 to files and 755 to directories recursively across your WordPress installation.

Never set permissions to 777, even temporarily. This gives full read, write and execute access to everyone, which is a serious security risk. Some hosting providers will actively block requests to files with 777 permissions, which can itself cause a 403.

If you're not sure how to change permissions, your hosting provider can usually do this for you.

Deactivate security plugins

Security plugins are one of the most common causes of 403 errors in WordPress. They can block your IP address after failed login attempts, restrict access to certain parts of the admin area or apply rules that conflict with your server configuration.

If you can still access the WordPress dashboard, go to Plugins → Installed Plugins and deactivate your security plugins one at a time, checking whether the 403 clears after each one.

If you're locked out of the dashboard entirely, connect via FTP or your hosting file manager and navigate to wp-content/plugins/. Find the folder for the security plugin you suspect is causing the issue and rename it (for example, change plugin-name to plugin-name-disabled). This deactivates the plugin immediately. Try loading the site again.

Once you've identified the plugin causing the problem, you can rename the folder back and reconfigure its settings to prevent it from blocking you again.

Switch to a default theme

In some cases, a theme can cause a 403 if it includes its own access rules or security restrictions. To test this, switch to a default WordPress theme (such as Twenty Twenty-Four) temporarily.

If you can access the dashboard, go to Appearance → Themes and activate a default theme. If you're locked out, connect via FTP and rename your active theme's folder inside wp-content/themes/. WordPress will automatically fall back to a default theme if one is installed.

Check server-level firewalls

Server-side firewalls like ModSecurity can block legitimate requests if they match a rule pattern. This is common after submitting forms with certain content, saving posts with specific HTML or making rapid requests to the admin area.

Your hosting provider can check the server's firewall logs and whitelist any false positives. If you've recently changed location or IP address, your new IP may have been caught by a blocklist.

Some hosting environments have hotlink protection enabled, which prevents other sites from loading your images and files directly. If the rules are configured too broadly, they can also block legitimate requests from your own domain, resulting in a 403.

If you suspect this might be the issue, ask your hosting provider to review the hotlink protection rules.

Still seeing a 403?

Your hosting provider should be your first port of call for persistent 403 errors, as they have access to server logs and firewall configurations that aren't visible from WordPress. If you need additional help, my emergency WordPress support service covers permission issues, configuration problems and security plugin conflicts.

Adam Greenough

Written by Adam Greenough

Freelance web developer with over 15 years of experience building and fixing WordPress sites. I work with businesses across the UK on everything from emergency support to full builds.

Need hands-on help?

I offer emergency WordPress support with a no-fix, no-fee guarantee.