Website Launch Checklist: 24 Checks Before You Go Live

What a website launch checklist verifies

A website launch checklist is a point-in-time verification that the site is controlled, correct, recoverable, and ready for real visitors. Record an owner, result, and date beside each check. Anything that cannot be verified should remain an open risk rather than becoming a box someone ticks from memory.

Launch verification is different from maintenance. Launch asks whether the system works at cutover; maintenance asks whether it remains accurate and recoverable after months of changes. Keep the two records separate so a one-time preflight does not masquerade as an ongoing operating plan.

Confirm ownership and recovery first

Document where the domain is registered, who controls DNS, which account owns hosting and deployment, where the source repository lives, how renewals are paid, and which monitored address receives recovery notices. Export the current DNS records before launch week and store the record outside the platform being changed.

Verify that the backup covers the complete site and can be restored into an isolated environment. A successful backup notification shows that a job ran; a dated restore test shows that the business can recover. Keep at least one recoverable copy outside the hosting account so one account failure cannot remove production and its only backup together.

• Domain, DNS, hosting, deployment, source, and billing owners
• Account-recovery routes and current second factors
• Backup location, recovery point, and retention
• Last isolated restore-test result and duration
• Named rollback decision maker

Remove unfinished content and verify trust claims

Give every public page a defined purpose, useful title, and one clear primary heading. Remove template pages, sample testimonials, demo posts, placeholder copy, and claims that no one has verified. Recheck prices, dates, citations, credentials, reviews, and commercial relationships immediately before release.

Submit the contact form as a visitor and confirm that the notification arrives. Call the public number and email the published address. Assign an owner for each route and document what happens during absence. Privacy, disclosure, editorial, correction, and terms pages should describe the tools and business practices that are actually live.

Verify HTTPS, canonical URLs, sitemap, and errors

Test HTTP and HTTPS on the apex and www hostnames. Every alternate should reach the chosen canonical URL in one redirect while preserving the intended path and query. Check canonical tags, robots directives, the XML sitemap, and the 404 response on the production hostname after the cutover.

A sitemap helps search engines discover the canonical URLs a site considers important. Google describes sitemap submission as a hint, not a guarantee that a page will be crawled or indexed. Make the sitemap accurate, reference it from robots.txt, and use Search Console to see processing errors after submission.

• Production pages return their intended status
• Staging noindex or robots blocks are removed
• Internal links use final canonical URLs
• Changed valuable URLs have specific redirects
• Images, scripts, fonts, and downloads load over HTTPS

Run accessibility and performance checks on real journeys

Complete the primary journeys using a keyboard and at narrow mobile widths. Focus should remain visible, follow a sensible order, and never become trapped. Check headings, labels, errors, contrast, text resizing, image alternatives, and any audio or video alternatives on representative pages.

W3C explains that automated tools can support an accessibility evaluation but cannot determine by themselves whether a website is accessible. Record the pages, journeys, tools, and manual checks that were used instead of turning a clean scan into an unsupported conformance claim.

• Homepage and navigation
• Representative content or service page
• Contact, quote, booking, or checkout path
• One media-heavy or interactive page
• Phone-sized and desktop layouts

Review delivery, security, and third-party dependencies

Inspect the representative pages for layout movement, oversized media, blocking assets, and third-party scripts with no active owner. Launch is a useful point to remove an abandoned chat widget, duplicate tag, or font file before it becomes part of the permanent baseline.

Review access controls, current dependencies, response headers, and secret handling. Confirm that credentials, tokens, private keys, and production data are absent from the repository and public assets. This is an operational preflight, not a security certification; higher-risk systems still need a review appropriate to their data and consequences.

Plan measurement, cutover, and rollback

Decide which analytics, consent, and webmaster tools will run before enabling their scripts. Put account ownership with the organization, document what data each tool receives, and verify that the privacy description matches the implementation. A launch without analytics can be valid when that choice is explicit and the site does not claim otherwise.

Write the rollback owner, measurable triggers, exact reversal steps, and expected recovery time. Choose a window that avoids unrelated domain, email, billing, or account migrations. When several systems change together, the first visible symptom rarely identifies which change caused it.

Recheck the production site after launch

After traffic moves, repeat the canonical, redirect, form, email, sitemap, asset, and primary-journey checks against production. Watch server errors and failed enquiries closely during the first day, then revisit them throughout the first week as DNS, cache layers, and real visitors expose conditions staging did not.

Keep a short launch record with the site, planned and actual time, launch owner, rollback owner, backup and restore-test date, final reviewer, known exceptions, and post-launch result. That record becomes the evidence for sign-off and the starting point for the recurring maintenance schedule.