Website Launch Checklist: Everything to Check Before Going Live

Launching a website without a checklist is how you end up with a staging robots.txt blocking Google, broken redirects sending visitors to 404 pages, an expired SSL certificate on day one, or analytics tracking that was never connected. Every one of these mistakes happens regularly, and every one is preventable.

This checklist covers everything you need to verify before, during, and after launch. It is organized into three phases: pre-launch (the days before you go live), launch day (the cutover itself), and post-launch (the first week after going live). For ongoing maintenance after launch, see the website maintenance and monitoring guide.

Pre-Launch: DNS

DNS errors are the most common cause of launch day failures. A misconfigured record can make your site unreachable, break email, or send traffic to the wrong server.

Verify A/AAAA records. Your domain's A record (IPv4) and AAAA record (IPv6, if applicable) must point to your production server's IP address. If you are using a CDN like Cloudflare, the records should point to the CDN, not directly to your origin server. For a full breakdown of record types, see DNS propagation explained.

Verify CNAME records. If you use a CNAME for www or other subdomains, confirm it resolves to the correct hostname.

Check nameserver delegation. The nameservers listed at your domain registrar must match the nameservers at your DNS provider. A mismatch means DNS queries go to the wrong place.

Lower TTL values in advance. If you are changing DNS records during launch, lower the TTL to 300 seconds (5 minutes) at least 24-48 hours beforehand. This ensures that when you make the switch, the old records expire quickly from caches around the world. You can raise the TTL back to a normal value (3600-86400 seconds) a day or two after launch.

Verify MX records. If you receive email on this domain, confirm MX records are correct. A DNS migration that forgets MX records means incoming email silently stops working.

Test with dig or nslookup. Run dig yourdomain.com A and dig yourdomain.com MX from multiple DNS resolvers (Google's 8.8.8.8, Cloudflare's 1.1.1.1) to verify records are correct and consistent.

Pre-Launch: SSL/TLS

An SSL problem on launch day means visitors see browser warnings instead of your site.

Install the certificate. Whether you are using Let's Encrypt, a commercial CA, or your hosting provider's auto-provisioned certificate, verify it is installed and active on your production server.

Verify the certificate chain. Incomplete certificate chains work in Chrome on desktop but fail on mobile browsers and older systems. Use an SSL checker to verify the full chain. See how to check an SSL certificate for testing methods.

Force HTTPS. Set up HTTP-to-HTTPS redirects so that any visitor hitting http:// is automatically sent to https://. This should be a 301 (permanent) redirect.

Check for mixed content. Load your site over HTTPS and check the browser console for mixed content warnings. Images, scripts, fonts, or iframes loaded over HTTP on an HTTPS page will trigger warnings or be blocked entirely. Fix all resources to use HTTPS.

Verify HSTS header. If you are using HTTP Strict Transport Security, confirm the header is being sent. Be cautious with the includeSubDomains directive -- it applies to all subdomains, including any that may not have SSL configured yet.

Pre-Launch: Redirects

If this launch replaces an existing site, redirect handling can make or break your SEO.

Map old URLs to new URLs. Create a complete redirect map for every URL on the old site that has traffic, backlinks, or search rankings. Each old URL should 301-redirect to the most relevant new URL.

Test every redirect. Do not assume your redirect rules work. Test each one individually. Pay attention to trailing slashes, query parameters, and case sensitivity. For testing methods, see how to check redirect URLs.

Handle missing pages. If old URLs have no equivalent on the new site, redirect them to the closest relevant page, not the homepage. Redirecting everything to the homepage is a soft 404 in Google's eyes.

Check for redirect chains. If old URL A redirects to old URL B, which redirects to new URL C, you have a chain. Collapse it so A goes directly to C. Chains add latency and can lose link equity.

Check for redirect loops. A redirects to B, B redirects to A. Browsers show "ERR_TOO_MANY_REDIRECTS" and the page never loads. Test thoroughly.

Pre-Launch: robots.txt

A wrong robots.txt on launch day can block Google from your entire site.

Remove staging blocks. If your staging site had Disallow: / to prevent indexing, that rule must not carry over to production. This is the single most common robots.txt mistake during launches.

Verify the production robots.txt. Visit https://yourdomain.com/robots.txt (or the staging equivalent that will become production) and read every rule. Make sure nothing important is blocked. For testing, use a robots.txt testing tool.

