Somebody built the site, and now it is yours to look after. Maybe the developer stopped replying. Maybe the person who handled it has left. Maybe you bought the business. Either way you are now responsible for something you did not build and cannot see inside, and the usual instinct — start fixing things — is the wrong first move.
Taking over a website from another developer is mostly an access problem before it is a technical one. Get hold of it first. Understand it second. Change it third.
The five things to get hold of before anything else
None of this is technical work, and all of it becomes far harder once the previous developer has moved on properly.
- The domain registrar login. Not the website — the domain. This is the one that matters most, because whoever controls the domain controls where the site points. Check the registration is in your name or your company name, not the developer’s.
- The hosting account. Same test: whose name and whose email is it registered to? A hosting account in a developer’s personal email is a problem waiting for the day they stop answering.
- A WordPress administrator account of your own. Your own, with your own email — not a shared login that somebody else also uses.
- Wherever the DNS is managed. Sometimes the registrar, sometimes the host, sometimes Cloudflare. Find out which, because email breaks here more often than websites do.
- The most recent backup, downloaded to somewhere you control. Before you touch a single setting.
Those five are your website handover checklist, and they are worth getting in writing. If the previous developer is still reachable, ask for all five in one message. It is a normal request and a reasonable person will hand them over. If they will not, that tells you something useful, and our note on what belongs in a website maintenance contract covers why account ownership is worth agreeing at the start of the next arrangement rather than the end of this one.
What to check in the first hour
Look before you touch. Almost all of this is reading, and it tells you what kind of site you have inherited.
Is anything wildly out of date? Open the WordPress dashboard and look at the updates screen. A site three years behind on core, with plugins last updated in 2021, is a different job from one that is a month behind. Do not update anything yet.
What is actually installed? Look at the plugin list and count. Fifteen is normal. Forty is a warning. Look for two things in particular: plugins that have been deactivated but not deleted, and plugins whose names you cannot place at all.
Is it a child theme? If the active theme is a child theme, customisations were probably made properly and will survive updates. If it is a parent theme that has been edited directly, updating it will erase that work. This single check changes how carefully you have to move.
Are backups actually running? Not “is a backup plugin installed” — is there a recent backup, and where does it go? A backup plugin writing to the same server it is backing up is barely a backup at all.
Does the contact form still send? Submit it yourself and watch for the email. This is the single most common silent failure on an inherited site, because nobody notices a form that stopped working — the enquiries simply stop, and it looks like a quiet month.
The three problems you will probably find
These come up often enough on handed-over sites to be worth expecting.
Licences in somebody else’s name. Premium themes and plugins are usually licensed to whoever bought them. If the developer used their own licence, your site keeps working but stops receiving updates — which quietly becomes a security problem. Check the licence status of anything premium and budget for buying your own.
Nobody knows where the emails go. The site sends enquiry emails somewhere. Find out where, and whether that inbox is still being read. Forwarding to an address nobody checks is the same as not sending at all.
Work that exists only on the live site. Custom code written directly into theme files, with no copy anywhere. It works until an update overwrites it. If you find this, take a copy before you do anything else.
What to fix, and in what order
Resist the urge to modernise everything in week one. On a site you did not build, every change is a change you cannot fully predict.
- Take your own backup and confirm you can restore it. A backup you have not tested is a hope.
- Fix anything that is actively broken — a form not sending, a payment method failing, an expired certificate. These cost money every day they wait.
- Update in small batches, oldest and least risky first, with a backup before each batch. Plugins one or two at a time, not all twenty at once.
- Then, and only then, tidy up. Delete the deactivated plugins. Remove the unused theme. Clean up whatever is left over.
If something breaks during the update stage, our guide on why WordPress websites keep breaking covers the usual causes and how to work backwards to the one that did it.
Decide who is looking after it from here
This is the decision most people postpone, and postponing it is how a site ends up in exactly the state you just inherited it in.
Doing it yourself is a real option for a site that changes rarely, as long as “yourself” means a scheduled hour each month rather than whenever you remember. The month you skip is usually the month something needed attention.
The alternative is somebody looking after it every month — updates applied with a backup taken first, the forms tested afterwards, and a written record of what changed. That record matters more on an inherited website than on one you built, because you are still learning what normal looks like for it.
Whichever you choose, make the account ownership permanent this time. You have just spent a week finding out what happens when it is not.