A 403 Forbidden response means an access-control layer rejected your request to /wp-admin/. The blocker may be WordPress’s account and role checks, file ownership or permissions, Apache/Nginx rules such as .htaccess, a security plugin or WAF, host authentication policy, or a damaged installation. The browser message alone cannot identify which layer refused access.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
Work through the checks below in order. Start with a backup and the host error log, make only reversible changes, and ask your hosting provider to inspect server policy when the denial is not explained by WordPress settings.
As an Amazon Associate I earn from qualifying purchases.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsWhat a 403 on wp-admin actually means
HTTP status 403 means the server understood the request but refused to authorize it. It is different from a 404 (not found) and from a 500 (server-side failure). A 403 can be generated before WordPress loads, while WordPress is deciding whether your account may view a dashboard page, or by a firewall inspecting the request.
That is why valid credentials do not rule out a 403. An IP restriction in .htaccess, directory authentication, an ownership mismatch, ModSecurity, or a host-level policy can reject /wp-admin/ even when the username and password are correct. WordPress’s installation and hardening documentation lists server permissions, filesystem restrictions, security-policy denials, and .htaccess IP rules among possible causes.
Before changing anything: preserve evidence and narrow the scope
- Make a backup. Save the database and the site files, including the root
.htaccess,wp-config.php, andwp-content. If your host provides snapshots, take one before editing rules or permissions. - Record the exact request. Note the full URL, time, browser, your public IP address, and whether the response is a plain server page, a WordPress-styled page, or a branded firewall page. Save a screenshot and any request ID shown.
- Test the boundaries. Open the public homepage,
/wp-login.php, and/wp-admin/in a private browser window. Ask another trusted connection to test, if possible. A public site that works while only/wp-admin/returns 403 points toward a directory rule, authentication policy, role check, or administrative security control. - Do not repeatedly guess passwords. Login attempts can trigger rate limits or IP bans, making a security rule look like a permissions problem.
Step 1: confirm the account, role, and requested page
If the response is a WordPress message such as “You do not have permission to access this page,” confirm that you are signed in to the intended site and account. WordPress.com’s access guidance specifically recommends checking the signed-in account, plan, assigned role, and permissions. On a self-hosted site, verify that the user has the administrator role and that a membership or capability plugin has not removed the required capability.
Check for an account mix-up
- Sign out, clear the site’s cookies, and sign back in at the site’s own
/wp-login.phpaddress rather than through a saved dashboard bookmark. - Check the browser address bar for the correct domain, subdomain, and scheme (HTTP versus HTTPS). A bookmark to a staging or old domain can lead to a different WordPress installation.
- Try a second administrator account only if you already have one and can do so safely. Do not create or elevate an account while access controls are still unexplained.
Distinguish a page-capability error from a directory denial
If /wp-login.php loads and authentication succeeds but every dashboard URL receives a server-generated 403, the web server or a security layer is more likely than a WordPress role check. If the dashboard shell loads but one settings page is denied, inspect role and capability changes, membership plugins, and the specific page’s URL.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Step 2: read the host error log before editing files
Ask your host for the web-server error entry at the exact time of the failed request, or open the control panel’s Apache/Nginx error log if you have access. Useful phrases include authz, “directory index forbidden,” “client denied,” “permission denied,” ModSecurity, a rule ID, SELinux denial, or an authentication-provider failure.
The log tells you which layer rejected the request. A filesystem “permission denied” entry calls for ownership or mode checks; an authz or IP-deny entry points to server rules; a ModSecurity rule ID points to a WAF false positive. A clean WordPress PHP log with no corresponding web-server entry can indicate that the request never reached PHP.
What to give support
- The exact URL and UTC/local time of the 403.
- Your public IP address and whether another network receives the same response.
- The response headers or request ID, if displayed.
- Whether the public site and
/wp-login.phpwork. - Any changes immediately before the problem: plugin update, host migration, SSL change, firewall rule, or account move.
Step 3: inspect .htaccess and other server rules safely
On Apache hosting, the root .htaccess can deny an IP range, require authentication, or contain a malformed directive. WordPress normally writes rewrite rules to the root file; it does not normally create a second .htaccess inside wp-admin. An extra file in that directory may have been added by a security tool or host policy.
Make a reversible test
- Use SFTP, SSH, or the host file manager to download the root
.htaccess. - Rename it to a dated backup such as
.htaccess.before-403. Renaming, rather than deleting, preserves the evidence. - Test the public site and
/wp-admin/. If the 403 disappears, compare the backup forDeny,Require, IP allow/deny lists, basic-auth directives, or accidental syntax. - Regenerate standard WordPress rewrite rules only after access returns: in the dashboard, visit Settings → Permalinks and select Save Changes without changing the structure. If you cannot reach the dashboard, have the host validate the file and Apache configuration.
Do not copy a generic .htaccess from another site. Custom caching, authentication, multisite, and host directives may be required. If the host uses Nginx, .htaccess is not read; the equivalent location, deny, and authentication rules live in the Nginx configuration and must be checked by the provider.
Step 4: verify ownership, permissions, and security policy
WordPress files must be readable by the web-server/PHP process, while write access should be limited to what the hosting arrangement requires. WordPress hardening guidance gives common examples of mode 755 for directories and 644 for files. Those values are examples, not a universal repair: the correct owner, group, PHP handler, and SELinux context depend on the host.
Typical diagnostic commands
After taking a backup and confirming the site path, an administrator can inspect modes and owners with:
Rank #3
ls -ld /path/to/site /path/to/site/wp-admin
find /path/to/site/wp-admin -maxdepth 2 -printf '%M %u:%g %pn' | headWordPress’s hardening examples use these patterns for ordinary files and directories:
find /path/to/site -type d -exec chmod 755 {} ;
find /path/to/site -type f -exec chmod 644 {} ;Do not run those commands blindly on a managed, multisite, or security-hardened installation. First confirm the provider’s documented owner and group. A PHP process that runs as a separate account may need group access, and an SELinux policy can deny an operation even when Unix mode bits look correct. As WordPress documentation notes, actions denied by security policy are often difficult to distinguish from ordinary file-permission errors.
Common permission mistakes
- The
wp-admindirectory is owned byrootafter a migration, while the site’s PHP account is different. - A deployment changed directories to
700or files to600, blocking the web-server process. - The directory is readable, but a parent directory lacks execute permission, so the server cannot traverse the path.
- SELinux labels or a host security context were lost during an archive restore.
Correct ownership through the host’s control panel or support team when possible. Changing ownership to a guessed username, or making the entire installation world-writable, can create a security problem and still fail to fix the denial.
Step 5: isolate plugins without wp-admin
A plugin can deny administrator requests, add an IP restriction, or trigger a firewall rule. WordPress’s common-errors guidance recommends deactivating all plugins to test whether a plugin is responsible. You can do that without dashboard access.
Using SFTP or the host file manager
- Open the site’s
wp-contentdirectory. - Rename
pluginstoplugins.off. This prevents WordPress from loading the installed plugins because the expected directory is absent. - Test
/wp-admin/and/wp-login.php. - If access returns, rename
plugins.offback toplugins. WordPress will mark the plugins inactive; restore them one at a time and test after each activation.
Using SSH and WP-CLI
If WP-CLI is installed and can bootstrap the site, list plugins first:
wp plugin list --status=activeTo deactivate all plugins from the site directory:
wp plugin deactivate --allIf WP-CLI itself cannot load because a plugin crashes early, use the directory rename method. Do not delete plugin folders until you have a backup and have identified the offending component. A plugin that blocks only one IP or URL may require reviewing its settings or allowlist rather than permanent removal.
Free tools Windows power users keep installed
One-click scans. No signup required.
Step 6: review security-plugin and WAF events
Security plugins and web-application firewalls are designed to refuse suspicious requests, so they can be both the protection and the source of a false-positive 403. ModSecurity is a commonly deployed open-source WAF. Its event should include a rule ID, request details, and sometimes the matched parameter.
Use the event, not guesswork
- Open the security plugin’s activity or firewall log through its own interface, database tools, or host panel.
- Match the event time, URL, source IP, and rule ID to your failed request.
- Determine whether the request was an administrator login, an AJAX call, a REST request, or a media/upload operation. A broad allow rule can expose more than the failing action needs.
- Allow only the minimum legitimate request, IP, or rule exception. Keep the original rule and document the change.
Do not permanently disable a firewall simply because the dashboard is inaccessible. If you must temporarily disable a control to recover access, do so through the provider’s documented emergency procedure, restrict access by a trusted network where possible, and restore protection immediately after identifying the false positive.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Step 7: ask the host to check policies you cannot see
Some denials exist outside the account’s files. Request a review of:
- Apache
Require/authzdirectives, Nginx location rules, and directory authentication. - ModSecurity or another WAF’s event and rule ID.
- Filesystem owner/group, parent-directory traversal, and PHP-FPM or web-server user.
- SELinux or another mandatory-access-control denial.
- Recent account moves, IP bans, malware rules, or changes to the hosting security policy.
- Whether
mod_rewriteis enabled on Apache and whether the Nginx equivalent is correctly configured.
WordPress’s installation FAQ recommends host support when visible settings appear correct. Provide the evidence collected in the earlier steps instead of asking support to “fix WordPress” without a timestamp; that lets them search the right log line.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutePC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Step 8: consider a damaged or compromised installation
If the block remains after plugin isolation, .htaccess review, permission checks, and host-policy inspection, treat repeated or unexplained denials as a possible compromise. WordPress’s common-errors guidance notes that a site may have been hacked after those checks.
- Preserve server, WAF, and login logs before rotating or deleting files.
- From a trusted computer, change hosting, database, SSH/SFTP, and administrator credentials; use unique passwords and multifactor authentication where available.
- Compare core files with a known-clean copy of the same WordPress version. Do not overwrite
wp-contentorwp-config.phpwithout a recovery plan. - Scan the files and database using a reputable security process, or engage qualified incident-response help when payment, personal, or account data may be exposed.
- Restore from a known-clean backup if integrity cannot be established, then update WordPress, themes, and plugins before reopening access.
A recurring 403 that moves between accounts or IP addresses, unexplained administrator accounts, modified core files, or new server rules are stronger compromise indicators than a single block immediately after a plugin update.
Choose the least risky remedy
| Remedy | Where the denial occurs | Access needed | Reversible? | Security trade-off |
|---|---|---|---|---|
| Confirm account and role | WordPress authorization | Login or another administrator | Yes | Low; changing roles without evidence can overgrant access |
| Rename the plugins directory | Plugin or plugin firewall | SFTP, SSH, or file manager | Yes | Plugins are inactive while testing; protection may be reduced briefly |
Back up and rename .htaccess |
Apache rewrite, IP, or auth rule | SFTP, SSH, or file manager | Yes | Custom redirects and restrictions may stop until rules are restored |
| Correct owner/mode | Filesystem or PHP access | Provider-approved shell or control panel | Usually, if recorded first | Overly broad write permissions increase exposure |
| Adjust one WAF rule | Security plugin or host WAF | Firewall log or host support | Yes, if documented | A broad exception can let malicious requests through |
| Host-policy review | Server, SELinux, or account policy | Host support and logs | Depends on provider | Changing policy without understanding scope can affect every site on the account |
Common mistakes that make a 403 worse
- Making everything 777: This grants unnecessary write access and does not fix an SELinux, WAF, or IP-deny rule.
- Deleting
.htaccessor plugin folders: Deletion destroys evidence and makes rollback harder. Rename and preserve backups instead. - Disabling every security control indefinitely: Use a narrow, time-limited exception tied to a logged event.
- Regenerating permalinks repeatedly: That changes rewrite rules but cannot fix ownership, host authentication, or a firewall block.
- Assuming a login failure is a role problem: A server-generated 403 can occur before WordPress sees the account.
- Ignoring a provider migration: Ownership, PHP-FPM users, SELinux labels, and Nginx rules often change during a move.
Prevent the next wp-admin denial
- Keep dated backups of
.htaccess, configuration, and the database before updates or migrations. - Record which account owns the files and which user runs PHP; retain the host’s approved permission guidance.
- Monitor WAF and security-plugin logs so a blocked administrator IP can be distinguished from a credential attack.
- Use a separate staging test for plugin and firewall changes, and make one change at a time in production.
- Limit administrator accounts, remove unused users, and use multifactor authentication.
- Keep WordPress core, themes, plugins, PHP, and the host operating system supported and updated.
When to stop troubleshooting and escalate
Contact the host immediately when the public site is also unavailable, the error log shows SELinux or account-policy denials, you lack SFTP or log access, or a change to permissions could affect other sites. Escalate to a security professional when logs show unauthorized changes, malware indicators, repeated rule manipulation, or possible exposure of sensitive data. A precise timestamp, URL, source IP, response body, and list of reversible tests will shorten both support and incident-response time.
Sources and terminology
The guidance here follows the WordPress Developer Resources Advanced Administration Handbook sections on hardening, file permissions, installation troubleshooting, and common errors, plus WordPress.com’s account-access guidance. Those references distinguish ordinary Unix permissions from mandatory security policy and recommend plugin deactivation and host support when local checks do not explain the refusal.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
