Sorry, You Are Not Allowed to Access This Page

What the message really means

The first thing to understand is who is speaking. Sorry, you are not allowed to access this page is a message WordPress prints itself, in its own plain error style, when a request reaches an admin page and fails a capability check. WordPress runs a permission test for the action you are trying to take, the test returns no, and WordPress stops the request with this sentence. That tells you something useful right away. WordPress loaded. PHP ran. The database answered. The site got all the way to a working permission check before deciding you were not allowed. The platform is healthy. The thing that is wrong is the answer to one question: does this user have the capability this page requires.

In WordPress, what you can do is governed by roles and capabilities. An administrator role carries the capabilities that unlock wp-admin, and those capabilities are stored in the database against your user. When the message appears for someone who should be an administrator, it means WordPress could not confirm you hold the capability, almost always because it could not find your role where it expected it, or because something rewrote your role to remove it. That is why the fixes all circle the same few places: the stored role, the prefix WordPress uses to locate that role, and any plugin that intercepts the capability check.

Because the failure is a capability decision rather than a server refusal, you do not fix it by touching files permissions or server rules. You fix it by correcting what WordPress knows about you, and you do that from outside the dashboard, since the dashboard is exactly what is locked. The rest of this page works through the handful of reasons WordPress loses track of your role, how to tell this apart from a server 403 that uses similar words, and the concrete ways to get back in.

WordPress message vs server 403

This is the single distinction that saves you from fixing the wrong layer, and most guides skip it. Two different things can stop you from reaching wp-admin, and they look superficially similar but have nothing in common under the hood.

If you are not sure which you have, look at the styling and the exact words. WordPress writes the full apologetic sentence in its own simple error page. A server 403 usually just says Forbidden or 403 and looks like a host error. The rest of this page is about the WordPress capability message. If yours is a server 403, the section below on restoring .htaccess and permissions is your starting point instead.

Which symptom matches yours

Find the row that matches what you see and when it started. Each one points to a specific cause and fix.

The six root causes

Once you have confirmed it is the WordPress message and not a server 403, the lockout is almost always one of these six.

The table-prefix trap

This is the cause that catches the most people, often right after a security tweak, so it is worth understanding even if you never touch the database. WordPress stores your role in a clever but fragile way. In the usermeta table, your capabilities are saved under a meta key that is built from the table prefix, so on a default install the key is literally wp_capabilities, and your user level under wp_user_level. The list of roles itself lives in the options table under wp_user_roles. The prefix is baked into all three names.

Now change the prefix and the trap springs. A common piece of security advice is to change the default wp_ prefix to something custom, and several security plugins offer a one-click tool to do it. The tool renames the tables and updates $table_prefix in wp-config.php, but if it does not also rename the prefixed meta keys and the option name, WordPress now looks for newprefix_capabilities and finds only the old wp_capabilities. Your role becomes invisible, your capabilities read as none, and every administrator is locked out with this message. The same thing happens after a migration where the prefix in the config and the prefix in the data drift apart.

DIY vs hand it off

A single clear cause with hosting access is a reasonable self-fix. Editing the capabilities row by hand, or several issues at once, is where handing it off saves time and risk. If the left column matches you can likely do this. If the right column matches, get help.

How to diagnose it

Work in this order. The first step decides which half of the problem you have.

How to fix it

Each branch stands alone. Pick the one your diagnosis pointed to. Back up the database before any SQL, and replace wp_ with your real table prefix in every query.

// In wp-config.php, set this to match your real table names
$table_prefix = 'wp_'; // e.g. 'xyz_' if your tables are xyz_posts, xyz_options

UPDATE xyz_usermeta SET meta_key = 'xyz_capabilities'
  WHERE meta_key = 'wp_capabilities';

UPDATE xyz_usermeta SET meta_key = 'xyz_user_level'
  WHERE meta_key = 'wp_user_level';

UPDATE xyz_options SET option_name = 'xyz_user_roles'
  WHERE option_name = 'wp_user_roles';

-- Find your user ID
SELECT ID, user_login FROM wp_users;

-- Restore the administrator role (replace 1 with your ID)
UPDATE wp_usermeta
  SET meta_value = 'a:1:{s:13:"administrator";b:1;}'
  WHERE user_id = 1 AND meta_key = 'wp_capabilities';

UPDATE wp_usermeta
  SET meta_value = '10'
  WHERE user_id = 1 AND meta_key = 'wp_user_level';

# Create a brand new administrator
wp user create rescue [email protected] --role=administrator --user_pass=StrongPasswordHere

# Or promote an existing user (replace 2 with their ID or login)
wp user set-role 2 administrator

# Over SFTP: rename the folder to deactivate every plugin at once
wp-content/plugins  ->  wp-content/plugins_off

# Or with WP-CLI
wp plugin deactivate --all

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

A real lockout-recovery session

A composite from the admin-lockout repairs we run most weeks, with identifying details removed.

WordPress admin lockout FAQ

Sources and further reading

Every technical claim on this page traces back to the WordPress documentation, the WordPress developer reference, the WP-CLI documentation, or the named host reference.

• WordPress: Roles and Capabilities
• WordPress Developer: wp-config.php and the table prefix
• WP-CLI: wp user create (and wp user set-role)
• WordPress Developer: the user_has_cap capability filter
• Liquid Web: changing the WordPress table prefix (usermeta and options SQL)