The website launch checklist.

Before anything else, check who owns what. A website is a domain, a hosting account, a content system, a code repository, and usually an email service for its forms. Each of those should be registered to your company and reachable by more than one person in it.

The common failure is not dramatic. A developer or agency registers the domain under their own account to save time, the relationship ends, and renewing your own domain becomes a negotiation. Fix it before launch, while everyone is still answering email.

A visitor arriving from a search result is asking four things: what this company does, whether it is for someone like them, where it works, and how to get in touch. If the homepage does not answer all four without scrolling far, nothing else on the page gets the chance to.

Give every page one main action. A page that asks the visitor to call, book, subscribe, and download is a page that has not decided what it is for. And put real contact details somewhere a person can find them: an email address that a person reads beats a form that goes nowhere.

Search engines need to know which address is the real one for each page and what each page is about. Most of that is configuration, done once, and it is far easier to do at launch than to repair after the wrong version has been indexed.

One example from this website: it serves regional versions of its pages for visitors in different markets, and for a while each regional copy told search engines it was the original. The copies were almost identical, so search engines picked between them on their own — and a regional service page, not the homepage, became the result for the company's own name. Each regional page now points to one canonical version. If your site has more than one URL for the same content — regional copies, tracking parameters, trailing slashes, www and non-www — decide which one is real before launch.

Google's Core Web Vitals describe a page that feels fast: the largest piece of content appears within 2.5 seconds (Largest Contentful Paint), the page responds to a tap within 200 milliseconds (Interaction to Next Paint), and nothing jumps around while it loads (Cumulative Layout Shift under 0.1). Google assesses these at the 75th percentile of real visits, so most visitors must get that experience, not just the ones on office Wi-Fi.

Test on a mid-range phone on mobile data before launch. The usual fixes are unglamorous: images exported at the size they are displayed and in a modern format, fonts that do not block text from appearing, and fewer third-party scripts. Every tag, chat widget and tracking pixel is code your visitors download before they can use the page.

Accessibility is not a separate project; it is a set of checks that take an afternoon at launch and much longer to retrofit. The Web Content Accessibility Guidelines (WCAG) at level AA are the usual standard, and most of what they ask for also makes a site easier for everyone to use.

Submit every form on the live domain, not only on the staging copy, and confirm the message arrives where it should. Then check what happens when it fails: a form that shows a success message while the email silently bounces is worse than no form, because the visitor thinks they reached you.

If the site sends email from your domain, set up the domain's email authentication records (SPF, DKIM and DMARC) with your email provider, or those messages are likely to land in spam.

A privacy notice should describe what this website actually collects and where it goes — not a template written for a different business. If the site sets no tracking cookies, it does not need a cookie banner; if it does, the banner needs to offer a real choice. Name the legal entity behind the site and give a way to contact it.

Serve every page over HTTPS, and ask your developer which security headers are set. A site that loads nothing from other domains can say so in a Content-Security-Policy, which limits what an attacker could inject.

Launch is when search engines start forming an opinion of the site, so the first weeks are worth watching. If the new site replaces an old one, every old URL that had visitors or links should redirect permanently to its closest new page — otherwise that history is thrown away.