WordPress has five built-in roles, and the default when adding someone is usually the wrong one. Giving everybody Administrator is the most common WordPress security mistake after not updating, not because people are untrustworthy, but because every administrator account is another way in.
The five roles
Administrator. Everything: install plugins, edit files, change settings, add and remove users. On a single-site install this role can execute code on your server.
Editor. Publish and edit any post or page, including other people's. Cannot install anything or change settings.
Author. Publish and edit their own posts only.
Contributor. Write drafts, cannot publish. Someone else reviews.
Subscriber. Read, and manage their own profile. This is what a commenter or member account should be.
The line that matters
Administrator can install plugins. Nothing else can.
That single capability is the difference between an account that can damage content and one that can run arbitrary code on your server. A compromised Editor account is a bad afternoon; a compromised Administrator account is a compromised site.
So the question when adding someone is not "how much do I trust them" but "do they need to install plugins". Almost nobody does.
Who should be what
You, and one other person: Administrator. Two is sensible so nobody is locked out; five is not.
Someone managing content: Editor. They can publish and edit everything without being able to break the site.
A regular writer: Author.
A guest or freelancer writing one piece: Contributor. They draft, you publish.
A developer working temporarily: Administrator, and remove it when they finish. That last part is the one that gets skipped, and old developer accounts with full access outlive the relationship by years.
WooCommerce adds two
A store installs Customer and Shop Manager.
Customer is what a shopper's account is, and it is essentially a Subscriber with order history.
Shop Manager can manage products, orders and store settings without touching plugins or site settings. This is the correct role for staff who process orders, and giving them Administrator instead is common and unnecessary.
Protect the administrator accounts specifically
Two-factor authentication on every account that can install plugins. That single change makes a stolen password useless, and it is the highest-value thing you can do with ten minutes.
Unique passwords, stored in a password manager, so a breach at some unrelated service cannot be replayed here.
And do not use admin as a username. It is the first guess of every automated login attempt.
Securing WordPress against vulnerabilities puts these in order against the other defences.
Remove the file editor regardless
Administrators can edit theme and plugin PHP from the dashboard, which is the fastest route from a stolen password to code running on your server.
Almost nobody needs it, because real edits belong in a child theme over SFTP. Disable it in wp-config.php:
define( 'DISALLOW_FILE_EDIT', true );
This costs nothing if you edit files properly and removes an entire category of post-compromise escalation.
Audit the user list occasionally
Twice a year, look at who has an account and at what level.
You are looking for three things: people who have left, accounts at a higher role than the person needs, and accounts you do not recognise at all. That last one is a strong signal. An unexpected administrator is a common first step after a compromise.
Delete rather than downgrade when someone has gone. WordPress asks what to do with their content and can reassign it to another user, so nothing is lost.
Custom roles
Plugins can create roles with specific capabilities, which is genuinely useful when the five built-in ones do not fit: someone who should manage one thing and nothing else.
Worth knowing that a custom role is only as good as its definition, and a role granting plugin installation is an Administrator whatever it is called. Check what capabilities a custom role actually carries rather than trusting its name.
The default role decides what an unwanted account can do, and it is occasionally set wrongly by a plugin. How to Stop Spam Registrations and Fake Accounts explains checking it.
What a role can do is not fixed
The five roles are a starting point, and plugins modify them freely: adding capabilities to existing roles as well as creating new ones.
That means a site's actual permissions can differ substantially from the defaults, and reading the role name tells you less than people assume. A plugin that grants editors access to its settings has changed what "editor" means on that site.
wp role list wp cap list editor | head -40
Worth running on any site you inherit, before deciding who should be what. The answer occasionally explains a permission nobody could account for. Auditing a WordPress site you inherited sets out the wider check.
Capabilities that are administrator access in effect
Three capabilities are worth treating as equivalent to full control, whatever role holds them.
Editing files: theme or plugin code, means being able to run arbitrary code on the server. That is the whole account, not a content permission.
Installing or updating plugins is the same thing with an extra step: an uploaded plugin is code you did not write, executing.
Managing users means being able to create an administrator, which is administrator access with a delay.
Any role granted one of these is an administrator in practice. That is worth knowing before granting them to a role named something reassuring, and it is the argument for disabling the file editor entirely rather than relying on the role.
The account that is not a person
Integrations, mobile applications and API clients frequently authenticate as a user, and that user is commonly an administrator because it was simplest.
Create a dedicated account with only the capabilities the integration needs, and use an application password instead of the login password, those can be revoked individually without changing anything else.
Then, when the integration is retired, one account is removed and nothing else is disturbed. An integration authenticating as a real person's administrator account is a credential that outlives both the integration and frequently the person. There is more on the store version of the same arrangement in webhooks and integrations.
What happens when a user is deleted
Deleting a user asks whether to delete or reassign their content, and the choice is not always reversible.
Deleting removes their posts. Reassigning keeps the content under somebody else's name, which is usually right for a departed employee.
On a store, a customer account with orders should not be deleted at all; the orders reference it, and removing the user leaves order records pointing at nothing. Anonymise rather than delete where a deletion request has to be honoured.
Deactivating is safer than deleting in almost every case: change the password, remove the role's capabilities, and keep the record. Stopping spam registrations goes into bulk removal of accounts that are genuinely not people.