WordPress Sorry You Are Not Allowed to Access This Page
What Is This Error?
The “Sorry, you are not allowed to access this page” message is WordPress telling you that the currently logged-in user account doesn’t have the permission level needed to view or use a specific area of the dashboard. It’s not a glitch — it’s WordPress enforcing its built-in access control system.
You’ll most often see it when trying to open wp-admin, edit a post, install a plugin, or change site settings. The frustrating part is that it can appear even on an account you’re certain should have full administrator access.
The good news is this is almost always fixable without reinstalling WordPress. The root cause is typically a misconfigured user role, a corrupted capability entry in the database, or a plugin that’s silently stripping permissions away.
Get free WordPress & AI tips
Join 500+ readers. No spam, unsubscribe anytime.
Why Does This Happen?
- Wrong user role assigned: If your account is set to “Subscriber” or “Editor” instead of “Administrator,” WordPress will block access to admin-only areas by design.
- Corrupted capabilities in the database: WordPress stores user permissions in the wp_usermeta table. If that data gets corrupted or accidentally deleted, your account loses its access rights even if the role looks correct on screen.
- A plugin conflict: Security plugins, membership plugins, or user role managers can override or strip capabilities — sometimes silently after an update.
- WordPress multisite misconfiguration: On a multisite network, a user can be an admin on one sub-site but have no access on another, which triggers this error when switching between sites.
- Manual database edits gone wrong: If someone edited user data directly in phpMyAdmin, a typo or bad value in the capabilities field will revoke access entirely.
How to Fix It — Step by Step
-
Check the user role from a second admin account
If you have another admin account, log in with it. Go to Users → All Users, find the affected account, and check its Role column. If it shows anything other than “Administrator,” click Edit, change the role to Administrator, and save.
You should see: The role updated to “Administrator” and a green success notice at the top of the Users screen.
-
Deactivate all plugins to rule out a conflict
Go to Plugins → Installed Plugins, select all plugins, and use the Bulk Actions dropdown to deactivate them all. Try accessing the restricted page again. If it loads, reactivate plugins one by one until the error comes back — that plugin is your culprit.
You should see: The previously blocked page now loads correctly once all plugins are off.
-
Fix the capabilities value directly in phpMyAdmin
Log into your hosting control panel and open phpMyAdmin. Select your WordPress database, then browse the
wp_usermetatable. Find the row for your user ID wheremeta_keyequalswp_capabilities. Themeta_valuefield should contain exactly this:a:1:{s:13:"administrator";b:1;}If it’s empty, missing, or shows a different role, click Edit, paste in the correct value above, and save.
You should see: A success message in phpMyAdmin. Reloading wp-admin should now grant you full access.
-
Use WP-CLI to reset the user role via SSH
If you have SSH access to your server, run this command — replacing
usernamewith the actual WordPress login name:wp user set-role username administratorYou should see: Output that reads “Success: Added role.” The user now has full admin access immediately.
-
Create a fresh administrator account through the database
As a last resort, open phpMyAdmin and insert a new row into
wp_userswith a username, email, and MD5-hashed password. Then inwp_usermeta, add a row settingwp_capabilitiestoa:1:{s:13:"administrator";b:1;}and another row settingwp_user_levelto10for that new user ID. Log in with the new account.You should see: A fully working admin dashboard. You can then repair or delete the broken account from inside WordPress.
Common Mistakes When Fixing This
- Making every user an Administrator to “just fix it”: This is a real security risk. Only accounts that genuinely need full access should be administrators. Track down and fix the specific broken account instead of elevating everyone.
- Editing the database without taking a backup first: A wrong keystroke in phpMyAdmin can break your entire site. Export your database before touching it — it takes under a minute and can save you hours of recovery work.
- Resetting the password instead of the capabilities: This error has nothing to do with your password. Resetting it won’t restore access unless the capability meta value in wp_usermeta is also correct.
- Reactivating all plugins at once after isolating the conflict: If a plugin caused the issue, turning everything back on together brings the problem right back. Update the offending plugin or contact its support before reactivating it.
Frequently Asked Questions
Can this error happen to the original administrator account?
Yes. Even the very first account created during WordPress installation can lose its capabilities if the database gets corrupted, a plugin overwrites the meta value, or someone manually edits wp_usermeta incorrectly. The fix is identical — restore the correct capabilities value directly in the database.
I don’t have a second admin account. Can I fix this without logging into WordPress?
Absolutely. Use phpMyAdmin through your hosting control panel (cPanel, Plesk, etc.) to directly edit the wp_usermeta table and restore the correct capabilities value. WP-CLI over SSH is another solid option. Neither method requires being logged into WordPress at all.
Will updating WordPress automatically fix this error?
No. A core update won’t repair corrupted database entries or undo a plugin conflict. You need to address the root cause directly. If a specific plugin update triggered the problem, updating or rolling back that plugin might resolve it.
Why does this error occur specifically on WordPress multisite?
On multisite, roles are managed per sub-site rather than globally. A super admin has network-wide access, but a regular administrator only controls the sites they’re explicitly added to. If a user tries to access a site they’re not assigned to, this error appears. Fix it by going to Network Admin → Sites, selecting the relevant site, and adding the user under its Users tab with the Administrator role.