An Editor manages website content. An Administrator also manages software, settings and users. For routine publishing, that extra control is often unnecessary. But Editor is still a broad content role: it is not limited to three assigned pages or draft-only work.
Choosing between WordPress Editor and Administrator starts with the job. Does the person need to prepare articles, publish service pages, maintain plugins or change the site’s structure? Write those tasks down before sharing a login. This guide concerns staff access on a self-hosted WordPress site, not customer accounts or a new security incident.
What is the difference between Editor and Administrator?
The official roles reference defines default capabilities, which are the actions an account may perform. Role names group those capabilities. Plugins, custom code and Multisite can change the practical result, so use the defaults as a starting point rather than proof of your site’s configuration.
| Task | Editor | Administrator |
|---|---|---|
| Edit and publish posts and pages, including other people’s content | Normally allowed | Normally allowed |
| Upload media and moderate comments | Normally allowed | Normally allowed |
| Delete other people’s published content or access private posts | Broad content capabilities include these actions | Normally allowed |
| Install or update plugins and themes | Not a default Editor capability | Normally allowed on a single site, subject to management restrictions |
| Manage users or general site settings | Not normally allowed | Normally allowed |
Editor therefore fits someone trusted to manage the site’s content as a whole. It does not mean view-only, approval-required or access only to pages they created. Administrator adds control that can affect the site’s operation and other accounts. Neither role should be assigned merely because its name sounds appropriate for a job title.
Choose the role from the actual publishing job
Consider a hypothetical business with a freelance writer, an internal marketing manager and a maintainer. The writer prepares three blog drafts for review. The marketing manager publishes approved posts and updates service pages. The maintainer handles tested software changes. These are different jobs, even if everyone sometimes calls themselves an editor.
The writer’s task does not require the ability to publish or change everyone else’s content. The Learn WordPress user-management lesson explains that a default Contributor can prepare their own posts but cannot publish them; an Author can publish their own posts. An Author is not a general page-editing role. Contributor also lacks the normal media-upload capability, so an agreed reviewer may need to handle images.
In this example, the marketing manager’s broader content responsibilities may justify Editor. The maintainer may need administrative capabilities for the agreed maintenance work. The decision is not to give all three Administrator access so every screen looks the same.
If the writer needs access to exactly three service pages, neither default Contributor nor broad Editor necessarily expresses that requirement. Ask for a scoped permissions design and a test on staging. A written instruction to avoid other pages is useful guidance, but it does not remove a capability the account still holds.
Check the native role before changing it
An existing authorized administrator can inspect Users > All Users. Identify the exact account by its login and intended person, then read the Role column. The Users screen documentation covers individual editing and bulk role changes. For a one-person review, avoid selecting every user or applying a bulk action.
- Record the account’s current role and the approved tasks privately, without storing its password.
- Confirm that a separate business-controlled administrator can still sign in and recover access.
- Check whether plugins or a custom role system change the default capabilities.
- Agree the proposed role, the verification steps and who can restore the previous access if legitimate work stops.
- Apply only the approved account change, then verify using that person’s own session rather than the administrator’s screen.
For a genuinely new approved staff account, use Users > Add User or Add New User, depending on the installed version. The native form has a Role selector. Review it before creating the account; do not assume the default is appropriate. The Add New User reference documents that choice, although older password and email wording may differ from the current screen.
Do not demote the only working administrator, change the site’s default registration role or invite a temporary administrator just to test this comparison. If access ownership is unclear, settle that handover first using the maintenance onboarding checklist.
WordPress Editor is not the same as a page-builder editor
A person may be allowed to edit a WordPress page but still lack the intended builder controls. The word Editor also appears in the block editor, Site Editor and Elementor editor. Those interface names are not interchangeable account roles.
For a block theme, access to the Site Editor involves theme-related capabilities rather than ordinary page editing alone. In Elementor, the vendor’s Role Manager guidance describes additional restrictions, including no editor access or access to existing content only. Available controls depend on the installed setup. Inspect that owning layer before changing a WordPress role.
If someone can edit text but cannot add a widget or alter a header, establish whether that restriction is intentional. Promoting the person to Administrator may bypass the intended boundary while granting unrelated software and user-management powers. A missing Plugins control has its own installation-access checks; it is not automatically a fault in the staff account.
Verify allowed work and deliberately unavailable actions
Use an isolated staging copy and disposable test content where possible. For the writer in the example, confirm they can create and revise their own draft, while publication remains with the reviewer. For the marketing manager, check an approved existing page, media selection, preview and the intended publication process. Use test content, not a live customer page, for destructive checks.
Also inspect what should remain unavailable. A content-only account should not unexpectedly expose plugin installation, user management or unrelated private business data. A screenshot showing a hidden menu is not sufficient verification of the underlying permission. If a custom workflow is involved, have its developer test the relevant capability checks as well.
Stop if an account can publish without the required approval, reach unrelated records, or no longer perform its agreed work. Preserve the observed result and restore only the approved previous configuration. Do not keep adding capabilities until the error disappears. Record which site, role, task and browser session were checked so the handover can be repeated.
Changing a role is not the same as ending access
Someone leaving the business needs a separate offboarding decision. A lower role can still allow sign-in, and external services have their own access controls. Do not treat a successful role change as proof that browser sessions, application credentials, hosting or vendor access have all been retired.
Our user-removal guide covers preserving content and author credit. The application-password guide covers separate integration credentials. On Multisite, ask the network owner to distinguish site administration from network privileges before changing access.
For an ordinary staff handover, WordPress maintenance is the relevant Webless route for reviewing ownership and ongoing access. Restrictions on particular pages, builder actions or custom integrations may need a separately agreed development task. Describe the person’s work and the missing boundary, not their password.