Notes

A checklist for shipping a static site

2026-09-30

Static sites are supposed to be the easy case. They are — until DNS, TLS, and caching are involved. This is the list I actually run through, in order, before pointing a domain at a new machine.

Before the switch

  1. Decide the canonical host. Pick one of example.com and www.example.com, and redirect the other with a 301. Do it before launch, not after people link to you.
  2. Check the certificate covers every name you will serve. A wildcard does not cover the apex; the apex does not cover subdomains.
  3. Serve a real 404. The default server page leaks the server version and looks unfinished. A static 404 page is five minutes of work.

Headers

For static assets, the cache policy does most of the work. Two rules cover almost everything:

location /assets/ {
    add_header Cache-Control "public, max-age=31536000, immutable";
}
location / {
    add_header Cache-Control "public, max-age=300";
}

Fingerprinted asset names can be cached forever; HTML cannot. If the HTML is cached for an hour, a deploy looks broken for an hour.

After the switch

  1. Request the site from a network that is not yours. A laptop on the same LAN will happily resolve a stale record for hours.
  2. Verify the redirect chain is one hop. http to https is expected; http to https to www to https://www is a slow page for no reason.
  3. Confirm the origin is not reachable directly if you are relying on an edge for anything. If it is, you have an edge you cannot trust.
The most common launch bug is not a missing file. It is a cached redirect from a previous attempt, still sitting in a browser somewhere.

Two things worth automating

Certificate expiry and the 404 page. The first because it is the only failure that takes the whole site down silently, the second because it is the first thing a visitor sees when a link is wrong.