WordPress user roles and permissions for small teams after a migration

The 'everyone is admin' trap

On AI builders, access control is simple: you invite someone and they can edit everything. When teams move to WordPress they often recreate that habit by handing every colleague an administrator account. Six months later nobody knows who installed the plugin that broke the checkout, who changed the homepage on a Friday evening, or why a former freelancer still has full access.

WordPress has a proper role system, and spending an hour on it after migration prevents a whole category of accidents and security incidents. The principle is called least privilege: every account gets exactly the rights it needs for its job, and nothing more.

The standard roles, translated to real jobs

Administrator can do everything, including installing plugins, changing themes and deleting the site. Limit this to the owner and the technical partner. Editor can publish and manage all content but cannot touch settings, plugins or the theme; this is the right role for a marketing colleague or content manager. Author can write and publish their own posts but not touch anyone else's; ideal for regular blog writers. Contributor can write drafts that an editor must approve; perfect for guest writers or interns. Subscriber can only manage their own profile; relevant only if you run memberships or comments.

A healthy small team looks like this: one or two administrators, one editor, everyone else author or contributor. When someone asks for more rights, ask which task they cannot do; usually there is a safer way to enable that one task than promoting them to admin.

Custom roles for edge cases

Sometimes the standard roles do not fit. A shop manager who needs WooCommerce orders but no blog access, a translator who should only edit posts in one language, a client who may preview drafts but not publish. WordPress roles are built from individual capabilities, and with a role editor plugin you can assemble a custom role that matches the job exactly.

My advice: keep custom roles rare and document them. A site with eleven custom roles becomes its own puzzle. Write one line per role in the project documentation: who has it, why, and what they can do. Future you, or the next developer, will be grateful.

Accounts are a security surface

Every login is a door. After migration, run through this checklist: remove every account that is no longer needed, especially the accounts of freelancers who helped with the old site. Enforce strong passwords and turn on two-factor authentication for every administrator and editor; it is the single most effective measure against account takeover. Never share one account between colleagues, because shared accounts destroy the audit trail and make offboarding impossible.

Speaking of audit trails: on sites with several editors I install an activity log plugin. It records who changed what and when. That is not about distrust; it is about being able to answer 'what changed since yesterday?' in seconds when something breaks.

Review access every quarter

Roles are not a one-time setup. People change jobs, projects end, responsibilities shift. Put a recurring fifteen-minute review in the calendar: list all accounts, check their roles, remove what is stale, downgrade what is too broad. If your migration partner handles the technical setup, as Convert2WP does for the conversion itself, ask them to configure sensible roles from day one so you start with good habits instead of cleaning up later.