A neighbourhood bakery had a website built by a friend five years earlier, then moved to a cheaper plan when the friend stopped taking calls. The domain was never moved, and nobody remembered the login for the old account.
Meanwhile, the bakery's map listing still linked to that address. Customers who tapped the website button saw a parked page full of adverts. A regular finally mentioned it, rather dryly, over a loaf of rye.
Getting back into the registrar took a week of emails and a photo of a utility bill. The owner then moved everything into accounts under her own name and kept the logins in a folder at the shop. It is a composite, but a very ordinary one: small businesses lose control of their domains far more often than they lose them to attackers.
How the site was set up in the first place
The website had been a favour. A friend who did a bit of web work offered to put something together when the bakery opened: a home page, opening hours, a photo of the counter, a menu of breads and a phone number. He registered the domain for her because it was quicker than explaining the process, and he put it in his own account at a registrar he already used. He also bought hosting for it from the same place and set the email address on the account to his own.
Nobody thought this was strange. The site worked, the bills went to his card, and she paid him back in cakes. For two years it ticked along.
Then he moved abroad for work, replies slowed down, and eventually stopped. The bakery, wanting to cut costs, signed up for a cheap shared plan elsewhere and had a template site put up in an afternoon. This new site lived at a different address, a free subdomain from the plan provider. The old domain was never mentioned again, because it seemed to belong to the old site.
What the customers saw
Nobody noticed at first, because nobody at the bakery typed the old address. The Instagram account pointed at the new site. The printed cards pointed at the new site. But the business listing on the map service, set up in the early days by the same friend, still carried the old domain in its website field.
Anyone who looked up the bakery on a phone, tapped Website and landed on the old address saw a page of generic adverts, loans, car insurance, a search box, and no bread. Some customers assumed the bakery had closed. A few, as it turned out later, had gone to the café down the road. The owner estimated lost custom only afterwards, and nobody could say how much, which is itself a lesson: a dead link rarely produces a complaint, only an absence.
Finding out who controlled the domain
The first step was to find who the domain was registered to, and where. A WHOIS or RDAP lookup gives the registrar and the nameservers even when the contact details are hidden by privacy settings.
$ whois example.com | grep -iE "registrar:|name server|expir"
Registrar: Example Registrar Ltd
Registry Expiry Date: 2026-11-02T00:00:00Z
Name Server: ns1.parking.example
Name Server: ns2.parking.exampleTwo things stood out. The nameservers belonged to a parking service, which explained the adverts. And the expiry date was only a few weeks away. If nobody renewed it, the domain would lapse, pass through a grace period and eventually be offered to anyone who wanted it. The bakery's old name, with five years of links and a map listing pointing at it, would be very attractive to someone selling adverts.
That turned a mild annoyance into something with a deadline.
Getting back in
The account email was the friend's old address, which still existed but was checked rarely. A password reset would go straight to him. So the owner did two things in parallel: she messaged him on every channel she could think of, and she contacted the registrar's support to say the domain belonged to her business.
Registrars are careful about this, rightly. Handing a domain to whoever asks would make theft trivial. Their request was a form, a photo of a utility bill showing the bakery's name and address, a copy of the business registration, and a note from the friend if one could be got. It took a week of replies, because each one came with a new document to find.
In the end the friend answered a text from a mutual acquaintance, agreed to forward the reset and approve the transfer, and the registrar changed the account holder. He was embarrassed and perfectly helpful. The week was the cost of nobody having written down who owned what.
Putting it back together
With control back, the work was short and she did it in a particular order, so that nothing broke twice.
- Renewed the domain for several years and turned on auto-renew, with a card that does not expire this year.
- Changed the account email to a shared mailbox for the bakery, and put two-factor sign-in on it.
- Pointed the domain at the current site, and set up a redirect from the old address so that every old link still lands on the live page. The redirect generator writes the rules.
- Updated the map listing, the social profiles and the printed cards to the same single address.
- Wrote the registrar, the account email, the renewal date and the support contact on one sheet of paper, in a folder at the shop.
She also lowered the lookup delay for the change by checking the TTL planner first, though in this case the old records were so neglected that the change showed within the hour.
Who should hold what
The underlying mistake was not the cheap plan or the departed friend. It was that the three things a website depends on, the domain, the hosting and the email address on the account, were held by three different people or by nobody. Once those are in the business's own name, a developer leaving is an inconvenience rather than an emergency.
| Item | Before | After |
|---|---|---|
| Domain registration | Friend's account, his email | Bakery's account, shared mailbox |
| Renewal | Manual, his card | Automatic, the bakery's card |
| Hosting | New plan, owner's name | Same |
| Map listing | Old domain | Current address |
| Logins | In nobody's head | On paper at the shop, plus a password manager |
One more safeguard worth asking the registrar about is a transfer lock, which stops the domain being moved away without an authorisation code. It is usually on by default, and it is the reason the registrar insisted on paperwork rather than a phone call. Leave it on, and know where the authorisation code can be found when you do want to move.
What changed afterwards
The domain is the part of a website that is yours alone, and it is the part most likely to sit in somebody else's account. Check who is on the registration, make sure the email is one you can read, renew automatically, and keep the details where a stranger could find them if you were away. The cost of doing it early is an hour. The cost of doing it late was a week of bills, forms and lost customers.