Website launch checklist: what we check before going live

Launching a site isn’t pressing a button: it’s confirming that everything promised is in place, and that nothing that used to work gets broken. This is the checklist we run before every release, grouped by area. It works for a brand-new site and for a redesign, and you can use it on your own site.

1. Technical SEO

The minimum for search engines to understand the site from day one.

• Unique title and description per page and per language. Titles up to roughly 60 characters and descriptions up to roughly 155, so they don’t get cut off in results.
• One <h1> per page and a heading hierarchy that makes sense.
• Canonical URL declared on every page.
• hreflang on multilingual sites, with each version pointing to the others.
• sitemap.xml published and referenced from robots.txt.
• robots.txt with no leftover blocks. The most expensive mistake on this list: going live with the noindex or Disallow: / used during development.
• Structured data (organization, articles, FAQs) validated with Google’s Rich Results Test.
• Open Graph set up: title, description and image, so the link looks right when shared on Slack, LinkedIn or WhatsApp.
• A custom 404 page that actually returns a 404 status code and offers a way back.

2. Redirects and domain

The section most often skipped in a redesign, and the one that costs the most traffic.

• A 301 redirect map. Every URL from the old site that changes needs to point to its new equivalent. Build it from the old sitemap and the top pages in Search Console.
• One version of the domain. With www or without, but not both: one redirects to the other.
• HTTPS enforced and a valid certificate.
• Consistent trailing slashes. /services and /services/ shouldn’t respond as two different pages.
• No redirect chains. Old URL to new URL in a single hop.
• DNS reviewed. Especially mail records: switching hosts without checking MX records is a classic way to lose email on a Monday.

3. Performance

• Core Web Vitals within the “good” thresholds: LCP at 2.5 s or less, INP at 200 ms or less, CLS at 0.1 or less. We explain them in Core Web Vitals explained.
• Lighthouse 95+ across all four categories as the target, measured in mobile mode.
• Images in AVIF or WebP, sized to how they’re displayed, with width and height declared.
• Hero image prioritized, everything else lazy-loaded.
• Self-hosted fonts in WOFF2, with font-display set.
• JavaScript only where it’s needed. Every third-party script has to earn its place.
• Caching configured for files that don’t change.

4. Accessibility

We aim for WCAG level AA. What we always check:

• Full keyboard navigation, with focus always visible.
• AA contrast: 4.5:1 for normal text and 3:1 for large text, in both light and dark themes.
• Alt text on informative images, and empty alt on decorative ones.
• Forms with real labels (<label>), not just placeholder text, and error messages that say what to fix.
• Correct lang attribute on each language version.
• Reduced motion respected: if someone has asked for it at the system level, animations turn off.
• 200% zoom without content getting cut off or overlapping.

Automated tools like Lighthouse or axe catch part of the problems. The keyboard walkthrough and the screen reader pass have to be done by hand.

5. Analytics and measurement

If you don’t measure from day one, that data is gone for good.

• Google Search Console verified and the sitemap submitted.
• Analytics installed and tested, with your own visits excluded if the tool allows it.
• Conversions defined: form submission, click-to-call, email click, chat or WhatsApp click. Each one tested.
• Baseline saved. A snapshot of PageSpeed Insights and current rankings, so there’s something to compare against later.

6. Forms and legal

• Form tested end to end. It submits, lands in the right inbox, doesn’t go to spam, and the sender gets a clear confirmation.
• Spam protection that doesn’t punish the people who actually want to write.
• Privacy policy and terms published and linked from the footer. Which laws apply depends on where your visitors are: state privacy laws such as California’s CCPA in the US, GDPR for visitors from the European Union, and local data protection laws across Latin America.
• A cookie notice only if it’s warranted. If the site uses advertising or tracking cookies, consent rules may apply. If it doesn’t, the banner is just noise.
• Business details in plain sight: legal name and a real way to get in touch.

This doesn’t replace legal advice: it’s what we verify is published and working.

7. Content and the details that show

• No filler text or test images. Searching the whole site for “lorem” takes ten seconds.
• Internal and external links checked; none pointing to the staging environment.
• Favicon and mobile icons.
• Footer year, phone numbers, addresses and social links up to date.
• Spelling checked in every language, metadata included.

The final detail

Go through the site on a real phone, on mobile data, start to finish: arrive from a search engine, browse, fill out the form. If it feels right there, it’s ready.

After launch

The checklist doesn’t end at publish. Over the first few weeks:

1. Day one: confirm the site is indexable and the redirects respond.
2. First week: check Search Console for crawl errors and not-found pages.
3. First month: compare traffic and rankings against the baseline, and review Core Web Vitals once field data shows up.

Area	Main tool
Technical SEO	Google Search Console, Rich Results Test
Performance	PageSpeed Insights, Lighthouse
Accessibility	axe, Lighthouse, keyboard and screen reader
Redirects	A link crawler and the old sitemap

Next step

This checklist is part of the launch stage of our process and also the basis of our audits. If you want to know how your current site holds up against it, see our performance and technical SEO service or get in touch and we’ll take a look.