Emergency Fix
WordPress 403 Forbidden Error? Fix wp-admin Access Fast
A WordPress 403 error means the server received your request but refused to serve it. The fastest fix depends on where the block appears: the whole site, only wp-admin, one page, the REST API, or immediately after an update or migration.
- Check whether the 403 affects everyone or only your IP/browser.
- Undo the most recent plugin, security, migration or CDN change.
- Back up and test
.htaccess. - Verify permissions—do not make files world-writable.
- Check Cloudflare, hosting firewall and server logs for the denied rule.
What a 403 Forbidden Error Actually Means
A 403 is different from a missing page. WordPress or the web server understands the URL, but an access-control layer refuses the request. That layer might be WordPress, a security plugin, Apache or Nginx, your host, Cloudflare, ModSecurity or file permissions.
Refreshing repeatedly normally does not help until the rule or configuration causing the denial changes.
First Identify Which 403 You Have
Prioritise root-level .htaccess, file permissions, ownership, host security rules and CDN/WAF blocks.
Prioritise security plugins, IP allowlists, brute-force protection, admin directory rules, Cloudflare rules and host firewall events.
Look for a request-specific WAF rule, REST API permission, nonce failure, hotlink rule or plugin restriction.
Investigate the exact changed plugin, copied server rules, ownership, paths, domain/protocol settings and migrated security configuration.
Fix 1: Reverse the Most Recent Change
If the error appeared immediately after a plugin update, disable that plugin first rather than changing several unrelated settings. Security, firewall, caching and redirect plugins are common sources of admin-only blocks.
When wp-admin is unavailable, rename only the suspected plugin folder through File Manager or SFTP. For broader conflict testing, follow the WordPress plugin conflict recovery guide.
Fix 2: Back Up and Rebuild .htaccess
On Apache or LiteSpeed hosting, a damaged or over-restrictive .htaccess file can deny WordPress routes.
- Download or copy the existing file as a backup.
- Rename it temporarily to
.htaccess-old. - Test the affected URL.
- If access returns, log in and save Settings → Permalinks to regenerate normal WordPress rules.
- Re-add only verified custom security or redirect rules.
Fix 3: Verify File and Folder Permissions
Incorrect permissions or ownership often appear after manual uploads, restores or migrations. A typical safe baseline is:
These are common baselines, not permission values to apply blindly across every server. Ownership must also match the hosting account. Setting files or folders to 777 is not a proper fix and creates a serious security risk.
Fix 4: Check Cloudflare, WAF and Host Firewall Logs
If the origin site works when Cloudflare is bypassed—or the 403 appears only on admin, forms or API requests—the block may come from a managed firewall rule.
- Review Cloudflare Security Events for the exact request and rule ID.
- Check rate limiting, bot protection and custom firewall expressions.
- Ask the host for ModSecurity or WAF logs if their firewall generated the response.
- Create the narrowest possible exception rather than disabling all protection.
A browser cache can preserve an old 403 response, but it does not cause a genuine server-side denial. Clear browser, plugin, host and CDN caches only after correcting the underlying rule.
403 After a WordPress Migration
Migration-related 403 errors commonly come from copied server rules, wrong ownership, changed paths, missing index files or security tools still configured for the previous domain or server.
- Compare file ownership and permissions with the new host's requirements.
- Rebuild WordPress rewrite rules for the new server.
- Review copied hotlink, IP, country and admin-protection rules.
- Check whether the migration copied an old WAF or security-plugin configuration.
- Confirm the new host allows the affected REST API, AJAX or form request.
403 on the WordPress REST API
A REST API 403 can be legitimate when the current user lacks permission, the authentication nonce is invalid, or a firewall blocks the endpoint. Identify the exact endpoint and response before weakening security. Do not globally expose private REST endpoints simply to remove the error.
Check for Malware or Unauthorised Changes
If permissions or deny rules changed without an authorised update, scan the site. Malware can alter .htaccess, add PHP files or change access controls. Compare recent files against a known-good backup and review administrator accounts and security logs.
See the WordPress hacked warning signs and security hardening guide.
What Not to Do
- Do not use 777 permissions.
- Do not disable HTTPS sitewide to test a 403.
- Do not remove every security layer without checking logs.
- Do not delete
.htaccesswithout a backup. - Do not restore an old full database over recent orders or enquiries without assessing data loss.
- Do not assume every 403 comes from WordPress; the host or CDN may be issuing it.
Frequently Asked Questions
An admin-specific firewall rule, security plugin, IP restriction or directory rule is likely blocking access.
Yes. Security, firewall, caching and redirect plugins can introduce rules that deny admin or frontend requests after an update.
No. That exposes files to modification. Correct ownership and use the host's safe permission baseline instead.
Yes. Check Security Events for a matching request, action and rule ID before making a narrow exception.
Still Locked Out by a 403 Error?
I can trace whether WordPress, your host, file permissions or Cloudflare is denying access, restore the site safely and document the root cause.
Request WordPress 403 Repair