Your website does not necessarily disappear if your web designer disappears. The outcome depends on who controls the domain, hosting, website files, accounts, database and third-party services. A well-structured website should be recoverable by another competent developer.
This is one of those risks nobody wants to think about when a project begins.
The designer seems reliable.
The site launches.
Everything works.
Then three years later emails stop being answered.
The agency closes.
The freelancer changes career.
A serious illness occurs.
Or the business relationship simply breaks down.
The client then discovers how much of the website they actually control.
Start with the domain
This is the most important thing to establish.
Who controls yourbusiness.ie?
Which registrar holds it?
Can the business log in?
Can it reset the password?
If the business controls the domain, a replacement website can usually be connected to that address even if the old website itself cannot immediately be recovered.
That is why I am so strong on businesses controlling their own domains.
Losing the site is painful.
Losing the public address as well is much worse.
Then identify where the site is hosted
The website has to live somewhere.
Traditional hosting account.
Managed WordPress host.
Website builder.
Cloud platform.
Something else.
You need to know which service is involved and whether the business has access.
If the designer paid for hosting through a private agency account, recovery may require cooperation from that provider.
If the client controls the hosting/deployment account, the transition is normally easier.
Do you have the website files?
For a static website, the source files can be enough to recreate the deployment elsewhere.
For a WordPress site, the files alone are not necessarily enough because the database contains important site content and configuration.
For a hosted builder, there may be no portable source package in the same sense.
Architecture changes what "backup" and "recovery" mean.
This is why website ownership should be discussed in practical terms rather than simply asking who owns "the site".
What about WordPress?
A WordPress site normally depends on several pieces:
the WordPress files;
themes;
plugins;
uploads;
database;
server configuration;
domain/DNS.
If you have a recent full backup and the appropriate licences/access, another developer can generally work with that much more easily than if the only copy exists on an inaccessible server.
This is one reason genuine WordPress maintenance often includes backup planning.
Static sites can be easier to reconstruct
A static site has a simpler public runtime.
If the business or new developer has the source files, the site can often be deployed again on suitable hosting without recovering a database.
Cloudflare Pages, for example, maintains deployment history and supports rollbacks to previous successful production deployments while the project account remains accessible.
That is useful operationally.
But deployment history is not a substitute for sensible source-file ownership and backups.
The platform account could itself be the thing you lose access to.
What about email?
Be careful.
Business email may use the same domain while being hosted somewhere completely different.
Changing nameservers or DNS in an attempt to recover the website can accidentally break email if existing mail records are not preserved.
This is why understanding DNS matters during a rescue.
Do not treat the domain as though it only belongs to the website.
Third-party services may survive independently
Booking systems.
Payment providers.
Email marketing.
Analytics.
CRM.
Forms.
These may all have their own accounts.
If the client owns those accounts, they can often continue regardless of what happens to the website provider.
If every service was created inside the designer's account, the dependency is much larger.
Again, client-controlled accounts reduce recovery risk.
Worth knowing
Losing contact with the designer does not automatically mean the website is lost. The domain may be recoverable through the registrar, hosting may be in a separate account, and third-party services may still be operating normally. I would avoid rushing straight into a rebuild. First work out what still exists and, especially, protect anything tied to business email before changing DNS or nameservers.
What if I have no access to anything?
Start with evidence.
Invoices.
Old emails.
Domain renewal notices.
Bank statements.
Login details.
Website source.
Any contracts.
Ask the registrar or host what recovery procedures they have.
If a domain or account is registered to the business, the provider may have processes for proving control.
If there is a legal dispute over ownership or access, that may require legal advice.
Do not let a new developer start changing random things before the current setup is understood.
Can I simply copy the live website?
Sometimes parts of a public site can be reconstructed from what is visible.
But that is not the same thing as owning or recovering the original source, backend, licences or content systems.
A replacement developer also has to respect copyright and licence issues.
The first goal should be legitimate recovery of the accounts/assets the business is entitled to.
Rebuilding comes after that.
What I'd do
I would give every small-business site a simple handover record rather than a pile of technical documentation nobody will read. It should identify the registrar, hosting/deployment platform, source location, analytics, forms, important third-party services and who controls each account. The client does not need to administer those systems day to day. They just should not have to become a digital archaeologist if the provider disappears.
Prevention is much easier
The best time to solve this problem is before anything goes wrong.
Know the domain registrar.
Know the hosting/platform.
Keep client-owned access.
Document third-party services.
Understand which subscriptions renew.
Maintain appropriate backups.
Make sure important passwords are not only in one person's head.
This is not bureaucracy.
It is basic business continuity.
Does this mean every client needs to manage everything?
No.
That would defeat the purpose of hiring somebody.
A client can have a developer manage the technical systems.
The important distinction is:
managed does not have to mean inaccessible.
I can configure DNS for a client without making the domain dependent on my personal account.
I can manage a deployment without pretending the client should never know where it lives.
A good service removes work.
It should not remove control.
Why agencies sometimes create lock-in
Sometimes it is an accident.
One central agency account is easier to manage.
Sometimes the platform itself is proprietary.
Sometimes recurring hosting/support is part of the business model.
And sometimes dependency is commercially useful because moving becomes difficult.
I do not think a client should discover that lock-in only after trying to leave.
If a platform cannot be moved, say so before the project starts.
Gavin’s perspective
Built by Gavin's approach
I want the "what if Gavin disappears?" question to have a boring answer.
The domain is controlled appropriately.
The key accounts are understood.
The site can be handed to another competent developer.
Third-party subscriptions are visible.
There is no secret monthly infrastructure arrangement holding the business together.
That is the standard.
Not because I expect to disappear.
Because sensible systems should survive individual people.
The bottom line
If your web designer disappears, recovery depends on what the business can access.
The domain is the first priority.
Then hosting/deployment.
Then website files and databases.
Then third-party systems.
A well-built client relationship should leave enough control and documentation that another developer can take over without a crisis.
Is your current website dependent on one person?
If you are not sure, send me the domain and tell me what access you have.
I can help you work out the current structure before you decide whether anything needs moving or rebuilding.
---