You hire a developer because something needs fixing. The checkout is broken. The contact form stopped sending. Your homepage suddenly looks weird on mobile. So you do the normal thing – hand over the keys.
And that’s where small business owners get into trouble.
A lot of website mess starts with totally reasonable access sharing. You trust someone, send your main admin login in WhatsApp or email, and hope for the best. Maybe it works out fine. Maybe. But if that person disappears, does sloppy work, installs junk, or gets their own laptop infected, you’re the one left cleaning it up.
Good news though. You can give a developer what they need without giving away the whole house.
First rule: don’t share your own login
This is the big one. Never send your personal admin username and password to a developer. Not your main WordPress login. Not your hosting login. Not your domain registrar login either.
Why? Because shared logins kill accountability. If five people use the same admin account, who changed the homepage? Who installed that nulled plugin? Who deleted the backups? You won’t know. And later, if you want to remove access, you have to change everything and hope you didn’t miss a place where that password was reused. Messy.
Create a separate account for each person. Always.
If you’re already working with someone who says, “Just send me your admin login,” honestly, that’s a yellow flag. Not always malicious. Sometimes just lazy. But still.
Give the lowest access level that still lets them do the job
Most developers do not need full admin rights for every little task. If someone’s writing blog posts, they don’t need plugin access. If they’re editing product descriptions, they don’t need your DNS panel. If they’re fixing CSS, they probably don’t need access to your payment gateway accounts. Sound obvious? You’d be surprised how often this gets ignored.
Here’s a simple way to think about it:
- WordPress Editor or Shop Manager – good for content changes, products, orders, pages
- WordPress Administrator – only if they truly need plugin, theme, or settings access
- Hosting panel access – only for server-level work, backups, staging, PHP settings, file access
- FTP/SFTP or SSH – only for code or file work
- Domain registrar access – almost never needed for normal site work
If you’re not sure what’s needed, ask them straight: “What exact access do you need for this task?” A decent developer can answer that in one or two sentences.
Vague answers are a bad sign. “I need full access to everything” is not a plan.
Create a temporary admin, then remove it
This is the safest approach for most one-off jobs.
Let’s say you hired someone to fix a broken WooCommerce email template or update a custom plugin. Create them a new admin account with their own email address. Strong password. Unique username. Then once the job is done, delete the account or downgrade it.
Simple. Effective. Easy to forget.
I’ve seen sites where a freelancer got access in 2021 for a two-hour task and still had admin rights three years later. That’s not unusual, which is a little depressing.
If you want to be extra careful, install an activity log so you can see what changed and when. Something like an activity log makes this much less murky if a plugin gets added, a setting changes, or a new user suddenly appears.
Don’t hand out hosting access unless there’s a real reason
WordPress admin access and hosting access are very different animals.
Your hosting panel might contain backups, databases, email settings, file manager access, cron jobs, staging tools, and sometimes billing info too. That’s a lot. If someone only needs to tweak page layout or fix a form, they don’t belong anywhere near that panel.
Same for your domain account. If a developer can change DNS records, they can move email, break the site, or point the domain somewhere else by mistake. Or on purpose. Rare, but it happens.
So keep access seperate. If they need WordPress, give WordPress. If they need hosting, give hosting. Don’t bundle everything together because it’s faster.
Use staging for risky work
If the developer is doing bigger changes – plugin updates, theme edits, custom code, checkout fixes – ask them to work on a staging copy first. Not on the live site where customers are trying to book appointments or place orders.
This matters more than people think.
A live WooCommerce shop with active orders is not the place for “let’s just test this quickly.” Big mistake.
If your current setup doesn’t make staging easy, that’s usually a sign the site wasn’t built with maintenance in mind. This piece on building for maintenance, not just launch explains the problem really well. A website shouldn’t be a fragile ornament that nobody wants to touch.
And if your site is older, patched together, or held up by 47 plugins and hope, getting proper WordPress maintenance in place will save you alot of stress later. Preventing problems is cheaper than emergency repairs. Usually by a mile.
Ask for a list of changes before they start
You don’t need a technical essay. Just something plain.
For example:
- Update Elementor and WooCommerce
- Test checkout on staging
- Replace outdated shipping plugin
- Push changes live after approval
That’s enough.
This does two things. First, it makes the work clearer. Second, it makes random surprise changes easier to spot. If you asked for a form fix and suddenly there’s a new SEO plugin, a disabled cache plugin, and three mystery users, you know something drifted off course.
Not every developer is dodgy, obviously. Most are fine. But structure helps even with good people. Maybe especially with good people.
Protect the login before you invite anyone in
Before adding a developer account, tighten your own access first. Use a strong password manager-generated password. Turn on two-factor authentication. Make sure there aren’t old admin users hanging around from previous agencies, staff members, or that guy who “helped once.”
If your login page is weak, every extra admin account raises the risk a bit. That’s just math.
A basic two-factor authentication setup goes a long way here, and this guide on admin account mistakes that hand hackers the keys is worth a read too. A lot of break-ins don’t start with clever malware. They start with sloppy accounts.
After the job, clean up properly
This part gets skipped all the time. The fix is done, everyone’s busy, and the temporary access just sits there.
Don’t do that.
Once the work is finished:
- delete or downgrade the developer’s account
- change passwords if you shared anything sensitive – though really, you shouldn’t have
- check installed plugins and themes
- review recent user accounts
- confirm backups are still running
- test the site yourself – forms, checkout, mobile, basic pages
Takes ten minutes. Maybe fifteen. Worth it.
If anything feels off after the work – weird redirects, new spam pages, surprise admin users, files changed that nobody can explain – don’t wait around hoping it settles down. Get the site checked and cleaned fast. If it turns out you’ve already been compromised, a proper site cleaning service is the thing to reach for, not random forum advice from 2018.
Trust people, but set boundaries
That’s really the whole game.
You don’t need to act paranoid every time a developer asks for access. But you also don’t need to hand over full control because “they’re the tech person.” Your website is part of your business. Sometimes a big part. Leads come through it. Orders come through it. Reputation too.
So keep ownership. Give access in layers. Remove it when the job is done. Know who has what.
That way, if something goes wrong, you’re not stuck guessing. And if everything goes right, great – you still stayed in control. That’s the point.