How to fix "Sorry, you are not allowed to access this page." in WordPress

WordPress shows this when the account you are logged in with lacks the capability a dashboard screen asks for. The account's role is too low, the roles in the database are damaged or stored under an old table prefix, or a plugin is in the way. Nothing on the site is lost.

By: WP Ministry
Published: October 7, 2026
Tested on: WordPress 7.1.3, PHP 8.3.35

In short

The message is about your account, not the site. Content and settings are untouched, and visitors still see the site.
Three WP-CLI commands show the account's role and the site's roles, which tells the causes apart.
After the table prefix changes, the two role keys in the database still carry the old prefix, and every administrator is refused.
Rename those keys to the new prefix. It keeps every user's role and every custom role.
When one screen alone refuses you, look at the plugins. One may be restricting it, or the screen's own plugin is switched off.

WordPress gives every account a role, and every role a list of capabilities: the things it may do. Each dashboard screen asks for one of them. When the account you are logged in with does not have it, WordPress stops and shows "Sorry, you are not allowed to access this page." in place of the screen, with the status 403.

Nothing has been lost. Your posts, pages, settings and users are where they were, and visitors still see the site. What is wrong is the record of what your account may do, or the place WordPress looks for that record.

Find out which cause you have

WordPress keeps the site's roles in one row of the options table, and each user's role in the user meta table. Both are named with the table prefix that $table_prefix sets in wp-config.php. With the default prefix, wp_, they are wp_user_roles and wp_capabilities.

With WP-CLI, three commands show what WordPress finds there. Put your own username in place of your-username.

bash

wp user get your-username --field=roles
wp user list-caps your-username
wp role list

The account's role	The list of roles	What it means
A role below `administrator`, such as `subscriber`	The usual five	The account's role was changed. Use the first fix.
Nothing	Nothing	WordPress is looking under a different prefix. Use the second fix.
`administrator`	Nothing, or a role is missing	The stored roles are damaged. Use the third fix.
`administrator`	The usual five	The role has lost a capability (third fix), a plugin is refusing the screen (fourth), or the screen is not there (fifth).

Two other faults look similar and are not this one. A page that says "Forbidden" in the web server's own words is a refusal before WordPress runs: see How to fix the 403 Forbidden error in WordPress. A login form that keeps coming back means you were never logged in: see How to fix a WordPress login page that keeps refreshing or redirecting.

Where it goes wrong

A page request passes through each of these in turn. This one comes from WordPress itself.

Browser
DNS
HTTPS
CDN or firewall
Web server
PHP
WordPress (this error comes from here)
Database and files

What causes it

The account's role does not include the screen
Common
The role was lowered, or the screen belongs to a higher role. On a multisite network, installing plugins and themes and managing users belong to the network's Super Admin, not to a site's Administrator.
Fix: Give the account its Administrator role back, or Create a new administrator
The table prefix changed and the role keys did not
Common
WordPress names the row that holds the roles, and the row that holds each user's role, with the table prefix. If the prefix changes and those names do not, it finds no roles and treats every account as having none.
Fix: Rename the role keys to match the table prefix
The stored roles are missing, or a role has lost a capability
Sometimes
Roles are kept in the database and code can change them. A capability taken from the Administrator role stays gone until something puts it back.
Fix: Put WordPress's default roles back
A plugin is refusing the screen
Sometimes
WordPress lets code change the answer each time a capability is checked, so a plugin can refuse a screen to an account whose role is complete.
Fix: Rule out a plugin
The address belongs to a plugin that is switched off
Sometimes
A screen that a plugin adds exists only while the plugin is active. Its address then gets this message, even for an administrator.
Fix: Switch the screen's plugin back on

How to fix it

Give the account its Administrator role back

Easy
Low risk
About 5 minutes
Steps tested on WordPress 7.1.3

An Administrator has access to all the administration features of a single site. Every other role is refused the screens above it. On a multisite network, installing plugins and themes and managing users belong to the network's Super Admin, so a site's Administrator is refused those screens by design. Ask whoever runs the network.

