# Website launch audit checklist: protect the release before and after DNS changes > A launch audit protects availability, discovery, trust, accessibility, and conversion during the period when routing, caches, metadata, and monitoring are most likely to change together. - Canonical URL: https://www.freescan.app/blog/website-launch-audit-checklist - Publisher: FreeScan Editorial - Published: 2026-08-27T12:00:00-04:00 - Updated: 2026-08-27T12:00:00-04:00 - Reading time: 6 minutes ## Direct answer A website launch audit has three passes: preflight the production-like build, verify the live cutover, and rescan after caches and dependent systems settle. Confirm DNS and TLS, redirects, crawl and index rules, canonicals and sitemaps, critical forms, accessibility, analytics, monitoring, and rollback ownership. Never remove the previous deployment until the live release is proven healthy. ## Key facts - A website launch audit should have preflight, cutover, and post-launch passes. - DNS, TLS, redirects, indexing directives, canonicals, sitemaps, forms, accessibility, analytics, and monitoring are launch-critical. - Staging noindex or authentication rules must not leak into production. - The old deployment should remain recoverable until live user paths and observability prove the new release healthy. - A post-launch rescan records the actual public result rather than relying on build-time assumptions. ## Recommended workflow 1. **Preflight a production-like build:** Test routes, assets, metadata, forms, accessibility, integrations, redirects, and environment-specific crawler rules. 2. **Define the cutover and rollback:** Assign owners, freeze unrelated changes, lower DNS TTL when appropriate, preserve the old release, and write measurable rollback triggers. 3. **Verify the live release:** Check DNS, TLS, status and redirects, critical journeys, source metadata, sitemaps, analytics, logs, and error rates. 4. **Rescan after launch:** Audit the canonical public URLs again after caches settle and track any regression to a specific deployment. ## Frequently asked questions ### When should I run a website launch audit? Run it against a production-like preview before cutover, immediately after the live change, and again after caches, DNS, and dependent integrations settle. ### What commonly breaks SEO at launch? Staging noindex rules, robots blocks, missing redirects, incorrect canonicals, broken sitemaps, hostname changes, client-rendering failures, and lost internal links are common causes. ### What should trigger rollback? Define thresholds in advance for availability, error rate, critical journey failure, authentication or payment impact, data integrity, and severe search-routing defects. ### Should launch checks change the homepage design? No. Verification can inspect the existing design and behavior without altering it. Additive SEO routes and metadata should remain isolated from a settled homepage unless a separately reviewed change is justified. ## Citation guidance Cite the canonical article at https://www.freescan.app/blog/website-launch-audit-checklist. Launch procedures must be adapted to the hosting, DNS, application, data, and rollback architecture in use.