Website Horror Stories (and How to Avoid Starring in One)

This Halloween, the scariest thing that can happen to your website is typing your own web address into a browser and finding someone else's site there, or nothing at all. It happens to real businesses every week, and almost every case comes down to one of five mistakes that could easily have been avoided. Below are the five stories, each one either real or really common, along with the safeguard that stops each one happening to you.

Story one: the domain nobody renewed

This one has caught out some very big names, so we'll start with the documented cases before anything that sounds like a campfire tale.

In 2003, Microsoft forgot to renew hotmail.co.uk. The registration lapsed on 23 October and a private individual snapped it up the moment it became available. To his credit, he contacted Microsoft to hand it back. Microsoft largely ignored him until The Register started asking questions about why one of its core UK domains belonged to a stranger. It wasn't even the company's first offence: in 1999 it let passport.com lapse, and a passing good samaritan paid the renewal bill himself to bring Hotmail logins back to life.

In November 2010, the Dallas Cowboys, a franchise worth billions, let dallascowboys.com expire. The domain had been registered since 1995 and cost $9.99 a year to keep. Fans got a parked placeholder page instead of their team's site for around a day, on the same weekend the club was sacking its head coach.

The grimmest version belongs to Sorenson Communications. In June 2016 the company failed to renew a domain that its video relay service depended on, and for nearly three days deaf users couldn't reach 911 through the service. The FCC found the lapse entirely preventable and the company agreed to pay roughly $3 million, a fine plus repayment of subsidies for the days the service was down.

If Microsoft, an NFL franchise, and a federally regulated telecoms firm can all miss a renewal email, your café or salon certainly can. The renewal notice goes to an old email address, or the inbox of someone who left, and the first you hear of it is a customer asking why your site shows adverts for something unsavoury.

What actually happens when a .co.uk lapses. You get more breathing room than most people think. Under Nominet's process, an expired .uk domain keeps working for about 30 days, with a suspension warning around day 23. At day 30 it's suspended, so the website goes dark and so does any email on that domain. Around day 90 it's cancelled and released for anyone to register. For .com and other generic domains, ICANN rules give you a renewal window and then a 30-day redemption period after deletion, though registrars typically charge a hefty restore fee once you're in redemption territory.

The safeguard. Turn on auto-renew at your registrar today, then register the domain for the longest term you can stomach, ideally five or ten years. Set the registrar contact email to a shared address like office@ rather than a person's inbox, and put the expiry date in the business diary anyway. Auto-renew helps a lot, but as story five shows, it can still fail.

Story two: the developer who owned everything, then vanished

There are no named victims for this one, because the businesses it happens to are small and the disputes stay private, but anyone who's worked in web development for a few years has seen it happen, and it usually goes something like this.

A freelancer or small agency builds your site. To keep things simple, they register the domain in their own name, host the site on their own account, and keep the code on their own laptop. Everything works fine until, a few years later, they retire, change careers, fall out with you over an invoice, or simply stop answering email. You now discover that you don't own your domain, can't access your hosting, and have no copy of the code or content. Legally and practically, the thing you paid thousands for belongs to someone you can no longer reach.

Sorting this out afterwards is miserable. Nominet and ICANN both have dispute processes for domains, but they're slow, and they only cover the domain itself, so your hosting account and your code are a separate fight. If the developer disappears entirely, you're often rebuilding from scratch.

The safeguard. It's much easier to sort out who owns what before any work starts. Whoever builds your site, ask for these in writing:

1. The domain is registered with you as the registrant, in an account you control, even if the developer manages it day to day.
2. Hosting is in your name or, at the very least, you have full access to the hosting account as well as a login to the CMS.
3. The source code lives in a repository (GitHub, GitLab, Bitbucket) where your business account is listed as an owner.
4. A handover document exists listing every service the site depends on.

A decent developer won't blink at any of this, because it's normal. If you're commissioning a site and want to know what else belongs in that conversation, our breakdown of what marketing websites cost in the UK covers ownership alongside pricing.

Story three: the night the backups weren't there

In April 2016, the UK registrar and host 123-reg ran a clean-up script against its virtual private servers. The script had a bug, decided that a number of live customer servers were empty, and deleted them. Sixty-seven servers were wiped, and the company then admitted something its customers assumed was impossible: it held no backups of customer VPS data. Customers who kept their own backups were able to restore their sites, while those who'd assumed "the host handles that" lost theirs, in some cases for good. Ross County Football Club's website was among the casualties.

