Launch Checklists for Brand Sites: DNS to Analytics Without Drama

Launches fail less from bad design than from skipped boring steps: wrong DNS TTL drama, www vs apex loops, analytics in the wrong property, forms posting to nowhere, OG images missing, staging robots still blocking, clients tweeting a URL that 404s. A website launch checklist is operational craft. Treat go-live like a scene change with a call sheet. This spoke sits under Websites That Feel Like Films.

Website launch checklist — the full call sheet

Use this as a living list. Not every item applies to every stack. Do not skip the ones that do.

Pre-launch freeze (T-72 to T-24 hours)

• Content freeze window agreed with the client
• Final copy pass on fold, contact, pricing/legal as relevant
• Redirect map approved (old → new)
• DNS access confirmed (who has the login, who can change records)
• SSL strategy clear (platform-managed vs custom)
• Backup of legacy site / export if replacing
• Rollback plan named (previous deploy, maintenance page, or DNS revert)

Technical go-live checklist (marketing site)

DNS and domains

• Apex and www strategy chosen (redirect one to the other, never both serving different sites)
• TTL lowered ahead of cutover if you expect iteration
• Records pointed to the correct host (Netlify, Cloudflare, Webflow, etc.)
• Email DNS (MX, SPF, DKIM) untouched unless intentionally migrating mail
• Preview/staging hostnames not confused with production

HTTPS and security headers

• Certificate issues clean on apex and www
• HTTP → HTTPS redirect
• Basic security headers appropriate to the stack (do not copy a random blog blindly)
• Mixed content scan (HTTP assets on HTTPS pages)

Redirects and legacy URLs

• Top traffic URLs from old analytics mapped
• Common vanity paths covered
• 404 page on-brand with a path home
• Trailing slash policy consistent

SEO and discoverability

• robots.txt allows production; staging blocked
• Sitemap submitted or available
• Canonical URLs correct
• Title/meta on key templates
• OG/Twitter images present for home and share targets
• Structured data only where true and tested

Analytics and tags

• Production property IDs (not staging)
• Consent/banner behavior verified in the real region assumptions you care about
• Key events: form submit, CTA click, optional lobby for chat
• Tag manager container published (draft containers help no one)

Forms and integrations

• Form endpoints live (Netlify Forms, serverless, CRM)
• Notification emails arrive
• Spam protection on without blocking real users
• CRM/automation test lead created and deleted

Performance and media

• Mobile Lighthouse smoke on home and one interior
• LCP image sized and compressed
• Favicon and app icons present
• 404 and 500 pages do not pull megabytes of hero film

Accessibility smoke

• Keyboard through nav and contact
• Focus visible
• Critical images have alt
• Reduced-motion does not break layout

Content and legal

• Privacy/terms links work
• Copyright year current
• Placeholder copy gone (“lorem”, “TBD”, “Coming soon” on primary paths)
• Client-approved proof and logos cleared

QA matrix

• iPhone Safari, Android Chrome, desktop Chrome/Safari samples
• Newsletter or marketing HTML links tested if campaign goes out same day
• Password gates removed if the site should be public

Go-live checklist marketing site — cutover day

Order of operations I prefer:

1. Deploy production build to the host while DNS still points old (or use host “production domain” pairing carefully)
2. Verify on a hosts-file or platform preview URL that mimics production config
3. Flip DNS / assign domain
4. Watch certificate provisioning
5. Hit apex and www; confirm single canonical home
6. Submit a test form
7. Check analytics realtime (or test events)
8. Spot-check redirects from the map
9. Tell the client the URL is live and what not to cache-panic about

Communicate TTL reality. Some networks will show the old site for a while. Have a one-sentence explanation ready so the client does not “fix” DNS every ten minutes.

Roles: who owns what

Role	Owns
Studio lead	Freeze, go/no-go, client comms
Implementer	Deploy, redirects, forms, tags
Client	DNS access, copy approvals, legal pages, analytics account access
Marketing	Campaign timing, UTM plan, announcement

Launches go sideways when everyone can edit DNS and no one wrote the redirect map. Name owners in the project channel before cutover week.

DNS without drama

Drama usually means: wrong account, expired registrar login, floating www CNAME fights, or email breaks because someone deleted MX records while “just updating the website.” Write the exact records you will change. Screenshot before. Change only what you need. If email is in Google or Microsoft 365, treat MX as sacred.

If the client cannot find DNS access two days before launch, the launch date moves. Do not heroically guess.

Staging vs production hygiene

Staging should be noindex, preferably passworded, and should not share production analytics IDs. Production should not still point at staging CMS datasets. Environment variables are part of the checklist: one wrong API key and forms silently fail.

Soft launch vs hard launch

Soft launch: domain live, limited announcement, watch errors for 24–48 hours, then campaign. Hard launch: domain flip aligned with email/social blast.

