Will a redesign make you more money, or simply cost you some?

A redesign is one of the few investments that regularly makes a business worse off. Not because new sites are bad, but because the old one was doing things nobody had bothered to measure, and the new one quietly stopped doing them.

A redesign raises revenue only when it fixes a specific problem that was costing you money: an unclear message, a slow or unusable site on phones, a structure search engines cannot read, or a site nobody can update. A redesign driven by taste alone frequently loses revenue, because it replaces pages that were converting without anybody knowing which ones those were.

The pattern nobody warns you about

It goes like this. The site feels old. Somebody new joins, or a competitor launches something striking, and the decision is made. Several months and a considerable sum later the new site goes live, everybody admires it, and then the enquiries fall.

Nobody can explain it, because nobody wrote down what the old site was doing. Which pages produced the enquiries, which searches brought the good customers, which small awkward paragraph happened to answer the question everybody had. All of that was invisible, so all of it was thrown away without discussion.

This is not an argument against rebuilding. It is an argument against rebuilding blindly. The difference between a redesign that earns and one that costs is almost entirely a matter of what you measured before you started.

What actually changes the revenue

It is worth being precise about which parts of a redesign have any effect on money at all, because a great deal of the effort typically goes into parts that have none.

• The message at the top of the important pages. Large effect, immediately.
• How easy it is to take the next step, especially on a phone. Large effect, immediately.
• Loading speed, particularly on mobile connections. Real effect, and often the easiest win.
• Whether proof appears where doubt appears. Real effect on the pages that matter.
• Whether search engines and AI assistants can read and understand the site. Large effect, more slowly.
• Colours, fonts, animations, and layout fashion. Small direct effect, though they influence trust when the site looks neglected or amateur.

Measure before you touch anything

This is the step that separates a profitable rebuild from an expensive one, and it takes a few days rather than a few months. Before a single page is designed, write down what the current site does.

Record which pages receive visitors, which pages produce enquiries, and which searches bring people who become customers. Note your current speed on a phone. Save a full list of every page address that exists, because you will need it later. Ask a handful of recent customers what they looked at before contacting you, since they will name things you would never have guessed.

With that record in hand the rebuild becomes a different exercise. You are no longer starting fresh. You are keeping what works, fixing what does not, and you can prove afterwards which it was.

How redesigns lose search visibility, and how to avoid it

The most common technical disaster in a rebuild is the loss of page addresses. The old site had pages at particular web addresses. Search engines learned them, other sites linked to them, and people bookmarked them. The new site uses a different structure, the old addresses stop existing, and everything built up over years is discarded in an afternoon.

The cure is well understood and frequently forgotten. Every old address must point to its closest equivalent on the new site, using a permanent redirect. Not to the homepage, which search engines treat as a soft failure, but to the page that genuinely replaces it.

The second common loss is content. A new site is usually shorter, because shorter feels cleaner. But the paragraphs removed were often the ones answering the specific questions that brought people through search. Before deleting a page, find out whether anybody was arriving on it.

• Export the full list of existing page addresses before the rebuild begins.
• Map each one to its equivalent on the new site, and redirect permanently.
• Keep the pages that produce enquiries, even if they do not fit the new design neatly.
• Keep the detailed content that answers real questions, rather than trimming for tidiness.
• Check after launch that the important pages are still being found, and fix anything that is not.

The case for improving in slices instead

For a great many businesses the honest answer is that a full rebuild is not necessary. The problems are specific, and specific problems can be fixed one at a time, with each change measured before the next begins.

Rewriting the top of the homepage, shortening the contact form, compressing the images, adding proof to the service pages, fixing the behaviour on phones, each of these is a small piece of work with a visible result. Done in sequence, they frequently produce more revenue than a full rebuild, at a fraction of the cost and with none of the risk.

This approach also teaches you something a rebuild never does. Because you change one thing at a time, you learn which changes mattered. That knowledge is worth having when the real rebuild eventually arrives.

When a rebuild genuinely is the right decision

There are situations where patching is money wasted on a foundation that cannot hold. These are the honest reasons to rebuild.

• The site cannot be made fast, because of how it was built or what it depends on.
• The site cannot be updated without paying a developer for every small change.
• It does not work properly on phones, and cannot be made to without rebuilding the structure.
• Search engines and AI assistants cannot read it, usually because the content only appears after code runs.
• The business has changed so much that the site describes something you no longer do.
• It is built on something no longer maintained or secure, which is a risk rather than an inconvenience.

How to run a rebuild without losing the good part

If a rebuild is right, a few habits protect the revenue you already have. None of them are complicated, and skipping them is what produces the horror stories.

