The launch checklist I run before every site goes live

Building a website has never been easier. Launching one properly has not changed at all.

Every site we build and every site we move goes through this list, and I run the parts that touch the head, the routes or the redirects again after any change. It exists because the same things break every time, and because none of them are visible in a design review. Every migration ends here, and 5Four® Run is this list running every month instead of once.

Play video

How to read it.

Sixteen sections, in the order we work through them. It took about ten builds to get the list where I wanted it, and every item is on it because something broke on a real launch.

Blockers get cleared before a domain is pointed at the site. Everything else can land in the first week. About half is machine checkable and runs as a script against the build, then again against the live domain. The other half is a phone, a browser and a person. Keep that half. No checklist replaces real eyes on a real device.

Take this and use it. Put your own name on it. Then after every launch, write down what broke, what rule would have caught it, and the project it came from. Only add from real incidents. That habit is worth more than any single item on the list.

Most launch problems are decisions nobody made. This section is where they get made.

• BlockerThe design is frozen, and every invented claim, price and number in the copy has been ruled on by the client.
• Every editable word, price, link and meta tag lives in content, not hardcoded in a template.
• Real details are in place, not placeholders: address, hours, phone, email, social profiles.
• The accounts exist and are in the client name: repository, hosting, content. That is the No-Hostage Rule, and it is easier on day one than on day ninety.
• BlockerReplacing an existing site: every live URL is written down next to the new URL it maps to, and the whole DNS zone is screenshotted before anything is touched.

The quiet half. None of it is visible, all of it is load bearing.

• Photography converted to WebP at 2000px maximum by a script that can be re-run, with originals kept. The Iru’s pass took 104.8 MB down to 6.6 MB.
• BlockerEvery image has width and height attributes, plus a global rule setting height to auto. Without it, a CSS aspect ratio is ignored and the photo renders at its file height. That is how a hero ends up 1,450px tall on a phone.
• Lazy loading below the fold, high fetch priority on the hero image only.
• Asset paths are root absolute. Relative paths break the moment a page sits at a nested URL.
• Internal links use one canonical form, and the host configuration agrees with it.
• Fonts self-hosted as WOFF2 with font-display swap, loaded from the head rather than an import buried in a design system file. On Pigeon’s Mission that single change was worth about four seconds of mobile Speed Index.
• Nothing the site cannot live without loads from a third party at runtime. An outage somewhere else should not be a blank page on your domain.
• Internal reference pages are unlinked from the nav and footer and carry noindex.
• Anything changed by hand after an export is commented in the code and listed in the README.

This is the longest section in my internal copy, because this is where the most launches go wrong. A phone is not a narrow desktop.

• BlockerEvery page at 320, 375, 414, 640, 768, 900, 1024, 1180, 1280, 1440 and 1920 wide: no sideways scrolling, nothing off canvas, no overlapping text.
• BlockerWide but short windows, 1440 by 790 and 1280 by 720. The headline and the main button are above the fold on a laptop. Heroes sized only by width overflow here and nowhere else.
• BlockerNo blank bands on phones. Heights designed against a desktop artboard can turn a short section into a screen of empty space, and an overflow check never sees it.
• BlockerThe mobile menu: open it, close it, open it again, on a real iPhone. Not in a device toolbar. Safari is where menus break, and most visitors are on Safari.
• Check the menu open, not just closed. A mega menu is invisible to a responsive sweep while it is shut, and text inside it can run past the panel on every page while the checks report nothing.
• Start halfway down the page, then open and close the menu. A menu that steals focus jumps the page to the top.
• No backdrop filter on anything above a fixed menu in the DOM: it traps the menu in its own layer and the menu stops covering the screen.
• BlockerIn-page anchor links land in the right place. If the target is a scroll reveal, measuring its position includes the reveal transform, so you land short and the section slides out from under you. Test every anchor, not one.
• Scroll-reveal content can never stay blank: anything taller than the viewport still shows, count-up numbers fall back to their real value, and printing shows everything.
• Stacked crossfading layers need pointer events switched off on the hidden ones, or the top layer quietly catches every click and sends people to the wrong page.
• BlockerA preloader is opaque, edge to edge, plays once per session, and nothing inside it is wider than the screen. One invisible layer a few pixels too wide makes iOS Safari zoom the whole page out to fit it.
• Reduced motion turns off the preloader, the reveals and every transition.
• Zero console errors on every page.
• BlockerNever delete a design effect to fix a bug. Fix the effect. Exports often write textures as inline data URLs the runtime mangles, so they paint nothing and log an error. Re-encode them.