This goes well beyond one host's bad week. Hosts fail, plugin updates corrupt databases, and ransomware (which we cover in our guide to the five cyber attacks that actually hit small firms) encrypts whatever it can reach. Read your hosting agreement and you'll often find backups are your responsibility, or are "best effort" only.

The safeguard. None of this is expensive:

• Keep a backup that isn't at your host. If the host's data centre is the only place your site exists, your "backup" is sitting in the same building as the original, so it goes down with it. Most CMS platforms have backup plugins or built-in exports that can push to cloud storage you control.
• Automate it. If a backup relies on someone remembering to do it, it'll probably stop the week that person goes on holiday. Daily for the database, weekly for files, is plenty for most small business sites.
• Test a restore once a year. Until you've tried it you don't really know it works, and plenty of businesses have discovered at the worst moment that theirs had been silently failing for months.

Story four: the login that left with the staff member

This is another general pattern, and a very common one. The person who "did the website" (a manager, a part-timer, the owner's nephew) set everything up under their personal email. They knew the WordPress password, the registrar login and which of their inboxes the renewal notices went to, and then they left.

Nothing breaks on day one, so it's easy to miss. The site keeps running and nobody notices the keys have gone. The problem only shows up months later when you need to change a price, the domain needs renewing, or you have to act fast because something's been hacked. Then you're doing password resets against an email account you can't read, or pleading with a former employee who may not feel especially helpful. The same failure plays out with social media accounts, where the recovery routes are even less forgiving.

The safeguard. Two habits will cover it:

• Use a shared password manager for business accounts. Bitwarden, 1Password and similar tools have cheap business tiers. Every site-related login lives in a shared vault the owner controls, so a departure never takes a credential with it.
• Put accounts in the business's name. The registrar account, hosting account and CMS admin should belong to office@yourbusiness.co.uk or similar, an inbox the owner can always access. Individual staff get their own named logins where the platform supports it, and removing those logins goes on the leaver's checklist alongside collecting the door keys.

Story five: the card that expired in silence

This is the quietest monster of the lot, and it catches people who did everything else right. You set up auto-renew like a sensible person, with the renewal tied to a company debit card. Cards expire every few years, and when this one does, the renewal payment fails.

The registrar emails you about it, but the message lands in an inbox nobody checks, gets swept into a promotions tab, or goes to whoever set the account up in 2019. So auto-renew quietly stops working, and the clock from story one starts ticking with nobody watching it. The Sorenson case shows how far a missed notice can run when nobody's keeping an eye on the right inbox, and the FCC noted the failure was preventable at several points.

The safeguard. Make sure a failed payment gets noticed:

• Point all registrar and hosting billing at one email address that a human reads weekly, ideally the shared office@ inbox from story four.
• When any company card is reissued, update the stored card everywhere it's used. Keep a list of which subscriptions sit on which card, which only takes about ten minutes to write.
• Once a year, log in to the registrar and check the expiry date, the auto-renew setting and the card on file. It takes two minutes and closes off stories one and five together.

The one-page audit: who owns what

Every story above ends with someone finding out, too late, that they didn't know who held a key. So here's a page to fill in this week. For each row, record the provider, whose name the account is in, the email address attached to it, where the login is stored, and any renewal date.

If you can fill in every row without ringing anyone, you're in better shape than most small businesses. If you can't, each blank cell points to one of the five stories above, so that's where to start.

Do it while the pumpkins are still out

In horror films the characters never check the basement until something's already down there. The website version of checking the basement takes about an hour, which means filling in the table, fixing the gaps and putting reminders in the diary. After that, it's worth doing once a year. Late October is as good a time as any, since the audit will be fresh in your mind and Halloween gives the habit a hook you won't forget.

Every one of these failures, from the lapsed domain and the vanished developer to the missing backup, the orphaned login and the dead card, only carries on as long as nobody's looking, so an hour a year spent checking is enough to keep your business out of stories like these.

---

References

• Microsoft forgets to renew hotmail.co.uk (The Register, 2003)
• Dallas Cowboys Forget to Renew Team Web Site (CNBC, 2010)
• FCC Announces Settlement with Sorenson Regarding Service Outage Investigation (FCC, 2017)
• Furious customers tear into 123-reg after firm's mass deletion woes (The Register, 2016)
• Users rage as 123-reg admits it has no customer data backups (ITPro, 2016)
• .uk renewal reminders and expiry process (Nominet Registrar Resources)
• 5 things every registrant should know about the Expired Registration Recovery Policy (ICANN)