Keep the pages that convert, and if they must change, change them one element at a time after launch rather than all at once. Launch with redirects already in place rather than promising to add them later. Watch the enquiry numbers weekly for the first two months, since problems announce themselves there before they appear in any ranking report.

And decide, before you begin, what success will look like. Not a feeling about the design, but a number: enquiries per month, calls, or orders. Written down in advance, so that afterwards there is something to compare against rather than an argument about taste.

How Licheo handles rebuilds

We look at what the current site is doing before proposing to replace any of it, because the fastest revenue often comes from repairs rather than replacement. Where a rebuild is right, the old addresses are mapped and redirected as part of the launch, not afterwards.

The agents then build with the whole revenue chain in mind: message, proof, speed, structure that search engines and AI assistants can read, and a clear next step on every page. Nothing goes live until you have seen it, and the enquiry numbers are watched closely in the weeks that follow.

Every part of this, in detail

Each section below is a full guide of its own, on one specific piece of the problem.

• Do you need one?: Rebuilding is expensive, disruptive, and frequently unnecessary. It is also occasionally the only sensible option. The difference is whether the foundation is the problem or merely the decoration.
• Redesign or repair: Three quite different pieces of work get discussed as though they were one decision. Separating them usually reveals that the cheapest option solves the actual problem.
• Measure first: This is the step that separates a rebuild that earns from one that quietly loses a year of progress, and it takes a few days rather than a few months.
• Keep what converts: Every website has a small number of pages producing most of the enquiries. In a redesign they are usually replaced along with everything else, because nobody had identified them.
• URLs and redirects: This is the single most common way a redesign destroys years of accumulated visibility, and it is entirely preventable with a spreadsheet and an afternoon of attention.
• What not to delete: Redesigns almost always shorten a site, because shorter feels cleaner and modern. The material cut is rarely chosen by evidence, and it frequently includes the specific answers that were bringing people through the door.
• Writing the brief: Most briefs describe pages and features. The ones that produce good websites describe customers, problems and outcomes, and leave the solution to whoever is being paid to design it.
• Timeline: Projects rarely overrun because the building took longer than expected. They overrun because of content, decisions and approvals, which are the parts nobody schedules.
• The launch sequence: Replacing a live website is a small operation with a specific sequence. Done in the right order it takes a morning; done in the wrong order it produces a week of confusing problems.
• After launch: Problems that appear in the first weeks are cheap to fix and easy to trace. The same problems discovered in three months are expensive, and by then nobody remembers what changed.
• Why traffic drops: This is the most common unhappy conversation in website work, and the causes are few enough to work through systematically. Most are recoverable if caught within a couple of months.
• Rebuild in slices: The all-at-once rebuild is the default because it is easier to sell and easier to project-manage. It is also the riskiest, and for many businesses a slower, piece-by-piece approach produces more revenue and fewer disasters.

Questions people ask

Will a website redesign increase my revenue?

Only if it fixes something that was actually costing you money, such as an unclear message, poor behaviour on phones, slow loading, or a structure search engines cannot read. Redesigns driven by taste alone often reduce revenue, because they replace pages that were converting without anybody having identified which ones those were.

Why do businesses lose traffic after a redesign?

Usually because the page addresses changed and were not redirected to their equivalents, so years of accumulated search visibility disappeared at once. The second common cause is deleting detailed content that seemed untidy but was answering the specific questions bringing people from search.

What should I measure before redesigning?

Which pages get visitors, which pages produce enquiries, which searches bring customers, your current speed on a phone, and a complete list of every existing page address. Ask a few recent customers what they read before contacting you, since they always mention something unexpected.

Is it better to fix my site or rebuild it?

Fix it, unless the structure itself is the obstacle. Rebuild when the site cannot be made fast, cannot be updated without a developer, cannot work properly on phones, cannot be read by search engines, or is built on something no longer maintained.

How long until a new site recovers its previous performance?

With redirects in place and the converting pages preserved, disruption is usually brief. Without those two things, recovery can take a long time and is not guaranteed, since the visibility being rebuilt was accumulated over years.

How do I judge whether the redesign worked?

Decide the measure before you start, and make it enquiries, calls, or orders rather than a feeling about the design. Compare against the same period in the previous year where seasonality matters, and give conversion changes a few weeks and visibility changes considerably longer.

Keep reading

• Does your website pay for itself?
• Where websites leak revenue
• Websites that make money
• Technical SEO built in

Rebuild without losing what already works

We measure what your current site is doing first, keep the parts that earn, and build the rest around the revenue chain. Old addresses are redirected as part of the launch, not afterwards.