I got the call at 6:40 in the morning. A boutique innkeeper I work with, voice somewhere between panic and disbelief, told me her website was “just gone.” Not slow. Not ugly. Gone. A browser warning, a blank page, and a booking engine that had stopped taking reservations sometime in the night. It was the second week of her peak season.
We had her back online in under two hours. But the reason I’m writing this is that the two hours weren’t the expensive part. The expensive part was the eleven hours before anyone noticed, while every single person searching for her hotel hit a dead page and either gave up or booked through an OTA instead. That is the quiet horror of a domain or SSL lapse: it doesn’t announce itself. It just bleeds direct bookings while you sleep.
So let me walk you through exactly what happens, how to diagnose it fast, and the precise order I work in to get a hotel back online. This is the playbook I actually run.
First: figure out which kind of “down” you have
“My site is down” is three completely different emergencies wearing the same coat. Before you touch anything, you need to know which one you’re in, because the fixes don’t overlap.
- Domain lapse. The registration on your domain name expired. The address itself stops resolving. Visitors get a “this site can’t be reached” or, worse, a registrar parking page plastered with junk ads.
- SSL/TLS certificate lapse. Your domain still works, but the little padlock certificate that proves the site is secure expired. Browsers throw a full-screen red warning (“Your connection is not private”) that 95% of guests will never click past.
- DNS misconfiguration. The domain is paid up and the cert is valid, but a DNS record got changed, deleted, or pointed at the wrong server, so the address leads nowhere or to the wrong place.
Here’s the fastest way I triage it from my phone before I’m even at a laptop:
| Symptom | Most likely cause | First check |
|---|---|---|
| ”Site can’t be reached”, no padlock, parking page with ads | Domain expired | Look up your domain’s WHOIS expiry date |
| Full-screen red “Not private” / “Certificate expired” warning | SSL cert lapsed | Click the warning details for the cert date |
| Site loads on one device, dead on another; email also broken | DNS change | Check your DNS records at your host |
| Everything dead AND your hotel email stopped too | Domain or DNS (not SSL) | Domain registrar first |
That last row is the tell I rely on most. SSL problems almost never break your email. So if [email protected] also went dark at the same moment the website did, you’re looking at a domain or DNS problem, and you can stop wasting time poking at certificates.
The cruelest detail about these outages is the timing. Domains and certs expire on a calendar date, not based on traffic. So they almost always die at midnight in some timezone, on a weekend, or over a holiday, exactly when no staff member is watching and exactly when peak-season searchers are most active.
The recovery order I actually follow
When a hotel is down, the instinct is to start clicking everything at once. Don’t. There’s an order, and following it saves you from “fixing” things that were never broken. Here’s my sequence.
Step 1: Confirm the domain is paid and active
Go to your registrar (GoDaddy, Namecheap, Google Domains successor, whoever holds the name) and log in. If you can’t remember who that is, a WHOIS lookup will tell you the registrar and the exact expiry date. If the date has passed, this is your problem and your fix is simple: renew it, right now, and enable auto-renew while you’re in there.
A renewed domain typically reactivates within minutes to a couple of hours. But there’s a catch I’ll cover in Step 4: caching. So renew first, then keep moving.
One thing that scares people more than it should: the grace period. Most registrars give you a renewal grace window (often around 30 days) after expiry where you can renew at the normal price and nobody can take the name. After that comes a redemption period where you can still recover it but pay a stiff redemption fee. Only after both windows close does the domain actually drop to the open market. So if you’re a few days late, breathe. You almost certainly still own it. Just renew immediately, because every day you wait is a day of dead bookings and a day closer to losing the name to a drop-catcher.
Step 2: Check the SSL certificate
If the domain is fine but browsers are throwing security warnings, your certificate expired. Click “Advanced” on the warning screen and you’ll usually see the cert’s valid-through date staring back at you.
Most modern hotel sites use auto-renewing certificates (Let’s Encrypt renews every 90 days automatically; many hosts handle this invisibly). When auto-renewal silently fails, it’s usually because of one of these:
- A DNS record the cert validation depends on got changed
- The hosting plan lapsed, so the auto-renew job stopped running
- The site moved hosts and the new host was never set up to issue a cert
- A manually purchased annual cert simply ran out and nobody renewed it
The fix depends on your host. On most managed hosting, it’s a single “renew SSL” or “force HTTPS” button in the dashboard. If you’re on something more hands-on, reissuing a free Let’s Encrypt cert takes a few minutes. The important part: do not let anyone “fix” the warning by telling guests to click through it. A security warning craters trust and torches conversion, and it absolutely guts your AI-search and book-direct funnel, which I dig into over on our book-direct CRO work.
Step 3: Verify your DNS records
If the domain is paid and the cert is valid but the site still won’t load right, you’re in DNS territory. This is the fiddliest of the three because the records are invisible to guests and easy to fumble.
The records that matter most for a hotel:
- A record (or AAAA for IPv6): points your bare domain at your website’s server IP.
- CNAME: points subdomains (like www) at the right place; often used for your booking engine subdomain too.
- MX records: route your email. If these got wiped, your reservations inbox is down even if the website is fine.
The classic disaster is a well-meaning person logging into the DNS panel to “add a record” and accidentally deleting or overwriting the A record. Compare your current records against any backup, screenshot, or your developer’s documentation. If you don’t have that, your host’s support can usually tell you what the correct values should be. Restore them exactly.
Step 4: Flush the caching, then verify from the outside
This is the step everyone forgets, and it’s why people think their fix “didn’t work.” DNS answers get cached all over the internet, governed by a setting called TTL (time to live). If your TTL was set to 24 or 48 hours, then even after you fix everything, a chunk of the planet keeps seeing the old, dead answer until the cache expires.
What I do:
- Lower the TTL on the affected records to 300 seconds (5 minutes) so future changes propagate fast.
- Check propagation from multiple locations using a public propagation checker, not just my own browser (your browser lies; it caches aggressively).
- Test the site on a phone over cellular data, completely off the office WiFi, because office networks cache too.
Then I verify the thing that actually pays the bills: does the booking engine load and accept a test reservation? A homepage coming back up means nothing if the reservation path is still throwing an SSL warning on the booking subdomain. Test the whole funnel, not the front door.
After the lights are back: protect the SEO
Here’s the part most “site is down” guides skip entirely. Getting back online is triage. Protecting your search visibility is the actual treatment.
The good news, and I want to be honest rather than alarmist here: a short outage of a day or two rarely causes lasting ranking damage if you restore the same URLs quickly. Google recrawls, sees the site is healthy, and moves on. I am not going to promise you escape a perfectly clean recovery with zero ranking wobble, because real life is messier than that, but the odds are firmly in your favor when you act fast.
The danger zone is prolonged downtime. Once an outage stretches past a week or so, you start risking pages getting dropped from the index, and clawing those back is slower and uglier. So speed isn’t just about bookings; it’s about not handing your hard-won rankings back to the OTAs, who are perfectly happy to keep your name-search traffic if your own site is the one flickering. I wrote a whole piece on why your hotel ranks below the OTAs for your own name and an outage is exactly the kind of gift that lets them widen that gap.
Once you’re stable, do these three things:
- Re-submit your sitemap in Google Search Console and use the URL Inspection tool to request indexing on your top pages, so you nudge Google to recrawl rather than wait.
- Watch for crawl errors in Search Console over the next two weeks. A spike in 5xx or DNS errors during the outage is normal; what you want to see is that curve flatten back to zero.
- Check your AI-search presence. Assistants like ChatGPT and Google’s AI summaries cache and re-fetch site content on their own schedules, and a dead site during their crawl window can quietly drop you from answers. If you’re not sure where you stand, our AI visibility (AEO/GEO) work exists for exactly this, and I’d start with is your hotel invisible to ChatGPT.
The outage that costs you the most isn’t the one that lasts the longest. It’s the one nobody noticed for eleven hours during peak, while every direct booking quietly rerouted to a 15 to 25 percent commission you didn’t have to pay.
How to never get that 6:40 AM call again
Recovery is reactive. The whole point is to make recovery rare. Here’s the prevention checklist I set up for every hotel I work with, and none of it is expensive.
- Auto-renew everything, with a card that won’t expire first. The single most common cause of a domain lapse is an expired credit card on the registrar account. Auto-renew is useless if the payment bounces. Put a card on file with a far-off expiry and check it yearly.
- Set calendar reminders 60 and 30 days before every expiry. Domains, SSL certs, and hosting plans. Belt and suspenders. Auto-renew can silently fail; a human reminder catches it.
- Use uptime monitoring. A free or cheap monitor that pings your homepage and booking engine every minute and texts you the moment either goes down. This alone would have turned that eleven-hour bleed into an eleven-minute one.
- Monitor SSL expiry specifically. Many uptime tools also watch cert expiry dates and warn you weeks out. Turn that on.
- Keep a one-page “break glass” doc. Registrar login, host login, DNS panel location, who your developer is, and the correct DNS record values. When the site is down at 2 AM is not when you want to be hunting for passwords.
- Know who actually owns the domain. I’ve seen hotels where a long-gone web designer or a former GM holds the registrar account. Get the domain into an account the owner controls. This is non-negotiable.
A healthy, resilient website is the foundation under every other thing we do, from local SEO and your Google Business Profile to clawing back direct bookings. You can have the best content and the sharpest AI-visibility play in your market, but if the site blinks out during peak, none of it matters. If you want a second set of eyes on your setup before the next holiday weekend, book a free intro call and I’ll walk through your registrar, SSL, and DNS with you. It’s a fifteen-minute check that can save you that 6:40 AM phone call.