WordPress User Roles: Who on Your Team Should Be Able to Change What

Reviewing access on a few customer sites this week, I kept finding the same thing. One login. Shared by everyone who has ever touched the website.

The owner uses it. So does the part-time staff member who updates the opening hours. So does the freelancer who set the site up eighteen months ago and has not been near it since. Same username, same password, full administrator access for all of them.

It feels simpler. It is also the single most common access mistake on small business websites, and it quietly creates three problems at once. Everyone can change everything, so an accident anywhere is an accident everywhere. Nobody can tell who made a given change, so when something breaks you are guessing. And one leaked password exposes the entire site, because that password is the keys to the whole building.

WordPress has had the fix built in for years. It is called user roles, and most small sites never use it. This is a plain-English guide to what the roles are, who should get which one, and where roles stop and your hosting has to take over.

What a WordPress user role actually is

A role is a label that decides what a person can and cannot do once they log in. WordPress ships with five of them, and each one grants a smaller slice of access than the one above it. The official WordPress documentation lays out the full list of roles and the granular capabilities behind each ^[1].

You do not need to learn the capabilities. You need to know roughly what each role lets a person do, so you can match the person to the right one.

Role	What they can do	Good for	Risk if over-assigned
Administrator	Everything: settings, plugins, themes, users, content	The owner and one trusted backup	A single mistake or leak affects the whole site
Editor	Manage and publish all content, moderate comments	A content manager or marketing lead	Can change or delete anyone's pages, but not settings
Author	Write and publish their own posts	A regular blog contributor on staff	Cannot touch other people's work or settings
Contributor	Write their own posts but not publish them	An occasional writer who needs sign-off	Low: their work waits for review
Subscriber	Manage their own profile only	Logged-in customers or members	Minimal

Read that table top to bottom and you are reading a ladder of trust. The Administrator can do anything. By the time you reach Subscriber, the person can barely change their own name. Everything in between exists so you can hand out exactly as much access as a job needs, and not a scrap more.

Administrator and Editor: the two that matter most

For most small business sites, the real decision is Administrator versus Editor. An Administrator can install plugins, change settings, edit other users and, in practice, take the site down. An Editor can manage every piece of content, publish, unpublish and tidy up, but cannot touch the plumbing.

So what does that mean on a normal Tuesday? It means the person who updates your blog and your service pages can do all of that as an Editor, and still could not accidentally deactivate the plugin that runs your contact form. They never had the button. That is not a restriction on a good employee. It is a seatbelt.

Author, Contributor and Subscriber: the quieter three

Author suits someone on staff who writes and publishes their own posts but has no business editing the homepage. Contributor is for the occasional writer whose work should pass a quick review before it goes live, which is genuinely useful if you want a second pair of eyes before anything reaches production. Subscriber is the floor: it is what a logged-in customer or member gets, and it lets them manage their own profile and nothing else.

Why "everyone's an admin" is the expensive default

Here is the scenario, and it happens more often than you would think. A small team, one shared admin login, a busy Friday afternoon. Someone is rushing to update a price before the weekend, clicks one setting too far, and deactivates the wrong plugin. The checkout goes down. Nobody notices until a customer rings on Saturday to say the website will not take their order.

That is the alternative reality of skipping roles. Not a dramatic hack. Just an ordinary person with more access than the task required, on a bad afternoon, with no way to trace what changed.

The numbers back up where the real risk lives. In Verizon's 2025 Data Breach Investigations Report, the human element, which covers ordinary mistakes as well as social engineering, featured in roughly six in ten breaches ^[2]. The same report found that in the web application attacks that hit sites like yours, the great majority, on the order of 88 percent, leaned on stolen or misused credentials, though Verizon is careful to note that figure is specific to that one attack pattern. Read those two findings together and the lesson is plain. The biggest threats to your site are people and passwords, not exotic exploits. Roles are how you limit the blast radius of both.

