WordPress · November 4, 2026 · 8 min read
How to Give a Freelance Writer Access to WordPress
Contributor if you review before publish, Author if you review after, Editor only for whoever manages other writers. Admin is a code decision, and a freelance writer never needs it.
By FluxWriter
Give a freelance writer WordPress access without admin rights and you have already made the decision that matters most. WordPress ships with five roles by default, and only one of them can install code that runs on every page of your site. A writer needs none of that to write. This covers which role matches which review workflow, what each one can quietly break, and how to close the account cleanly when the work ends.
Admin Is a Code Decision, Not a Writing One
An Administrator on a standard single-site WordPress install can install and activate plugins and themes, change site settings, create and delete other user accounts, and edit any existing account including yours. None of that is a writing capability. It is an infrastructure capability that happens to sit in the same dashboard as the post editor.
That overlap is the whole problem. The writer asks for "access", you open the user screen, and the role that obviously works is the one at the bottom of the list. Administrator works for every task because it permits every task. It is the path of least thought, not the path of least risk.
The realistic failure here is rarely dishonesty. A freelance writer may hold logins to a dozen client sites, work from a personal laptop, and reuse a password somewhere they have long forgotten about. When one of those credentials leaks, whoever has it inherits whatever the account could do. If that is Contributor, they get a pending draft queue. If it is Administrator, they get the ability to upload a plugin, and uploading a plugin is the ability to run code on your domain.
Contributor, Author and Editor Map to Who Reviews Before Publish
The role follows from your review workflow. Either someone reads the post before the public does, or nobody does, and every other consideration is secondary to that.
If that reader is you, every time, the role is Contributor. A Contributor can write and edit their own posts and submit them for review, but cannot publish anything and cannot edit a post once it has gone live. On a default install a Contributor also cannot upload images, which is the friction that pushes most owners to upgrade them within a fortnight. Either your reviewer adds the images at approval, or you accept that the role does not fit the way you actually work.
If nobody reads it first and you are reviewing after the fact instead, the role is Author. An Author publishes their own posts, uploads media, and can edit and delete their own published work. They cannot touch a post written by anyone else. This is the honest default for a trusted freelancer on a content retainer, and it is the role most small sites should be using.
Editor is a management role, not a writing role. An Editor publishes, edits and deletes anyone's posts and pages, moderates comments, and manages categories and tags. Give it to the person who runs your other writers, or to a long-term contractor who genuinely owns the blog. Giving it to a writer you hired last week because the upload button felt awkward is a poor trade.
One caveat before you rely on any of this. Roles are editable. Membership plugins, ecommerce plugins, page builders and role editors all add capabilities to existing roles. "Editor" on your site is whatever your plugins have made it, not necessarily what WordPress shipped.
Each Role Breaks Something Different When It Goes Wrong
The table below describes WordPress core defaults on a single-site install; the worst-case column is an illustrative judgement rather than a measured figure, and your own plugins may have widened any row in it.
| Role | Publishes without review | Uploads media | Realistic worst case if the account is misused |
|---|---|---|---|
| Subscriber | No | No | Reads its own profile. Almost no blast radius. |
| Contributor | No | No | Fills your pending queue with drafts you have to delete. |
| Author | Own posts only | Yes | Publishes something unreviewed, deletes its own back catalogue, uploads a file nobody vetted. |
| Editor | Any post or page | Yes | Rewrites or deletes your entire published library, pages included, and can place raw HTML on a live page. |
| Administrator | Any content | Yes | Installs code, changes your email and password, locks you out of your own site. |
Two rows deserve a note. Editors and Administrators on a single-site install can save unfiltered HTML in a post, so an Editor-level account is enough to put a script tag on a live page; on a multisite network that capability is held back for network administrators. And the Administrator row is the only one where the damage is not confined to content. An account that can edit other users can change your email address, which is the same thing as owning your password recovery.
"Just Make Them Admin For Now" Is How Sites Get Defaced
Temporary admin is not temporary. It gets granted on a Tuesday because something is blocked, and it is still sitting there two years later when the freelancer's old email account turns up in a breach. Nobody schedules the downgrade.
Work out what is actually blocked before you escalate. Three requests cover most of it. "I can't upload images" is solved by Author. "I need to fill in the SEO title field" is usually solved by Author or Editor too, because most SEO plugins expose their fields to anyone who can edit the post. "I need to install a plugin" is the genuine admin task, and the answer there is that you install it once yourself rather than handing over the capability permanently.
Three habits do more for safety than the role choice itself. Create one account per human, never a shared writer login, so revisions stay attributed and you can remove one person without disrupting anyone else. Let WordPress send the new user its own account email with a password-set link, rather than choosing a password yourself and sending it over chat. And require two-factor authentication on any account that can publish, which means installing a plugin, because core does not provide it.
Revoking Access Takes Four Steps, Not One
Changing the password is not revocation. Work through the account properly on the day the engagement ends, not the week after.
First, remove the user. When you delete a WordPress user who has written posts, it asks whether to delete their content or attribute it to another user. Attribute it, unless you genuinely want the archive gone. Demoting to Subscriber is the reversible version if you would rather keep the account dormant, but a dormant account is still a credential somebody else holds.
Second, revoke any application passwords on that profile. Those are separate credentials used by tools and integrations, they live on the user's profile screen, and you should treat them as independent of the login password rather than assuming a password change clears them. Deleting the account removes them with it, which is one more argument for deletion over demotion.
Third, look for the things that outlive the account. Scheduled posts stay scheduled and will publish on their date. Drafts and revisions stay in the database. Any third-party access you granted alongside WordPress, whether that is Search Console, analytics, a stock image subscription or a staging login, is untouched by anything you do inside the dashboard.
Fourth, treat the unpublished work as a paperwork question rather than a dashboard one. What happens to drafts that were written but never published, and who holds what, is governed by your agreement with the writer. Check what that agreement says before you delete anything, and if it says nothing on the point, that is the gap to close in the next one.
Drafts Can Arrive Without Anyone Logging In
There is a third option beyond "they log in" and "they email you a document". WordPress exposes a REST API, and application passwords let an external tool authenticate as a named user without ever touching the interactive login screen. Drafts appear in your dashboard ready for review, and no browser session exists for anyone to hijack.
The role logic does not disappear, it moves. An application password inherits the role of the user it belongs to, so a machine account set to Contributor can create pending drafts and nothing else, while one set to Author can publish. Create a dedicated user for the integration rather than hanging it off a person's account, name it after the tool so the next person understands what it is, and you can cut the whole connection from one screen without disturbing anybody's login.
Two checks before you plan around this. Some hosts and security plugins restrict the REST API or disable application passwords, so confirm yours are available before you promise a workflow that depends on them. And an integration account is still an account. It belongs on the same review list as every human one.
FAQ
Can a Contributor upload images in WordPress?
Not on a default install. The Contributor role does not include the media upload capability, so the writer either supplies images separately or your reviewer adds them at approval. If that is unworkable in practice, the usual answers are to move the writer to Author or to use a role-editor plugin that grants upload to Contributors specifically.
Should my whole freelance team share one writer account?
No. A shared login destroys attribution, so the revision history cannot tell you who changed what, and you cannot remove one writer without resetting the password for everybody. One account per person costs nothing and turns offboarding into a single action.
Do I need a plugin to limit what a writer can do?
Usually not. The core roles already cover the common cases: review before publish, publish without review, and manage other people's work. Reach for a role-editor plugin only when you need a specific mismatch fixed, such as a Contributor who must upload media, and recognise that every custom capability is one more thing to audit later.
The Practical Takeaway
Open Users in your dashboard this week and filter by Administrator. For each name, ask whether that person needs to install code on your site. Anyone who does not should be an Editor, an Author or gone, and anyone you no longer recognise should be gone today. Then decide the default for your next hire before you need it: Contributor if you review before publish, Author if you review after, with a unique account and WordPress sending the invitation email itself. The first thing to do is count how many administrators your site currently has.
FluxWriter connects to WordPress this way too: it authenticates with an Application Password, recommends a dedicated Editor-role user rather than a person's login, and publishes under that user, so the whole connection is one account you can find and remove on the same Users screen as everyone else.