Short answer: change the role before you install anything. Most of the time, "this client is overwhelmed by the admin" is really "this client is sitting in an Administrator account and only needs to be an Editor." Demoting them to Editor removes the Plugins, Appearance, Users, Settings and Tools menus, and every core and plugin update notice, from their screen. It takes about thirty seconds, installs nothing, and it keeps working after every WordPress release because it is based on capabilities rather than on menu positions. Only once that is done is it worth asking what genuinely still needs hiding.
Simplify the WordPress admin for a client by changing the role first
Most guides on this topic open with a plugin that hides admin menus, and treat user roles as a footnote. That is backwards. A hidden menu is a cosmetic change sitting on top of a permission the client still has. A role change removes the permission, and the menu disappears as a consequence.
WordPress ships six roles, and the documentation on wordpress.org describes an Editor as "somebody who can publish and manage posts including the posts of other users." That is a precise description of most clients: they need to write, edit, publish, add images and moderate comments, and they need nothing else. Here is what each role can reach, taken from the capability table on the official Roles and Capabilities page:
| Menu the client sees | Capability that reveals it | Administrator | Editor |
|---|---|---|---|
| Posts, Pages, Media, Comments | edit_posts, edit_pages, upload_files, moderate_comments |
Yes | Yes |
| Categories and tags | manage_categories |
Yes | Yes |
| Plugins | activate_plugins |
Yes | No |
| Appearance (themes) | switch_themes |
Yes | No |
| Appearance menus, widgets, customizer | edit_theme_options |
Yes | No |
| Users | list_users, edit_users |
Yes | No, only their own profile |
| Settings | manage_options |
Yes | No |
| Tools, Import and Export | import, export |
Yes | No |
| Updates for core, plugins and themes | update_core, update_plugins, update_themes |
Yes, on a single site | No |
One nuance worth knowing before you promise anything: on a Multisite network, update_core, install_plugins and several others belong to the Super Admin, not to a site Administrator. The same demotion therefore removes less than you expect, because the site Administrator never had those menus in the first place.
Choose the role from what they actually do each week
Do not choose the role from what the client might one day want. Choose it from the two or three things they will really do, then confirm the rest is genuinely out of reach.
| What the client does every week | Role to give them | What they still cannot do |
|---|---|---|
| Publishes and edits anyone's posts and pages, moderates comments, manages categories | Editor | Install or update anything, change settings, add users, switch theme |
| Writes and publishes only their own posts | Author | Touch anyone else's content, manage categories, moderate comments |
| Writes drafts for someone else to approve | Contributor | Publish, and upload images at all |
| Only signs in to read something restricted | Subscriber | Everything above |
The Contributor row catches people out. A Contributor has no upload_files capability, so they cannot add an image to their own draft. If your client writes and needs pictures, Contributor is the wrong answer no matter how cautious you are feeling.
Someone still has to hold an Administrator account. Decide out loud whether that is you, the business owner, or both, and make sure the owner controls at least one Administrator login that does not depend on your continued involvement. A site where only the departed developer can install a security update is a worse outcome than a cluttered menu.
The update notices, and why an Editor stops seeing them
The update banner is the single most destabilizing thing in a non-technical owner's admin. It produces two failure modes and both are expensive. Some owners click Update All on everything the moment a badge appears, at 5pm, with no backup. Others freeze, ignore it for eleven months, and end up on a version so far behind that the eventual jump is the risky one.
An Editor sees neither. Without update_core, update_plugins or update_themes there is no Updates screen and no count badge on the menu, because WordPress surfaces those only to accounts that could act on them. That is not you hiding a warning from your client. It is you moving the decision to the person whose job it is, which also means someone has to decide whether WordPress auto-updates are a good idea on a client site or whether a human will do it on a schedule.
Whoever keeps the Administrator account then owns a real responsibility. If that is you, say so in writing, and understand why some sites break after every update while others never do, because "the client clicked update" is only one of the causes and usually not the main one.
What is actually left after the role change
Sign in as the client's real account before you decide anything else. Create a test user with the role you plan to use, open a private browser window, and look at the screen they will look at. An Administrator's view tells you nothing about an Editor's view, and half the things you were about to hide are already gone.
What usually remains is:
The dashboard widgets nobody reads. WordPress's own Dashboard documentation, last updated on 2024-06-06, describes five default widgets (At a Glance, Activity, Quick Draft, WordPress Events and News, and Welcome) and a Screen Options panel that lets you check or uncheck each one. Two cautions, and both matter. First, that documentation predates the 7.0 admin redesign, so look at your own install rather than trusting the screenshot: the capability is stable, the exact control has moved before. Second, those choices are stored per user, in options like metaboxhidden_dashboard in the wp_usermeta table, so tidying your own dashboard does nothing at all for your client's. Do it while signed in as their account, or walk them through it once on a call.
A Posts screen that does not look like any tutorial they will find. The 7.0 release on 2026-05-20 brought the first visual overhaul of the admin since 2013, built on a component called DataViews, and 7.1 followed on 2026-08-19. If your client searches for help, they will land on articles written against the old screens. Spending five minutes on what DataViews actually is and why the Posts list changed shape will save you more support calls than any menu you remove.
A general sense that everything moved. It mostly did not, and saying so calms people down faster than a guided tour of the redesign. It is worth being able to tell a client exactly which menus genuinely moved and which only feel like they did, because the honest answer is that the main menu tree is close to unchanged and the disorientation is concentrated in a couple of screens.
One or two tasks they will genuinely repeat. Name them. Write those two down as numbered steps, in their words, on a page only they and you can see. That document does more for a nervous owner than a stripped-back interface, because the anxiety is usually about not knowing the sequence, not about the number of menu items.
If you still need to hide something, put the code in the right place
Sometimes a role does not solve it. A membership plugin adds four menus an Editor can see, or a page builder puts a licensing notice on the dashboard. That is a legitimate reason to remove something.
Do not put that code in your theme's functions.php. If it is a parent theme, the next theme update overwrites the file and your change vanishes without warning. If the client ever switches theme, the change silently stops applying. And if the snippet has an error, the site can go down with no way in through wp-admin. The same code in a small site-specific plugin can be deactivated from the Plugins screen, or by renaming its folder over SFTP, which turns a site-down emergency into a two-minute fix. A child theme is the right home for template and styling changes, not for admin permissions, which have nothing to do with how the site looks to visitors.
This article does not recommend a particular plugin for hiding menus, deliberately. If you choose one, read its own documentation, check when it was last updated against the WordPress version you are running, and confirm it works through capabilities rather than by matching menu slugs or hiding elements with CSS. Slug matching and CSS both break when the admin changes shape, and the admin has now changed shape twice in three months.
Two things are deliberately out of scope here. Login-screen branding and white-labeling the admin are presentation decisions, not configuration ones, and they do nothing for a confused client. And hardening the login is a separate job with separate reasoning; a simpler admin is not a safer one.
The trade-off nobody in this niche states plainly
Every layer of simplification you add is a layer someone has to discover later.
A role change is self-documenting. Anyone who opens Users sees that the client is an Editor and instantly understands why their menu is short. A plugin that hides menus is semi-documented: at least it appears in the plugin list. Code in a site-specific plugin is invisible unless you go looking. Code in a theme file is close to undiscoverable, which is the real reason not to put it there, beyond the update risk.
The person paying that bill is the next developer, and often the next developer is you, eighteen months later, wondering why Tools is missing on a site you no longer remember configuring. So the practical rule is: hide the smallest number of things that solves the actual complaint, and write down every one of them in a handover note that lives with the site, not in your email.
Two more honest points, because they get left out:
A client locked out of something at 6pm on a Friday will call you. Simplification transfers work from the client to you. That is fine when it is deliberate and priced, and unpleasant when it is a surprise. Before you remove access to something, ask whether the client will need it while you are unreachable.
An Editor is not a security sandbox. On a single-site install, the Editor role holds unfiltered_html, which wordpress.org describes as allowing a user "to post HTML markup or even JavaScript code in pages, posts, comments and widgets," with an explicit warning that enabling it for untrusted users can result in malicious or poorly formatted code. Roles solve confusion. They are not a substitute for trusting the person you hand the login to.
A five-line handover note that prevents most of the support calls
Keep this with the site, not in your inbox:
- Which role each person has, and why that role rather than Administrator.
- Who holds the Administrator account, and who else can get into it if that person disappears.
- Anything hidden beyond what the role hides, where the code or plugin doing it lives, and how to switch it off.
- Who is responsible for updates, and on what rhythm.
- The date this was written, and the WordPress version it was written against.
That last line is not a formality. WordPress shipped a major admin redesign on 2026-05-20 and a follow-up on 2026-08-19. Any note about where a button lives has a shelf life, which is why it pays for both of you to learn how to read a WordPress release note and judge whether a given change touches your setup at all.
FAQ
Is Editor the right role for every client?
No. Editor fits a client who manages all the content on the site. If they only write their own posts, Author is a tighter fit. If someone else approves their work before it goes live, Contributor is closer, but remember that a Contributor cannot upload images.
Will demoting a client to Editor delete anything they made?
No. Roles control what an account can do from now on. Posts, pages and media that account created stay exactly where they are, and authorship does not change.
Can I hide dashboard widgets for my client without touching code?
Yes, through the Screen Options control on the Dashboard, but the setting is stored per user account, so it has to be done while signed in as that user. Setting it on your own account changes only your own dashboard.
Does hiding admin menus make a WordPress site more secure?
Not on its own. A hidden menu changes what is displayed, not what an account is allowed to do. Real restriction comes from the role and its capabilities. If security is the goal, change the role, and treat the visual tidying as a usability decision.
How do I check what my client will actually see?
Create a test user with the intended role, sign in as that user in a separate browser or a private window, and work through the tasks they will do. It is the only reliable check, and it takes a couple of minutes.
Written and verified on 2026-08-24 against WordPress 7.1 "Mary Lou", released 2026-08-19, and WordPress 7.0 "Armstrong", released 2026-05-20, both confirmed on wordpress.org's own version documentation. Role and capability details taken from the Roles and Capabilities page on wordpress.org (last updated 2024-09-20). Dashboard widget details taken from the Dashboard Screen page on wordpress.org (last updated 2024-06-06), which predates the 7.0 redesign, so the control's exact location should be confirmed in your own install.
