How to Create a Website Launch Checklist for a Client (Pre-Flight QA)

The High-Stakes World of Website Launches

Launching a client website is an exhilarating milestone, but without systematic pre-flight verification, it can quickly turn into a reputational nightmare.

Common launch disasters include:

• The staging site's noindex meta tag was accidentally deployed to production, wiping the client's site from Google within 72 hours.
• Contact forms fail to deliver notification emails because SMTP credentials were never switched from sandbox to live mode.
• Legacy URLs return 404 errors, causing organic search traffic to plummet by 60%.
• The SSL certificate fails to provision on the apex domain, showing scary browser security warnings to incoming visitors.

A comprehensive, pre-flight launch checklist turns a nerve-wracking gamble into a calm, repeatable operational procedure.

The 5 Critical Phases of Pre-Flight Launch Verification

Phase 1: Technical SEO & Crawlability

1. Robots.txt & Meta Robots: Verify that robots.txt allows crawlers and that no global noindex tags exist on indexable pages.

2. Canonical URLs: Ensure all pages specify self-referencing canonical tags pointing to the official production URL.

3. XML Sitemap: Confirm that /sitemap.xml is generated dynamically and contains only 200-OK canonical routes.

4. 301 Redirect Mapping: If redesigning an existing site, map every legacy URL to its closest new equivalent in a redirect spreadsheet. Implement server-side 301 permanent redirects to preserve backlink equity.

Phase 2: Analytics, Tags & Conversion Tracking

1. Google Analytics 4 (GA4): Confirm the measurement ID is active and inspect the GA4 Realtime dashboard to verify pageview tracking.

2. Google Search Console (GSC): Add DNS TXT verification record to client domain registrar and submit the live XML sitemap.

3. Conversion Goals: Test form submission event tracking and purchase confirmation events.

Phase 3: Forms, Security & Transaction QA

1. Real Form Submissions: Submit test entries through every contact, inquiry, and newsletter form. Verify that:

• The user sees a clear, accessible confirmation message.
• The client receives the notification email with intact data fields.
• Anti-spam protections (Turnstile, reCAPTCHA, honeypot) block bot spam without trapping legitimate users.

2. Payment Gateway Verification: If ecommerce is present, perform a real $1.00 transaction using a live credit card, confirm receipt generation, and execute a refund in Stripe.

3. HTTPS & Security Headers: Enforce automatic HTTP-to-HTTPS redirection and verify SSL certificate expiration is handled automatically.

Phase 4: Performance, Mobile & Accessibility Audit

1. Core Web Vitals: Run Google PageSpeed Insights on mobile and desktop viewports. Ensure Largest Contentful Paint (LCP) is under 2.5s and Cumulative Layout Shift (CLS) is under 0.1.

2. Mobile Viewport QA: Test across actual devices (iPhone Safari, Android Chrome) at 375px and 390px widths, checking for horizontal scroll bugs or overlapping sticky headers.

3. Accessibility: Verify color contrast ratios (minimum 4.5:1 for body copy) and ensure all interactive controls have visible :focus-visible rings.

Phase 5: DNS Migration & Post-Launch Monitoring

1. Lower TTL (Time-To-Live): Lower DNS record TTL to 300 seconds (5 minutes) 24 hours prior to launch to enable rapid propagation.

2. DNS Cutover: Update A and CNAME records to point to production hosting servers.

3. Post-Launch Smoke Test: Test the live domain on cellular network (disconnect from local WiFi to bypass local DNS caching).

Follow our ready-to-use Website Launch Checklist Template for every client deployment.

The 30-Point Pre-Flight Launch QA Matrix

Never launch a client website on a Friday afternoon, and never launch without completing a structured pre-flight QA audit:

Follow our full interactive Website Launch Checklist for a complete pre-flight review.

Zero-Downtime DNS Migration & Rollback Procedures

Flipping DNS records is the most technically delicate phase of a website launch. Follow these operational rules to prevent downtime and preserve email routing:

1. The Pre-Launch TTL Reduction (48 Hours Prior)

DNS records are cached by internet service providers according to their Time-To-Live (TTL) setting (often set to 86,400 seconds / 24 hours). If you change DNS without lowering the TTL first, some users will see the old server while others see the new server for up to 48 hours.

• 48 hours before launch, reduce the TTL on all A and CNAME records to 300 seconds (5 minutes).
• Once the migration is complete and stable for 72 hours, raise the TTL back to standard values (86,400 seconds) to reduce DNS lookup latency.

2. Protect MX & Email Records

When updating DNS to point to a new web host (like Vercel, Netlify, or AWS), never delete existing MX (Mail Exchange), SPF, DKIM, or DMARC TXT records. Accidental deletion of mail records will immediately shut down the client's corporate email, causing chaos. Always export a full BIND zone file backup of all existing DNS records before editing.

3. The Emergency Rollback Plan

Before updating DNS, document the exact previous IP address and CNAME targets. If a catastrophic bug appears in production, you can revert DNS records to the old server within 5 minutes thanks to your reduced TTL.