Your contractor disappeared. What’s left of your website?

You need to change the phone number on your website. A routine job: the old number no longer works, you have a new one, and all that’s left is to replace a few digits. You message the person who built the site. One message. Then another. Then one where “Hello” sounds like a last attempt to preserve diplomatic relations.

No reply.

Meanwhile, the website is alive and well. The buttons work, the logo is where it should be, and even the animation still runs-the one you spent longer approving than the company name. Only potential customers are calling a dead number. And for the first time, you seriously ask yourself: where does this website actually live, and who can change it?

This is where you discover that “we commissioned a website” and “we can manage it” are two different stories. The first has an invoice and a good-looking result. The second also has access, clear responsibilities, services that are paid for, and a way to bring in a new specialist without holding a séance.

This article will help you check the second story. Ideally, while your contractor still replies more often than a comet returns to the Sun.

Imagine a café. You can walk into the dining area, see your menu, and even straighten the little sign on a table. But the key to the premises, the lease, and access to the electrical panel are all with the person who once helped with the renovation. You can keep working. Until the first time you actually need the key.

You can end up with a similar dependency on your website. You open a page and see your business, but behind it are several separate parts. The domain is an address such as example.com. Hosting is the service where your website runs. The admin dashboard lets you change the content. Files and a database store what the site is made of. Email receives enquiries. And the form on the page still needs somewhere to deliver them.

These parts don’t all have to be managed by the same company. The domain might be with one provider, hosting with another, and business email with a third. That’s fine, as long as you know who is responsible for what and how to get in.

The trouble starts with the answer: “I don’t know. Serhii set all that up.”

Serhii may be a wonderful person. This isn’t a question of his character. He could change jobs, lose his phone, or stop working with you. Your business needs a way to carry on in each of those situations. Control over access is a normal part of handing over the work, just like receiving the final design or agreeing where enquiries should go.

If the website was sold as a “turnkey” service, it’s worth checking exactly what the result was supposed to include. We’ve already written about the gap between an attractive package name and a clear agreement in “Turnkey Services: Avoid Misunderstandings”.

It’s easy to overlook a domain. It’s short, you can’t show it off in a presentation like a new design, and the word “registrar” sounds as if someone is about to ask you to take a number and produce a copy of your passport.

But that address is printed on your packaging, in your Instagram profile, on your business cards, and in your ads. Losing control of it is a bigger problem than “we’ll hire another developer”.

Find the name of the company where the domain is registered, and check whether you can sign in to your account. See which email address receives notifications, when the paid registration period ends, and how you can recover access. If all the emails go to your contractor, ask them to set a contact address your business controls. Think through the recovery address too: it shouldn’t disappear along with the service you’re trying to regain access to.

There’s an important difference between access to the account and the details of the person or organisation the domain is registered to. Check both. If anything is registered in the contractor’s name, work out the procedure for changing it with the registrar, rather than simply passing over a password and pretending the matter is settled.

Don’t rush to transfer a domain just because there’s a button for it. ICANN’s domain transfer FAQ describes the conditions and restrictions for domains covered by its policy. Check the procedure for your particular domain extension with your registrar. Your first task is simpler: know where the address is registered, who manages it, and how to avoid missing its renewal.

Imagine two hypothetical businesses. The first owner receives the domain invoice directly and can invite a specialist into the account. The second sends the contractor money every year with the reference “for the internet” and doesn’t know the provider’s name. Both websites work today. But only the first owner knows how to keep things running without that particular person.

The next welcome discovery: you have a password for the website. Can you breathe a sigh of relief? A small one. Then check what that password actually lets you do.

An account for editing text may not let you add another administrator, install updates, or obtain a backup. And access to the website’s admin dashboard doesn’t, by itself, give you access to the hosting account. It all depends on the platform and the permissions assigned to you.

So check by doing. Can you invite another specialist with their own user account? Can you see the list of users? Can you find the hosting provider, payment status, and support? If you don’t know, ask someone to explain and show you. A screenshot that says “Administrator” is reassuring, but signing in successfully from your own device is more reassuring still.

