First, what is actually at risk
When the person who built your website stops answering, the website itself is rarely the first thing to fail. The things that fail are the renewals: the domain expiring, the hosting card declining, the SSL certificate lapsing. Each of those takes the site down without warning, and each is fixable in an afternoon if you know where the accounts are and impossible if you do not.
So the first week is not about fixing anything. It is about finding out what you have, where it lives, and who controls it. This is the checklist we run when a business arrives with an inherited site, and you can run most of it yourself.
Day one: find the domain
Your domain name is the one thing you cannot rebuild. Everything else can be replaced; the domain is your address.
Look up who owns it. Any public WHOIS lookup will show the registrar and, unless privacy is on, the registrant. If the registrant is you or your company, good. If it is the developer, their agency or "Domains By Proxy", you need to establish control before anything else.
Then find the registrar account. Search your email for the registrar's name and for words like "domain renewal". If you find a login, sign in and check the expiry date and the payment card. If you find nothing, the developer registered it in their own account. That is recoverable, but it starts with a polite written request and can end with a transfer dispute, so start now.
Day two: find the hosting
Hosting is where the files and database live. It is usually a separate account from the domain, at a company like SiteGround, WP Engine, Kinsta, Cloudways or a reseller you have never heard of.
Search your email again, this time for "hosting", "server", "cPanel" and "invoice". Look at your bank statements for a monthly or annual charge you do not recognise. If you are paying, you have a right to the account. If the developer is paying, the site is one missed payment from disappearing, and you have no say in it.
Once you find the hosting, check three things: the renewal date, the backup schedule, and whether you can download a full backup right now. Do it, even if you do not know what to do with the file. A backup on your own computer is the difference between a bad week and a lost business.
Day three: get into the site itself
For a WordPress site, the admin is usually at your address followed by /wp-admin. Try any login you have been given. If you have none, the password reset only works if the admin email is yours. If it is the developer's, you will need hosting access to reset it from the database, which is exactly why day two came first.
Once in, do not change anything yet. Note the WordPress version, the theme, the plugins, and which ones are showing updates or licence warnings. Take a screenshot of the plugin list. This is what any developer you hire next will ask for.
Day four: check the things that fail quietly
A site can look fine and be broken in the ways that cost you customers. Test these yourself:
- The contact and booking forms. Submit one. Does it arrive? Forms that stopped sending months ago are the most common finding on inherited sites.
- The padlock. Does the browser show the site as secure? An expired certificate will start scaring visitors away within days.
- The phone number and email. Tap them on a phone. Are they still yours?
- The speed. Load the site on a phone on mobile data, away from your own Wi-Fi. If you are counting seconds, so are your customers.
- Google. Search your business name. Is your site the first result, and does the description look right?
Write down what works and what does not. You now have a diagnosis most developers would charge for.
Day five: write to the developer
One clear, polite email. State that you need the following in your name within a set period: domain registrar access, hosting account access, WordPress admin access, and any licences bought on your behalf. List them. Give a date. Keep it factual and keep a copy.
Most vanished developers are not malicious; they are overwhelmed, or have changed careers, or have let a business fold. A clear list with a date gets a response from most of them. If it does not, you have a paper trail for the registrar's transfer process, and for anyone you hire to help.
What not to do
Do not let a new developer "just rebuild it" before you control the domain. A beautiful new site on a domain you do not own is the same problem in better clothes.
Do not delete plugins or change themes to see what happens. Inherited sites are held together by dependencies nobody documented.
Do not pay a rescue company that phoned you. The people who cold-call about your website found your expiring domain in a public database, and that is who they are.
Where a diagnosis fits
If you would rather have someone run this checklist for you and hand back a plain-English report, that is what our $299 diagnosis is. It covers the accounts, the forms, the speed, the security and the fix-or-rebuild question, and it is yours to take to anyone, including a developer who is not us. Most of them end with three fixes and a care plan rather than a rebuild, which is usually the right answer.