Most businesses could not answer, today, where their website is hosted, who holds the account, or what would happen if that account stopped being paid. Not through carelessness. Somebody set it up years ago and it has worked ever since, which is exactly the condition under which nobody looks.
It costs nothing to know and it is genuinely awkward to find out in a hurry, which is always when you need to.
The four places it can be
Everything your business runs on sits in one of four places, and the differences matter more than the technology does.
Somebody else’s product. Your accounting package, your booking system, your email. You pay a monthly fee, they run it, you have an account. You are a tenant. You cannot break it and you cannot take it apart, and if they change the price or close down you have limited options.
Hosting you rent. A web server somewhere, with your website on it. You control what goes on it, somebody else keeps the machine running. This is where most small business websites live and where most people are vaguest about the details.
A platform. Microsoft 365, Google Workspace and the like. Part product, part place to build things. You own the data, they own the environment, and leaving is possible but rarely quick.
A machine in your building. Less common than it was, and it has not vanished. A server in a cupboard, or somebody’s desktop that everyone quietly depends on. Cheapest until the day it is not.
Why it matters, in the moments it bites
Nobody needs this information on an ordinary Tuesday. It becomes urgent in five specific situations, and by then it is a scramble.
- Something is down and you do not know who to ring.
- You want to change supplier and discover the account is not in your name. This happens with domains constantly and it happens with hosting just as often.
- The person who set it up has left, and the recovery email is theirs.
- A card expires and something quietly stops renewing. Most services warn the billing contact, which may be somebody who no longer works there.
- Someone asks a question about your data, a client, an insurer or a tender, and you cannot say where it is kept or who can reach it.
Four of those five are account problems rather than technical ones. That is the useful insight here: the risk is almost never the server. It is who holds the login.
Three situations, worked through
A shop whose website is “with the lad who built it”. He has been reliable for years, so nothing has ever forced the question. The website, the domain and the hosting are all in his personal account, billed to his card, and the business reimburses him. It works perfectly until he emigrates, gets busy, or falls out with them.
A practice with a server in the back office. It holds the files, it is backed up to a drive beside it, and it has run for six years. The backup being in the same room as the server is the entire problem, and it is invisible until there is a flood, a fire or a theft.
A firm on a platform they have outgrown. Everything is in one product, which is fine, but nobody has ever exported anything. They do not know whether they can leave, only that they have not tried. Being able to get your data out is a different question to owning it, and the time to check is before you want to.
The list worth making
One page. Not a project, and not something that needs anyone technical. For each thing the business depends on, four columns:
- What it is. The website, the email, the booking system, the file storage.
- Who the account is with, and crucially whose name and email are on it.
- Who pays for it, and on which card.
- Who to contact when it breaks.
Most businesses find at least one row they cannot complete, and that row is the actual finding. It is usually the one nobody has thought about in years, which is precisely why it is the risk.
Five things worth doing
- Make the list. An hour, once, and it is the whole exercise.
- Check whose email is on each account. If it is a person rather than the business, that is the thing to change first.
- Use an address that outlives people. Something like accounts@ rather than an individual’s, so a departure does not take the recovery route with it.
- Confirm the backup is somewhere else. A backup in the same room as the thing it protects is a copy, not a backup.
- Try exporting something from whichever product holds the most important data. Finding out you can is worth a great deal; finding out you cannot is worth more.
Common misconceptions
- “We paid for it, so we own it.” Paying for something and holding the account are different, and it is the account that decides what you can do.
- “It is in the cloud, so it is backed up.” Sometimes. Many products protect themselves against their own failures and not against you deleting something. Worth checking rather than assuming.
- “Our developer has all that.” Very likely true, and it is still your business that stops if they are unreachable.
- “This is an IT job.” Nearly all of it is admin: names, emails, cards and contacts. The technical part is the smallest part.
The honest summary
There is nothing wrong with any of the four places. A machine in the back office can be fine. A developer holding an account can be fine for years, and usually is.
What is not fine is not knowing, because every one of these becomes urgent at exactly the moment you have the least patience for it. The fix is a page of writing rather than a change of supplier, and most businesses that do it change nothing afterwards. They just stop having a question they cannot answer.
If you make the list and one row will not fill in, say which one. That is usually the interesting one, and it is normally more fixable than it looks.
Common questions
How do I find out who hosts my website?
Start with your own records: search your email for renewal invoices, which is usually faster than anything technical. Public lookup tools will tell you which company the site is served from, though they often show the provider sitting in front of it rather than where it actually lives. Whoever built the site will know, and asking them is not an admission of anything.
Is it a problem if our developer holds the accounts?
Not while the relationship is good, and it is rarely done for any bad reason. It becomes a problem the day you want to change something and they are unreachable. Moving accounts into the business’s own name is usually routine when everyone is on good terms, which is the argument for doing it now rather than later.
Does it matter which country our data is stored in?
It can, depending on what the data is and who is asking. The practical point for most small businesses is simply being able to answer the question when a client, insurer or tender asks it. Reputable providers state where data is held, so this is usually a matter of looking it up once and writing it down.
Should we move everything to one place?
Not for its own sake. Consolidation is easier to administer and puts more of your business behind one supplier and one bill. The thing worth fixing is not the number of places, it is the rows on the list you cannot complete.