Most website launches are announced a day too early. A page 404s, a form sends into the void, or the old site is still showing in search results a month later. None of these are hard to prevent; they are just easy to forget when everyone is impatient to share the link.

This is the list worth running through before you post the announcement — in order, because later items depend on earlier ones.

Content and copy

  1. Every page has one clear job. If you cannot say what a page is for in a sentence, it is not ready.
  2. Spelling and consistency checked by someone who did not write it.
  3. Contact details are correct — email, phone, address, hours — and tested by sending a message to each.
  4. No placeholder text anywhere: no "lorem ipsum", no "[insert case study]", no template company name.
  5. Prices and dates current. Old prices are the most common embarrassing launch bug.
  6. Legal pages live: privacy policy, terms, returns or refunds if you sell online.

Technical basics

  1. HTTPS everywhere, with the certificate covering both the bare domain and www.
  2. One canonical version — pick https://example.com or https://www.example.com and redirect the other permanently.
  3. 404 page is useful: it explains the problem and links back to the homepage and main sections.
  4. Forms tested end to end — submit, receive, reply. Test on a phone, with a different email provider, and with an empty submit.
  5. Email deliverability checked: SPF, DKIM and DMARC records set, so confirmations do not land in spam.
  6. Backups running daily, with one restore tested.

Search setup

  1. Sitemap generated and submitted in Google Search Console and Bing Webmaster Tools.
  2. robots.txt allows crawling and points at the sitemap — and does not block the whole site by accident.
  3. No noindex left on from staging. This is the single most common launch failure.
  4. Titles and meta descriptions written for every page, unique and under the usual length limits.
  5. Structured data validates for the pages that use it — organisation, article, product, FAQ.
  6. Analytics or Search Console connected so you can see traffic from day one. A 28-day delay makes launches impossible to read.
  7. Old URLs redirected with 301s to their closest new equivalent; check the top ten pages by traffic from the old site.

Experience on a real phone

  1. Read the whole site on a phone, on mobile data rather than office wifi. Tap every link in the main menu.
  2. Check the slowest page — usually the image-heavy homepage or a gallery. Compress before launch, not after.
  3. Keyboard and screen reader pass: tab through the homepage, check focus is visible, confirm images have alt text and buttons are named.
  4. Test the checkout or enquiry flow as a first-time customer who has never heard of you.

The day after

  • Watch the error log and the 404 report for the first week.
  • Submit the sitemap again after any batch of changes.
  • Ask three customers to find one specific thing on the site and watch where they go.
  • Fix the first five things they stumble on — those are worth more than any redesign.

A short pre-announcement test

Before you tell anyone, open the site in a private window on a phone and try to do the one thing the site exists for: buy, book or enquire. If you cannot complete it in under two minutes without help, the launch is not ready.

Then send the link to two people who do not work with you, with one instruction: "Find out what we sell and how much it costs." Their confusion in the first thirty seconds is your to-do list.

Checklist summary

  • Copy checked, contact details tested, no placeholders
  • Legal pages live; prices current
  • HTTPS, one canonical domain, useful 404
  • Forms and email deliverability tested
  • Sitemap submitted; no stray noindex
  • Titles, descriptions and schema in place
  • Old URLs redirected; analytics connected
  • Read on a phone, keyboard and screen reader checked
  • Three real users asked to find something specific

A launch is not the finish line; it is the first day of evidence. Keep the list and run it again before every significant change — the second launch is usually the one that breaks something, because nobody expects it to.