You are logged in. The admin bar is there, your name is in the corner, and yet clicking a menu item or opening a saved bookmark gives you a plain grey page with one line on it: “Sorry, you are not allowed to access this page.”
It feels personal, especially when you are the one who owns the website. But the message is not a ban and usually not a hack. It is WordPress checking whether your account has permission for one specific screen and deciding, rightly or wrongly, that it does not. The work is figuring out which of those it is.
What WordPress is checking
Every admin screen in WordPress is tied to a capability, a named permission such as manage_options (change site settings), edit_posts, install_plugins or manage_woocommerce. Roles like Administrator, Editor and Shop Manager are simply bundles of these capabilities. Our article on how WordPress user roles work explains the bundles in more detail.
When you open an admin page, WordPress looks at two things: does this page exist right now, and does your account hold the capability it needs? If either answer is no, you get this message. Internally it is sent with a 403 status, the same “forbidden” code a server uses, but it comes from WordPress itself rather than from the server, which matters when you are deciding where to look.
Close relatives of the same message include “Sorry, you are not allowed to edit this item”, “Sorry, you are not allowed to upload files” and “Sorry, you are not allowed to manage options for this site”. They come from the same permission system, so the reasoning below applies to them too.
The likely causes, from most to least common
The page belongs to a plugin that is no longer active
Plugin settings screens live at addresses like /wp-admin/admin.php?page=some-plugin. If that plugin has been deactivated, deleted, or failed to load after an update, the page is no longer registered, and WordPress answers with the “not allowed” message rather than a “page not found”. People hit this most often from a browser bookmark or a link in an old email. Even full administrators see it in this case.
Your role doesn’t include that permission
If you log in as an Editor, Author or Shop Manager, some screens are simply out of reach by design. This is common in businesses where the developer kept the only Administrator account and gave the owner an Editor login. Membership, LMS and WooCommerce setups add their own roles, and those roles may not include what you expect.
A role editor or security plugin changed permissions
Plugins that edit roles or restrict admin areas can remove capabilities from Administrators by mistake, or by design for a “client-safe” view. Some security plugins also hide or lock certain admin pages. If the error started the day someone adjusted roles, that is the first place to look.
The database table prefix changed during a move
This one causes a total lockout and catches people out after migrations. WordPress stores each user’s roles in the usermeta table under a key named after the table prefix, for example wp_capabilities, and stores the definition of the roles in an option named wp_user_roles. If the prefix in wp-config.php is changed to xyz_ but those keys still begin with wp_, WordPress can no longer find anyone’s role. Every page in the dashboard then shows the message, even for the site owner. It is one of the usual suspects in our list of errors after moving to a new host or domain.
Multisite: site admin versus network admin
On a WordPress Multisite network, an Administrator of one site cannot open network screens such as installing plugins or themes. Those belong to the Super Admin. If you are on a network and the error appears on a plugins or themes page, check which role you actually hold.
The roles option got corrupted
Less common, but it happens: a failed update, a broken plugin or a bad database import leaves the user_roles option empty or damaged. Then roles exist in name only and grant nothing.
Working through it, gently first
Several of these checks are read-only, so start with those. Anything that touches the database comes later, and before it you need a fresh database export (from your host’s backup tool or phpMyAdmin) saved somewhere off the server. Permissions live in the database, and a mistyped edit there can lock out every user at once.
1. Look at the address bar
Does the URL contain ?page= followed by a plugin’s name? Go to Plugins → Installed Plugins and see whether that plugin is active. If it is missing or inactive, the message is expected, and reactivating or reinstalling it brings the page back. If you no longer use that plugin, update your bookmark and move on.
2. Check your own role
Open Users → Profile. If you can see Users → All Users, find your account and note the role in the list. If you can’t open the users screen at all, you probably aren’t an Administrator, and someone who is will need to change your role.
3. Ask whether anything changed recently
A new role or permissions plugin, a security plugin update, a site move, a new developer. The timing is often the quickest clue. If you have activity logs, they can show who changed a user’s role and when.
4. Deactivate role and security plugins
If you can reach the Plugins screen, deactivate any role editor, membership or security plugin and test again. If you can’t, rename that plugin’s folder inside wp-content/plugins/ through your host’s file manager. If access returns, the plugin’s settings were the cause, and you can reactivate it and fix its rules rather than leaving it off.
5. Compare the table prefix with the database
Open wp-config.php and find the line beginning $table_prefix. Then, in phpMyAdmin, check two things:
- In the
optionstable, there should be a row whose name is your prefix followed byuser_roles. - In the
usermetatable, your user should have a row named your prefix followed bycapabilities, and another followed byuser_level.
If those names start with a different prefix from the one in wp-config.php, that’s your answer. Renaming the keys to match is the fix, but it should be done carefully and only on the rows that need it. If your host gives you WP-CLI, the read-only command wp user get yourusername --field=roles shows what WordPress currently thinks your role is.
6. Repair the roles themselves
If the prefix matches but roles are empty, the roles option itself is probably damaged. Restoring that one option from a recent backup is usually cleaner than rebuilding roles by hand. Plugins that reset roles to WordPress defaults also exist, but read what they will change before using one, because custom roles from WooCommerce or a membership plugin may be wiped.
A few situations we see often
The developer left and only an Editor login remains
The owner can write blog posts but cannot install a plugin, change the menu or renew a licence key. Every settings screen answers with the “not allowed” line. Nothing is broken; the account was simply created with a limited role. If the developer is reachable, ask them to promote your account or hand over an Administrator login. If they aren’t, someone with access to the hosting account can fix the role directly, which is the moment to also review who else has admin access. Our post on taking over a website from a previous developer covers the rest of that handover.
A store manager can’t reach WooCommerce settings
The Shop Manager role that WooCommerce adds can manage products and orders but is not meant for every setting on the site. If a staff member hits the message on a plugin or payment screen, that is normally the role working as designed. Decide whether they truly need more access before handing out Administrator.
The error started straight after a migration
When every screen fails right after moving hosts, check the table prefix before anything else. It is quick to confirm and, if it is the cause, nothing else you try will help.
When it might be something worse
An Administrator losing access with no explanation, alongside a new admin user you don’t recognise or a changed admin email address, is not a permissions glitch. Attackers sometimes downgrade the real owner and create their own account. If that matches, our post on finding an admin user you didn’t create walks through what to check, and our admin access recovery service handles the lockout safely.
Stopping it happening again
- Keep at least two Administrator accounts for real people you trust, so one mistake can be fixed from the other.
- Give staff the lowest role that lets them work, and write down which custom roles exist and why.
- Don’t change the table prefix on a live site unless you rename the matching keys at the same time, ideally on staging first.
- Remove plugins cleanly and update bookmarks and team documentation when you do.
When to ask for help
If you are the owner and every dashboard screen shows this message, you’re effectively locked out of your own business site. That’s worth fixing properly rather than by trial and error inside the database. Our overview of common WordPress errors lists related access problems if this doesn’t match exactly.
For a lockout that isn’t a hack, our WordPress login problem fix is the closest match. Send a screenshot of the message and the address it appears on, and we’ll check the roles and prefix before changing anything.
Next in this series: WordPress 403 Forbidden Error: Causes and Fixes
