Launches rarely fail on the big things. The design is approved, the pages are built, the domain is ready. They fail on small things nobody owned: a contact form that sends to an old inbox, a noindex tag copied from staging, a cookie banner that fires ads before consent. This checklist lists 50 checks, grouped by area, with the role that usually owns each.
What should a website launch checklist cover before you go live?
Before launching a website, check that the content is final, search engines can index it, forms and tracking work, consent is handled correctly, pages load fast on a phone, and the basics of accessibility are in place. Launch is the last stage of the website design process, and most of these checks should run on staging a few days before the go-live date, not on the day itself.
Owners below are roles, not people. On a small team one person may hold several roles. What matters is that each line has exactly one name next to it before launch week starts. Use it alongside a proper website QA testing routine, which covers how to test, while this list covers what must be true.
- Copy this list into a shared doc or tracker.
- Put one name in the owner column for every item.
- Run checks 1 to 43 on staging, then fix and re-check.
- Run the launch-day section with the developer and the site owner together.
- Keep the list: it becomes your template for the next release.
Which content checks belong on a pre-launch checklist?
Content checks confirm that every word, image and link on the site is final, correct and approved. Placeholder text that survives to launch is common, especially in footers, meta descriptions and rarely visited pages like the privacy policy.
No. | Check | Owner |
|---|---|---|
1 | No placeholder text anywhere, including footers and empty states | Copywriter |
2 | Every page approved in writing by the named approver | Founder |
3 | Spelling and product names consistent across pages | Copywriter |
4 | Pricing, plan names and numbers match what sales quotes | Founder |
5 | Customer logos and testimonials cleared for public use | Marketing |
6 | All internal links point to live pages, none to staging | Developer |
7 | Images compressed and given descriptive alt text | Designer |
8 | Legal pages (privacy, terms, cookies) published and linked | Founder |
What SEO and indexing checks do you need before going live?
SEO checks make sure search engines can find, crawl and correctly index the new site, and that old URLs pass their value to new ones. The single most damaging miss on this list is item 9: a noindex rule left on from staging. If you're replacing an existing site, the website redesign checklist covers redirect mapping in more depth.
No. | Check | Owner |
|---|---|---|
9 | Staging noindex removed from production (meta tag, header and robots.txt) | Developer |
10 | robots.txt allows the pages you want indexed | Developer |
11 | XML sitemap generated, live and listing only canonical URLs | Developer |
12 | Redirects from every old URL tested, with no chains | Developer |
13 | Each page has a unique title and meta description | Copywriter |
14 | Canonical tags point to the production domain | Developer |
15 | One H1 per page that says what the page is about | Copywriter |
16 | Custom 404 page with links back to key pages | Designer |
17 | Search Console verified and sitemap submitted | Marketing |
18 | Social share images and titles set for key pages | Designer |
How do you check forms, tracking and consent?
Check forms by submitting each one yourself and confirming the result arrives where it should, and check consent by watching which tags fire before and after you accept. A form that shows a success message but never delivers is invisible until a lead complains. Consent Mode v2 errors are just as quiet: the research we rely on lists race conditions, missing ad_user_data and ad_personalization signals, and duplicate GA4 and Ads tags as the usual causes.
No. | Check | Owner |
|---|---|---|
19 | Every form submitted on production and received in inbox or CRM | Developer |
20 | Form emails sent from an authenticated domain so they don't land in spam | Developer |
21 | Spam protection on forms that doesn't block real users | Developer |
22 | Thank-you state or page confirms what happens next | Copywriter |
23 | Analytics installed once, with no duplicate tags | Marketing |
24 | Key events (demo request, signup, booking) firing and named consistently | Marketing |
25 | Consent banner blocks non-essential tags until the visitor chooses | Developer |
26 | Consent mode signals sent correctly, including ad_user_data and ad_personalization | Developer |
27 | Booking, chat and CRM integrations connected to production accounts | Marketing |
How to test consent mode in five minutes
Open the site in a private window with developer tools on the network tab. Before touching the banner, filter for analytics and ads requests: you should see either none or only cookieless pings, depending on your setup. Accept all, reload, and confirm the full tags now fire once each.
Then repeat with reject all. If you see the same requests in both cases, consent isn't wired up. If you see two analytics requests per page view, a tag is installed twice, often once in the code and once in a tag manager. A short list of the events you expect, written before launch, makes these checks much faster.
Which performance and mobile checks matter most?
The performance checks that matter most are on a real phone over a cellular connection, because that's how many visitors first see the site. A fast office laptop on fiber hides problems. Core Web Vitals, especially interaction responsiveness (INP), suffer most from heavy third-party scripts added late in a project.
No. | Check | Owner |
|---|---|---|
28 | Key pages tested on a real phone over cellular, not just Wi-Fi | Designer |
29 | No horizontal scroll or clipped text at narrow widths | Designer |
30 | Hero images sized correctly and not lazy-loaded above the fold | Developer |
31 | Fonts load without long invisible-text flashes | Developer |
32 | Third-party scripts audited: remove anything nobody can justify | Marketing |
33 | Lab speed test run on home, pricing and a long page | Developer |
34 | Animations respect reduced-motion settings | Developer |
35 | Site checked in current Chrome, Safari, Firefox and Edge | Developer |
What accessibility and legal checks should you run?
Run an accessibility smoke test before launch: keyboard navigation, visible focus, color contrast, alt text and form labels. It won't replace a full audit, but it catches the problems that block real users. If you sell to consumers in the EU, the European Accessibility Act has applied since 28 June 2025, so accessibility is also a legal question. Test it from a staging environment so fixes don't touch the live site.
No. | Check | Owner |
|---|---|---|
36 | Every interactive element reachable and usable by keyboard | Developer |
37 | Focus states visible on links, buttons and form fields | Designer |
38 | Text contrast meets WCAG AA | Designer |
39 | Form fields have labels and clear error messages | Developer |
40 | Page language set and headings in a logical order | Developer |
41 | Videos have captions; nothing autoplays with sound | Marketing |
42 | Cookie and privacy wording reviewed for your markets | Founder |
43 | Domain, hosting and code accounts owned by the company (ownership checklist) | Founder |
What should you do on launch day and in the first 48 hours?
On launch day, switch the domain, then immediately re-check indexing, redirects, forms and analytics on the live site. Things that worked on staging can break on production because of DNS, caching or environment settings. Launch early in the week and early in the day so people are around to fix problems.
No. | Check | Owner |
|---|---|---|
44 | DNS switched and HTTPS working on both www and the bare domain | Developer |
45 | Live page source checked for noindex (repeat of item 9) | Developer |
46 | Top old URLs spot-checked for correct redirects | Developer |
47 | One real test submission through every form on production | Marketing |
48 | Real-time analytics showing visits and key events | Marketing |
49 | Uptime monitoring and error alerts switched on | Developer |
50 | Search Console checked after 48 hours for crawl and indexing errors | Marketing |
After that, launch turns into maintenance. Our guide to the first 90 days after a website launch covers what to watch, and the website maintenance checklist covers the recurring tasks.
