Giving a client Administrator access can feel like the simplest way to avoid access problems. On a WordPress single-site installation, however, that decision may provide far more control than the client needs for everyday publishing. It can include access to plugins, themes, users and core settings, so an agency should connect permissions with documented tasks rather than with ownership or job titles.
This guide compares the default Subscriber, Contributor, Author, Editor and Administrator roles for agency workflows. It also explains the capabilities behind plugin, theme, user and settings administration, and presents a practical least-privilege process. These recommendations are a practical synthesis of WordPress documentation, not an official policy that every agency must follow. Installed plugins and themes may change the actual access model and should be checked on each website.
Why WordPress Roles Are Not the Same as Job Titles
WordPress includes six predefined roles: Super Admin, Administrator, Editor, Author, Contributor and Subscriber. A role is a predefined bundle of permissions, while a capability represents a particular action that a user may perform. This distinction matters when an agency decides what a client, freelancer or internal team member should be able to do.
For example, “content manager” is not itself a WordPress permission. The practical question is whether that person needs to publish their own posts, manage other users’ content, moderate comments or change site-wide settings. The assigned role should follow those tasks.
Roles as Permission Bundles
Roles group capabilities into a reusable permission set. Capabilities provide the more specific basis for authorization. This means that assigning a role is only the starting point: the relevant question is what actions the account can actually perform on the website.
On a single-site installation, Administrator is the highest standard role for that site. In Multisite, network-wide administration belongs to Super Admin, so the two contexts should not be treated as equivalent.
Why Default Permissions Need Verification
The default comparison is useful, but it is not a guarantee of identical behavior on every installation. Plugins, themes and other products can register custom capabilities or change the way access is checked. A page builder, WooCommerce extension or another installed product may therefore introduce permissions that are not represented by the basic WordPress role names.
Also, hiding an administration menu does not necessarily remove the underlying capability. Agencies should verify the real behavior of the installed configuration instead of relying only on visible menu items.
Quick Role Comparison for Agency Client Access
The best default role for a client is the lowest role that supports the client’s documented work. Ownership of the website does not, by itself, explain which technical capabilities are required.
Role Selection by Client Task
- Subscriber: suitable when the user only needs profile access.
- Contributor: suitable when the user prepares and edits their own posts, while another person retains publishing control.
- Author: suitable when the user must publish, edit and delete their own posts and upload files.
- Editor: suitable when the user must publish and manage content created by multiple users, moderate comments and work across the documented content permissions.
- Administrator: reserved for site-wide administrative work on a single-site installation, not automatically assigned because the user is the client or owner.
This approach separates content access from administration. A client who needs to update copy may need an Editor, Author or Contributor role, but not access to plugin installation, theme switching, user management or core settings.
The Administrator Boundary
Editors, Authors and Contributors are primarily content-focused by default. They do not receive the administrative capabilities needed to install plugins or themes, manage users or change core site settings. Administrator access crosses that boundary and should therefore be considered separately from editorial work.
For a Multisite network, the relevant network administration belongs to Super Admin. Advice designed for a single-site Administrator should not be transferred to network administration without checking the different scope.
Editor vs Author vs Contributor: Which Content Role Fits?
The choice among these three roles depends mainly on who owns the publishing decision and whose content the user must manage. It is not enough to ask whether the client “works with content”; the agency should identify the required workflow.
Editor for Multi-Author Content
By default, Editors can publish and manage posts and pages created by other users within their content-management scope. They can moderate comments, manage categories, upload files and access private content within the documented content permissions.
This makes Editor a reasonable choice for a client or content lead who coordinates a multi-author website and must make publishing decisions across other users’ content. It is still not an Administrator role by default: Editors do not receive manage_options, which controls access to important site settings screens.
Author or Contributor for Controlled Publishing
Authors can publish, edit and delete their own posts, including published posts, and upload files. They do not receive the Editor’s ability to manage other users’ content. Author is therefore more limited than Editor while still allowing independent publication of the user’s own posts.
Contributors can write and manage their own posts but cannot publish them by default. They also do not have the default upload_files capability. This role supports a workflow in which the agency or an Editor reviews and publishes submitted drafts.
None of these three default roles receives plugin or theme installation capabilities or site-wide settings administration by default. If a product changes those permissions, the result must be verified on the specific website.
Capabilities Behind Plugin, Theme and User Administration
Capability names show why administrative access is broader than content access. They help an agency identify the action that requires permission and avoid granting a wider role without a clear reason.
Plugin and Theme Capabilities
For plugins, the relevant capabilities include install_plugins and update_plugins. Additional plugin administration capabilities include delete_plugins, activate_plugins and edit_plugins.
For themes, the corresponding capabilities include install_themes, update_themes, delete_themes, switch_themes and edit_themes. On a standard single-site installation, these capabilities are associated with Administrator-level access by default.
This distinction is useful when documenting an agency task. “Update one plugin” and “manage the complete plugin and theme layer” are not necessarily the same operational request, even though the default role model places the relevant capabilities with Administrator.
Settings and User Management
The manage_options capability provides access to core settings screens such as General, Writing, Reading, Discussion, Permalinks and Miscellaneous settings. Editors do not have manage_options by default, which reinforces the separation between managing content and configuring the website.
The edit_users capability provides access to the Users administration area. On a single-site installation, capabilities such as create_users, delete_users, promote_users and remove_users relate to managing user accounts. Standard Editor, Author and Contributor roles do not have these capabilities by default.
When Administrator Access Is Actually Required
Administrator access is justified when a user must perform site-wide actions that lower default roles cannot perform. It is not required for ordinary writing, editing, publishing, media uploading or comment moderation.
Tasks That Need Administrator-Level Capabilities
- Installing, updating, deleting, activating or editing plugins.
- Installing, updating, deleting, switching or editing themes.
- Changing core site settings through
manage_options. - Managing user accounts through the relevant user-management capabilities.
On a single-site installation, these are examples of Administrator-level work by default. If the task is temporary, the agency should consider temporary access rather than leaving broad permissions in place indefinitely.
Single-Site Versus Multisite
Administrator is the highest standard role on a single-site WordPress installation and has access to all administration features for that site. Multisite has a different structure: network-wide administration belongs to Super Admin.
Consequently, an agency should first identify whether it is managing one site or a network. The same role label does not describe the same administrative scope in both contexts.
A Least-Privilege Access Workflow for Agencies
Least privilege is a practical way to connect access with actual work. It is not a WordPress-mandated agency policy, but it helps reduce unnecessary administrative exposure and makes client access easier to review.
Document, Grant and Review
- Describe the specific task, such as preparing drafts, publishing posts, managing other authors’ content or updating a plugin.
- Choose the lowest default role that supports that task.
- Check whether installed plugins and themes add capabilities or alter access checks.
- Review the account after the task changes or ends, and remove access that is no longer needed.
This process prevents a broad role from becoming a substitute for a clear access decision. It also gives the agency a practical record of why a client received a particular level of access.
Separate Accounts and Recovery Planning
Each person should use an individual, named account. Do not share one Administrator username and password among agency staff or clients. Separate accounts make it possible to review and remove access for one person without affecting everyone else.
Before changing roles or capabilities, create a tested backup and confirm that another trusted account retains the access needed for recovery. Accounts with administrative access should use strong, unique passwords, and the agency should consider additional authentication measures such as two-step authentication.
Security Checks Before Giving or Removing Access
Administrator access has a high potential impact. Official WordPress hardening guidance notes that a compromised Administrator account may allow an attacker to install malicious scripts that could compromise the entire server. This is a practical reason to minimize such accounts and protect every account that retains them.
Final Permission Review
- Confirm whether the requested task truly requires Administrator-level capabilities.
- Check whether active plugins or themes add custom capabilities or change access checks.
- Do not treat a hidden administration menu as proof that a capability has been removed.
- Use caution with
unfiltered_html, which can allow HTML or JavaScript and may permit malicious or poorly formatted code for untrusted users. - Verify that a separate trusted recovery account remains available after the change.
Where a test environment is available, test the role change before applying it to the active website. The WordPress role system does not cover hosting-panel, SSH, FTP, database, CDN or third-party service permissions, so those access areas require separate consideration.
For agency client access, start with the task, not the title. Subscriber, Contributor, Author and Editor can support progressively broader content workflows without automatically exposing site-wide administration. Administrator on a single-site installation is appropriate when the user must manage plugins, themes, users or core settings, but it should not be the default reward for ownership. Use named accounts, strong authentication, recovery planning and documented reviews, then verify the final behavior against the installed plugins and themes. Explore our WordPress plugins, WooCommerce extensions, themes and membership plans to find the right tools for your website.