How to keep your website online

Catch what expires, make the site fail cleanly, take load off the origin, and be able to lose a server or restore from backup.

Most outages are not dramatic. A domain or a certificate expires because the card on file did. A platform version goes out of support and the fix you need does not exist for it. A crawler hits the site harder than any visitor and the origin falls over. A server dies and it turns out the backup was never restored, not even once.

This journey goes through those in order: what expires without telling you, how the site behaves when something is missing or broken, how much load reaches your origin and how fast it answers, and whether you can lose a server, a region or your data and come back.

The first half has auditors that check your monitored URL. The second half is about your own infrastructure and processes, and completes by hand.

Resilience is not a state you reach once. The last step sets these checks to run on a schedule, so the next expiry or regression reaches you before it reaches your visitors.

Running Liferay? How to keep your Liferay site online covers the same ground with Liferay settings and checks Liferay's support window for you. Related journeys: How to secure your website and How to secure your email.

Steps

Open a step to read it

1
Keep the domain from expiring
Verifies with Domain Expiration Auditor
An expired domain takes the website and the email down together, and a domain that lapses past its grace period can be registered by someone else. It usually happens because the renewal card expired or the reminder went to someone who left.
The Domain Expiration Auditor reads the expiry date from the registry. It fails when the domain expires within 30 days and warns within 90.
Do this
- Turn on auto-renew at your registrar
- Check the payment method on file and its expiry date
- Make sure the registrar's contact address is a shared mailbox, not one person
- Renew for several years at a time if you can, and turn on the registrar lock
Done when the auditor passes. It will warn again 90 days before the next expiry, which is the point of running it on a schedule (last step).
2
Make certificate renewal automatic
Verifies with Certificate Auditor
Browsers refuse an expired certificate outright, so the site is effectively down for everyone at once. Certificates now last 90 days or less and the maximum lifetime keeps shrinking, so renewing by hand is no longer realistic.
The Certificate Auditor validates the chain the way a browser does and fails on an expired, revoked, untrusted or wrong-hostname certificate.
Do this
- Use ACME (Let's Encrypt, ZeroSSL) with automatic renewal, or your host's or CDN's managed certificates
- Check that renewal also reloads the web server; a renewed file on disk does not help if the old certificate stays in memory
- Cover every hostname: www, the apex, API and status subdomains
- Know where each certificate lives if TLS ends at more than one place (CDN, load balancer, origin)
Done when the auditor passes and renewal is automated.
3
Stay inside your platform's support window
A version out of support gets no security fixes and no bug fixes. When something breaks, the fix exists only in a newer version, and the upgrade you put off becomes an emergency.
Do this
- Open the project that owns this URL and make sure Software Stack lists the platform and version in production
- Look up the end-of-support date for your CMS or framework, runtime, database and operating system on endoflife.date or the vendor's site
- For anything ending within a year, plan the upgrade now and put it in the calendar
- Prefer long-term-support lines for production when the platform offers them
Done when nothing in production is out of support, and anything ending within a year has an upgrade date. On Liferay, the End of Life auditor checks this against Liferay's service life table; for other platforms this step completes by hand.
4
Make missing pages fail cleanly
Verifies with Not Found Auditor
Broken links, removed pages and mistyped URLs happen on every site. What matters is the answer. A missing page that returns 200 OK (a soft 404) gets indexed and cached as if it were real, hides broken links from monitoring, and can be served to every visitor by a CDN.
The Not Found Auditor requests a URL that cannot exist on your site and checks the answer. It fails when the status is not 404 or 410, and warns about details of the 404 page, such as whether it tells search engines not to index it.
Do this
- Make the application return a real 404 status for unknown paths. Single-page apps often need a server or edge rule for this
- Give the 404 page a link home, search and your main navigation
- Redirect pages you removed on purpose to their closest replacement with a 301
Done when the auditor passes.
5
Catch errors that only show in the browser
Verifies with Browser Console Messages Auditor
A page can return 200 OK and still be broken: a script fails to load, an API call is blocked, a third-party widget throws. Uptime checks see nothing wrong; visitors see a blank form or a button that does nothing.
The Browser Console Messages Auditor loads the page in a real browser and reports what the console logs: errors fail, warnings warn.
Do this
- Run the auditor and fix the errors that come from your own code first
- For third-party scripts, update or remove the ones that fail. A tag that breaks your page is worth removing even if marketing asked for it
- Add front-end error tracking (Sentry, Bugsnag, your host's equivalent) so you see the errors real visitors hit, not only on this page
Done when the auditor reports no errors from your own code. Warnings from third-party scripts are often outside your control, so this step completes by hand.
6
Let caches answer so the origin does not have to
Verifies with Cache Auditor
Every request a browser or CDN answers from cache is one your origin never sees. That is the cheapest way to survive a traffic spike, and it keeps the site partly up even when the origin is slow.
The Cache Auditor reads the caching headers of the page and its resources and reports those that cannot be cached, or only for a short time.
Do this
- Give static assets with a hash in their name Cache-Control: public, max-age=31536000, immutable
- Give HTML a short max-age or s-maxage plus stale-while-revalidate, so the CDN can serve a slightly old copy while it fetches a new one
- Add stale-if-error where your CDN supports it, so it keeps serving the last good page when the origin fails
- Do not cache responses that depend on a signed-in user
Done when the auditor passes.
7
Serve through a CDN
Verifies with CDN Coverage Auditor
A CDN spreads your content over many locations, absorbs traffic spikes and most denial-of-service traffic, and can keep serving cached pages while your origin is down.
The CDN Coverage Auditor checks where the page's resources come from and fails for each one served directly from your backend.
Do this
- Put the site behind a CDN (Cloudflare, Fastly, CloudFront, Bunny, or the one built into your host)
- Route static assets through it as well as the HTML, including images and fonts
- Lock the origin so it only accepts requests from the CDN, otherwise attackers can go around it
Done when the auditor finds no resource served straight from the origin.
8
Know how fast the origin answers
Verifies with Time To First Byte Auditor
Time to first byte is how long the server takes to start answering. A slow TTFB under normal traffic means there is no headroom: a modest spike, a slow database query or a cold cache turns it into timeouts.
The Time To First Byte Auditor measures it five times. Under 800 ms passes, up to 1800 ms warns, and above that fails.
Do this
- Run the auditor a few times at different hours and write down the typical value. This is your baseline
- If it warns or fails, look at the slowest part of a request: database queries, external API calls made while rendering, no page cache
- Load test the busiest page at a few times your peak traffic before a launch or campaign
Done when you know your baseline and it is one you can live with. A page that must render per user can be slower than 800 ms for good reasons, so this step completes by hand.
9
Keep crawlers from overloading you
Verifies with Robots Crawl Delay Auditor
Search engines, AI crawlers and SEO tools can send more requests than all your visitors together, often to the most expensive pages: search, filters, calendars, endless pagination.
The Robots Crawl Delay Auditor fails when robots.txt is missing and warns when it has no Crawl-delay.
Do this
- Publish /robots.txt and disallow paths with endless combinations: internal search, faceted filters, sort parameters
- Add Crawl-delay for crawlers that respect it (Bing, Yandex and many smaller bots). Google ignores it and adjusts on its own when the site slows down
- Rate-limit by IP or user agent at the CDN for bots that ignore robots.txt
Done when the auditor passes.
10
Have backups you have actually restored
A backup you have never restored is a hope, not a backup. The usual surprises come out only during the first restore: a database dump that is empty, uploaded files that were never included, a missing encryption key, a restore that takes a day.
Do this
- Back up the database and uploaded files automatically, at least daily
- Keep at least one copy in another account or provider, where the site's own credentials cannot delete it
- Restore to a separate environment and check that the site works. Time how long it takes
- Write the restore steps down where someone else can follow them
- Repeat the test every few months, and after major changes
Done when you have restored a recent backup end to end and know how long it takes.
11
Be able to lose a server
Servers, disks and whole data centres fail. The question is whether the site goes down with them.
Do this
- Run at least two application instances behind a load balancer with health checks, so a failed one is taken out automatically
- Use a managed database with automatic failover, or a replica you have promoted at least once in a test
- Keep shared state (uploaded files, sessions) out of the app servers, in object storage and a shared store
- Lower DNS TTLs on records you might need to change in a hurry, and know how you would point traffic elsewhere
- If an outage of one region would be unacceptable, decide what a second region needs and test it
Done when you have taken one instance down on purpose and the site stayed up.
12
Prepare for the outage you will still have
Even a resilient site goes down sometimes. How long it stays down depends on how fast you find out and whether people know what to do.
Do this
- Set up uptime monitoring from outside your network that alerts the right person, by phone if it matters
- Publish a status page hosted somewhere other than your own infrastructure
- Write a short runbook: who is on call, where the logs and dashboards are, how to roll back a release, how to restore from backup, who to tell
- After each incident, write down what happened and what will change
Done when an alert reaches a person within minutes, and someone other than you could follow the runbook.
13
Run these checks on a schedule
Everything in this journey can regress: a domain renewal fails, a release drops a cache header, a new script throws errors, a CDN rule changes. A check you ran once tells you about the past.
Do this
- In 37 Audits, schedule the auditors from this journey to run regularly on this monitored URL. Daily is enough for most
- Make sure alerts reach a shared channel or mailbox, not one person
- Add your other important URLs (checkout, sign-in, API) as monitored URLs too
Done when the auditors run on a schedule and someone sees their results.
Related: How to secure your website.

Create an account, add your site as a monitored URL and work through these steps on it.