You want to restrict admin access on WordPress, but your collaborator only needs part of what an administrator can do. Handing them a full administrator account feels like giving them the keys to the whole house. You want a narrower option, one that keeps the site running and the right people out of the wrong places. That worry is fair, and it’s very solvable.
Restricting permissions is one part of securing your WordPress admin; protecting the accounts that retain access matters too.
Most people reach for a plugin, an IP rule, or a redirect first. Those tools help, but they work best after you’ve picked the right permission. Skip that step, and a hidden menu can feel like security while the account still does far more than it should.
By the end, you’ll match each person to the smallest safe permission, test what they can actually do, and know how to undo a mistake. We cover four standard methods, from the simplest to the most demanding, along with the checks we run on a WordPress 6.9.4 test site.
TL;DR: Start with the smallest role that fits each person’s job, then test what they can actually do. First action: Open Users, edit the account, choose the role that matches the work, save it, and check the task.
Which method should you use?
Start with roles. Most team members need a standard set of permissions, and a role is the easiest change to undo. Move to a plugin, an IP rule, or custom code only when a role can’t express what you need. We list the methods from least to most stringent, because each step up gives tighter control and more ways to lock yourself out.
- Roles: The right choice for most team members who need standard content or profile access.
- A dashboard plugin: The right choice when someone should stay out of the dashboard entirely, or land on a different page.
- An IP allowlist: The right choice for a private office or trusted VPN with predictable addresses.
- Custom code: The right choice for a developer who’s comfortable with PHP and wants a narrow rule.
📝 Note: Write down the one action each account needs before you pick a method. That single sentence keeps convenience from quietly turning into permanent administrator access.
Start with the smallest role that works
A role is a bundle of capabilities, and a capability is one specific permission, such as publishing a post or managing users. Thinking in capabilities helps you match the role to the job rather than to a job title. For someone who should only manage their own profile, choose Subscriber. It’s the strictest standard role, and its dashboard only lets people change their own profile.
Editors can publish and manage other people’s posts. Authors can publish their own. Contributors can write drafts, but an editor or administrator has to approve them before they go live. A writer who submits drafts usually needs less access than a content manager who publishes everyone’s work, so the role should follow the workflow.
To change a role, open Users in the left menu. Click Edit on an existing account, or Add New for a new one. Find the Role dropdown, choose the role, then click Update User or Add New User. You’ll need to be an administrator to make these changes.
On a WordPress 6.9.4 test site, an editor could sign in and reach the dashboard. The editor saw a new-post link but no Users menu. A subscriber also reached the dashboard, but only profile access appeared. The same address loaded for both accounts, yet their actions were very different.
📝 Note: Being able to open /wp-admin/ doesn’t prove the role is working. Check what the account can do once it’s inside, because that’s the part that matters.
Block the dashboard with a plugin
If a genuine team member gets locked out of WordPress, check their permissions first. Sometimes a role isn’t enough, and the person should stay out of the dashboard altogether. We use Remove Dashboard Access for this case. It lets you allow or block dashboard entry by role or by a built-in WordPress capability, and it can send each user to a custom redirect page. A membership site might send members to their own dashboard, for example.
Before you install any plugin, check its last update date, its compatibility with your WordPress version, and its support history on the plugin directory page. A tool nobody maintains can become the weak point it was meant to cover, so choose a maintained alternative if the one you’re considering has gone quiet. If members also need private front-end content, configure page access for logged-in users separately; blocking the dashboard doesn’t make public pages private.
Go to Plugins, then Add New. Search for Remove Dashboard Access, click Install, then Activate. Open Dashboard Access from the sidebar, choose which roles can enter, set any redirect URLs, and click Save changes. Then log out and sign in with a test account for each role.
If a genuine team member gets locked out, check their permissions first. If that doesn’t fix it, deactivate the plugin from the Plugins page. If you can’t reach the dashboard, connect by FTP or SFTP, open the root folder, then wp-content, then plugins. Rename the plugin’s folder to turn it off, then test the login again.
📝 Note: Keep a copy of your redirect settings before you change them. A WordPress redirect loop can lock out the people you’re trying to help, and the record shows you what to restore.
Limit access by IP, but only on a stable network
An IP allowlist works like a guest list. Only approved addresses get through, which suits a private office or a trusted VPN with fixed addresses. It’s a poor fit for a remote team, because travel, mobile connections, and changing home networks can lock out people who should be inside. Dynamic IP addresses change often, so you’d need to keep updating the list.
Start with a full backup. Then find your public IP address with a trusted lookup site. Connect to your server by FTP or SFTP using the credentials from your hosting account. Locate the .htaccess file that controls the area you want to protect, and confirm that location with your host, since it isn’t always the folder you’d expect. Add rules that allow your approved addresses and deny everyone else, then upload the file.
Test from an approved network, then from a network that should be blocked. The blocked connection should show a forbidden error. This method works on Apache servers. Nginx uses different controls, so ask your host which setting applies before you copy any example.
📝 Note: Check both /wp-admin/ and the login page. A rule that covers the dashboard can leave the login path open, so test the login separately.
Use custom code only with a backup and a child theme
Custom code can limit the admin area to administrators in one step. The check looks at whether a user lacks the administrator capability, skips background AJAX requests so the site keeps working, and sends that user to the home page. It’s a narrow rule, and narrow rules are the reason to choose it.
Put the code in a child theme’s functions.php file, not the parent theme. Theme updates can overwrite changes made to a parent theme, but a child theme keeps your code safe. If editors also need access, replace the word administrator with editor. The check works on capabilities, so the change covers editors and anything higher.
Connect by FTP or SFTP, open the root folder, then wp-content, then your active child theme’s folder. Download functions.php, add the code, save it, and upload it to replace the old version. Then log in as a non-administrator to test the result.
If your change doesn’t appear, clear your page and browser caches. Check the file for syntax errors, since one stray character can stop the whole file from running. Confirm that the parent theme is also active, because a child theme depends on it.
📝 Note: Keep a working administrator login open in another browser while you test. If the rule blocks you, that session is the only way to undo it.
Test each account before you trust it
A successful login proves that sign-in worked, not that the account can do only what you intended. Test each account in its own browser session or an incognito window, so your own administrator login doesn’t mask the result.
Perform the task the account should allow, such as publishing a draft. Then try the task it must not do, such as opening Users. Log out and check the route a real person would use if the rule blocked them. If you changed IP rules, repeat the test from an approved network and from one that should fail.
A good result means the required task works and the denied task stays unavailable. If something breaks, restore the previous setting before you narrow the rule and test again. Never fix a failed test by adding more rules on top of the broken one.
📝 Note: Record the old role, the new role, the approved IP addresses, any file you changed, and the rollback steps. The next person who maintains the site will need that record more than you think.
Add protection the access rules can’t cover
Restricting admin access helps, but it doesn’t solve everything. It won’t stop WordPress privilege escalation through a vulnerable plugin or theme, and it can’t protect you from a compromised account belonging to a real user. In our experience, most serious incidents involve an account or a component that was trusted a little too long.
For that reason, layer these protections alongside your access rules:
- Strong passwords and two-factor authentication for every privileged user.
- An activity log that shows who changed what, and when.
- A firewall and login protection against brute-force attempts.
- Disabled registration if your site doesn’t need public sign-ups.
- Automatically log out idle users to reduce the risk of an unattended privileged session.
We build a WordPress firewall and an activity log for this purpose, and you can compare them with other options before you choose. If you’d like, we can walk you through the login security steps next.
📝 Note: Disabling registration won’t fix an over-privileged account or a stolen password. Match each control to the specific problem it solves, rather than treating any single setting as the answer.
Once account permissions are in place, review your wider WordPress hardening settings to reduce other routes attackers could use.
FAQs
Can I restrict admin access on WordPress without a plugin?
Yes, changing roles in Users handles most cases with no plugin needed. Choose Subscriber for full restriction, or Editor, Author, or Contributor for narrower content work.
Should I give a developer permanent administrator access?
No, give them only the permission the task needs. Installing one plugin may require elevated access, so remove that access once the work is finished.
Can I use an IP allowlist for a remote team?
Usually not, because travel, mobile connections, and changing VPN addresses can lock out real people. An allowlist fits a private office or a trusted VPN with fixed addresses far better.
Will changing someone’s role stop them from opening /wp-admin/?
Not always, because some roles can still reach the dashboard. Check what the account can do after you save the role, not just whether the page loads.
Does disabling registration restrict my existing administrators?
No, it doesn’t change current accounts or their roles. Turn registration off only when your site doesn’t need public sign-ups.
Conclusion
Restricting admin access on WordPress works when each person can finish their job and nobody else can reach what they shouldn’t. Review your privileged accounts this week, test one recovery route, and use a WordPress security checklist to keep permissions and other protections under regular review.
