Website Launch Checklist: Everything to Test Before You Go Live

Overview

This checklist gives you a practical way to launch a website with fewer surprises. Instead of checking everything at once, divide the work into categories: infrastructure, security, content, functionality, SEO, analytics, performance, and recovery. That makes the website QA checklist easier to assign, verify, and repeat.

A useful launch process has three phases:

• Pre-launch setup: confirm hosting, domain, DNS, SSL, redirects, backups, and access.
• Pre-launch validation: test templates, forms, links, structured pages, mobile layouts, analytics, and speed.
• Post-launch verification: re-check live URLs, cache behavior, indexing settings, logs, and conversions after traffic starts hitting the real domain.

Before you begin, define a short launch record with these fields:

• Primary domain and any alternate domains
• Hosting provider and environment names
• DNS provider and relevant records
• SSL certificate method
• CMS or framework version
• Rollback plan
• Backup location
• Owner for each checklist section
• Launch window and freeze period

That small document saves time when something goes wrong under pressure.

If your launch includes DNS changes, keep a separate note of TTL values, current records, and target records. If you need a refresher, see How to Point a Domain to Your Website: DNS Records Explained for Beginners and DNS Propagation Checker Guide: How Long DNS Changes Take and What to Do While Waiting.

Checklist by scenario

Use the scenario closest to your project. Most launches borrow from more than one list.

Scenario 1: New website on a new domain

• Domain registration: confirm the domain is registered, auto-renew is enabled if appropriate, and contact email is valid.
• DNS records: verify A, AAAA, CNAME, MX, TXT, and any verification records are correct for the production domain.
• Canonical host: choose whether the preferred version is www or non-www and redirect the other one.
• SSL: test https on the preferred domain and alternate hostname. Check for certificate warnings and mixed content.
• Hosting: confirm the production environment has the correct code, environment variables, and file permissions.
• robots.txt: make sure staging blocks are removed and production rules are intentional.
• Indexing readiness: check that pages are not blocked by noindex tags unless intentionally excluded.
• Core pages: test homepage, about, contact, pricing or service pages, legal pages, and key landing pages.
• Navigation: verify desktop menu, mobile menu, footer links, and breadcrumb behavior if used.
• Forms: test submissions, email notifications, spam protection, validation errors, thank-you pages, and storage of entries.
• Analytics: confirm your analytics code fires once, not twice, and key events are mapped.
• Backups: create a clean baseline backup before launch.

Scenario 2: Redesign on an existing domain

• URL inventory: compare old URLs to new URLs and prepare 301 redirects for anything changing.
• Template parity: check that high-traffic pages from the old site still exist and preserve key content.
• Metadata: verify titles, meta descriptions, canonicals, open graph tags, and social preview images.
• Search visibility safeguards: avoid launching with empty headings, missing internal links, or broken sitemap generation.
• Media: confirm old image paths still resolve or are redirected.
• Analytics continuity: preserve tracking IDs, conversion goals, and search console access.
• Performance regression check: compare the new site against the old one for key pages.
• Error monitoring: prepare alerts for 404s, server errors, and JavaScript failures.

Scenario 3: WordPress launch or migration

• Site URL settings: confirm WordPress Address and Site Address match the production domain.
• Permalinks: re-save permalinks if needed after migration.
• Theme and plugin review: disable unused plugins, update active components, and confirm compatibility.
• Caching: clear plugin cache, server cache, and CDN cache after launch.
• Search engine visibility setting: confirm the site is not discouraging indexing in Settings > Reading.
• Media library: spot-check images, PDFs, thumbnails, and background assets.
• Admin access: verify at least two trusted admin accounts work and recovery email is correct.
• Form plugins and SMTP: test outgoing email rather than assuming it works.
• Security basics: check login URL behavior, brute-force protections, backup plugin status, and file editing rules if used.

If your launch includes a host move, this related guide may help: Step-by-Step Guide to Migrating a WordPress Site to a New Host with Zero Downtime.

Scenario 4: Application or SaaS front-end release

• Environment variables: verify production API endpoints, keys, and feature flags.
• Authentication flows: test sign up, login, logout, password reset, email verification, and session timeout.
• Error states: confirm 404, 403, 500, and maintenance pages are styled and useful.
• Client-side monitoring: enable error tracking for JavaScript exceptions and network failures.
• Accessibility basics: check keyboard navigation, visible focus states, form labels, and contrast.
• Rate limits and abuse protections: make sure public endpoints and forms cannot be trivially abused.

Scenario 5: Content-heavy site or editorial launch

• Category and tag structure: check archive pages, pagination, and filter URLs.
• Author pages: verify bios, social metadata if used, and indexation rules.
• Search: test on-site search with common and edge-case queries.
• Related content: confirm internal linking modules populate correctly.
• Feeds and sitemap: validate XML sitemap output and any RSS behavior you rely on.

What to double-check

This is the part many teams skip because the first pass looked fine. Double-checking catches the issues that only appear on the live domain or on real devices.

