WordPress "Not Allowed to Access This Page": The Real Fix

You log into WordPress, click Dashboard, Plugins, or Users - and instead of the admin screen you were expecting, you get one blunt line: "Sorry, you are not allowed to access this page." No stack trace, no error code, nothing to Google except that exact sentence. Here's what's actually happening behind it and how to get back in.

What This Message Actually Means

This isn't a server error, a plugin crash, or a database problem in the usual sense. WordPress is running fine - it's deliberately refusing you. Every admin screen checks the logged-in user's capabilities before rendering anything, and this message is what shows up when that check fails. You're authenticated (WordPress knows who you are), but not authorized (WordPress doesn't think you're allowed to see this particular screen).

That distinction matters because it rules out a whole category of fixes. It's not a caching issue, not a corrupted install, and reinstalling WordPress core won't touch it. The problem lives in one of three places: your user account's stored permissions, a plugin actively restricting access, or a site-wide setting that's misconfigured.

Cause 1: Your Account Lost Its Administrator Role

By far the most common trigger, especially right after a migration, a database restore, or a bulk find-and-replace on the database. WordPress stores your permissions as serialized data in the wp_usermeta table, under a key called wp_capabilities (the wp_ prefix matches your site's actual table prefix, which isn't always wp_). If that row gets deleted, corrupted, or copied from the wrong environment during a migration, WordPress falls back to treating you as a subscriber - which is exactly enough access to log in, and nowhere near enough to open the Dashboard.

How to check it

Open phpMyAdmin from cPanel, select your WordPress database, and browse the wp_usermeta table (again, swap wp_ for your real prefix - check wp-config.php if you're not sure). Filter for your user_id and look for the wp_capabilities row. A healthy administrator account looks like this:

meta_key: wp_capabilities
meta_value: a:1:{s:13:"administrator";b:1;}

If it's missing, empty, or shows a role like subscriber or contributor instead, you've found it.

How to fix it

If you have SSH or Terminal access in cPanel and WP-CLI installed, this is the cleanest route - one command, no manual SQL:

wp user list --role=administrator
wp user set-role your_username administrator

No WP-CLI? Fix it directly in phpMyAdmin's SQL tab (replace the prefix and user ID with your actual values):

UPDATE wp_usermeta
SET meta_value = 'a:1:{s:13:"administrator";b:1;}'
WHERE user_id = 1 AND meta_key = 'wp_capabilities';

Log out of WordPress completely and back in after either method - the old capabilities are cached in your session cookie until you do.

Cause 2: A Security or Membership Plugin Is Blocking the Screen

Plugins like Wordfence, iThemes Security, All In One WP Security, or membership/role-management plugins (Members, User Role Editor, Restrict User Access) can lock down specific admin screens by design - and a misconfigured rule blocks the very account trying to fix it. This usually shows up right after installing or updating one of these plugins, or after someone edits role permissions and saves the wrong thing.

How to fix it

Since you can't reach the Plugins screen to deactivate anything through the UI, do it over FTP or cPanel's File Manager instead:

1. Navigate to public_html/wp-content/plugins/.
2. Rename the suspect plugin's folder - for example, wordfence to wordfence-disabled. WordPress can't find the plugin's main file and deactivates it automatically on the next load.
3. Try logging into wp-admin again. If you're back in, the renamed plugin was the cause - go into its settings and undo whatever role restriction was set before renaming the folder back.
4. If nothing changes, rename the folder back and repeat with the next suspect plugin rather than disabling everything at once.

Cause 3: Multisite - You're Not a Super Admin on This Specific Site

On a WordPress Multisite network, being an administrator on one site in the network does not automatically make you one on every site. If you manage several sites under one network and this error only shows up on one of them, check Network Admin > Users and confirm your account actually has the administrator role assigned on that specific site, not just Super Admin status on the network as a whole. The two are checked separately for most admin screens.

Cause 4: A Duplicate or Mismatched User ID After a Migration

If a site was migrated with a tool that doesn't remap user IDs properly, you can end up with your username correctly showing "Administrator" in the Users list, while the underlying wp_capabilities row is still keyed to a different, stale user_id. This is rarer but worth ruling out: in phpMyAdmin, cross-check the ID column in wp_users against the user_id in the wp_usermeta row you're editing. If they don't match what you expect, that's your answer - update the correct row rather than assuming the first one you find is the right one.

If You're Completely Locked Out (No Working Admin at All)

When every admin account on the site shows this error, skip straight to the SQL fix above for each one, or - if you'd rather not touch the database by hand - create a brand-new administrator account through phpMyAdmin by inserting rows into wp_users and wp_usermeta directly. In practice, running the UPDATE query against your existing account is faster and doesn't leave an orphaned test user behind afterward.

Prevention: Keep This From Happening Again

• Before running any find-and-replace across the database (URL changes, migrations), back up wp_usermeta and wp_users separately so you can restore just those two tables without a full-site rollback.
• Keep one WP-CLI-accessible admin account you trust. If the UI ever locks you out, wp user set-role gets you back in thirty seconds instead of an hour of database digging.
• When testing a new security or role plugin, do it in an incognito window while staying logged in on your main browser - if the rule locks out your test session, your main session is still live to undo it.
• On multisite, document which accounts have per-site administrator roles versus network-wide Super Admin status, especially when onboarding a new site manager.