Client-Proof WordPress: Locking Down Editor Roles and Permissions

The call comes on a Tuesday. The homepage layout is broken, nobody knows why, and the client swears they only changed a headline. You check the revision history and find that a marketing intern with an administrator account deactivated a plugin, then reactivated a different one with a similar name.

That incident is a permissions problem, not a training problem. Getting WordPress user roles for clients right at handover removes an entire category of emergency, and it takes about an hour per site. This post covers what each built-in role can actually do, which capabilities to strip, how to build a safe custom role, and where role hardening overlaps with genuine security work.

Everyone is an administrator, and that is the problem

Default agency behaviour is to hand the client an administrator account at launch because it is the quickest way to stop being asked for access. Three years later a site has nine administrators: two former employees, an SEO contractor, a plugin vendor’s support login and someone’s personal Gmail.

The cost shows up in three ways. Broken layouts from well-meaning edits. Plugins installed without review, which is the most common route to a compromised site that had nothing to do with a zero-day. And an audit trail that tells you nothing, because everyone can do everything.

What the built-in roles really allow

Most people know the names. Fewer know where the sharp edges are.

Role	Can do	Sharp edge
Subscriber	Manage own profile only	Harmless, but open registration turns it into a spam vector
Contributor	Write own posts, cannot publish, cannot upload media	The no-media rule makes it unusable for most real content work
Author	Write, upload and publish own posts	Can delete their own published posts without review
Editor	Full control of all content, pages, comments, categories	Can delete any page, and in most builders can restructure layouts
Administrator	Everything, including plugins, themes, users and core updates	One account away from a broken or compromised site

Editor is where most client users should sit, and it is still too permissive on a modern build. An editor can open the site editor in a block theme, edit templates and template parts, and change the header for every page on the site. That is rarely what anyone intended when they said the client should be able to update content.

The capabilities worth stripping

Roles are just bundles of capabilities. You rarely need a whole new role; you need an existing one with a few capabilities removed. These are the ones that cause the most damage in practice.

• edit_theme_options – controls menus, widgets and the site editor. Removing it stops global layout edits but also removes menu editing, so decide deliberately.
• install_plugins, activate_plugins, update_plugins – nobody on the client side needs these unless they employ a developer.
• edit_files, edit_plugins, edit_themes – disable the file editors entirely with DISALLOW_FILE_EDIT in wp-config.php rather than relying on role settings.
• delete_published_pages – keeping this away from editors turns an accidental deletion into a support request instead of a restore from backup.
• manage_options – settings pages, permalinks, and most plugin configuration screens.
• promote_users – stops a client user quietly upgrading a colleague to administrator.

Removing a capability changes what appears in the admin menu, which is half the benefit. A client who cannot see the plugins screen does not ask what the plugins screen does. If you want the deeper mechanics of capability mapping, the WordPress documentation and our tutorial on customising WordPress user roles and permissions both go further into the code.

Building a client editor role in six steps

Our standard approach on client builds is a single custom role, usually named after the client’s own vocabulary rather than ours.

1. Clone the editor role programmatically in a must-use plugin, so it survives theme changes and cannot be edited away in the admin.
2. Remove the capability set above, keeping menu editing only if the client genuinely maintains navigation themselves.
3. Grant access to the custom post types and taxonomies they own, and nothing else. A restaurant client editing menu items does not need access to the case study post type.
4. Lock the templates. In a block theme, restrict template and template part editing; in a page builder, use its own role manager to disable structural editing while allowing text and image swaps.
5. Hide admin notices, plugin upsells and unused menu items for that role. Noise causes clicks, and clicks cause tickets.
6. Test the role by logging in as it, not by reading the settings screen. Walk through every task in the editor guide as that user.

Step six catches more problems than the other five combined. A role that looks correct in a settings panel routinely turns out to hide a field the client needs, and you would rather discover that before handover than during their first content push. The same principle applies to the block layer, which we cover in building reusable Gutenberg blocks clients cannot break.

Roles are a security control, not just a tidiness measure

Compromised WordPress sites are far more often the result of a weak or reused administrator password, or an abandoned account belonging to someone who left the company, than of an exotic exploit. Reducing the number of accounts that can install code reduces your exposure directly.

• Enforce two-factor authentication for every account with administrator capabilities. No exceptions for the client’s founder.
• Give each person their own account. Shared logins destroy the audit trail and outlive the people using them.
• Set a quarterly review to remove dormant accounts. Automate the reminder so it does not depend on anyone remembering.
• Log user actions with an activity plugin, so “I only changed a headline” becomes a checkable claim.
• Keep one break-glass administrator account, held by you, documented in the access register, and not used day to day.

Treat this as part of the same discipline as updates and hardening. Hardening the server and configuration layer is the other half of the job. When something has already gone wrong, remediation belongs with a specialist rather than a panicked Friday evening. That is what WordPress security and malware removal exists for, and the incident process is set out in our agency malware response playbook.

How much to lock down

There is a real trade-off here and it is worth being straight with clients about it. Every restriction you add is a task they now have to send to you. For some clients that is the point, and they will pay for it. For others it feels like being held hostage, and it damages the relationship.

Client profile	Recommended level
No in-house technical staff, on a maintenance retainer	Tight. Custom editor role, no plugin or template access.
In-house marketer, publishes weekly	Tight on structure, generous on content types and media.
In-house developer or technical marketer	Give them an administrator account, agree change rules in writing.
Multi-site portfolio managed by you	Standardised role definition applied identically across every site.

Whichever level you pick, say it out loud at handover and write it into the documentation. A client who understands that the lock exists to protect their layout reacts very differently from one who discovers it while trying to fix something at 9pm. Ongoing role reviews sit naturally inside a WordPress maintenance and support arrangement, alongside updates and backups, and the broader case for structuring outsourced delivery this way is in our white label WordPress development guide for agencies.

Frequently asked questions

Should the client ever have an administrator account?

They should always own one, legally and practically, even if they do not use it daily. Withholding administrator access from a client who owns the site is a bad look and a contractual risk. Give them the account, explain what it is for, and encourage day-to-day work in a restricted role.

Plugin-based role editor or custom code?

Code in a must-use plugin for anything you want to be permanent, because it is version-controlled, repeatable across sites and cannot be undone from the admin. A role editor plugin is fine for exploration or for a one-off site where nobody will maintain code.

How do roles work with page builders?

Most major builders have their own permission layer that sits on top of WordPress capabilities. You need to configure both. A user blocked from the site editor can still restructure a page inside a builder if the builder’s own role settings were left at default.

What about WooCommerce stores?

WooCommerce adds shop manager, which is broad. It includes access to order data and customer records, so treat it as a privileged role under whatever data protection rules apply to your client. Split product editing from order handling if different people do those jobs.

How long does role hardening take on an existing site?

Roughly one to three hours for a standard site: audit the users, build the custom role, migrate people onto it, test each task, document the result. Complex stores or membership sites take longer because the capability map is larger.

If you manage a portfolio of client sites and role hardening keeps sliding down the list, it is exactly the kind of standardised work that suits a monthly block of development capacity. Our dedicated plans run month to month with no lock-in if you want to work through the backlog.