Launch checklist: 38 things to check before your website goes live

Here are the 38 checks we run before a site goes live, grouped so that each person can own their section: content, search, performance, forms and tracking, legal, DNS and email, and backups and monitoring. Copy the list, tick each item on staging the week before launch, and tick it again on the live site in the hour afterwards.

Every item on this list is here because we or a client have been caught by it on a website design and development project. The expensive ones are not the technical ones; they are the forms that went to a mailbox nobody read and the staging block that stayed on after launch.

Is the content final?

Content problems are the ones customers notice first and the ones most often skipped because "we checked it in the design".

• Every page has been proofread by someone who did not write it, on a phone as well as a desktop.
• No placeholder text anywhere. Search the whole site for "lorem", "TBD", "xxx", "[", and the name of the template or previous client.
• Phone numbers, email addresses, postal address, opening hours and prices are correct and identical on every page, in the footer, and on the contact page.
• Every link has been clicked, internal and external. A crawler such as Screaming Frog or a free broken link checker does this in minutes; fix every 404.
• Every image is the final version with descriptive alt text, and no stock-library watermarks or placeholder graphics remain.
• The 404 page exists, matches the design, and links to the homepage, the main services and the contact page.

Can search engines find and understand the site?

This is where a redesign loses its rankings. The full set is in our technical SEO checklist; these are the launch-day essentials.

• Every page has a unique title and meta description, written by hand and checked against Google's display limits with the meta length checker.
• One H1 per page, and headings in order below it.
• The staging noindex tag and any password protection have been removed from the live site, robots.txt allows crawling, and the staging site itself is password-protected or taken down so it is not indexed as a duplicate. Generate a clean robots.txt with the robots.txt generator and read it once more after the DNS switch.
• An XML sitemap exists at /sitemap.xml, lists only live, indexable URLs, and is referenced in robots.txt. The XML sitemap generator builds one from a URL list if your platform does not.
• Every page has a canonical tag pointing to itself, using the final domain and the chosen www or non-www form.
• If this replaces an existing site, every old URL redirects with a 301 to its closest new equivalent, tested from a list, not from memory. Pages with no equivalent go to the most relevant section, not the homepage.
• Structured data (Organization or LocalBusiness, plus FAQ where there is a FAQ section, built with the FAQ schema generator) validates: Google's Rich Results Test for most types, and the Schema Markup Validator for FAQ markup, which Google no longer tests.
• Open Graph and Twitter card tags are present with an image at 1200 by 630 pixels, tested by pasting the URL into a LinkedIn or WhatsApp message.

Is it fast enough on a phone?

Google measures Core Web Vitals on real visitors, and the mobile numbers are the ones that count. The thresholds from Google's web vitals documentation are LCP under 2.5 seconds, INP under 200 milliseconds and CLS under 0.1.

• Images are compressed, served at the size they are displayed, in WebP or AVIF, and lazy-loaded below the fold. Run the originals through the image compressor before upload; it is usually the biggest single saving.
• The homepage and the main service page pass Core Web Vitals on the mobile tab of PageSpeed Insights, or come close enough that the remaining items are known and scheduled.
• Web fonts are limited to two families, self-hosted or preconnected, with font-display: swap.
• Third-party scripts have been listed and each one justified. Chat widgets, heat maps and tag managers loaded "just in case" are the usual cause of a failing INP.
• Caching and a CDN are on, and a hard refresh of a page shows cache headers on static assets.

Do forms and tracking actually work?

The most common post-launch failure is a form that submits successfully and goes nowhere.

• Every form has been submitted for real, on the live site, and the email arrived in the inbox that will be monitored, not the developer's. Check the spam folder as well.
• The visitor sees a confirmation message or page, and gets an auto-reply if one is configured.
• Spam protection is on, whether a honeypot field, a managed CAPTCHA or rate limiting, and a real submission still goes through.
• Analytics is installed on every page and receiving data, confirmed in the real-time report, with the staging and office IP addresses excluded.
• Conversion events fire for form submissions, phone taps and WhatsApp clicks, and have been seen once in the analytics debug view.
• Google Search Console is verified on the final domain, the sitemap is submitted, and the account is owned by the client, with the developer added as a user.

Are the legal pages in place?

What applies depends on where you are and what you collect; check with your lawyer for the specifics. The checks below are the ones every business site needs in some form.

• The privacy policy describes what the site actually collects (form fields, analytics, cookies, embedded video) and names the tools used. A template copied from another site usually gets this wrong.
• Cookie consent is implemented if the law where your visitors are requires it, and analytics does not fire before consent where that applies. Our cookie consent guide covers who needs what.
• Terms of service, and refund and shipping policies if you sell online, are published and linked from the footer and the checkout.
• The company's registered details appear where the law requires them. In India, the Companies Act requires a company's name, registered address and CIN on its website; other countries have equivalents for registered businesses. Check with your accountant or company secretary.

Are DNS, SSL and email ready?

DNS is where a launch is won or lost, and email is the thing most likely to break when a domain's records are edited.

• The DNS TTL on the records that will change was lowered to 300 seconds at least a day before launch, so the switch takes minutes instead of hours.
• An SSL certificate is installed and renews automatically, http:// redirects to https://, and the www and non-www forms redirect to the one you chose, in one hop.
• The MX records were left untouched, and SPF, DKIM and DMARC records are in place for the domain, so mail from the business and from the website's forms is delivered. The business email setup guide covers each record.
• The old hosting account stays live for at least two weeks after launch, so anything missed can be recovered.
• The domain is registered in the client's own account, auto-renew is on, and the renewal date is more than a month away.

What happens when something breaks?

A launched site is a running system. These four items are the difference between finding out from a monitor and finding out from a customer, and they are the core of what a website maintenance plan covers after launch.

• A full backup was taken immediately before launch and again after, and a restore has been tested once, not just assumed.
• Uptime monitoring is on, checking from outside the hosting provider, with alerts going to a person who will act on them.
• Error logging or monitoring is configured so that a failing form or a broken page is reported, not silent.
• Every account created during the project (hosting, DNS, CMS admin, analytics, Search Console, email) is listed in a shared document, is owned by the client, has two-factor authentication on, and has had the developer's temporary credentials removed or downgraded.

Run the list on staging first and fix everything that can be fixed before the DNS switch; only the DNS, SSL, email and analytics items need the live domain. When we take a site through design and development, the launch is a scheduled hour with this list open, not an afternoon of surprises.

Then switch, run the list again on the live site, and move to what to do after your website launches, which covers the first 90 days. The checklist is also the last step in our pillar guide on how to plan a company website, where the earlier steps make most of these items trivial to tick.