You don’t need to become a developer. A restaurant owner doesn’t have to repair the fridge either. But it helps to know where it is, who to call, and why the repair technician should be able to come through the door rather than track down the former chef.

Give a new specialist their own access with the permissions they need. Posting the main password in a group chat is convenient until it quickly turns into a mystery: who’s using it, where it’s been saved, and whether you now need to change it every time the team changes. If the service supports user invitations and roles, use them.

Pay attention to two-factor authentication too: an extra check when signing in, for example through an app. If the code only reaches your contractor’s phone, your password still requires their involvement. The person responsible in your business should understand the recovery process, and backup codes should be stored securely, away from everyday messages.

“We have backups” is a lovely sentence. You immediately want to add: where, from what date, and who checked whether they can actually restore the website?

Because the backup might turn out to be a folder called site_final_really_final, downloaded before launch. Since then, you’ve added new products, changed prices, and started taking orders through the website. The copy patiently preserves the past. Rather like your school graduation photo: definitely yours, but of limited use to today’s business.

What matters here is knowing exactly what gets backed up. For example, a full restore of a typical WordPress website needs both the files and the database. The files include themes, plugins, and images; the database holds posts and other site data. The official WordPress backup documentation explains this directly. Downloading only the website folder and expecting a full restore may not be enough.

A different platform will need a different set of components. A website builder may have its own export and recovery options; a custom-built website may need separate instructions for getting it running. You don’t need to demand the same archive from every website. You need a clear answer: what are we restoring, from what, and into which environment?

Ask a specialist to test the restore in a separate test environment, without overwriting the live website. Depending on the business, the check may cover pages, images, products, signing in to the admin dashboard, and a test form submission. The test mustn’t create real orders, charge anyone, or flood customers with emails.

Another practical recommendation: keep a copy you can access separately from your main hosting. Otherwise, a problem with the hosting account could cut off access to both the website and its rescue plan at the same time. The date of the backup, how often it’s updated, and protection for the data it contains matter too.

This doesn’t mean every loss can be fixed painlessly. New orders may have arrived between the last backup and the failure. But knowing that limit is much more useful than discovering it during recovery.

Sometimes the website handover goes well, but everything that helps you understand how it’s performing stays with the specialist. You receive a monthly report but can’t open the advertising account. You see a traffic chart in a presentation but don’t know where the analytics are. Nice charts: yes. Access: no. Your business is running on “trust me, I checked”.

Ask exactly which accounts hold your ads and analytics, and what permissions your own user account has. Record the account IDs: they help you avoid confusing the right account with a test account or an old one. Also check who manages payments, who receives important notifications, and how to invite a new specialist.

Google Ads has different access levels with different capabilities, listed in Google’s official help. Agencies also use separate manager accounts. Their “ownership” designation within the platform describes a set of administrative permissions; don’t draw conclusions from a single word in the interface. The manager account help page explains the relationship in detail. The practical aim is to make sure your business has access you’ve actually tested and understands how to change contractors.

In Google Analytics, access can be granted at account level or for an individual property, the particular analytics entity you’re working with. Adding and changing users requires the appropriate administrator role; higher-level permissions affect the levels below. This is described in the Google Analytics documentation. Being able to see a report doesn’t, by itself, tell you whether you can manage the access you need.

Still, don’t remove the contractor from every service in one go before you understand the connections. Forms may be sent through a separate email service, events may be configured through Google Tag Manager, and enquiries may feed into a CRM, a customer relationship management system. Before changing access, map those connections and check the handover.

If you need to work out exactly what’s being measured and where the data goes, that’s an analytics setup task. And to check an advertising account and how results are measured, you can start with our Google Ads page. The name of a service won’t fix anything on its own; the useful result here is clear access, clear connections, and a system you’ve checked is working.

Not every dependency on a contractor began with bad intentions. At the start, everyone wanted to get the site live, someone created the accounts that were needed, and a proper handover never happened afterwards. The same “afterwards” where the price-list update, new photos, and your holiday are already waiting.

