A 403 on wp-admin says a request was refused. It does not identify the rule or prove that your password is wrong. Find which layer produced the response before changing permissions, deleting security settings, or repeatedly attempting login.
Capture one refusal you can trace
Record the exact URL, method, time with timezone, browser action, and any request or incident ID on the error page. Note whether wp-login.php loads, whether the refusal happens before or after authentication, and whether only a particular save action fails. Do not paste session cookies, login passwords, or a full authenticated request into a support ticket.
A branded block page is a clue, not definitive attribution. Response headers and corresponding provider logs are stronger evidence. An edge firewall can refuse a request before WordPress records anything. An empty WordPress log therefore does not establish that the request was allowed.
Use a layer-by-layer decision
| Observation |
First place to investigate |
Avoid |
| Provider request ID on a block page |
Matching CDN or WAF event |
Disabling the firewall globally |
| Only your network is refused |
IP, country, rate-limit, or allowlist rule |
Repeated login attempts that extend a block |
| Admin opens but saving fails |
Rule matching that specific request |
Removing protection from all POST requests |
| Refusal after a hosting move |
Server access rules and filesystem ownership |
Recursive permission changes without a baseline |
If authorized, compare a trusted alternate connection once. A different result helps locate a network-sensitive rule; it does not justify bypassing an intentional access policy. For broader authentication symptoms, follow the WordPress admin lockout guide.
Explanatory worksheet for your own test evidence. No customer results are represented.
Correct the responsible rule narrowly
Ask the host or security administrator to match your timestamp and request ID to the decision log. A useful answer names the layer, rule identifier, reason, and scope. For a false positive, prefer a route- and rule-specific exception with an owner and review date. Verify it does not allow unrelated dangerous requests.
If WordPress's security plugin made the decision, use its supported unlock or recovery method. Maintain host-console or SFTP access before changing authentication controls. Avoid removing an entire security plugin merely because its name appears somewhere in the stack.
For filesystem issues, compare ownership and access settings with the host's known-good configuration. WordPress hardening guidance describes restricting file permissions and access. There is no universal permission command that repairs every hosting arrangement. Setting everything to 777 creates a new problem rather than identifying the old one.
Distinguish a missing login route
Some sites intentionally change or restrict their login path. Check the site's documented administration route with its owner. Guessing hidden URLs, broadly allowing wp-admin, or altering rewrite rules can undo that policy. A 403 on a directory listing also differs from a denied request to a real PHP endpoint.
If a request returns 200 but displays an error message, record both facts. Do not classify it as an HTTP 403 based only on text in the browser. Likewise, cached block responses may outlive a repaired rule; test the precise route after a targeted purge when the provider confirms caching is involved.
Finish with access and protection checks
Sign in as the intended administrator, open the affected screen, and complete the formerly blocked action using harmless test content. Confirm an unauthenticated visitor still cannot reach restricted functions. Remove temporary allowlist entries and document what changed.
When nobody can identify the refusing layer, request a scoped WordPress access repair with the sanitized request evidence. The acceptance condition is restored legitimate access with the security boundary still working, not simply a page that loads after all controls are switched off.
References checked September 25, 2026. Illustrations and examples are explanatory, not customer case studies.