When WordPress shows “Sorry, you are not allowed to access this page” after you sign in, a capability check failed for that Admin screen or action. You may still reach the dashboard, or only some menus. That is different from being unable to log in at all, and different from a one-off security-check / nonce screen. The cause is often a role, capability, or table-prefix mismatch after a migration or plugin change, not automatically a hack.
Work this checklist in order. Prefer staging when you can reproduce the denied screen there. Take a backup before editing the database, roles, or wp-config.php on production. If you cannot complete login, start with admin login not working. If you see “Are you sure you want to do this?” on a form submit, use are you sure you want to do this. If one covered WordPress issue is clearly to blame and you want help, use the $99 one-time fix. We confirm the scope before work begins.
Define what failed
- Confirm you can sign in, then hit the message on a specific Admin URL or menu (Plugins, Settings, a plugin screen), not on every public page.
- Note when it started: after a migration, table-prefix change, role-manager change, plugin update, or multisite move.
- If login itself fails (loop, rejected password, blank login), use admin login not working first.
- If unknown admin users appeared, the admin email changed without your action, or you see other compromise signs, pause this checklist and use site hacked / malware cleanup.
Quick triage map
| What you observe | Likely layer | First useful check |
|---|
| Denied after migration or DB prefix change | Prefix / usermeta mismatch | Ask the host to compare config, table names, and role keys for the affected site |
| Second known-good admin works; your account does not | Your role or capabilities | Inspect that user’s role in the database or host tools |
| Started after a role or membership plugin change | Plugin capability gates | Staging isolation; see also plugin not working |
| Multisite: site Admin works; network screens denied | Site admin vs super admin | Confirm which role the account has on that network |
| Unknown admins, changed admin email, odd redirects | Possible compromise | Malware cleanup checklist |
Safe diagnostic order
- Confirm login works and isolate the denied screen. Sign in, open the dashboard if you can, and note the exact Admin URL that shows the message. Retry once from a fresh session so you are not chasing a stale cookie alone.
- Control test with a second administrator. If you have another trusted admin account (or the host can create a temporary one on staging), try the same screen. If the second admin can open it, focus on the first account’s role and capabilities. If every admin is denied the same screen, look at plugins, prefix, or multisite role next.
- Check table prefix after a migration. In
wp-config.php, note $table_prefix. In the database (host panel or a trusted tool), check that capability-related rows match that prefix: the options row that stores roles (often {prefix}user_roles) and usermeta keys such as {prefix}capabilities and {prefix}user_level. On multisite, these keys use the affected site’s prefix, which can include a site number such as wp_2_; ask your host to identify the correct site before changing anything. A restored database with an old prefix while wp-config.php uses a new one commonly produces this screen. Ask your host before renaming rows; back up first.
- Confirm the intended role before restoring access. Ask the site owner to confirm which screens this account should access. A denied page may be correct for its role. If a migration or plugin change removed previously authorized administrator access, have your host or an authorized administrator restore that role using supported WordPress tools. Avoid copying SQL from search results. Retest the denied screen after the repair.
- Isolate capability-related plugins on staging. Security, membership, role-manager, and “hide admin” plugins can remove or gate capabilities. On staging, note active plugins, temporarily disable the newest relevant one for a short test, retest the screen, then restore protection. See plugin not working when isolation points at one product.
- On multisite, confirm site admin versus super admin. A user can administer one site and still be denied network Admin screens. Check the account’s role on that site and whether super-admin is required for the URL you need.
- Retest with durable fixes kept. Restore any security plugins temporarily changed for testing. Keep prefix or role corrections that fixed access. Open the original denied screen and a second normal Admin task, and confirm both work.
Common causes
- Table prefix mismatch after migration (config prefix vs roles / usermeta keys).
- Administrator role removed or capabilities corrupted (interrupted update, role plugin).
- Plugin or theme capability checks denying a screen you used to open.
- Multisite confusion between site administrator and super admin.
- Compromise that changed roles or admin accounts (treat as a security event).
When a $99 one-time fix fits
Request the $99 one-time WordPress fix if you want help on one WordPress site clearing a repeatable “Sorry, you are not allowed to access this page” after login: confirming role or prefix mismatch, coordinating a host-approved role or prefix repair, and verifying the denied Admin screen opens again. Paste the exact Admin URL, when it started, and the last migration or plugin change. We confirm the scope before work begins. Send credentials only through the private access link provided after your request is accepted.
Full rebuilds, custom role systems, network-wide multisite redesigns, and active malware cleanup are outside this offer. Use site hacked / malware cleanup when compromise signs are present, admin login not working when you cannot authenticate, and are you sure you want to do this for nonce / security-check screens on form submit.
Related checks
If a second admin, host-confirmed prefix or role repair, and staging plugin isolation still leave the denied screen, send your host the exact Admin URL, the start time, your $table_prefix value, and whether any unknown admins appeared. Suspected compromise needs a security investigation as well as restoring the right capabilities.