The LIVE line: what has to be true before a site is called live

I keep a status file for every client, and one word in it carries more weight than the rest. That word is LIVE. It only goes on a line after a written list of checks has run and I’ve looked at what they produced.

Why the word needs a rule

A green build tells you the code compiled. It doesn’t tell you what a person sees on their phone. Every item on my list exists because a green build shipped something a person saw first, before I did.

Some of those were ours. On 2026-09-09 a site went live with a noindex tag on it, which tells search engines to ignore it. The same day a contact form went live without the secrets it needed to send anything. Both passed the gates we had at the time. Our own site once shipped with four typefaces and a sign-in link nobody could see, and the audits that were running said it was fine.

So the word got a rule.

What has to be true

Shipped means served. A deploy isn’t the finish. The ship script ends by asking the live address for the build stamp and checking it matches the latest commit. I learned this one on 2026-09-22: a deploy without the cache purge left jkca.studio serving the old build for hours while I believed the new one was up.

Phones from frames. Every screen gets captured at 375 by 812, the size of a phone, plus 768 and 1280. I look at every frame in light mode and dark mode. Then I run it again in Safari’s engine, because that’s the browser I proof in. A single long screenshot of a whole page isn’t a phone. One hid a cropped hero image from me for a day.

Design gates. A script counts what the page actually renders. No more than three type families. One footer, with every tap target at least 44 pixels. No sentence told twice across the site.

The launch check. Another script walks the live site. The home page can be indexed. The sitemap agrees with itself. Pages on hold stay hidden. Canonical links point at the right host. There’s a real 404 page, and the business details search engines read are present. Then I submit the contact form once, for real, and check that it lands in the client’s inbox.

The link gate. Any link I send to someone outside the shop returns a working page, and its preview image loads. I open it cold on a phone before it goes out.

Content exists without tricks. Nothing sits invisible waiting for an animation to reveal it. If the script doesn’t run, the words are still there.

State shots. Every page gets captured with the menu closed and open, along with the footer and the 404, at all three widths. They go into the client’s folder on a contact sheet, and I look at the sheet. They run again after every production deploy.

The Safari bar. The strip at the top of an iPhone takes its colour from the page. A missing tag leaves it grey. It’s a small thing, and a client will notice it before anything else.

Stores and paid flows get one more pass through a checkout list at phone and desktop widths before the line is written.

What it means for a client

When I tell you a site is live, it means the address you type serves the build I checked, on a phone, in the browser you probably use. It means your form reaches your inbox because I sent one through it. It doesn’t mean the deploy command finished without an error. Those are different claims, and I’ve been burned by treating them as one.

It also means launch day is quieter. Most of what used to come back as a text from a client the next morning now gets caught by a script before anyone else sees the page.

Why it’s written down

The list grows by one line each time something slips past it. Each line carries the date it was added and what went wrong. That’s the useful part. When a check feels like overkill on a busy afternoon, the date next to it reminds me what happened the last time it wasn’t there.