Almost every failed website redesign we are called in to repair failed for the same reason: the planning stage was skipped, compressed into a single meeting, or treated as a formality between winning the budget and starting the design. The build itself is rarely the problem. Development is the most predictable part of a web project. It is everything decided before development that determines whether the new site earns its cost.
What follows is the work that should happen before anyone opens a design tool. It is not glamorous, and it is the difference between a redesign that pays for itself and one that quietly costs you a third of your enquiries.
Start by writing down what the redesign is for
This sounds trivial. It is not, because “the site looks dated” is not a goal — it is an observation. If dated appearance is the only stated reason, the project has no way to be judged afterwards, and every design decision becomes a matter of taste with no tie-breaker.
Useful goals are specific and measurable: increase enquiries from the services pages, reduce the proportion of visitors who leave the homepage without going deeper, allow the marketing team to publish a new service page without a developer, or reduce the time to first meaningful content on mobile. Each of those implies different structural decisions, and some of them conflict. Better to discover that conflict now than in the third round of design feedback.
Write down two or three goals, in priority order. When a decision is contested later — and one will be — the priority order resolves it without a meeting.
Record a baseline before you change anything
You cannot tell whether a redesign worked without knowing where you started. This is the single most commonly skipped step, and its absence is why so many redesigns are evaluated on whether the client likes the look of them.
Before any work begins, record: monthly enquiry volume by source, traffic to your top twenty pages, conversion rate on your key journeys, the search queries bringing people to the site, and current Core Web Vitals on your most important templates. Take screenshots of the analytics views. Put the numbers in a document with a date on it.
Six months after launch, that document is the only thing standing between an honest assessment and a conversation in which everyone remembers the old site being worse than it was.
Inventory every page, then decide its fate
Export a complete list of the URLs on your current site. Crawl it if you do not have one — the point is to have every page in a spreadsheet, including the ones nobody remembers publishing.
Then add columns: monthly traffic, whether it converts, whether the content is still accurate, and a decision. Every page gets exactly one of four decisions:
- Keep — it performs, it is accurate, it moves across largely unchanged.
- Rewrite — the topic is right, the execution is not.
- Merge — three thin pages about adjacent topics become one good page.
- Retire — it serves nobody, and it should not be carried across.
This exercise is uncomfortable, because most sites contain a great deal of content that nobody reads. Carrying it across because deleting it feels wasteful is how sites accumulate three hundred pages, of which twenty do the work. A smaller, better site is easier to maintain, easier to navigate and performs better.
Plan the redirects at the same time as the structure
This is the step that, when skipped, silently destroys search visibility built over years. It happens like this: the new site launches with a new URL structure, the old URLs return a 404, and over the following weeks search engines drop them. Rankings fall, traffic falls, enquiries fall — and by the time anyone connects the drop to the launch, two months have passed and the decline is being attributed to a quiet season.
The fix is straightforward but must happen early. Take the URL inventory you already built and add a destination column. Every URL gets one of three outcomes: a one-to-one redirect to its equivalent on the new site, a redirect to the most sensible parent page where no equivalent exists, or a deliberate retirement recorded as such with a reason.
Do this during the structure stage, not on launch day. When redirect mapping happens on the day of launch it is done in a hurry, by someone who did not write the content, against a deadline. That is precisely the wrong conditions for a task where each individual decision is small and the cumulative cost of getting them wrong is enormous.
After launch, re-crawl the old URL list and confirm every one resolves as intended. It takes an hour and it is the cheapest insurance in the project.
Decide who is writing the content, and when
Content is the reason redesign projects overrun. Not development, not design, not integrations. The build finishes on schedule and then waits three weeks for the About page, the team biographies and the product photography.
This is entirely understandable — writing is hard and it competes with running a business. But it has to be planned rather than assumed. Go through the page inventory and, for every page marked rewrite or new, put a name and a date against it. Not a department: a person. Then be realistic about how much any one person can write while also doing their actual job. Two good service pages a week is a reasonable pace for someone who is not a full-time writer.
If the honest answer is that nobody internally has the time, that is a legitimate finding, and the options are to hire a writer, to reduce the number of pages being rewritten, or to launch with existing content on some pages and improve them afterwards. All three are better than discovering the problem in the final week.
Establish what the new structure actually needs to do
With the page inventory and the goals in hand, the new information architecture becomes a much more concrete exercise. The question is not “what pages should we have” in the abstract — it is “what is the shortest sensible route from each entry point to an enquiry”.
Most visitors do not arrive at your homepage. They arrive at a service page, a blog post or a product from a search result, and the homepage is something they may never see. So each significant entry page needs to work as a landing page: it must establish what you do, answer the question that brought the visitor, and offer an obvious next step.
Navigation follows from that, not the other way round. A navigation menu that mirrors your internal org chart rather than your customers’ decision process is one of the more reliable ways to lose people.
Agree what is out of scope, in writing
Scope creep on redesign projects is rarely dramatic. It is a series of individually reasonable additions: a booking integration, a members’ area, a second language, a newsletter signup that syncs to the CRM. Each one is small. Together they double the project.
The defence is a written scope with an explicit exclusions list, and a change process agreed before work starts. Changes are normal and often sensible; what causes damage is changes being absorbed silently and reappearing later as an unexplained delay. Every change should carry a cost and a schedule impact, stated at the time it is requested.
Check whether you need a redesign at all
The last item on a pre-redesign checklist should be a genuine reconsideration of the whole project.
A redesign fixes structure, clarity, editability and technical foundations. It does not create demand that was never there. If your problem is that almost nobody visits the site, a redesign will produce a better-looking site that almost nobody visits. If your problem is one specific broken journey, fixing that journey costs a fraction of a rebuild. If your problem is that the content is thin, better content on the existing site will outperform thin content on a new one.
We tell perhaps a third of the people who approach us about a redesign that a smaller intervention would achieve more for less. It is a shorter invoice and a considerably better outcome for them, and it is the conversation that most reliably earns the larger project a year later.
The short version
Before any design work: write down two or three measurable goals in priority order. Record a baseline. Inventory every URL and decide its fate. Map the redirects. Name a content owner and date for every page being rewritten. Design the structure around entry points rather than around the homepage. Agree scope and exclusions in writing. And check, honestly, that a redesign is the right intervention.
None of it is technically difficult. All of it is routinely skipped, and skipping it is why so many redesigns cost a great deal and change very little.
