My Web Developer Disappeared, What Do I Do Now?
Practical steps to regain control of your website when your developer has gone AWOL.
Direct Answer
First work out what you actually control: the domain registrar, the DNS, the hosting, and the site files. You often own more than you think, and it’s usually the domain that matters most.
Then lock down what you can reach, change the passwords you can change, and don’t let anything lapse while you sort it out.
Once you’re stable, get someone to take it over properly with a real handover, so you’re not in the same position again next year.
1) Work out what you actually have access to
Before you panic, check what you can still get into. Can you log in to your domain registrar? Your hosting panel? WordPress admin? Your email? Make a list of what you have and what you don’t.
If your developer registered the domain or hosting in their name, that’s a bigger problem, but it’s not unsolvable. Start by checking your invoices and emails for any login details they sent you.
- Check domain registrar access (GoDaddy, Namecheap, etc.)
- Try your hosting login
- Check WordPress/CMS admin access
- Search emails for login credentials
2) Secure what you can right now
If you can log in to anything, change the passwords immediately. If you have hosting access, download a backup of your site files and database. Even if you don’t know what to do with them yet, having a backup means you’re not starting from zero.
If your domain is about to expire and you can’t reach the registrar, that’s urgent. Contact the registrar directly with proof of ownership, they deal with this all the time.
3) Get someone else to take over properly
Find a developer who does this kind of handover work. A good one will audit what’s there, identify what’s missing, and either fix the existing site or rebuild it, depending on what makes more sense.
I’ve taken over sites where the previous developer locked everything down and refused to cooperate. It’s not always pretty, but there’s almost always a way to get your business back in control of its own website.
Implementation Playbook
- 1 Confirm outage impact and affected systems immediately.
- 2 Restrict access and isolate risky components.
- 3 Capture logs, timestamps, and file-state evidence.
- 4 Restore from known-good state where required.
- 5 Patch vulnerable plugins/themes/core components.
- 6 Rotate credentials and API keys tied to the stack.
- 7 Reinstate services with active monitoring enabled.
- 8 Run smoke tests on forms, checkout, and critical routes.
- 9 Document root cause and the exact remediation steps.
- 10 Apply long-term hardening and backup verification.
Common Mistakes to Avoid
- Treating launch date as fixed while scope keeps changing.
- Skipping technical QA because the design looks complete.
- No owner for approvals, causing review bottlenecks.
- Launching without monitoring or backup verification.
- Ignoring mobile conversion flow until after launch.
Follow-up Questions People Ask
Not always. Decide based on risk and exposure. In some cases isolation plus controlled traffic handling is safer than a hard shutdown.
No. Backups restore state, not security posture. You still need root-cause patching and credential rotation.
Immediately. Alerting thresholds should be tightened during the post-incident period while the system stabilises.
LET’S TALK
Tell us about your project. We’ll get back to you within 24 hours. Emergency? Call us directly.