“Sorry, You Are Not Allowed to Access This Page” in WordPress: How to Fix It

You log in, click Dashboard or Plugins, and WordPress throws back one flat line: “Sorry, you are not allowed to access this page.” You’re the admin. It’s your site. And WordPress is acting like you’re a stranger.

The “sorry, you are not allowed to access this page” error in WordPress is almost never a hack and almost never permanent. It’s a permissions check failing. WordPress looked at your user account, couldn’t find the capability that page requires, and refused. The fix is finding out why the capability went missing, and there are only a handful of reasons.

What Does “Sorry, You Are Not Allowed to Access This Page” Mean in WordPress?

The “sorry, you are not allowed to access this page” message means WordPress checked your user account against the capability a specific admin page requires and the check failed. WordPress stores each user’s role and capabilities in the database, so the error usually points to a missing role, a broken database entry, or a plugin page that no longer exists.

WordPress doesn’t decide access by “is this person the admin.” It decides by capabilities: manage_options, activate_plugins, edit_posts, and so on. Each role (Administrator, Editor, Author, Contributor, Subscriber) is just a bundle of those capabilities.

Those capabilities live in two places in the WordPress database:

• The wp_usermeta table, in a row with the key wp_capabilities for each user (the wp_ part matches your table prefix).
• The wp_options table, in a row named wp_user_roles that defines what each role is allowed to do.

If either of those gets renamed, corrupted, or overwritten, WordPress can’t match your account to a role, and every protected screen returns the same error. That’s why the problem so often appears right after a migration, a restore, or a security plugin “hardening” step.

Common Causes and Fixes at a Glance

The “not allowed to access this page” error in WordPress has five common causes: a deleted plugin’s admin page, a changed database table prefix, a corrupted or downgraded user role, a security plugin restriction, and a non-super-admin trying to reach a Multisite network screen. The table below matches each cause to its symptom and fix.

Cause	Typical symptom	Fix
Plugin page no longer exists	Only one bookmarked URL like admin.php?page=... fails	Go to the main Dashboard and reactivate or remove the plugin
Table prefix mismatch	Every admin screen fails right after a migration or prefix change	Rename the capability rows in usermeta and options
Corrupted or changed user role	Your account suddenly behaves like a Subscriber	Restore the Administrator role via WP-CLI or phpMyAdmin
Security plugin restriction	Error appears after enabling a hardening or lockdown setting	Disable the security plugin via FTP, then reconfigure it
Multisite permissions	Network Admin screens fail, single-site screens work	Grant Super Admin from an existing Super Admin account

Before touching anything below, take a full backup of files and database. Several of these fixes edit the database directly, and a typo in phpMyAdmin is far harder to undo than a typo in a settings screen. If you have one, a WordPress staging site is the safest place to test the fix first.

Fix 1: Check Whether the Page Still Exists

If only one admin URL triggers the error, the page probably belongs to a plugin that was deactivated, deleted, or updated with a new menu slug. WordPress shows “sorry, you are not allowed to access this page” for any admin.php?page= URL it can’t find a registered handler for, even if you’re a full Administrator.

Test it in ten seconds: go to /wp-admin/ directly, then /wp-admin/plugins.php. If both load, your account is fine. The problem is a stale bookmark or a plugin that’s no longer active. Reactivate the plugin or find its new menu location, and you’re done.

This is the most common “false alarm” version of the error, and it’s worth ruling out before you start editing database rows.

Fix 2: Repair a Table Prefix Mismatch After Migration

A table prefix mismatch happens when the $table_prefix in wp-config.php was changed, but the capability keys inside the database still use the old prefix. WordPress then looks for newprefix_capabilities, finds only wp_capabilities, and treats every user as having no role at all.

This happens a lot when changing the default wp_ prefix “for security,” or when a WordPress site migration imports the database under a different prefix than the original site used.

First, check the prefix WordPress expects. Open wp-config.php and find this line:

$table_prefix = 'abc_';

Then open phpMyAdmin and confirm the tables actually start with abc_. If they do, run this query to see which capability keys exist (replace abc_ with your prefix):

SELECT user_id, meta_key FROM abc_usermeta
WHERE meta_key LIKE '%capabilities' OR meta_key LIKE '%user_level';

If the results show wp_capabilities and wp_user_level instead of abc_capabilities and abc_user_level, that’s your problem. Rename them, along with the role definitions in the options table:

