The website launch checklist.

Before a site goes live, eight things get checked: the words, the phone view, the speed, the enquiry route, the search basics, security, measurement and the paperwork. It is the same list we run against every build. Each item takes a minute to check and an hour to fix afterwards — which is the whole argument for checking before launch rather than after.

Reviewed October 9, 2026. Prices are quoted per project; nothing on this page is a published price list.

The short answer

Words. Phone. Speed. Enquiry route. Search. Security. Measurement. Paperwork.

A launch is not a moment, it is a check. Read every page on a phone with one hand. Send the enquiry form yourself and watch where it lands. Search the site for the words a customer would actually use, and make sure every account created during the build is registered in your name. None of it needs a developer; all of it needs doing once, in order, before the URL leaves the building.

1. The words

• Every page has one heading that says what the page is, in the words a customer would use.
• Names, prices, phone numbers and opening hours spelled the same way everywhere they appear.
• No template copy left behind: demo text, placeholder tags or somebody else’s testimonials.
• One obvious next step per page — call, book, or send the form.

2. The phone view

Most of your visitors arrive on a phone, and that is the layout that gets checked last. Open the site on a real handset: does the menu open, can you hit the buttons with a thumb, does the text read without zooming, and does anything run off the side of the screen? Rotate it. A site that works on a laptop and embarrasses you on a phone is not finished.

3. Speed

Images are the usual culprit. They should be sized for the screen they are shown on and compressed, not camera originals dropped in at full resolution. Beyond that: the page should read and navigate with scripts blocked, and nothing should sit and spin before the content appears. If a visitor on a weak signal has to wait, you have lost them before the headline loads.

4. The enquiry route

• Fill in the form yourself, on a phone, and confirm it arrives — check the inbox and the spam folder.
• Check every link that matters: phone numbers should dial, the map should open, email addresses should compose.
• Click a link that should not work. You want a real 404 page, not a blank screen.
• Read the confirmation message the customer gets. It is the first sentence of your reply.

5. Search and discoverability

• One title and one description per page, written to say what the page says.
• One H1 per page, and links between your own pages with anchors that describe where they go.
• A sitemap that lists every page you want found, and robots rules that do not block the crawlers you want reading it.
• Each page canonical to itself, and structured data that parses — an FAQ or a product block that fails validation is worse than none.
• Submit the sitemap to search consoles, and check back in a week: discovered is not the same as indexed.

6. Security and access

• Serve over HTTPS, and check that nothing on the page loads over plain HTTP.
• No default or shared logins left on anything, and no admin account on the public site that nobody uses.
• Unique passwords in a password manager, not in a spreadsheet or a group chat.
• Domain, hosting and email registered in your name — the four things you must own, checked at launch rather than assumed.

7. Measurement

Whatever you use — analytics, a search console, a form log — confirm it is actually recording before launch, and send one test event so you know the wiring works. Install it on day one, not in month six: the first weeks are when you learn which pages people arrive on and where they give up, and you cannot recover that data afterwards.

8. Paperwork and handover

The launch is not done until you hold the keys: registrar login, hosting account, the full source files, and the email admin for your own addresses, all listed in one document with where each one lives. Keep that document somewhere you would still find it if this relationship ended — because the test of a handover is whether the site survives you never speaking to the builder again.

After launch, nothing is owed to us. If you would rather have monitoring and a monthly allowance of updates than quote every piece, care plans are published with their prices; if you would rather not, a quiet static site may never need one.

Questions

Do I need this checklist for a one-page site?

Yes — the list gets shorter, it does not disappear. A one-page site still needs its words checked, its form tested, its phone layout read and its accounts registered in your name. What you can usually skip is nothing: every item on the list protects something you paid for.

What do people forget most often?

Where the enquiry form actually goes, and who owns the domain. A form that delivers nowhere looks exactly like a form that works until the first customer uses it, and a domain registered in the designer’s name only surfaces when you want to leave. Test both on the day.

When should the checklist be run?

Before launch, and again after any significant change — a new section, a new form, a new integration. Most launch problems are not introduced at launch; they arrive later, quietly, with the third edit nobody retested.

Do you run this for me?

It is part of every build, and the handover document lists what was checked along with every account, password and file. You get the same list, so you can run it yourself on anything else you own — the checklist is not the valuable part; doing it before launch is.

Related: our five-step process · the search work that follows launch · the answers hub.