← All posts

The website pre-launch checklist for client sites

A website pre-launch checklist for client sites: content, routes, redirects, forms, search settings and the domain, all checked in staging before go-live.

13 October 2026 6 min read by Contentive · Team

The things that go wrong at launch are almost never the things you worked hardest on. The design is fine. The home page is fine. What breaks is the contact form that sends to a test inbox, the old URL with nothing behind it, the robots setting left on "don't index" from the build. Small, dull and very visible.

This is a website pre-launch checklist for client sites, grouped so you can hand sections to different people. It assumes you have somewhere private to check the site before it's live. If you don't, that's the first problem to fix, and staging vs production explains why.

Content

No placeholder text anywhere. Search for "lorem", "TBC", "test" and "xxx", including in alt text and page descriptions.
No test entries: sample posts, a dummy team member, the "Product name here" card.
Every image has meaningful alt text, or is marked decorative on purpose.
Legal pages exist and are current: privacy, cookies if you set any, terms if the client sells anything, accessibility if they need one.
Company details are correct everywhere they appear: phone, address, registration number, opening hours. If they're stored once and reused, check the source. If they're typed on each page, check every page.
The client has signed off the copy in writing, not in a meeting.

Routes and redirects

Every page you expect is reachable from the navigation or from a link. Look for orphans.
Every old URL from the previous site either still works or redirects to its new home. Work from the old site's sitemap, not from memory.
Redirects go straight to the destination, without passing through a chain of other redirects.
The 404 page exists, is styled, and offers a way back.
Links inside content point at the live domain, not at a staging or development address.

Forms

Every form has been submitted for real, from the staging site, with the kind of data a visitor would send.
The notification arrived, at the right inbox, and that inbox belongs to the client. A role address beats a person's.
The submission is stored somewhere the client can find it, not only in an email.
Spam protection is on, and a legitimate submission still gets through it.
The thank-you message or redirect after submitting is correct.

There's more on getting forms right in website contact form spam, notifications and where submissions go.

Search and crawlers

Every page has its own title and description, written rather than defaulted.
The sitemap lists the pages you want indexed, and nothing you don't.
robots.txt allows search engines. The build-time "disallow everything" is gone.
No page carries a leftover "noindex" from development.
The AI-crawler policy is a decision, not an accident: which answer engines may read and cite the site, and whether training crawlers are blocked.
Sharing previews (the title, description and image shown when a link is pasted) look right on the pages the client will share most.

Performance and images

Images are sized for where they appear, not uploaded at camera resolution.
The heaviest page loads acceptably on a phone, on a mobile connection, not just on office wifi.
Fonts load without the page jumping around as they arrive.
Third-party scripts are only the ones you need. Every embed costs load time.

Domain, certificates and the password wall

You know who controls DNS and have the access you need on launch day.
The DNS change is planned, including how long old records will linger.
The certificate is valid on both the bare domain and www, and one redirects to the other.
Email records (MX, SPF and the rest) are untouched by the website change. Check this twice; it's the mistake that takes the client's email down.
If the site was behind a password during the build, it comes down at launch, and you check it from a private window afterwards.

Analytics

Analytics is installed on the live domain, not only on staging.
If it uses cookies, the consent banner works and blocks tracking until consent. If it doesn't, you know why it doesn't need one.
Someone at the client knows where to look at the numbers.

Check it in staging, not in your head

Every item above is easier to tick against a real address than against your memory of what you built. Use a private staging copy of the site and send preview links to anyone who needs to look. Check on a phone. Check signed out. A checklist done from the CMS admin is a checklist of what you think is there.

In Contentive, every site has a standing staging address next to the live one, every page there carries a "Staging preview — not the live site" bar, and visitors need an expiring preview link to see it at all. The sitemap is generated from the published pages, so checking it in staging tells you what live will list. Every site also serves a robots.txt with an AI-crawler policy by default: answer engines allowed, training crawlers blocked. A pre-launch site can sit behind a whole-site password until you take it down.

The launch hour

Promote the checked staging version to live.
Load the live site signed out, in a private window, on desktop and phone.
Click through the main navigation and the five most important pages.
Submit every form again, on the live domain, and confirm the notifications arrive.
Fetch robots.txt and the sitemap from the live domain.
Tell the client, with the live link.

The second form test is not redundant. Forms are the part most likely to behave differently on a new domain.

Write the rollback plan before launch

Decide in advance what you'll do if the live site is wrong in a way you can't fix in ten minutes. Write it down: who decides, and what the steps are. If your platform keeps versions, the plan is usually to roll back to the last good version and put it live. In Contentive that's two steps: roll back, which puts the earlier version on staging, then promote it. Worth knowing before the moment you need it.

The three most often missed

If you only check three things, check these. Form notifications going to a real, monitored inbox. Redirects from every old URL. And a crawler policy, in robots.txt or a stray "noindex", that's still blocking search engines a month after launch, when someone finally asks why the site isn't in Google.

Once it's live, the website handover checklist picks up from here.