There is a credibility point in here too. Sharing one login means you have no record of who did what. When a page disappears or a setting changes, separate accounts at least tell you where to look. A shared login tells you nothing.

Least privilege: the principle that does the work

Security people call it least privilege. Strip away the jargon and it is common sense: give each person the smallest amount of access that still lets them do their job, and no more.

Think about a hair salon in Cork with a couple of part-time stylists who take turns updating the booking notice and the seasonal offers. None of them needs to install plugins or change billing settings. Give each of them their own Editor login and the most damage a rushed update can do is to the content, which is easy to fix and easy to roll back. Give them all the shared admin password and the most damage a rushed update can do is anything at all.

Matching the role to the task is the highest-value access control most small sites can apply, and it costs nothing. You set it once, when you create the account. After that it just sits there, quietly stopping accidents that would otherwise be waiting to happen.

Now the honest concession. If you are a genuine sole operator, one person, one login, nobody else ever touching the site, then elaborate role management is not your priority, and a simpler setup is perfectly fine. Least privilege is about the gap between people and access. If there is only one person, there is no gap to manage. The advice in this article starts to matter the moment a second person can log in.

And one limit worth stating plainly, because it is the kind of thing that catches people out. Roles control what an account is allowed to do. They do nothing to stop the wrong person getting into an account that already has high access. If someone phishes or guesses your administrator password, the role system was never going to stop them, because as far as WordPress is concerned they are the administrator. That is exactly why roles sit on top of login protection, not instead of it. Strong, unique passwords on every account, and two-factor authentication where your hosting or login setup supports it, are what guard the door. Some platforms make passwordless or hardware-key logins available, which removes the guessable password from the equation entirely. Roles decide what happens once someone is inside.

The account nobody thinks about: access that outlives the person

Roles are about the people who work for you now. The trap is the people who used to.

When a staff member leaves, or a freelancer finishes a project, or you part ways with the agency that built the site, their WordPress account does not go anywhere. Nothing removes it. Nothing downgrades it. It stays exactly as it was, full access and all, until a human being decides to take it back. An old administrator account belonging to someone who no longer works with you is a live key to your business, held by someone you no longer have a relationship with.

I will admit to a version of this myself. Early on, we finished a piece of work for a client and left a contractor's administrator account active on their site, on the reasonable-sounding logic that they might need us again. Months later that account was still sitting there, a door we had simply forgotten to close. Nobody misused it. That was luck, not process. We changed how we offboard the same week, and now an account is removed or downgraded the day the work ends.

The fix is not technical. It is a habit. Offboarding a person should always include offboarding their access. Same day, every time:

• Remove or downgrade the account of anyone who has left or finished their work.
• Reassign their published content to a current user first, so nothing breaks when the account goes.
• Change any shared password they knew, on the assumption that knowing it once means knowing it forever.

This is also where owning your site matters in a way that is easy to miss until the day it bites. If your website is locked inside a closed platform, or your only access runs through an agency, then taking back control when a relationship ends is somebody else's decision, on somebody else's timeline. On a site you genuinely own, with your own administrator account, removing someone else's access is a thirty-second job you can do yourself, today.

Where roles stop and the hosting layer takes over

Roles are the application layer. They govern behaviour inside WordPress, for accounts that are behaving normally. They are necessary, and on their own they are not enough. Underneath the roles you set, you need the layer that handles accounts that are not behaving normally: the brute-force attempts on your login page, the malware that tries to create a hidden administrator of its own, the leaked password being tried against your site by a bot at three in the morning.

That is the infrastructure layer, and it is where the real protection against credential-based attacks lives. Server-level hardening that blocks the obvious attack routes. Intrusion prevention that locks out an IP after repeated failed logins, so the brute-force attempt against your login never gets the thousands of guesses it needs. Automatic malware scanning that catches the rogue admin account a clean role setup would never have created. On a Web60 site, that server-level security hardening is included on every site by default, which means the roles you set at the application level are backed by protection at the infrastructure level rather than left to fend for themselves.