Brand sites with heavy campaigns should soft-launch when possible. Hard launches amplify every missed redirect.

Post-launch (T+24 to T+7)

• Search Console / Bing ownership verified
• Crawl errors reviewed
• Convertible events visible in analytics
• Client trained on CMS (if applicable)
• Redirect map adjusted for any missed 404s
• Performance re-check after marketing tags settle
• Retro: what slipped, update the template checklist

Anti-patterns

• Launching Friday 6pm with no on-call
• “We’ll add analytics next week”
• Forgetting www
• Leaving basic auth on production
• Testing forms only on staging
• Client announcing a URL you have not QA’d on the production domain

Checklist as deliverable

I paste a shortened go-live checklist into the project Notion or Linear and tick it in public with the client. Shared visibility reduces “I thought you did DNS” arguments. Cinema-grade craft includes the boring reel.

When you want a brand site launched with ops discipline — not hope — explore /websites or book a sprint at /contact?intent=websites-sprint.

Content QA the day before cutover

Walk every primary navigation destination. Click every footer link. Submit every form with a unique test string you can search for in the inbox. Open the site in a private window to verify consent banners and first-visit states. Check that social share previews resolve using a debugger for Open Graph.

Verify 404 by typing a nonsense URL. Verify that HTTPS lock icons appear without warnings. Verify that old blog or project URLs from the previous site redirect if this is a migration. If you skipped the redirect map, you are planning to donate equity to the void.

Confirm that noindex is not present on production money pages. Confirm that staging is either password protected or noindexed. Confirm that demo content, ThemeForest leftovers, and ‘lorem ipsum’ are gone. These mistakes are common on builder exports and rushed custom launches alike.

Have a non-project human attempt the primary conversion path. If they cannot find how to contact you, the fold job failed — fix before ads. Pair with Above the Fold That Works.

Photograph the DNS panel before edits. Photograph it after edits. Future you will thank present you when something odd appears in propagation.

Security and access at launch

Rotate any credentials that were shared over insecure channels during build. Remove contractor access that is no longer needed. Enable 2FA on the host, DNS, domain registrar, analytics, and CMS. Launch week is a popular time for account takeovers because people share passwords under time pressure.

Review environment variables on the production deploy: no test API keys, no debug flags, no private staging URLs in public config. Check that forms do not expose internal emails in client-side code if that is a concern.

If the site has a file upload, verify size limits and malware scanning posture appropriate to the platform. If the site has a members area, verify that private routes are actually private.

Security is not separate from craft. A compromised brand site becomes an anti-case-study overnight. Keep the launch calm by preparing access hygiene early. Explore /websites or book a sprint at /contact?intent=websites-sprint.

Migration-specific launch notes

Migrations multiply risk. Inventory old URLs with a crawl before you redesign. Decide which pages deserve redirects and which deserve to die. Legacy query-parameter URLs and trailing-slash variants often hide in analytics — export top landing pages from the trailing twelve months and include them in the map.

If blog content moves, preserve slugs when possible. Changing every slug for aesthetics is an expensive vanity move. If you must change, redirect relentlessly. Update internal links inside content, not only the server redirect table.

Announce migrations to stakeholders with a clear ‘old site / new site’ window. Keep the old host available briefly for emergency rollback when contracts allow. Do not cancel the old host the same hour you cut DNS unless you enjoy gambling.

For SEO continuity, monitor Search Console coverage and 404 reports in the first two weeks. Fix in batches. Celebrate only after the chart stabilizes.

Migrations still answer to the same craft standard in Websites That Feel Like Films; they just add a redirect subplot. Explore /websites or book a sprint at /contact?intent=websites-sprint.

Keep the checklist alive

Save this checklist in the project repo or Notion and tick it per launch. Reuse beats reinvention. After each launch, add one lesson learned at the bottom so the next cutover is calmer than the last.

FAQ

What belongs on a website launch checklist?

DNS/SSL, redirects, robots/sitemap, analytics, forms, performance smoke, accessibility smoke, legal links, and a named rollback. Customize by stack; do not skip owners.

What is a go-live checklist for a marketing site specifically?

Domain canonicalization, campaign-ready OG tags, tag manager in production, CRM test lead, and coordination with announcement timing — plus the core technical list above.

When should we lower DNS TTL?

Before a planned cutover when you may need to correct records quickly. Raise it again after the site is stable.

Should we launch on a Friday?

Only if someone is accountable over the weekend and the change is low risk. Most brand cutovers are happier Tuesday–Thursday.

How do we handle the old site?

Archive or keep a backup, map top URLs, and redirect. Do not leave the old host serving competing content on alternate domains without a plan.

What if analytics can wait?

It can wait only if you accept blind weeks. Prefer production tags at launch with a test event. Retroactive guessing is a poor substitute for instrumentation.