Giving a contractor website access should start with the job they need to do, not with the easiest account to share. Write down the task, give the narrowest access that can complete it, set an end point, and decide how you’ll verify both the work and the access removal.
That sounds formal for a small job, but it solves a very ordinary problem: six months later, nobody remembers which login was shared, whether the contractor created another account, or which outside services they could reach.
Translate the job into permissions
“Work on the website” is not a permission plan. A writer may need to edit drafts but not publish them. A designer may need media and page access but not user management. A developer changing plugins may need broader temporary access, plus hosting or deployment access that WordPress itself cannot provide.
WordPress roles are bundles of capabilities. The official roles and capabilities documentation makes the important point visible: Administrator access includes powerful tasks such as managing plugins, themes, options, and users. Do not make somebody an administrator merely because a lower role was inconvenient. Identify the blocked task first, then decide whether the role, a temporary technical path, or your own involvement is the right answer.
Use an individual account
Create or approve an account that belongs to one person or vendor relationship. Do not hand over your own login. An individual account makes the change record easier to understand, keeps your credential private, and can be removed without interrupting your access.
Record the person’s name, company, account username, approved task, systems they can reach, start date, expected end date, and who can extend the work. If the contractor needs hosting, analytics, domain, email, or payment access, list each one separately. “Website access” doesn’t tell you which systems are exposed.
Prepare for the changes their access allows
Some work genuinely requires high privilege. Treat that as a reason for stronger change control, not as evidence that the access is harmless. Before plugin, theme, database, DNS, or checkout work, confirm a usable backup or rollback path and name the changes the contractor is authorized to make.
A good access note also says what is out of scope. Updating one plugin doesn’t authorize installing three more, changing the theme, creating new administrators, or modifying unrelated settings. If the job expands, update the authorization before the work expands.
Close the loop
At completion, verify the promised result, collect operating notes, and review every access surface you listed at the start. Disable or remove access that is no longer needed, rotate any credential that could not be individually revoked, and keep evidence of what changed.
For an existing site, use the same discipline in reverse with a WordPress user access audit. And before a higher-risk change, write a rollback plan that names the stopping condition.
The contractor may be completely trustworthy, and setting these limits protects both of you. You’ll each know what work was agreed, what access it needs, how you’ll check it, and when that access ends.
TechDex Presents…
Flashback to the ’90s
Get 2026 services at 1990s prices.
For a limited time, I’m rolling prices back on six focused small-business services. Choose one service for $800, or choose two for $1,200. Nothing is purchased here—I’ll review your request and confirm the scope with you first.
For related website work, explore this Rewind service:
The campaign form lets you choose one or two services and request a follow-up. It isn’t a checkout, and you won’t be billed when you submit it.