A form that silently fails is worse than no form, because you never find out.

• BlockerEvery form submitted from a phone, and the email arrives in the inbox it is supposed to arrive in. Not "the success message appeared".
• The form posts to a real handler with a real email service, never a mailto link.
• If the handler fails, nothing is lost: fall back to a pre-filled draft. Never show a fake success message.
• Spam protection: a hidden honeypot field plus a minimum fill time.
• BlockerTest the submit empty, fix it, submit again path. If errors clear on blur, the button jumps out from under the pointer and the click lands on nothing.
• Booking and checkout embeds tested end to end, including where they send people afterward.
• Thank-you pages carry noindex, and the conversion event fires there.

Nine checks, and one of them is the single most common thing I find wrong on a site someone launched themselves.

• BlockerA unique title of 60 characters or fewer and a description of 155 or fewer on every page a search engine should see.
• BlockerA self-referencing canonical tag pointing at the production domain, not the preview URL.
• BlockerExactly one h1 per page, with no skipped heading levels.
• Alt text that describes the actual photo on content images, empty alt on decorative ones.
• One host is the real one, and the other redirects to it. Canonicals, sitemap and robots all agree on which.
• The sitemap lists every indexable URL, and robots.txt points at it and disallows the internal pages.
• BlockerThe preview host is noindexed with a header, so a preview copy cannot outrank the real site.
• A 301 from every old URL inventoried in section 1, each landing on a live page in one hop. I test every one before launch and again on the live domain.

Rendered on the server, not injected with JavaScript. Crawlers that skip JavaScript never see the second kind.

• BlockerAll the JSON-LD parses, and no placeholder brackets survived.
• The business or person entity is on every page. Search engines do not follow a reference from one page to another.
• The types match the content: Organization, LocalBusiness, Product, Article, FAQPage, BreadcrumbList.
• Schema images are JPG or PNG at absolute URLs. WebP is not accepted here, which is the one place it is not.
• The sameAs list contains only profiles that actually exist.
• BlockerNo review or rating markup for reviews collected somewhere else. Showing the stars is fine, claiming them in schema is a penalty waiting to happen.
• FAQ markup only for an FAQ visible on the page, with answers matching word for word.

The newest section, and the cheapest. This is the part most sites skip entirely, which is exactly why it is worth doing.

• An llms.txt at the root: who you are, what you sell, the links that matter. It costs about twenty minutes.
• robots.txt explicitly allows the AI crawlers, unless you have decided otherwise on purpose.
• Your name, address and phone number are identical in the page copy, the schema and llms.txt. Character for character.
• An FAQ section built from facts you can confirm, in the words people actually use.

Cheap to get right before launch, annoying to fix after, because the platforms cache the first thing they saw.

• BlockerEvery page has an og:title, og:description, og:type, og:url, og:site_name, an og:image and a summary_large_image card.
• The share image is 1200 by 630, under 1MB, JPG or PNG, at an absolute HTTPS URL. Not WebP, not relative, not a screenshot of the page.
• After launch, paste the URL into the platform debuggers to clear their caches.

Most sites have a tag. Fewer have ever confirmed it fires.

• BlockerAnalytics on every page, and the requests confirmed firing in the network tab, not just the tag present in the source.
• Replacing an old site: check it for an existing property and reuse it, so the history survives the rebuild.
• Conversion events for the things that matter: form submit, purchase, booking, outbound clicks.
• BlockerEverything named in the privacy policy is actually installed, and nothing is installed that it does not mention.
• BlockerLoad the live site on a real iPhone after adding analytics. Some session replay tools trigger Safari tracking protection, which puts a gray notice bar above your hero as the first thing a visitor sees.
• Tags gated on the production hostname, so local and preview testing never reaches the real data.
• Lighthouse measured before and after the tags. On Pigeon’s Mission, GA4 plus Clarity took performance from 75 into the high 60s and best practices from 100 to 79. That may be a fine trade, but make it knowingly.

