Website Launch Checklist: Technical QA Before and After Going Live

Overview

A launch is more than publishing files or switching a staging site to production. It is a controlled change to the address, content, infrastructure, and user journey that visitors and search engines rely on. A page can look finished while its forms fail, its canonical URLs point to staging, or its domain still sends visitors to an old host.

Use this website prelaunch checklist in three passes:

1. Content and experience: confirm that people can understand the site and complete its main tasks.
2. Technical release: verify domains, DNS, HTTPS, redirects, indexing controls, analytics, and deployment settings.
3. Post-launch observation: check the live site from outside your development environment and monitor it after traffic arrives.

For a new build, test on a staging environment before launch. A staging site lets you review production-like behavior without exposing unfinished pages to regular visitors. See how to create a staging website for a safer preview workflow.

Checklist by scenario

For a new website

• Confirm the final site name, page hierarchy, navigation labels, contact details, and primary calls to action.
• Review every important page for a clear title, descriptive heading, useful body copy, and a sensible URL.
• Replace placeholder text, sample images, test accounts, development links, and temporary email addresses.
• Check that the production domain is used consistently in internal links, canonical tags, structured data, open graph metadata, and XML sitemaps where applicable.
• Test the home page, main navigation, search, forms, downloads, login flows, and any checkout or booking process.

For a redesign or CMS migration

• Export or record the old URL list before changing the site structure.
• Map changed URLs to the closest relevant new pages and create permanent redirects where the content has moved.
• Check internal links, image paths, embedded media, pagination, category pages, and author or archive pages.
• Preserve important metadata only when it remains accurate; do not carry over obsolete titles, descriptions, or indexing rules.
• Keep a backup of the database, uploaded assets, configuration, and any deployment-specific files. Review the website backup strategy for cloud hosting before making the switch.

For a domain or hosting change

• Confirm the authoritative DNS provider and the records required for the website, email, verification services, and third-party tools.
• Lowering DNS TTL before a planned change may help with coordination, but it does not make every resolver update immediately.
• Verify that the new host serves the correct site for the intended domain and does not expose a default server page.
• Install and test the SSL certificate for the root domain and relevant subdomains. Check that HTTP requests reach HTTPS without creating a redirect loop. For troubleshooting, use this SSL certificate setup and HTTPS errors guide.
• Keep the old hosting environment available until the new site, redirects, forms, and backups have been verified.

For a campaign landing page

• Test the exact campaign URL, including query parameters used for attribution.
• Make the destination and next step obvious on small screens as well as large screens.
• Confirm that the form sends submissions to the intended system and that visitors receive a useful success or error message.
• Decide whether the page should be indexed. A campaign page that is intentionally excluded should use the planned indexing control, not an accidental sitewide rule.
• Check that analytics records visits and conversions without relying on a single unverified browser session.

Browser-and-device test matrix

Choose representative tests rather than assuming one desktop browser proves compatibility. Test at least one current desktop browser, one mobile browser on a narrow screen, and one wider mobile or tablet layout. If your audience uses a known device or browser, include it. For each combination, check:

• navigation, menus, accordions, modals, and buttons;
• text wrapping, image cropping, horizontal scrolling, and sticky elements;
• keyboard focus and form completion;
• loading behavior on a slower connection or less powerful device;
• error states, confirmation messages, and back-button behavior.

What to double-check

Domain, DNS, and redirects

Test the preferred hostname and common alternatives: HTTP, HTTPS, the root domain, and the www version if both exist. Decide which version is canonical and redirect the others consistently. Confirm that redirects preserve important paths and do not send every old URL to the home page when a more relevant destination exists. Review DNS records carefully, particularly when the same domain also handles email. The DNS records guide can help separate website records from mail-related records.

Indexing and technical SEO

• Remove accidental noindex directives from pages that should appear in search.
• Keep staging authentication and blocking rules out of production, while retaining intentional exclusions.
• Open the production robots.txt and confirm that it does not block critical assets or entire sections unintentionally.
• Check canonical URLs, sitemap entries, language or regional annotations if used, and internal links.
• Search the rendered page source and browser developer tools for staging domains, localhost references, and insecure asset URLs.

Forms, tracking, and privacy controls

Submit each important form with valid and invalid data. Verify required fields, spam protection, notification delivery, storage, autoresponders, and the success page. Use a test address that someone will actually monitor. Confirm that analytics and conversion events fire once, not multiple times, and that events still work after navigation or consent choices where those controls apply. Treat consent settings as a deployment requirement: review the configuration for the regions and tools relevant to your audience rather than copying a setup from another site.

Accessibility, security, and performance

Navigate with a keyboard, inspect focus visibility, check heading order, label form controls, provide useful alternative text for meaningful images, and ensure text and controls remain usable at increased zoom. These checks do not replace a full accessibility review, but they catch common launch blockers.

Remove test credentials, update dependencies through your normal release process, restrict administrative access, and confirm that error pages do not reveal sensitive configuration. Test the 404 page and a server error path where practical. Measure representative pages after deployment, including the home page, a content page, and a form page. Look for oversized images, blocked resources, slow third-party scripts, and caching problems. Use a repeatable website performance optimization workflow instead of optimizing only the page you happened to test.

Common mistakes

• Launching directly from an untested production copy: keep a staging review and a rollback plan.
• Forgetting the old URLs: a redesign can lose useful pathways when redirects are treated as an afterthought.
• Testing only the happy path: deliberately submit empty, malformed, duplicate, and unusually long form values.
• Checking appearance but not behavior: inspect links, keyboard controls, loading states, error messages, and integrations.
• Leaving indexing rules unchanged: staging may need blocking, while production usually needs a carefully reviewed, different configuration.
• Assuming HTTPS means everything is secure: verify certificate coverage, redirect behavior, administrative access, backups, and exposed files.
• Declaring success immediately: a site can pass a local test and still fail after DNS, cache, or third-party systems change.

When to revisit

Use this checklist before every new site, redesign, domain change, hosting migration, major CMS update, and campaign launch. Revisit it after changes to analytics, consent tooling, payment or form integrations, DNS providers, certificate management, or deployment workflows. Browser behavior, search-engine guidance, platform defaults, and privacy requirements can change, so review the relevant checks before a seasonal planning cycle or a major release.

For the first 24 hours after launch:

1. Open the site from a separate network or device and test the highest-value journeys again.
2. Review server logs, form notifications, analytics activity, error reports, and uptime alerts.
3. Check redirects, key status codes, certificate warnings, and unexpected indexing blocks.
4. Compare performance with the staging baseline and investigate sudden slowdowns.

After 30 days, review search coverage, landing-page engagement, failed forms, common 404s, support questions, uptime history, and backup restore readiness. Turn recurring issues into a small release checklist for the next deployment. If the launch includes a hosting move, keep the website migration checklist alongside this one, and use uptime and performance monitoring to maintain visibility after the initial QA window.