Step 1: If another administrator can log in
On the Users screen, they select the checkbox beside your account, choose Administrator in the "Change role to…" menu and select Change.

Step 2: With WP-CLI

bash

wp user set-role your-username administrator

3
Step 3: With only a database tool
Back up the database first. In the user meta table, find the row whose user_id is your account's ID (the ID column of the users table) and whose meta_key ends in capabilities. Give it the value below. This is the statement for the prefix wp_ and the ID 1.
sql
```
UPDATE wp_usermeta SET meta_value = 'a:1:{s:13:"administrator";b:1;}' WHERE user_id = 1 AND meta_key = 'wp_capabilities';
```
Step 4: Reload the dashboard
You do not need to log in again.

If the role changed and nobody on your team changed it, go through every account that can log in. How to audit a WordPress site for security weaknesses covers who should hold the Administrator role and what an account nobody can explain means.

To undo it: Set the role the account had before, the same way.

Rename the role keys to match the table prefix

Advanced
Back up first
About 20 minutes
Steps tested on WordPress 7.1.3

When a site's tables are given a new prefix and $table_prefix is changed to match, during a move for example, the rows inside the tables keep their old names. WordPress then asks for the roles under the new prefix, finds nothing, and treats every account as having no role, administrators included. Everyone can still log in. Nobody can open the dashboard.

1
Step 1: Export the database
~/ is your home folder. Keep the file out of the folder the site is served from. Without WP-CLI, use the export in your host's database tool.
bash
```
wp db export ~/before-prefix-fix.sql
```
2
Step 2: See which prefix is which
The first line is the prefix WordPress uses now: the value of $table_prefix, and the start of every table's name. The other two show the keys as they are stored. If they begin with something else, that is the old prefix and this is your cause. If they begin with the same prefix, it is not: leave them alone.
bash
```
wp db prefix
wp db query "SELECT option_name FROM $(wp db prefix)options WHERE option_name LIKE '%user_roles'"
wp db query "SELECT DISTINCT meta_key FROM $(wp db prefix)usermeta WHERE meta_key LIKE '%capabilities'"
```
3
Step 3: Write the three statements
Here new_ stands for the prefix in use and old_ for the one on the keys. Put your own in place of both.

Rename these three and no others. Not every name that begins with wp_ is built from the prefix: the option wp_page_for_privacy_policy, for one, has that name on every site.
rename-keys.sql
```
UPDATE new_options SET option_name = 'new_user_roles' WHERE option_name = 'old_user_roles';
UPDATE new_usermeta SET meta_key = 'new_capabilities' WHERE meta_key = 'old_capabilities';
UPDATE new_usermeta SET meta_key = 'new_user_level' WHERE meta_key = 'old_user_level';
```
4
Step 4: Run them
Paste them into your database tool's SQL box, or save them as rename-keys.sql in the site's folder and run:
bash
```
wp db query < rename-keys.sql
rm rename-keys.sql
```
Step 5: Reload the dashboard
The login you have still stands. If nothing changes and the site has a persistent object cache, WordPress may still be using what it stored before the change. Clear it with wp cache flush or from your host's panel.

Renaming keeps every user's role and every custom role. A move changes addresses as well: How to move WordPress from a subdirectory to the root of your domain and How to change your WordPress URL without locking yourself out cover those.

To undo it: Run the same statements with the two prefixes swapped, or restore the export.

Put WordPress's default roles back

Takes care
Back up first
About 10 minutes
Steps tested on WordPress 7.1.3

Roles and their capabilities are stored in the database, and code can add to them or take from them. A capability taken from the Administrator role stays gone after the code that took it has gone too.

1
Step 1: Reset the roles
It names each role and what it did, for example Restored 1 capability to and removed 0 capabilities from 'administrator' role.
bash
```
wp role reset --all
```
Step 2: Reload the screen that refused you
If the whole list of roles was missing, the reset writes the five default roles again. Custom roles that were in the lost list are not brought back.

To undo it: Restore the database export.

Rule out a plugin

Easy
Low risk
About 10 minutes
Steps tested on WordPress 7.1.3

