“Sorry, you are not allowed to access this page.” means WordPress knows who you are, but thinks your account doesn’t have permission for that screen. Either the page needs a capability your role lacks, or WordPress can’t read your role at all.
The second case is common after a migration, and it can lock even the site owner out of the whole dashboard. Work out which situation you are in first.
Start here: one page or the whole dashboard?
- Only one screen (a plugin’s settings page, a bookmarked URL): it’s probably a missing capability or a deactivated plugin. See the next two sections.
- All of wp-admin right after logging in: your account has lost its role, or WordPress can’t read roles at all. Skip to the role and migration sections.
- Only on one site in a multisite network: jump to the multisite section.
Cause 1: the page belongs to a deactivated plugin
Plugin settings pages live at URLs like /wp-admin/admin.php?page=some-plugin. If that plugin is deactivated, deleted, or failed to load, the page no longer exists and WordPress shows this message instead of a 404.
Check Plugins → Installed Plugins and make sure the plugin is active. If it was just updated, it may have moved its settings under a new menu, so look for it in the sidebar rather than using an old bookmark. If a plugin fails to load because of a PHP error, check the error log.
Cause 2: your role doesn’t have the capability
Every admin screen requires a capability such as manage_options or edit_theme_options. Editors and Authors simply don’t have most of them, so this message is expected if you aren’t an Administrator.
If you should be an Administrator, check Users → Profile or ask another admin to look at your account under Users → All Users. Role editor plugins can remove capabilities from the Administrator role itself, so if you use one, check what it changed. Security plugins that hide or restrict admin screens can cause the same symptom; deactivating them is a quick test.
Cause 3: your account lost its role
If no admin can get in, fix the role from outside WordPress. With WP-CLI this is quick:
wp user list --fields=ID,user_login,roles
wp user set-role 1 administrator
Replace 1 with your user ID. If the roles column is empty for everyone, the role definitions themselves are missing or broken. This restores the default WordPress roles and their capabilities:
wp role reset --all
Be aware that this also undoes any custom capability changes made by role editor plugins. Take a backup of the database first.
Without WP-CLI, open phpMyAdmin, go to the wp_usermeta table, and find the row where user_id is your ID and meta_key is wp_capabilities. Its meta_value for an administrator should be exactly:
a:1:{s:13:"administrator";b:1;}
This is serialized data, so copy it exactly. The 13 is the length of the word “administrator”.
Cause 4: a table prefix mismatch after a migration
This is the one that catches people out. WordPress stores roles under keys that include the database table prefix. With the default prefix wp_, those keys are:
wp_capabilitiesandwp_user_levelin theusermetatable (one per user).wp_user_rolesin theoptionstable (the role definitions).
If a migration renamed the tables to a new prefix, say abc_, and updated $table_prefix in wp-config.php, but didn’t rename those keys, WordPress looks for abc_capabilities and finds nothing. Every user loses their role and the dashboard says you aren’t allowed in.
Check the prefix in wp-config.php:
$table_prefix = 'abc_';
Then, in phpMyAdmin, look at abc_usermeta and abc_options. If you see keys starting with the old prefix, rename them. Back up the database first, then run this in the SQL tab, swapping in your real old and new prefixes:
UPDATE abc_usermeta
SET meta_key = CONCAT('abc_', SUBSTRING(meta_key, 4))
WHERE meta_key LIKE 'wp\_%';
UPDATE abc_options
SET option_name = 'abc_user_roles'
WHERE option_name = 'wp_user_roles';
The 4 is the length of the old prefix plus one. If your old prefix was wp_ (3 characters), use 4; for a 6-character prefix, use 7. The \_ makes the underscore literal, so only keys that really start with the old prefix change. Look through the matching rows before you run the update, because some plugins store unrelated keys that happen to start with wp_.
Log out, clear your browser cookies for the site, and log back in. Our migration service handles this as part of every move.
Cause 5: multisite permissions
On a multisite network, a user only has a role on the sites they’ve been added to. Logging into a subsite’s /wp-admin/ where you aren’t a member gives this exact message.
- Network-level screens under My Sites → Network Admin require Super Admin. Being an Administrator of one site isn’t enough.
- Each subsite stores roles under its own key, such as
wp_2_capabilitiesfor site 2. A prefix mismatch after migration affects these too. - A Super Admin can add a user to a site under Network Admin → Sites → Edit → Users.
To grant Super Admin from the command line:
wp super-admin add yourusername
Still stuck?
If you’re locked out of your own site, our $79 one-time fix restores admin access and repairs the roles, usually within 24 hours, fixed or your money back. If it happened after a move, we’ll check the rest of the migration while we’re in there.