Diagnose before you rebuild

Most businesses arrive at a rebuild the same way. Something feels wrong. Enquiries are slower than they should be, admin has quietly expanded, and the website looks dated next to a competitor. The conclusion is a new website.

Sometimes that is right. Often it is the most expensive way to avoid a diagnosis.

The symptom is not the fault

A website is the visible edge of a system. Behind it sit the enquiry route, the data that records what happened, the admin work that follows, the tracking that tells you whether any of it worked, and the content that search engines and AI systems read. A slow month can come from any of those layers. Replacing the visible edge changes only one.

Before scoping any build, three questions decide the shape of the work.

1. What is the site saying to a buyer in the first fold, in plain words.
2. What can be read by search engines and AI systems, and what is invisible to them.
3. Where does information currently live, and how many places have to agree before anything is true.

What a diagnosis produces

A diagnosis is not a mood board. It is a written position on what to keep, what to connect, what to replace and what to rebuild, with the reasoning attached. That position can be uncomfortable. It sometimes concludes that the website is adequate and the operational layer behind it is the constraint.

That conclusion saves more money than a redesign ever will.

Where to start

• Write down the last five enquiries and trace each one end to end. Note every place a human retyped something.
• Open the site on a phone with the sound on and read the first screen out loud.
• Check whether your primary service has structured data. If it does not, AI answers are guessing at what you do.

Diagnosis first. Scope after. That order is the whole method.

Earlier issues

• Issue 003 · What AI systems can read about you →
• Issue 002 · The cost of a borrowed system →