Include the sitemap reference. Your robots.txt should include a Sitemap: directive pointing to your XML sitemap.

Block what should be blocked. Admin areas, search result pages, user account pages, and other non-public paths should have Disallow rules.

Pre-Launch: XML Sitemap

The sitemap tells search engines what pages exist and which ones matter.

Generate the sitemap. Use your CMS's built-in sitemap feature or a sitemap generator. Verify the sitemap is valid XML.

Include only canonical URLs. The sitemap should contain the canonical (preferred) version of each URL. Do not include redirected URLs, paginated pages, or URLs with query parameters that are duplicates of other pages.

Verify accessibility. The sitemap should be accessible at https://yourdomain.com/sitemap.xml or whatever path your robots.txt references. For sitemap submission steps, see how to submit a sitemap to Google.

Check the format. Each URL entry should include a <lastmod> date if possible. Make sure no URLs return 404 or redirect. A sitemap full of redirecting URLs sends the wrong signals to search engines.

Pre-Launch: Analytics and Tracking

If analytics is not set up before launch, you lose data from day one and have no way to recover it.

Install tracking code. Whether you use Google Analytics, Plausible, Fathom, or another analytics tool, verify the tracking snippet is on every page of the production site.

Verify data is flowing. Open your analytics dashboard and browse your staging/pre-production site. Confirm that page views appear in the real-time report.

Set up goals and conversions. If your site has forms, purchases, or other conversion actions, configure them in your analytics tool before launch so you start collecting conversion data immediately.

Install Google Search Console. Verify ownership of your domain in Google Search Console. This gives you access to indexing data, crawl errors, and search performance reports.

Check for tag conflicts. If you are using a tag manager, verify that tags fire correctly and do not conflict with each other. Duplicate analytics tags will double-count page views.

Pre-Launch: SEO Meta Tags

Meta tags control how your pages appear in search results. Missing or duplicate tags hurt click-through rates.

Title tags. Every page should have a unique title tag under 60 characters. The homepage title should include your brand name and primary keyword.

Meta descriptions. Every important page should have a unique meta description under 155 characters. While not a direct ranking factor, descriptions affect click-through rates from search results.

Open Graph and Twitter cards. If you want your pages to display correctly when shared on social media, include OG tags (og:title, og:description, og:image) and Twitter card tags.

Canonical tags. Every page should have a <link rel="canonical"> tag pointing to its own URL (self-referencing canonical) unless it is a duplicate that should point to the original.

Structured data. If your site uses schema markup (Organization, Article, Product, FAQ), validate it with Google's Rich Results Test before launch.

Pre-Launch: Performance

A slow site on launch day makes a poor first impression on both visitors and search engines.

Test page speed. Run your key pages through Google PageSpeed Insights or Lighthouse. Address any critical issues (render-blocking resources, unoptimized images, missing compression).

Enable caching. Configure browser caching headers for static assets (images, CSS, JS). Set appropriate cache durations -- static assets that rarely change can have long cache lifetimes (1 year). HTML pages should have shorter or no caching.

Enable compression. Verify your server sends gzip or brotli compressed responses. This typically reduces transfer sizes by 60-80%.

Optimize images. Convert images to modern formats (WebP, AVIF where supported). Resize images to the dimensions they are displayed at, not larger. Use lazy loading for images below the fold.

Test under load. If you expect significant launch day traffic, run a basic load test to verify your server can handle the volume.

Pre-Launch: Security

Security holes are cheapest to fix before launch. After launch, they become incidents.

Update all software. CMS, plugins, themes, server OS, and runtime environments should all be on their latest stable versions.

Remove default credentials. Change all default admin passwords, API keys, and database credentials. Remove any test accounts.

Set up backups. Verify that automated backups are configured and running. Test a restore to confirm backups actually work. A backup you have never tested is not a backup.

Configure security headers. Add Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, and Permissions-Policy headers. These do not prevent all attacks, but they close common vectors.

Review file permissions. Configuration files, environment files (.env), and database credentials should not be accessible via the web. Request https://yourdomain.com/.env and verify you get a 403 or 404, not your database password.

Pre-Launch: Monitoring Setup

Set up monitoring before launch, not after your first outage.

Uptime monitoring. Configure checks for your homepage and key pages. Set alert thresholds and notification channels (email, Slack, SMS).

SSL monitoring. Set up certificate expiry alerts at 30, 14, and 7 days before expiration.

DNS monitoring. Monitor your critical DNS records for unexpected changes.