UPDATE abc_usermeta SET meta_key = 'abc_capabilities' WHERE meta_key = 'wp_capabilities';
UPDATE abc_usermeta SET meta_key = 'abc_user_level' WHERE meta_key = 'wp_user_level';
UPDATE abc_options SET option_name = 'abc_user_roles' WHERE option_name = 'wp_user_roles';

Log out, log back in, and wp-admin should behave normally. Some plugins also store prefixed keys in usermeta (dashboard widget settings, for example). Those won’t block access, but it’s worth a quick scan for any other rows still carrying the old prefix.

Fix 3: Restore Your Administrator Role

If the prefix is correct but your account still can’t reach admin screens, the Administrator role on your user has been removed or corrupted. Restoring it takes one WP-CLI command, or one edit in phpMyAdmin if your host doesn’t offer SSH.

Roles get changed for boring reasons: another admin edited the wrong user, a membership or role-editor plugin overwrote the role, or an import tool reset the user list. Sometimes it’s not boring at all, which is covered further down.

Using WP-CLI (the fast way)

If you have SSH access, WP-CLI fixes this in seconds:

# See every user and their current role
wp user list --fields=ID,user_login,roles

# Give your account the Administrator role back
wp user set-role your_username administrator

# If the Administrator role itself is broken, reset its default capabilities
wp role reset administrator

The wp role reset command matters when the role definition is damaged, not just your user. A role-editor plugin can strip capabilities like manage_options from the Administrator role itself, which locks out every admin on the site at once.

Using phpMyAdmin

Without SSH, open the usermeta table in phpMyAdmin, find the row where user_id matches your account and meta_key is yourprefix_capabilities, and set its value to exactly this:

a:1:{s:13:"administrator";b:1;}

Then set the matching yourprefix_user_level row to 10. That value is a PHP serialized array, so copy it exactly: the 13 is the character count of the word “administrator,” and changing anything breaks it.

Fix 4: Rule Out a Plugin or Theme Conflict

Security plugins, membership plugins, and role-editor plugins can all block admin pages on purpose or by accident. If the error started right after installing or updating one, disabling that plugin is the fastest way to confirm it’s the cause.

You can’t deactivate plugins from a dashboard you can’t reach, so do it over FTP or your host’s File Manager. Rename /wp-content/plugins/ to /wp-content/plugins-off/, then try wp-admin again. If it loads, rename the folder back and disable plugins one at a time until the error returns. The full process is in this guide on how to find which WordPress plugin is causing a problem.

Themes rarely cause this error, but if plugins come up clean, rename the active theme folder too. WordPress will fall back to a default theme if one is installed.

Fix 5: Check PHP Version, Debug Log, and Multisite Settings

When the first four fixes don’t solve it, the remaining causes are an outdated PHP version, a fatal error hidden behind the permission message, or Multisite network permissions. The WordPress debug log usually reveals which one it is.

Turn on logging in wp-config.php, just above the “That’s all, stop editing!” line:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Reload the failing page, then read /wp-content/debug.log. Errors mentioning a specific plugin file send you back to Fix 4. Errors about deprecated or unsupported functions point to PHP, and this guide on how to update the PHP version in WordPress covers that safely. Turn WP_DEBUG back off when you’re done.

On WordPress Multisite, regular site Administrators can’t open Network Admin screens. Only Super Admins can. If network screens fail while your own site’s dashboard works, another Super Admin needs to grant you that status from Network Admin → Users, or run wp super-admin add your_username with WP-CLI.

Is This Different From a 403 Forbidden Error?

Yes. “Sorry, you are not allowed to access this page” is generated by WordPress itself, after it loads and checks your role. A WordPress 403 Forbidden error comes from the web server or a firewall before WordPress even runs. Different layer, different fix.

When the Error Means Something Worse

Most of the time this error is a migration or plugin mistake. But if your role was downgraded and nobody on your team changed it, treat the site as possibly compromised. Attackers sometimes create their own admin account and demote the real ones.

Run wp user list or check the users table for accounts you don’t recognize, especially ones with the Administrator role. If you find any, restore access first, then follow the signs your WordPress site is hacked checklist before doing anything else.

The Takeaway

The “sorry, you are not allowed to access this page” error in WordPress is a capability check failing, not a broken site. Start with the cheapest test (does /wp-admin/ load?), then check the table prefix, then the user role, then plugins. Work in that order and the fix is usually found within the first two steps.

Frequently Asked Questions