A 403 error means the server received the request but refused access. Before changing WordPress files, check which URLs fail and whether the problem affects everyone. That distinction usually points to the responsible security layer.
Try the affected URL in a private browser window and on a different network, such as a phone using mobile data. Then check:
- Does the homepage return 403, or only
/wp-admin/? - Is one page, file, or form affected?
- Does the error occur only from your IP address?
- Did it begin after a plugin update, firewall change, migration, or permissions change?
If the site works from another network, investigate an IP block in your security plugin, CDN, or hosting firewall before modifying WordPress.
Check security plugin rules
Security plugins can deny requests based on IP reputation, login attempts, URL patterns, or firewall rules.
If you can access the dashboard, review the plugin's firewall and activity logs around the time of the blocked request. Look for the affected IP address or URL. Remove or allowlist only the specific rule responsible. Consult the plugin vendor's documentation before changing unfamiliar firewall settings.
If /wp-admin/ is blocked, use your hosting file manager or SFTP to rename the security plugin's directory inside wp-content/plugins. For example:
security-plugin
security-plugin-disabledReload the affected URL. If access returns, restore the original directory name and adjust the plugin's rules instead of leaving protection disabled.
Renaming a plugin directory can affect login protection and other security controls. Keep the test brief and restore the directory immediately afterward.
Review CDN and web application firewall blocks
A CDN or web application firewall can return a 403 before the request reaches WordPress. Check its security events for the exact URL, IP address, timestamp, and rule ID. Cloudflare users can review requests in the official Security Events dashboard documentation.
Common triggers include:
- Managed firewall rules
- Bot protection
- Rate limiting
- Country or IP restrictions
- Browser integrity checks
- Custom access rules
Temporarily disabling the specific rule is safer than turning off the entire firewall. Retest the same request, then narrow the exception to the required URL, IP, or action.
If no matching event appears, check the hosting control panel next. The block may come from a server firewall or a rule such as ModSecurity.
Verify file ownership and permissions
Incorrect permissions can prevent the web server from reading a directory or file. WordPress documents common permission patterns in its file permissions guide.
A typical starting point is:
Directories: 755
Files: 644These values are not universal. File ownership and the host's PHP configuration also matter, so confirm the required settings with your provider.
Do not recursively set everything to 777. That grants unnecessary write access and can create a serious security problem.
If the error started after moving files or restoring a backup, ask the host to verify that WordPress files belong to the correct system user. Changing numeric permissions will not fix incorrect ownership.
Test the .htaccess file
On Apache and compatible servers, a rule in .htaccess can deny access to the entire site or a particular path.
Create a backup of the existing .htaccess file, then rename it:
.htaccess
.htaccess-disabledTest the affected URL. If the 403 disappears, the original file contains a rule that the server rejects or that explicitly blocks the request.
When dashboard access is available, go to Settings > Permalinks and save the page to let WordPress write its standard rewrite rules. Compare the regenerated file with your backup before restoring custom redirects, security directives, or caching rules.
If renaming .htaccess has no effect, restore its original name. Nginx does not use .htaccess; its access rules must be checked in the server configuration by the host or server administrator.
Check whether a single plugin causes the error
If no security event explains the block, deactivate the plugin most closely connected to the failing request. For example, check a form, membership, download, media protection, or caching plugin when only its URLs return 403.
When the dashboard is unavailable, rename that plugin's directory through SFTP or the hosting file manager. Test again, then restore the directory name.
Avoid disabling every plugin on a live site unless a backup is available and the site can tolerate disrupted forms, checkout, authentication, or scheduled tasks.
Ask the host to identify the rejecting rule
Contact the hosting provider when the 403 affects the whole site, permissions and ownership appear correct, or you cannot access the relevant firewall logs.
Provide:
- The exact blocked URL
- The time of the request, including timezone
- Your public IP address
- Whether another network can access the URL
- Any recent plugin, migration, DNS, or server changes
Ask the host to check the web-server error log, ModSecurity events, filesystem ownership, and IP deny rules. Request the specific rule or log entry responsible rather than a broad firewall shutdown.
Once access is restored, reverse temporary plugin renames and firewall changes. Retest the homepage, /wp-admin/, login, forms, uploads, and any URL that originally returned the error.