Most solo operators running WordPress sites hand out Editor or Author accounts without thinking twice. A guest contributor needs to draft a post. A VA needs to schedule content. A designer needs to tweak a page. You create the account, pick a role from the dropdown, and move on.
But WordPress user roles aren’t just about what someone can publish—they control what someone can see. And the default permissions expose more than most site owners realize.
What each role actually accesses
WordPress ships with five default roles. Here’s what each one can see and do, with the gaps that catch people off guard:
Administrator: Full control. Installs plugins, changes themes, deletes users, accesses all post types, sees all custom fields. No surprises here.
Editor: Can publish and manage all posts and pages—including other users’ drafts. Can moderate comments. Can see private posts. Cannot install plugins or change site settings. But here’s the catch: Editors can see all content across the site, including unpublished work from other authors. If you’re working on a product launch post in draft mode, your Editor can read it.
Author: Can write, edit, and publish their own posts. Can upload media. Cannot see other users’ drafts or private posts. Cannot edit pages. This is the role most operators think they’re assigning when they want someone to “just write posts.” But Authors can still delete their own published posts after the fact, and they can upload files to your media library with no size or type restrictions unless you add a plugin to lock it down.
Contributor: Can write and edit their own posts, but cannot publish them. Cannot upload files. Drafts stay in draft mode until an Editor or Admin publishes them. This is the safest role for guest writers, but it adds friction—every post needs manual review and publishing.
Subscriber: Can log in and manage their own profile. That’s it. This role exists mostly for membership sites or comment systems that require login. It doesn’t grant access to the WordPress admin dashboard in any meaningful way.
Where exposure happens in practice
The most common leak: Editors seeing subscriber data.
If you’re running a membership site or using a plugin like MemberPress, Restrict Content Pro, or Paid Memberships Pro, Editors can often view the full subscriber list—names, emails, membership levels, and payment history. The plugins don’t always respect WordPress’s user role boundaries. They assume anyone with Editor-level access is trusted with customer data.
Same problem with form plugins. If you’re collecting emails via WPForms, Gravity Forms, or Fluent Forms, an Editor can usually export the entire entry database as a CSV. That means every lead magnet signup, every contact form submission, every quiz result.
Another gap: Authors seeing plugin settings they shouldn’t touch.
Some plugins—especially SEO tools like Yoast or RankMath—let Authors edit meta descriptions and schema markup on their own posts. That’s fine. But if the plugin doesn’t scope its settings properly, Authors might also see site-wide SEO settings, analytics tokens, or API keys in the plugin’s dashboard. They can’t change them, but they can see them. If you’ve pasted a Google Analytics measurement ID or a Mailchimp API key into a plugin settings page, check whether your Author-level users can view it.
How to audit what your users can see
Log out of your admin account. Create a test user for each role you’ve assigned to real people—Editor, Author, Contributor. Log in as each test user and click through the dashboard.
Check these areas specifically:
- Posts → All Posts: Can they see drafts from other users?
- Users → All Users: Can they see the subscriber list and export emails?
- Plugin settings pages: Can they view API keys or third-party credentials?
- Media library: Can they see all uploaded files, or just their own?
- Custom post types (if you use them): Can they access posts they shouldn’t edit?
If you find something you don’t like, you have two options: switch to a more restrictive role, or install a role management plugin like PublishPress Capabilities or Members. Both let you fine-tune permissions at the capability level—”edit_others_posts,” “view_users,” “upload_files”—without writing code.
One non-obvious fix
If you need someone to publish posts but not see other users’ drafts, create a custom role. Use PublishPress Capabilities or Members, duplicate the Author role, and add the “publish_posts” capability. Name it something like “Publisher.” This gives them the ability to publish their own work without exposing them to the full Posts list that Editors see.
For most solo operators, this setup works better than Editor access. You avoid the draft-exposure problem, and you keep tighter control over who sees subscriber data.
Before you hand out the next Editor account, log in as that role and see what you’re actually sharing. It’s more than you think.
Got a WordPress question you’d like answered? Reply to this email—we cover operator problems every week.