One check here saves more arguments than the rest of the section put together: measure it properly first.

• Lighthouse on mobile and desktop, the LCP image preloaded or high priority, and layout shift near zero.
• Before chasing a bad mobile score, re-run it with real throttling instead of the simulated default. Simulated runs charge third-party embeds to your first paint. On this site it reported 8.8s where real throttling measured 1.6s.
• Immutable cache headers on hashed assets.
• Third-party scripts async, and embeds loaded after the page load event.
• A hero video never ships with preload set to auto. Use metadata and a real poster, and the poster is the video first frame or the handoff reads as a stutter.
• Background video: muted and playsinline as real attributes, pointer events off, and a retry on the first play attempt. iOS rejects the first one often enough to matter.

Usually four lines between a site and a score of 100, and all four help everyone.

• The html lang attribute is set. Exports ship a bare html tag, and this is often the only thing in the way.
• Contrast meets WCAG AA, and any deliberate departure from the design is written down.
• Header, main and footer landmarks, and a skip link to main. Exports almost always have the header and footer and no main at all.
• BlockerAdding main can break the page: if the footer sits inside a full-bleed wrapper, closing the tag in the wrong place collapses the section. Check the rendered height before and after.
• Every interactive element reachable and visible by keyboard, with a focus style that is not the default outline removed and never replaced.

• BlockerHTTPS everywhere, HTTP redirecting to it, and the certificate covering both the bare domain and www.
• Security headers set: content type options, frame options, referrer policy, permissions policy.
• No secrets in the repository. Keys live in the host environment variables.
• A branded 404 that returns a real 404 status and carries noindex.
• Uptime monitoring on the live URL. The point is that you find out before your client does.

• A privacy policy and terms linked in the footer, honest about the analytics, the forms and the newsletter.
• A cookie banner decided on purpose: generally needed for EU and UK visitors or any advertising pixel, generally not for a US-only site with basic analytics. Decide, do not drift.
• The copyright year is right, and updates itself.

The one day where a mistake is visible to everyone, including the client accounting department.

• BlockerEvery blocker above is cleared, and the client has signed off on the copy, especially anything factual.
• BlockerThe production build is live on the preview URL and every route returns 200 there, files included. An over-broad ignore rule can silently drop one PDF and nothing will tell you.
• Both the bare domain and www are added at the host, with the non-primary one redirecting.
• BlockerLook at the whole DNS zone before changing a single record. Change only the website records. Never touch MX, TXT, SPF, DKIM or DMARC: those are the client email, and taking a business email down on launch day is the one mistake nobody forgets.
• Registrar parking and forwarding is off. A parked page can hijack a bare domain even when the records look right in the dashboard.
• Wait for the nameservers to actually answer with the new records before worrying about the certificate. They can disagree with each other for a few minutes after a save.
• BlockerRe-run the automated half against the live domain: redirects, certificate, every page 200, robots, sitemap, the form endpoint.
• Open the site on a real phone, on the real domain. Use the menu. Send the form.

• Search Console: add the domain, verify, submit the sitemap, request indexing for the homepage. Then import into Bing Webmaster Tools, which takes one click.
• Turn the old site off, or remove the domain from it. Two live copies of the same content is the worst outcome of a rebuild.
• Update every profile that points at the old URL: business profile, social bios, email signatures, directory listings.
• Replacing a hacked site: find the spam URLs in the old sitemap, answer them with a 410 Gone, and file removals in Search Console. Otherwise you inherit the penalty along with the domain.
• Analytics is showing real traffic, and conversions are firing.
• Access and credentials are written down somewhere other than one person head, and the README is current.

A launch checklist that runs once is a launch checklist that expires. This is the part that keeps a site current instead of slowly rotting.

• Content changes go straight to live. Visual and structural changes get a preview link and an approval first. That is the Approval Loop.
• BlockerRe-run sections 5, 8 and 12 after anything that touches the head, the routes or the redirects. That is where a quiet, invisible regression lives.
• Re-run the image script and commit its output.
• One change per commit, described in plain English. The history becomes a Change Log, and any change is reversible.

Ready to stop paying the Ticket Tax?

Book a 30-minute call. We'll look at what you have, tell you which system to start with, and give you a clear price range before you leave the call.