WordPress lets code change the answer each time it checks a capability. A plugin that does so can refuse a screen while the account's role, and the list of capabilities WP-CLI prints for it, look complete.

1
Step 1: Switch every plugin off
Without WP-CLI, How to deactivate WordPress plugins when you are locked out of the dashboard gives the other ways, from a renamed folder to the list in the database.
bash
```
wp plugin deactivate --all
```
Step 2: Open the screen again
If it opens, a plugin was refusing it.
3
Step 3: Switch them back on one at a time
Open the screen after each one. The plugin that brings the message back is the cause. Look in its settings for a rule about who may see what.
bash
```
wp plugin activate plugin-folder-name
```

To undo it: Activate the plugins again.

Switch the screen's plugin back on

Easy
Low risk
About 5 minutes
Steps tested on WordPress 7.1.3

Look at the address. One that contains page=, such as /wp-admin/admin.php?page=example-reports, is a screen that a plugin adds. While that plugin is switched off or deleted the screen is not registered, and WordPress answers its address with this message, even for an administrator. A bookmark or an old link is enough to land on one.

1
Step 1: See which plugins are switched off
bash
```
wp plugin list --status=inactive --field=name
```
2
Step 2: Switch the one you need back on
bash
```
wp plugin activate plugin-folder-name
```
Step 3: Open the address again
If the plugin was removed on purpose, nothing is wrong. Open the dashboard from /wp-admin/ and delete the bookmark.

To undo it: Deactivate the plugin again.

Create a new administrator

Takes care
Low risk
About 10 minutes
Steps tested on WordPress 7.1.3

Use this when no account you can log in to is an administrator.

Step 1: See whether any administrator is left

bash

wp user list --role=administrator --fields=ID,user_login,user_email

2
Step 2: Create one
WP-CLI makes a password and prints it. Keep it in a password manager. In the WP-CLI command builder you choose a job, fill in what it needs, and copy the command with its flags in place.
bash
```
wp user create new-admin person@example.com --role=administrator
```
Step 3: Log in with it and put the other accounts right
On the Users screen, give each person the role they should have.

To undo it: Delete the new account.

When to get help

If the account and the roles both look right, the plugins are off and the screen still refuses you, stop editing the database by hand. A wrong value in these rows leaves every account without a role. The same goes for a role that changed when nobody changed it, where how it happened matters more than putting it back.

Common questions

Why did this start right after I moved the site?

Most likely the table prefix changed and the role keys did not. The tables carry the new prefix, but the row that holds the roles and the rows that hold each user's role still carry the old one, so WordPress finds no roles. The second fix renames them.

Is "You do not have sufficient permissions to access this page." the same error?

Yes. That was the wording in older versions: WordPress 4.5 has it at the point in the code where current versions have the new sentence. The causes and the fixes are the same.

Why does logging in take me to the home page instead of the dashboard?

After a login, WordPress sends an account that cannot edit posts to its profile, and an account that cannot even read to the site's home page. Landing on the home page with the right password means the account has no capabilities at all. That points to the prefix (second fix) or to missing roles (third fix).

In short

Find out which cause you have

Where it goes wrong

What causes it

The account's role does not include the screen

The table prefix changed and the role keys did not

The stored roles are missing, or a role has lost a capability

A plugin is refusing the screen

The address belongs to a plugin that is switched off

How to fix it

Step 1: If another administrator can log in

Step 2: With WP-CLI

Step 3: With only a database tool

Step 4: Reload the dashboard

Step 1: Export the database

Step 2: See which prefix is which

Step 3: Write the three statements

Step 4: Run them

Step 5: Reload the dashboard

Step 1: Reset the roles

Step 2: Reload the screen that refused you

Step 1: Switch every plugin off

Step 2: Open the screen again

Step 3: Switch them back on one at a time

Step 1: See which plugins are switched off

Step 2: Switch the one you need back on

Step 3: Open the address again

Step 1: See whether any administrator is left

Step 2: Create one

Step 3: Log in with it and put the other accounts right

When to get help

Common questions

More on this subject

Would you rather we fixed it?