Start with the task, not the login
Before inviting a contractor into your website, write down what they need to do. “Update the contact page text” is a clearer request than “help with the website.” Ask which parts of the site they need, whether they will work on the live site or a test site, and when they expect to finish. These answers help you choose access that is useful without granting control over unrelated settings.
For example, a writer revising three pages may only need permission to edit content. A developer fixing a form might need access to a test site and certain technical settings. Neither task automatically calls for access to your billing account, domain registrar or every administrator setting. If the work involves those areas, discuss each one separately.
Take a backup before substantial changes and agree on a way to check the finished work. A backup is not a substitute for careful permissions, but it can make recovery easier if an edit breaks a page.
Create a separate account with limited permissions
Use your website platform’s invitation or user-management feature to give the contractor an account in their own name. Do not send them the password for an account your team already uses. Separate accounts make it easier to see who made a change and to remove one person’s access without disrupting anyone else.
Choose the lowest permission level that allows the agreed work. Many platforms offer roles such as author, editor and administrator, though the exact names and abilities vary. Review what a role can actually do before assigning it. If the contractor needs a higher level briefly, grant it for that part of the job and reduce it afterward, if your platform allows.
Ask the contractor to use a unique password and enable multifactor authentication if the platform supports it. Send invitations through the platform rather than emailing credentials. If a tool has no individual accounts, consider whether you can perform the restricted step yourself while the contractor provides instructions, or use another supported access method. Avoid turning a shared password into the default workaround.
Set boundaries before work begins
Put the scope in a short written message: which site or test environment the contractor may use, what they may change, which areas are off-limits, and when access will end. Name a person on your team who can approve a change in scope. This need not be a lengthy policy; a clear email can prevent misunderstandings.
Whenever practical, have the contractor try changes on a test site first. If they must work on the live site, choose a suitable time and ask them to tell you before making changes that could affect visitors, such as replacing a form or changing site navigation. Keep a simple record of what was changed so someone on your team can review it.
Access to a website can extend beyond its dashboard. A contractor may request access to hosting, analytics, a code repository or a third-party form service. Treat each request as a separate decision. Give access only where the task requires it, preferably through an individual invitation with its own permissions.
Review the work and close access
When the contractor says the work is finished, check the result against the original request. Visit the affected pages, try any changed forms and review the site on a phone as well as a larger screen. Ask for a brief handover note covering what changed, anything your team should monitor and where editable files or instructions are stored.
Then remove the contractor’s account or disable it. Also review any separate invitations you granted to hosting, analytics, repositories or other tools. If your platform offers active-session controls, consider ending remaining sessions. Remove access to test sites too; they may contain website content or configuration details even when visitors cannot see them.
Set a calendar reminder for the agreed end date rather than relying on memory. If the project continues, extend access deliberately after checking that the permissions still fit the task. A contractor who returns for future work can be invited again when needed.
Make the workflow easy to repeat
Keep a short checklist for the next project: define the task, confirm the needed systems, make a backup, invite an individual user, select limited permissions, enable available account protections, agree on an end date, review the work and remove access. Assign one team member to own that checklist so invitations do not get overlooked.
The aim is not to make contractor work difficult. It is to give people the access they need for the time they need it, while keeping your organization in control of its accounts. A few minutes spent setting up and closing access is easier to manage than a shared password that remains in circulation long after the project ends.
