Why Does Your Redesign Convert Worse Than the Page It Replaced?

The new site launched on a Tuesday. It photographs well, the review call was unanimous, and the team is proud of it. Three weeks later enquiries are down, and nobody can say which of the two hundred changes did it. That is the ordinary shape of a redesign conversion drop, and it is almost never a question of taste.

Redesigns rarely fail because the new design is uglier. They fail because a redesign is a hundred changes shipped on a single day, and four or five of them quietly took away something visitors were relying on. The bundle is the problem. When everything moves at once nothing can be attributed, so the discussion defaults to opinion, and the person with the strongest opinion wins it.

The job is to decompose the bundle. Four causes cover most of what we find: content that was removed, labels and paths that lost their meaning, a page that got heavier, and controls nobody recognises. Work them in that order. The first two are cheap to reverse, and they are guilty far more often than the conversion work that usually gets commissioned once the number has already moved.

Check the measurement before you check the design

A good share of the redesign drops we are asked to look at turn out to be partly an artefact of counting. A new build ships a new analytics implementation, a new consent banner, a new form endpoint, and a tag that fires on a route change the new router no longer emits. The number falls because the measurement changed, not because the page did.

Spend an hour here before anything else, because a real drop and a phantom drop look identical in a dashboard. Submit the form yourself and follow the record all the way to the place it is supposed to arrive. Confirm the thank-you page still fires the event and has not quietly become a client-side state change that produces no page view at all. Then compare like with like on dates: same weekdays, same paid spend, same mix of sources. A launch that happened to coincide with the end of a campaign is not a design failure.

The content you removed was doing work

Start with content, because it is the most common real cause and the least interesting thing to talk about in a design review. The old page had grown over four years. It was cluttered, repetitive and visually tired. It also answered, somewhere in that clutter, the six objections that stop people enquiring. The redesign tidied it up. Tidier meant shorter, and shorter meant some of those answers are now gone.

Nobody removes them on purpose. They fall out of a layout with three cards where the old page had nine paragraphs, or a hero that replaced a plain list of what you do with one sentence about who you are. The visitor who needed the fifth paragraph does not write in to complain. They leave without ever telling you what was missing.

• The specifics. The old page named the services, the formats, the scope and what sits outside it. The new one says you are a partner in growth. Only one of those answers a buying question.
• The operational facts. Turnaround, what happens after a form is sent, who replies, what a first conversation covers. Dull information that removes the risk of starting.
• The long tail of questions. An FAQ block dropped because it did not suit the new grid. Those questions were being asked, which is why somebody wrote them down in the first place.
• The second route. A page that offered two ways to make contact now offers one, and the one it kept is the one with the longest form.
• Internal links to the pages that convert. The old sidebar linked to eleven service pages. The new template has room for three, and eight pages lost most of their entrances overnight.

Restoring any of this is only cheap if an editor can do it. If putting a paragraph back means a ticket, a sprint and a release, it will not be put back, and the redesign keeps the loss permanently. That is the practical argument for a content workspace over hardcoded page copy: a tool like Acrosite generates the required files, commits them to GitHub and triggers the configured deployment, so the person who noticed the missing paragraph is also the person who can put it back that afternoon.

Information scent: the labels and paths that stopped meaning anything

Information scent is the smell of the right path: how confidently somebody can tell, from a link alone, that clicking it moves them closer to the thing they came for. Redesigns damage it routinely, and almost always while making the navigation look tidier.

The labels you renamed

"Services" became "What we do". "Pricing" became "Plans". "Contact" became "Say hello". Every rename passed the brand review, and every one of them costs a slice of the people who were scanning for the old word. Scanning is not reading. Somebody arriving with a task runs an eye down the header looking for a token match, and a clever label does not match.

The test is unglamorous and takes an afternoon. Show five people who have never seen the site a screenshot of the header, give them a task in their own words, and ask which link they would click. If two hesitate, the label is wrong however well it reads in the brand document. Naming rules only hold when they are written down and reused, which is one of the arguments for a design system that covers language and not only components.

The paths that changed underneath

Then there are the URLs. A redesign is also a migration, and a migration without a redirect map loses the pages people had bookmarked, the pages that already earned their entries, and the deep links inside every campaign you ever ran. It presents as a conversion problem, because arrivals land on a generic page instead of the specific one they were promised, and a generic page converts worse than the page it replaced. Check the map against a crawl of the old site before anybody argues about a button colour.

Depth matters as much as naming. The old homepage linked straight through to eleven service pages. The new one hides them behind a menu that opens on hover, and hover does not exist on a phone. Half the audience has lost the map, which is the sense in which mobile first is not a layout decision so much as a decision about what people can still reach.

The new page is prettier and heavier

Design directions have weights. A full-bleed video hero, a scroll-linked animation, a type family in five weights and a card grid that renders on the client all arrived on the same day, and every one of them pushes back the moment the page becomes usable. Speed is not a workstream running alongside design. It is a consequence of design decisions taken in a tool that has no network and no cheap Android phone.

Two measures carry most of the meaning on a page whose only job is to start a conversation: when the largest thing in the viewport finishes painting, and how long the page takes to answer the first tap. Largest Contentful Paint and interaction latency are not vanity numbers here. Somebody who taps a field and waits does not think "this site is slow". They think "this is not working", and they go back to the results page they came from.

