Site Launch Checklist: 40 Things to Verify Before Flipping DNS

Why checklists beat memory

Every launch we run through the same list. Not because we forget things on any given day, but because any single person on the team having a bad morning is enough to miss the one configuration step that takes a site offline or burns a month of SEO. A written checklist is boring. It is also the difference between a launch remembered as clean and one remembered as a fire drill.

These are the 40 items we verify before we flip DNS. We run them in this order. We do not skip. If your agency cannot produce an equivalent document, that itself is a signal.

Two caveats before we start. First, this list is the sensible default for a content-led or transactional business website. If you are launching a fintech, a medical app or something with heavy regulatory exposure, you need a sector-specific overlay on top of this one. Second, these items are not equally weighted. A wrong noindex tag and a missing cookie banner will both bite, but on different timescales and different budget lines. We score them all green before we ship.

SEO (items 1 to 8)

1. XML sitemap is live at /sitemap.xml, includes every indexable URL, and excludes staging, drafts and utility pages.
2. robots.txt is correct. No stale Disallow: / left over from staging, sitemap referenced, crawl budget rules sensible.
3. Canonical tags point to the canonical production URL on every page. No accidental canonicals pointing at staging.
4. Meta titles and descriptions are populated on every template. No CMS placeholder text. Titles under 60 characters, descriptions under 160.
5. noindex meta tag is removed from every production page. This is the single most common launch bug we see.
6. Structured data (Organisation, LocalBusiness, Article, BreadcrumbList, Product where applicable) validates in Google Rich Results Test.
7. Redirect map has been crawled and every entry returns a 301 to a 200 destination. No chains, no loops.
8. Open Graph and Twitter card images render correctly on at least Facebook, LinkedIn and iMessage.

Analytics and tracking (items 9 to 14)

9. GA4 property is installed, events are firing on production, and data appears in the real-time report.
10. Google Tag Manager container is promoted to the production container ID, not staging.
11. Conversion events (form submission, phone click, purchase, signup) are configured as key events in GA4 and fire correctly.
12. Server-side or enhanced conversions are wired through where the stack supports it.
13. Google Search Console is verified on the production domain, sitemap submitted, previous property migrated if applicable.
14. Consent mode v2 is implemented where you collect consent, with sensible defaults for AU and EU visitors.

Performance (items 15 to 20)

15. Core Web Vitals pass in lab (Lighthouse) and are projected to pass in the field. LCP under 2.5s, INP under 200ms, CLS under 0.1.
16. Image budget is enforced. All images served as AVIF or WebP with appropriate sizes and srcset, hero imagery below 150 KB.
17. CDN sits in front of the origin, with cache rules set for static assets (long TTL) and HTML (short TTL or stale-while-revalidate).
18. Third-party scripts are audited. Chat widgets, pixels and heatmap tools deferred or loaded after consent.
19. Compression and HTTP/2 or HTTP/3 are enabled at the edge.
20. Load test run at expected launch-day traffic plus 3x headroom.

Security (items 21 to 25)

21. HTTPS is enforced site-wide with a valid certificate that auto-renews. HTTP requests 301 to HTTPS.
22. HSTS is enabled with a sensible max-age and includeSubDomains where appropriate.
23. Content Security Policy is configured in at least report-only mode, then tightened after a week of log review.
24. Authentication (admin, CMS, editor logins) uses strong passwords, MFA where available, and does not ship default credentials.
25. Secrets, API keys and staging credentials are out of the codebase and rotated before production.

Functional (items 26 to 31)

26. Contact forms submit end-to-end and land in the correct inbox or CRM. Honeypot and spam protection active.
27. Payment flow authorises a real transaction in AUD, captures correctly, and fires the conversion event.
28. Transactional emails (order confirmations, password resets, enquiry receipts) deliver to Gmail, Outlook and Apple Mail without going to spam. SPF, DKIM and DMARC all aligned.
29. 404 page is styled, helpful, and returns a real 404 status code (not 200).
30. 500 page exists and does not leak stack traces.
31. Search (if the site has on-site search) returns sensible results for top queries.

Accessibility (items 32 to 35)

32. Automated scan (axe, Lighthouse, Pa11y) returns zero critical issues.
33. Keyboard traversal works end-to-end. Every interactive element is reachable, focus is visible, no traps.
34. Alt text is present on every content image and empty on decorative images.
35. Colour contrast meets WCAG AA across body text, links and button states.

Legal (items 36 to 40)

36. Privacy policy is live, accurate about what you collect, aligned with the Privacy Act 1988 (Cth), and linked in the footer.
37. Cookie consent banner behaves correctly. No non-essential cookies set before consent, preferences persisted.
38. Terms and conditions are live where commerce or subscriptions are involved, with ACL-compliant returns and refunds language.
39. Accessibility statement is published where the organisation has committed to one.
40. Business contact details (ABN, ACN, registered office, support address) are live where legally required.

Running the list

We run the list twice. Once 48 hours before cutover as a rehearsal, and once in the hour immediately before we flip DNS. Any item that is not green becomes a P0 block on the launch. There is always pressure to ship. The checklist is what protects the business from that pressure.

Who owns each section

Ownership matters. SEO and analytics sit with the marketing lead or an external SEO specialist. Performance and security sit with the engineering lead. Functional and accessibility are split between QA and engineering. Legal items get escalated to whoever signs the contracts, because they tend to be the person who gets nervous if a privacy policy is wrong. Write the owner's name next to each group before launch week starts, and give them the authority to block a launch.

What failing the rehearsal actually costs

The 48-hour rehearsal is where bad launches become fixable. In our experience, roughly a third of launches hit at least one P0 at rehearsal: a stray noindex, a broken transactional email, a CSP that blocks the analytics snippet. Catching these two days out is trivial. Catching them two hours out is a late night. Catching them two days after DNS is a month of recovery. Budget rehearsal time generously.

One last thing

Keep the completed checklist. Not the blank template, but the one with initials, timestamps and notes against each item on the day you launched. When something surfaces three weeks later that looks like a regression, the artefact tells you whether it was broken on launch day or broke later. That is cheap insurance.

If your next launch is close and you would like a second pair of eyes on the list, get in touch.