Website Launch Checklist: 44 Things to Check Before a Client Site Goes Live

Every agency has launched a site that still said noindex a week later. Or one where the contact form sent its emails into nothing, or the old URLs all turned into 404s. None of it is hard. It is just easy to forget on launch day, when the client is waiting and everyone wants to see it live.

This is the checklist we would want on that day. It is written for agencies and freelancers building sites for clients in the EU, the UK and Norway, so it includes the legal part that most launch checklists leave out.

Technical basics

• HTTPS works on every page, and http and the bare domain redirect to the one canonical address (with or without www, pick one).
• The staging noindex tag and any password protection are gone from production.
• robots.txt allows crawling and points to the sitemap.
• An XML sitemap exists and lists only real, indexable pages.
• Old URLs from the previous site redirect (301) to their new equivalents.
• There is a custom 404 page that sends people somewhere useful.
• Every link in the navigation and footer works, and there are no placeholder links left (href="#").
• Every form has been submitted once on production, and the email arrived where the client expects it.
• Forms have spam protection.
• Backups run, and someone has tested restoring one.
• Uptime monitoring is set up, and the alert goes to a person, not an unread inbox.
• DNS is documented: who controls the domain, and where it points.

SEO

• Every page has its own title and meta description.
• Every page has exactly one H1.
• Open Graph title, description and image are set, and a shared link previews correctly.
• Canonical tags point to the right URL.
• Language and hreflang are set if the site has more than one language.
• The site is verified in Google Search Console, and the sitemap is submitted.
• Images have descriptive file names and alt text.

Performance

• Images are compressed and served in a modern format at the size they are shown.
• Core Web Vitals pass on mobile in PageSpeed Insights.
• Caching is configured for static files.
• Fonts are self-hosted rather than loaded from a third party. That is faster, and it avoids sending every visitor's IP address to Google Fonts.
• No leftover scripts from the build: test pixels, heatmaps nobody looks at, chat widgets from the demo.

Accessibility

• Text contrast meets WCAG AA (4.5:1 for normal text).
• Every form field has a label, and error messages say what is wrong.
• The site can be used with the keyboard alone, with a visible focus state.
• Lighthouse's accessibility audit has no serious findings.

This is not only good practice. The European Accessibility Act has applied to many online services, including most online shops, since June 2025, and Norway has its own regulation on universal design for websites aimed at the public.

The legal part most checklists skip

This is where a site that looks finished can still be a problem for the client. In the EU, the UK and Norway, analytics and marketing cookies need consent before they are set, and the order is what regulators check.

• No analytics or advertising tag runs before the visitor has agreed. Load the page in a private window, do not touch the banner, and look at what starts. Our free GDPR scan does exactly that in about ten seconds.
• The banner lets visitors reject as easily as they accept.
• YouTube videos, maps and other embeds wait for consent too, or show a placeholder.
• There is a cookie declaration that lists the cookies the site really sets. A cookie policy generator can write it from a scan.
• There is a privacy policy that describes this client's processing, not a template from another site.
• Visitors can change or withdraw their consent later, for example through a link in the footer.
• If your agency hosts or maintains the site and can access personal data on it (form submissions, user accounts, order data), you and the client have a data processing agreement in place.

The consent part is also where sites drift after launch. Someone in marketing adds a new pixel six months later, and the banner never hears about it. If you look after many client sites, it is worth handling consent in one place rather than one tool per client. We wrote about how that works in cookie consent for agencies.

Analytics

• Analytics is installed on the production domain, not just staging, and only loads after consent.
• Conversions the client cares about (form sent, purchase, booking) are tracked as events.
• Your own team's visits are filtered out, if the tool supports it.
• If the client uses Google Ads, Consent Mode v2 is set up. You can check the signals with a Consent Mode v2 checker.

Handover to the client

• The client owns the domain, the hosting account and the analytics property, and your agency has access, not the other way round.
• Logins are shared through a password manager, not email.
• The client has a short guide to editing content.
• It is written down who is responsible for updates, security patches and keeping the cookie declaration current when new tools are added.
• The maintenance agreement, if there is one, says what is included and how fast you respond.

Run the quick checks last

Most of this list is done once. A few things are worth running again on launch day itself, because they change when the site moves from staging to production: the noindex tag, the form emails, and what loads before consent. The last one takes ten seconds with the GDPR scan, and the report link is something you can send straight to the client.