Website Launch Checklist: A Pre-Launch and Post-Launch QA Template

Overview

Website launch work is easiest to manage when it is divided into clear stages. First, confirm that the site is ready in a private staging environment. Next, verify the technical connections that make the site reachable, secure, measurable, and easy to use. Finally, monitor the live site and correct issues that only appear after real traffic arrives.

This checklist works for a site built with a website builder, a managed hosting platform, or a custom application on cloud web hosting. The exact controls will vary by platform, but the checks remain broadly useful. If you are still deciding between a hosted builder and managed infrastructure, see Website Builder vs Managed Hosting before finalizing the implementation.

Keep a record of each check, its result, the person responsible, and any follow-up date. A simple shared document or issue list is usually enough. The goal is not to create paperwork; it is to make missing work visible before launch.

Checklist by scenario

For every new website

• Confirm the launch scope. List the pages, forms, integrations, languages, user roles, and features that must work on day one. Mark anything intentionally deferred.
• Review content. Check page titles, headings, body copy, calls to action, contact details, pricing or service descriptions, spelling, dates, and legal or support information. Remove placeholder text, sample accounts, and unused sections.
• Test navigation. Follow the main menu, footer links, logo link, breadcrumbs, buttons, and internal links as a first-time visitor. Check both successful and error states.
• Test on real devices. Review representative pages on a phone, tablet, and desktop-sized screen. Check menu behavior, scrolling, image cropping, readable text, touch targets, and whether important actions remain visible.
• Check accessibility basics. Confirm that images have useful alternative text where needed, headings follow a logical order, form fields have labels, keyboard navigation works, focus states are visible, and color is not the only way information is communicated.
• Verify forms. Submit every form with valid and invalid data. Confirm required-field messages, confirmation messages, notification delivery, spam controls, autoresponders, CRM or ticket routing, and the storage or deletion process for submissions.
• Set up analytics deliberately. Confirm the correct property or workspace, page-view tracking, key events, campaign parameters, consent or privacy settings where applicable, and exclusion of internal test traffic. Record the events that matter rather than measuring every interaction without a purpose.

For a domain and hosting change

• Record the current setup. Document the registrar, DNS provider, hosting account, email provider, third-party services, current DNS records, redirects, and any scheduled jobs.
• Prepare DNS changes. Confirm the required A, AAAA, CNAME, MX, TXT, and other records with the relevant providers. Avoid deleting mail or verification records simply because they are not related to the website.
• Confirm the canonical domain. Decide whether the site uses the root domain, a www hostname, or another preferred hostname. Make the alternate version redirect consistently to it.
• Verify SSL. Test the final hostnames over HTTPS. Check for certificate coverage, insecure asset warnings, mixed-content issues, and redirects from HTTP to HTTPS. For a broader setup sequence, use the domain, hosting, DNS, and SSL launch guide.
• Plan the cutover. Lowering DNS time to live before a planned change may help with coordination, but it does not guarantee instant worldwide updates. Keep the old environment available long enough to handle delayed resolution and rollback needs.

For a redesign or migration

• Create a URL map. Match important old URLs to their new destinations. Use one-to-one redirects where possible, and send retired pages to the closest relevant replacement rather than a generic homepage.
• Preserve valuable metadata. Review titles, descriptions, canonical references, structured data, image information, and indexation settings. Do not carry staging noindex controls into production.
• Compare key pages. Check the home page, top landing pages, blog or documentation pages, login and checkout paths, contact forms, and any pages that receive traffic from external links.
• Test data and integrations. Verify accounts, orders, subscriptions, search, comments, webhooks, API connections, scheduled tasks, and transactional email. A migration can preserve page content while silently breaking background processes.
• Keep a rollback plan. Take a tested backup, define who can make the decision, and write down the steps for restoring the previous version. The cloud hosting migration checklist can help organize this work.

For a small business or creator site

• Make the primary action obvious: contact, book, subscribe, buy, or request information.
• Check that business hours, location, service area, social links, and contact methods are accurate.
• Test the site using a slow connection and a small screen, especially if visitors may arrive from mobile devices.
• Confirm that you can update text, images, products, and contact details without depending on the original launch process.
• Write a short maintenance note covering logins, renewal dates, backup locations, analytics access, and who receives important notifications.

What to double-check

Performance and reliability

Load representative pages rather than testing only the homepage. Look for oversized images, unnecessary scripts, blocked resources, layout shifts, slow third-party embeds, and server errors. Confirm that caching and compression are configured appropriately for the platform. A site can feel fast in a developer environment while behaving differently on a typical connection, so test from more than one device and network when possible. Use the page speed optimization checklist for a deeper review.

SEO and indexation

• Give each important page a distinct, descriptive title and a useful meta description.
• Use one clear primary heading and organize supporting sections logically.
• Check internal links, canonical references, XML sitemap output, robots directives, and indexation controls.
• Remove staging passwords, temporary noindex settings, test subdomains, and duplicate versions of the site.
• Confirm that redirects do not create chains or loops.

Security, backups, and operations

Remove unused administrator accounts, replace temporary credentials, enable appropriate multi-factor authentication, and review permissions. Confirm that software, plugins, themes, dependencies, and integrations are supported by the chosen hosting environment. Verify that backups run, are retained for an appropriate period, and can actually be restored. A backup that has never been tested is an assumption, not a recovery plan.

Check monitoring and notifications for certificate expiry, failed backups, uptime problems, storage limits, domain renewal, and unusual application errors. Make sure alerts reach someone who can act on them.

Common mistakes

• Launching from the builder preview alone. Preview modes may not reproduce production DNS, SSL, caching, email, analytics, or third-party behavior. Test the real staging or production-like address.
• Forgetting email. Website DNS and email DNS often share the same zone. Changing records without documenting mail requirements can interrupt business communication.
• Using one generic redirect. Sending every old URL to the homepage can confuse users and discard useful context. Map pages carefully.
• Testing only the happy path. Submit empty forms, invalid email addresses, duplicate entries, long text, expired sessions, and failed payments where relevant.
• Leaving test content behind. Search for placeholder names, sample phone numbers, dummy images, developer comments, test webhooks, and internal links.
• Measuring without a baseline. Record important page paths, conversion actions, error rates, and performance observations before launch so post-launch changes are easier to identify.
• Assuming DNS changes are immediate. Keep the launch window controlled and monitor both the old and new paths until the transition is stable.

When to revisit

Run the full checklist before the initial launch, a domain change, a hosting migration, a major redesign, or a release that changes forms, checkout, authentication, analytics, or navigation. Run a smaller version before seasonal campaigns, promotions, product launches, and other periods when a failure would be costly.

After launch, review the live site immediately, again after the first meaningful traffic period, and after the first backup and restore cycle. Then schedule recurring checks based on how often the site changes. A monthly review may suit an active business site; a less frequently updated site still needs checks for domains, certificates, backups, forms, and software.

Update this checklist when your hosting platform, website builder, DNS provider, analytics workflow, payment system, or internal ownership changes. Keep the last completed date, findings, and unresolved risks beside the checklist. Before each launch, start with the previous findings rather than assuming the same test results still apply.

To launch website online with fewer surprises, assign an owner to every critical check, test the public hostname, save evidence for important results, and keep a rollback path until the site has been observed in production. That small discipline turns a one-time launch into a repeatable website operation.