If you want the fuller picture of how access control, hardening and recovery fit together, our complete WordPress security and backup guide for Irish websites walks through the whole stack. And if the password itself is the part that worries you, it is worth understanding why a passwordless login can actually be safer than the strong password you keep meaning to set.

One more honest limit, because it belongs here. Good roles and good hardening reduce the odds of a bad day. They do not abolish it. The thing that turns a bad day back into a normal one is a verified backup you can restore in one step. Roles limit how much damage an accident or a compromise can do. Backups are how you undo the damage that gets through anyway. You want both, and you want to have tested the restore before you ever need it.

Setting up team access without losing sleep

You do not need a security project to get this right. You need about twenty minutes and a short routine you can repeat whenever your team changes.

The access setup routine

Audit who has a login today. Open your users list and look at every account, especially any you do not recognise or that belongs to someone who has moved on.

Give everyone their own account. Replace any shared login with individual accounts, so every change is tied to a real person.

Assign the smallest role that fits the job. Default to Editor for content people and Author for writers. Reserve Administrator for the one or two who genuinely run the site.

Remove access the day someone leaves. Make offboarding an account a fixed step, reassign their content first, and change any password they knew.

Verify it holds, then leave it alone. Confirm there is no stray administrator account, and that the only people with high access are the people who should have it.

Do that once and keep the last two steps as a habit, and you have closed the access gap that most small business sites leave wide open for years.

Conclusion

User roles are not a feature you switch on and admire. They are a small, deliberate decision you make every time a new person gets access to your site: what is the least this person needs to do their job? Answer that honestly, give them their own login at that level, and take it back the day they leave, and you have done more for your site's safety than most businesses ever do.

The shared admin password feels like the simple choice on the day you set it up. It stops feeling simple the first time a page vanishes and nobody can say who touched it. You have the tools to do better, built into the website you already run. The next person who asks for access is a good moment to start using them.

Frequently Asked Questions

What WordPress user role should I give an employee?

Give the smallest role that still lets them do their job. Someone who only writes blog posts or updates a notice rarely needs more than Author, which lets them publish their own posts but not touch other people's content, plugins or settings. If they manage the whole content side, Editor is usually enough. Administrator should be reserved for the one or two people who genuinely need to install plugins, change settings and manage other users.

Can I limit what someone changes without making them an administrator?

Yes, and that is exactly what roles are for. Editor, Author, Contributor and Subscriber each grant a smaller slice of access than Administrator. An Editor can manage all your content but cannot install plugins, edit code or add users. Matching the role to the task is the single most effective access control most small sites can apply, and it takes seconds when you create the account.

What happens to a WordPress account when an employee or developer leaves?

Nothing happens on its own. The account stays active, with the same access, until someone removes or downgrades it. An old administrator account belonging to a former staff member, contractor or agency is a live key to your site that you no longer control. Offboarding should include removing or reassigning that account the same day the person leaves, and changing any shared password they knew.

Is sharing one admin login between staff a problem?

It is one of the most common problems we see on small business sites. A shared login means everyone has full access, nobody can tell who made a given change, and a single leaked password exposes the whole site. Separate accounts with appropriate roles fix all three issues at once and cost nothing.

Do small business websites really need user roles?

If you are a sole operator with a single login, role management is not your priority and a simpler setup is fine. The moment a second person can edit the site, a staff member, a freelancer, a family member helping out, roles start to matter. They decide how much damage an accident or a compromised account can do, and they cost nothing to set up correctly from the start.

Does Web60 give me proper user roles and access control?

Yes. A Web60 site is full WordPress, so you get the complete role system, your own logins, and the freedom to add as many users as you need at the right access level. Underneath that, the platform runs server-level security hardening, intrusion prevention and automatic malware scanning on every site, so the roles you set are backed by infrastructure-level protection rather than standing on their own.

Sources