So start with a calm request. Rather than “give everything back immediately, I know what’s going on”, try “we’d like to organise access and the project handover”. Ask for a list of services, access that the person responsible in your business has tested, and a description of what’s needed to keep things running.

You could write:

For a custom-built website, also ask for the source code, instructions for getting it running, and a list of external dependencies. For a website built on a website builder, ask about project transfer options and export limitations. For paid plugins, fonts, photos, and other materials, ask about the terms of use and what you need to keep paying for. Having access to a file doesn’t, by itself, explain its licence.

Check the scope of the handover against your contract and agreed terms. Not everything the contractor used automatically becomes a separate product they have to give you: an agency’s shared tool, for example, may serve several clients. In that situation, you need clear boundaries, access to the data available to you, and an agreed way to continue working.

If the agreement is buried among voice messages and “👍” reactions, save it in one readable record. The approach in our article about agreements in chats can help. You don’t need to write a dissertation. You need both sides to understand the same thing about what’s being handed over and how you’ll check the result.

Put together a short table for yourself. Four columns are enough: the service, what it does, who is responsible within the business, and when you last checked that you could sign in. Don’t store passwords in this table: they need secure storage with controlled access.

Then work through these checks in order:

1. Sign in yourself. The domain account, hosting, admin dashboard, main email, advertising account, and analytics, wherever your business uses them. Don’t treat the contractor’s open session as proof that you have access.
2. Check your permissions. Can you invite a new contractor? Which changes can you make yourself, and which require another administrator?
3. Check account recovery. Which contact details and verification methods are set up? Does the person responsible in your business control them? Don’t reset working passwords just as an experiment.
4. Find payments and renewal dates. The domain, hosting, email, and licences. Record who receives the invoices and how they’re notified about renewal.
5. Ask for a backup check. Where is it, what does it contain, what date is it from, and can it be restored in a test environment?
6. Send a test enquiry. Agree on the test beforehand, confirm that the enquiry is received, and check that it doesn’t trigger unnecessary actions in your live systems.

Suppose you own a small workshop. You renew the domain yourself and can access the admin dashboard, but the form says “Thank you!” and nobody knows what happens to the enquiry after that. In this hypothetical example, the first conclusion would be to investigate enquiry delivery. You don’t need to replace the whole website for that yet. A success message on the page doesn’t prove that an email or CRM record was actually received.

Another hypothetical situation: the website runs on a platform where the project sits in the agency’s account. You only have viewing access. Here, you first need answers about transferring the project, exporting it, and paying for it going forward. It’s hard for a new specialist to help when their first job is to guess what you actually bought.

After checking, write down the specific gaps: “we don’t have access to the registrar”, “account recovery depends on someone else’s phone number”, “the backup hasn’t been tested”. You can work with statements like these. “It all feels a bit unreliable” is a fair feeling, but a weak brief.

First, record what still works and what you have access to. Save correspondence, invoices, the names of services you know about, and account IDs. Obtain the copies of data available to you. Don’t publish passwords, tokens, or backup codes when asking for help, even if you’re very tempted to show just how bad things are.

Contact the official support team for the particular provider. A registrar, a hosting company, and an advertising platform have different verification and recovery procedures. What they can do depends on the circumstances and the evidence you can provide. A promise of “we’ll get everything back, just pay us” sounds lovely, but without checking the accounts, it’s still only a promise.

If you bring in a new specialist, start with an inventory and a plan: what’s accessible, what can be preserved, where the dependencies are, and which changes will affect the live website. Agree on a backup before changes and checks afterwards. Don’t begin by deleting users en masse, reinstalling the website, or changing every setting. It’s very easy to turn one problem into a gripping three-season series.

Perhaps the site needs moving. Perhaps restoring access and configuring the form will be enough. That should be a conclusion of the check. Having a new developer doesn’t automatically mean the old website belongs in the bin.

Your first step today: find the account where your domain is registered and check that you can sign in yourself. If that’s in order, move on to hosting. If it isn’t, you’ve already found a specific issue to resolve while the website still works.

A good working relationship with a contractor can last for years. It’s just better when it rests on value and trust, rather than the fact that the only key to your business is on their phone.