Good websites
begin with a
clear direction.

Most launch problems are not technical; they are unresolved decisions. Before anyone opens a design tool, agree on one sentence that states what the website must achieve in its first six months — for example, “generate twenty qualified enquiries a month from local search” or “replace our paper catalogue with a store that sells while we sleep”. A goal such as “look more professional” cannot be tested, cannot be measured, and cannot settle a single argument about scope.

Once that sentence exists, three things follow. Scope: list what version one includes and, just as importantly, what it deliberately leaves out. Success: choose the two or three numbers you will actually watch — enquiries, sales, sign-ups, organic visits — and set up measurement before launch rather than after it. Timing: pick a go-live date you can keep and work backwards from it, giving content, approvals, testing and team training a deadline of their own. When a late request arrives, the goal makes the decision for you: if it does not serve the goal, it goes into version two.

A page with two jobs ends up doing neither well. Before launch, walk through the whole site page by page and write down the one question each page answers and the one action it should earn — buy, book, call, subscribe. If a page cannot state its single purpose in a single sentence, merge it with another, rewrite it, or cut it. A smaller site with sharp pages is easier to read, easier to approve and far easier to keep current.

The table below is an example for a project kickoff: short enough to fit on one screen, specific enough that everyone knows who owns what once the site is live. Keep it next to the sitemap and revisit it whenever you add a page — it is the fastest way to spot orphan pages, competing messages, and the duplicate “about” content that quietly doubles your maintenance work.

Run the checklist twice: once on the staging site a few days before go-live, and again an hour after the real site is up. Split it between two people so nobody signs off their own work, and record what fails rather than trusting memory — the second pass exists precisely to catch what the first pass quietly fixed. Anything that fails gets an owner and a re-test before the announcement goes out, not a note to “look at after launch”.

• Redirects and broken links — every old URL mapped, no 404s in the main journeys.
• Forms and inbox — each form tested end to end, notifications reaching a monitored address.
• Mobile and speed — key pages checked on a real phone and against a speed budget.
• Analytics and ownership — tracking verified, registrar and hosting accounts under company credentials.
• Content and proofreading — prices, phone numbers and legal text signed off by a second reader.
• Contingency — a recent backup, a written rollback plan, and one named person on launch duty.

Testing is a rehearsal, not an inspection. Walk the site as a first-time visitor on at least three devices — a phone, a mid-range laptop and a tablet — following the main journey from an ad or a search result all the way to a submitted form. Try the awkward cases too: a slow connection, a half-typed form, the back button, and a long name in a required field.

Then check what people will actually read. Headings should make sense on their own, paragraphs short enough to scan, and contrast strong enough to hold up outdoors in daylight. Ask someone outside the project to click through while you stay quiet — wherever they hesitate is where your copy or navigation is failing them. Fix what you find, re-run the affected checks, and only then schedule the launch announcement for a date you can keep, not one you hope to hit.