What usually did it

• Hero media that loads before everything else and is purely decorative.
• Fonts requested in more weights than the design actually uses, with no fallback behaviour while they load.
• Above-the-fold content rendered on the client, so the first paint is an empty shell.
• Third-party scripts added back one at a time after launch, each by a different team, none of them reviewed together.
• Images shipped at their design dimensions rather than their display dimensions.

Here is the honest concession. Weight is rarely the whole story, and we have seen redesigns that got measurably faster and still converted worse. Treat it as a multiplier on the other three causes rather than a cause in its own right: a slow page makes a confusing path unbearable, and a fast one buys patience for a layout somebody is still learning. Fix it because it is fixable and cheap, not because it will explain the drop on its own.

Controls that nobody recognises

The fourth cause is the one designers defend hardest. A custom select that looks like a text field. A slider standing in for a number input. A multi-step form that hides how long it is. A card that is clickable but does not look it, sitting next to a card that looks clickable and is not.

Novelty in a control is a tax charged to every visitor and paid first by the least confident ones. The safest interface is ordinary in its mechanism and distinctive on its surface: standard controls, standard keyboard behaviour, visible focus, dressed in your own typography and colour. To find out how much novelty shipped, put the mouse away and try to complete your own primary action. What a keyboard user experiences on the new build is the fastest audit in this article, and it needs no tooling at all.

The form is where it shows up

Most redesign losses are collected at the form, because the form is where every earlier doubt is finally charged. Fields get added because a stakeholder asked. Required markers move. Validation turns eager and starts objecting before anyone has finished typing. Error text that used to say what to do now says "invalid input". Our parent company has written about treating a form as a triage instrument rather than a data-collection exercise, and that is the right frame: each new field has to earn its place against the enquiries it costs.

Check the screens either side of the happy path too. The zero-results state, the validation state, the submitted state, the state where something is temporarily unavailable. These get skipped in design review because they never make it into the deck. Empty states are the most neglected screen in almost every build, and they are exactly where an uncertain visitor decides to stop.

The parity check to run before you launch

All of this is far cheaper before launch. A parity check is a short, boring pass that asks one question: does the new page still do everything the old page did? Not look like it did. Do it. That work belongs inside product design rather than in QA, because everything it surfaces is a design decision somebody has to own.

1. Inventory the old pages. List every distinct piece of information and every outbound link on the twenty pages that produce enquiries, not the twenty with the most traffic. Twenty pages is one morning of work.
2. Mark each item kept, moved or dropped. Dropping things is allowed. Dropping them without anyone noticing is not. Every deletion gets a named person against it.
3. Map every URL, one to one. Old address to new address, never many-to-homepage. Test the map against a crawl of the live site rather than the sitemap you meant to publish.
4. Run the same task with five people on both builds. Identical wording, old build first for half of them. You are watching for hesitation and back-tracking, not collecting opinions about the visuals.
5. Measure on a real device on a real network. A throttled profile on a developer laptop is a starting point. A mid-range phone on mobile data is the evidence.
6. Confirm the old build is still deployable. Whatever your hosting calls it, prove you can put the previous version back and that forms, DNS and analytics all still work when you do.

If the launch has already happened, the same evidence reads backwards. Symptoms point at causes reliably enough to save you a fortnight of guessing.

Rolling back without pretending it did not happen

Most teams cannot roll back, which is precisely why they argue instead. If the only two options on the table are "keep the new site" or "rebuild the old one", the conversation stops being diagnostic and turns political within a week. Decide the rule before launch, while nobody is defensive and nobody has anything to protect.

A workable rule has three parts: a metric, a threshold set in advance, and a window. Something like: if completed enquiries across the top five pages sit below the pre-launch band for two consecutive weeks on comparable traffic, the previous build goes back up while the cause is found. Write it down and get it agreed by the people who will be tempted to renegotiate it. A rollback rule agreed in advance is not pessimism. It is the thing that lets you ship without hedging the design.

A redesign you cannot undo is not a launch. It is a bet, and it gets settled by whoever argues longest.

Where we would start on Monday

If the drop is already live, take it in this order. Rule out measurement in an hour. Put removed content back within a day, because it is reversible and costs nothing to test. Repair the redirect map next, because that damage compounds while you deliberate. Only then open the argument about the design, and open it with evidence rather than preference.

There is one case where this advice reverses. If the redesign deliberately narrowed who you speak to, then fewer enquiries is the intended outcome, and the number to watch is not how many arrive but how many you accept. A positioning change carried through the site should be judged on what turns up rather than how much, and three weeks is nowhere near long enough to read it. That is also the argument for running the brand work and the build together instead of in sequence, which our parent company sets out in when brand and build run together.

The pattern underneath all four causes is the same one. A redesign is judged in a room, by people who already know what the company does, on a large screen with a fast connection, looking at a page they have now seen forty times. The visitor is none of those things. Build the check that stands in for them, run it before you launch, and keep the previous build one command away. If the number has already moved and you want a second read on which of the four is doing it, tell us what changed and what you can still measure.