Error tracking. If your site has dynamic functionality, set up error tracking (Sentry, Bugsnag, or similar) to catch JavaScript errors and server-side exceptions.

See the website monitoring checklist for a complete setup guide.

Launch Day

Launch day itself should be boring. If you did the pre-launch work, the cutover is just flipping a switch.

DNS Cutover

If launch involves a DNS change (pointing your domain to a new server), make the change and then monitor propagation. DNS propagation typically takes minutes to a few hours, but can take up to 48 hours in edge cases with high TTL values.

Check propagation from multiple locations. Use DNS lookup tools that query from different geographic regions. Do not rely on your own machine's DNS cache -- it may resolve the new records before everyone else does, giving you a false sense of completion.

Cache Clearing

After the DNS cutover, clear caches at every layer:

• CDN cache. Purge your CDN (Cloudflare, Fastly, CloudFront) to ensure visitors get fresh content from the new site.
• Application cache. Clear any server-side caches (page cache, object cache, opcode cache).
• Browser cache. You cannot force visitors to clear their browser cache, but proper cache headers and versioned asset filenames (e.g., style.v2.css) handle this automatically.

Real-Time Monitoring

Watch your monitoring dashboards for the first few hours after launch. Pay attention to:

• Uptime alerts. Any downtime notifications mean something went wrong during cutover.
• Error rates. A spike in 404s or 500s suggests broken URLs or server configuration issues.
• Response times. Elevated response times may indicate server overload or misconfigured caching.

Post-Launch: First Week

The work is not done when the site is live. The first week after launch requires active verification.

Verify Indexing

Submit your sitemap to Google Search Console if you have not already. Use the URL Inspection tool to request indexing of your most important pages. Monitor the Index Coverage report for any pages that Google cannot crawl or index.

It takes days to weeks for Google to fully crawl and index a new site. Do not panic if pages are not appearing in search results within hours. Do check back after 3-5 days to verify progress.

Monitor for Errors

Check Google Search Console daily during the first week. Look for:

• Crawl errors. 404s, server errors, and redirect issues that Google encounters.
• Indexing issues. Pages excluded due to noindex tags, canonical issues, or robots.txt blocks.
• Mobile usability issues. Pages that do not render correctly on mobile devices.

Check your server logs for 404 errors. These often reveal broken internal links, missing images, or URLs that were not included in your redirect map.

Check Redirects

If you set up redirects from an old site, verify they are working in production. Request several old URLs and confirm they redirect to the correct new pages. Check the HTTP status codes -- they should be 301 (permanent), not 302 (temporary).

Test Forms and Functionality

Submit every form on the site. Contact forms, newsletter signups, search, login, checkout (if applicable). Verify that form submissions arrive where they should, confirmation emails are sent, and error handling works correctly.

Verify Analytics

After a day of real traffic, check your analytics data. Confirm page views are being recorded for all pages, not just the homepage. Verify that conversion tracking fires correctly. Compare traffic patterns to what you expected.

Review Security

Run a security scan on the live production site. Check that no development tools, debug modes, or test endpoints are accessible on the production URL. Verify that error pages do not leak sensitive information (stack traces, file paths, database queries).

The Condensed Checklist

For quick reference during launch week:

Pre-Launch:

• DNS records correct (A, AAAA, CNAME, MX, nameservers)
• TTL lowered 24-48 hours in advance
• SSL certificate installed and chain verified
• HTTPS forced, no mixed content
• Redirect map complete and tested
• robots.txt reviewed, staging blocks removed
• XML sitemap generated, accessible, and valid
• Analytics installed and data flowing
• Search Console verified
• Meta tags (title, description, canonical, OG) on all pages
• Page speed tested, critical issues fixed
• Caching and compression enabled
• Software updated, defaults changed, backups configured
• Security headers set, sensitive files inaccessible
• Monitoring configured (uptime, SSL, DNS)

Launch Day:

• DNS cutover completed
• Propagation verified from multiple locations
• CDN and application caches purged
• Real-time monitoring watched for first few hours

Post-Launch (First Week):

• Sitemap submitted to Search Console
• Crawl errors and indexing status checked daily
• Redirects verified in production
• All forms and interactive features tested
• Analytics data confirmed
• Security scan on production URL

References

1. Google Search Console
2. Google PageSpeed Insights
3. Google Rich Results Test
4. Mozilla Observatory - Security Headers