Domain, DNS, and SSL

• Open the site using both http and https, with and without www if both are possible. The preferred version should resolve cleanly, and all other versions should redirect once to the canonical host.
• Inspect certificate coverage for the exact hostnames you use.
• Check that MX and TXT records were not accidentally removed during DNS edits.
• Verify CDN or proxy settings do not interfere with origin SSL or caching rules.

For DNS troubleshooting, keep these references handy: Troubleshooting Common DNS and Domain Issues: A Practical Checklist for IT Admins.

Page rendering and front-end behavior

• Test in at least one desktop browser and one mobile browser.
• Confirm fonts load, hero images display, and layout shifts are not severe.
• Open browser developer tools to look for JavaScript errors, failed network requests, mixed-content warnings, and blocked assets.
• Verify cookie banners, chat widgets, embeds, and consent-dependent scripts do not block essential interactions.

If something looks wrong but not obviously broken, use How to Use Browser DevTools to Troubleshoot CSS, JavaScript, and Network Errors.

Forms, transactions, and user paths

• Submit every form with valid data.
• Try invalid data to confirm field validation is clear and useful.
• Check where submissions are stored and who receives notifications.
• Follow the full conversion path: landing page to form to thank-you page or confirmation state.
• If payments are involved, test taxes, receipts, confirmation emails, and failed payment handling in the correct environment.

SEO and crawl readiness

• Review page titles and headings on key pages.
• Confirm each important page returns the expected status code.
• Test redirects individually, especially for old URLs with backlinks or traffic history.
• Verify XML sitemap generation and robots.txt accessibility.
• Make sure canonical tags point to live URLs, not staging domains or parameter variants.

Analytics and monitoring

• Load a page and check whether analytics fires once.
• Validate event tracking for clicks, form completions, signups, downloads, or other business-critical actions.
• Confirm dashboards, search console, uptime checks, and error tracking are pointed at production.
• Set alerting before launch, not after the first complaint.

Performance and resilience

• Test a few representative pages: homepage, a content page, a form page, and a media-heavy page.
• Check image compression, caching headers, script loading order, and lazy loading behavior.
• Warm caches if your stack benefits from it.
• Prepare a rollback path that can be executed without debate.

After launch, use monitoring rather than guesswork. A helpful next read is How to Monitor and Troubleshoot Web Application Performance.

Common mistakes

Most launch problems are not exotic. They are ordinary oversights made under deadline pressure.

• Launching without a redirect map. Redesigns often break old URLs silently, which damages user experience and search discovery.
• Forgetting staging restrictions. A noindex tag, password wall, or robots block can follow the site into production.
• Testing forms without verifying delivery. A green success message is not enough if no one receives the email or stores the lead.
• Ignoring alternate hostnames. The main domain may work while www, non-www, or http variants fail or loop.
• Double-loading analytics. This commonly happens when a tag manager and theme or plugin both inject the same script.
• Skipping mobile QA. Menus, sticky elements, viewport spacing, and tap targets often fail first on mobile.
• Clearing only one cache layer. Browser cache, CMS cache, server cache, and CDN cache may all need attention.
• Updating DNS without preserving unrelated records. Email and verification records are frequent casualties.
• Not documenting credentials and ownership. A launch is fragile when only one person knows where DNS, hosting, and backups live.
• No recovery plan. Teams sometimes prepare the launch in detail but improvise the rollback.

A good rule is simple: if a failure would be embarrassing, expensive, or hard to diagnose in public, test it twice before launch and once again immediately after.

When to revisit

This checklist works best as a living document, not a one-time article you read and forget. Revisit it whenever the underlying inputs change.

At minimum, review your website launch checklist in these situations:

• Before a new site launch or redesign: copy the checklist into the project workspace and assign owners.
• Before seasonal planning cycles: re-check conversion paths, landing pages, uptime alerts, and traffic-sensitive pages.
• When workflows or tools change: update items for new analytics tools, CDN settings, form providers, or deployment methods.
• After a hosting move or DNS change: confirm domain and SSL setup, redirects, email records, and caching behavior.
• After adding major plugins, integrations, or scripts: re-test performance, forms, consent flows, and JavaScript error handling.
• After an incident: add the missed step that would have prevented it.

To make this practical, turn the article into an internal runbook with three columns: item, owner, and evidence. Evidence can be a screenshot, URL, test result, or note showing the check was actually completed. That one habit prevents the common problem of assuming someone else verified it.

For teams, keep a short launch day sequence:

1. Freeze non-essential changes.
2. Take a fresh backup or snapshot.
3. Deploy or switch traffic.
4. Verify canonical domain, SSL, and core page access.
5. Test one live form or conversion path.
6. Check analytics and error logs.
7. Watch for 15 to 30 minutes for immediate issues.
8. Record anything unexpected and add it to the checklist for next time.

The goal is not perfection. It is repeatability. A strong go live checklist for website projects reduces preventable mistakes, shortens troubleshooting time, and gives you a clear path to launch a website with confidence each time.