When WordPress says you are not allowed to access an administration page, identify the screen and its required capability before changing the user's role. A missing menu item, an obsolete URL and a real authorization denial can look similar but need different fixes.
Do not share an administrator password or give every affected user full access as a test. Keep a separate authorized administrator available while investigating, especially when editing a custom role on a production site.
Start with the exact screen and account
Record the sanitized administration URL, expected task and active account. Open the screen through its current menu instead of an old bookmark. If the plugin that owns the screen was removed or changed its menu slug, role changes will not bring that old destination back.
Check whether the same task is available to another appropriately authorized account. Compare only accounts whose access you are allowed to inspect. A visible menu item is not proof that the server accepts the action behind it.
Distinguish role names from capabilities
The WordPress capability reference describes the permissions behind roles. Plugins can define their own capabilities, and custom role names are not a reliable specification of what an account can do.
Ask the extension maintainer which capability guards the denied screen and any operation it performs. Compare that requirement with the user's effective capabilities. Do not copy an entire administrator capability set just to satisfy one check.
Missing route: Role escalation cannot restore an obsolete screen. Wrong context: Site admin is not network super admin. Positive control: Authorized task succeeds after correction. Negative control: Unrelated sensitive actions remain denied. Original explanatory guide, not a customer test result.
Check site and network context
On Multisite, confirm the user belongs to the intended site and that you are not opening a network-only screen. A site administrator and a network super administrator are different access scopes. The correct fix may be an authorized network operator performing the task, not escalating the site user.
If the denial began after migration, inspect role registration, plugin activation and environment-specific configuration. Repeatedly changing the database table prefix or replacing serialized role data from a forum example can make the problem worse. Preserve the current state and have a developer compare it with a known-good environment.
Test the smallest supported correction
Use a private staging copy and a dedicated test account. Apply the vendor-supported role assignment or capability repair, then check both the intended task and unrelated sensitive screens. The test must prove that the user can do the necessary work without gaining unwanted access.
For editorial teams, use the roles and revisions test guide to include drafts, revisions and publish actions. A successful page load does not establish that editing and publishing boundaries remain correct.
If a security plugin supplies the denial, correlate its event with the request before adding an exception. Do not globally disable authorization or a firewall just because the message mentions access.
Document and retest the result
Record the screen owner, required capability, account scope and exact correction. Test a fresh login, because an existing browser tab may show stale interface state. Retain a denied control account to verify the boundary is still enforced.
Ask for an access-control investigation when multiple plugins modify the same role. Provide the task and sanitized denial, never shared login credentials. A narrow, documented permission is easier to maintain than an unexplained permanent promotion to administrator.
Sources checked October 1, 2026. Instructions and visuals are explanatory, not claims of customer tests.