Como proteger a conversão durante o redesenho de um site

The short version: most redesigns do not fail because the new site looks worse. They fail because nobody measured what the old one was actually doing before it got replaced. Baseline first, change one thing at a time, protect what already converts, and watch the weeks after launch as closely as the weeks before it.

Let me tell you why I get nervous every time a client says the word "redesign," because the instinct that follows is almost always the wrong one.

Why do most redesigns lose ground instead of gaining it?

Here is the uncomfortable part. Research from Info-Tech Research Group's SoftwareReviews division found that 80 percent of website redesigns fail to reach their full potential, undone by a gap between what the business built and what the visitor actually needed (SoftwareReviews via PR Newswire, to re-verify). That is not a fringe outcome. That is the norm.

The clearest public case I know of is Marks & Spencer. In February 2014 the retailer launched a redesign that took roughly three years and around £150 million to build. Online sales dropped 8.1 percent in the quarter right after launch, and only half of its six million registered customers had bothered to re-register on the new site (IEEE Spectrum, to re-verify). Money and time were not the problem. The site simply asked existing customers to start over, and changed enough at once that nobody could say afterward which decision caused which loss.

That is the pattern I want you to notice. It is rarely one catastrophic choice. It is a stack of untested changes launched together, so when the number moves, nobody can point to why.

What should you actually measure before you touch anything?

You cannot protect what you never measured. Before a single pixel changes, I want a clean baseline, held steady long enough to trust it.

That means, per page and per key flow, at least four to six weeks of:

• Conversion rate, and the rate for each meaningful step inside the funnel, not just the final one.
• Traffic by source, so you know which channels are sending the visitors who currently convert.
• Load time, on the real devices your visitors actually use.
• Search visibility and indexed URLs, so you have a map of what currently ranks and gets found.
• The handful of top-performing pages, ranked by revenue or leads, not by opinion.

Write this down. Put a date on it. This document becomes the only honest judge of whether the redesign worked, and without it, every conversation after launch turns into a guess dressed up as a debate.

Why is changing everything at once the riskiest move you can make?

Because it destroys your ability to learn. If you swap the layout, the copy, the checkout flow, and the hosting platform in the same release, and conversion drops, you now have four suspects and no evidence. If it rises, you still do not know which change earned it, so you cannot repeat the win on the next page.

A redesign is not one decision. It is dozens of decisions, wearing one coat. Split them, ship them in a sequence you can observe, and you keep the one thing a big-bang launch throws away: the ability to say, with evidence, what actually worked.

What already works, and how do you make sure it survives?

Before anyone touches a wireframe, I want a short, ranked list of what the current site is quietly getting right. In my experience this is the single most skipped step, because a redesign project is emotionally about the new thing, and nobody wants to spend the kickoff meeting admiring the old one.

Look for:

• The two or three pages carrying a disproportionate share of revenue or leads. Protect their structure and their message even if their visual style changes.
• The specific phrases in your highest-converting copy. A headline that converts is a business asset, not a placeholder for a copywriter to improve on instinct.
• The flow with the fewest steps to your best outcome. Simplicity that already works is not the same as simplicity that looks dated. Do not confuse the two.
• Any trust element (reviews, case studies, credentials) sitting near your highest-intent moments. These get dropped constantly in visual refreshes, and their absence is rarely blamed correctly afterward.

Carry this list into every design review as a checklist of things that need a deliberate reason to change, not a default assumption that everything old is a problem.

How do you roll out a redesign without flying blind?

Stage it. A full replacement launched on one day, to every visitor, with no prior exposure, is the highest-risk version of this project you can run, and it is also the version most agencies default to because it is easiest to schedule.

The alternative is a rollout you can watch as it happens:

1. Ship structure and technical foundations first, separately from the visual redesign. Confirm nothing broke before you add anything new for a visitor to react to.
2. Roll out by segment or by traffic share. Show the new experience to ten percent of visitors, or one channel, before it reaches everyone. Watch the metrics on that slice before you widen it.
3. Swap component by component where the platform allows it: the hero, then the pricing block, then the form, each held against the baseline before the next one ships.
4. Run a genuine test, not a preview. A design review in a meeting room tells you what stakeholders think. Only live behavior tells you what visitors do.

Booking.com is the extreme, useful example here. At any given moment it is reportedly running more than a thousand live experiments on its own booking page, and the company has kept its internal experimentation framework, built by its own engineers, largely intact since the mid-2000s rather than replacing it wholesale (Silicon Canals, to re-verify). Its own leadership has said that even a proposed new logo does not get adopted on authority alone. It gets tested first. You do not need a thousand experiments to borrow the principle: nothing large ships to everyone before it has proven itself to someone.

What causes the post-launch dip, and how long should it last?

Almost every redesign sees some dip immediately after launch. The question that matters is whether it is a shallow, explainable dip that recovers in days, or a deep one still bleeding months later. Five causes explain most of what I see.

Lost URLs and broken redirects. Change your URL structure without a complete redirect map, and you lose both visitors and the search ranking those pages had earned. One widely cited breakdown of a single 2016 redirect case found a consistent traffic loss on the redirected page, with no recovery months on (via Ann Smarty, directional, to re-verify). At a larger scale, a 2026 analysis of 1,052 domain migrations found that only about 27 percent recovered their organic traffic within 90 days (SALT.agency, to re-verify). Every old URL needs a mapped destination before launch, not a best effort afterward.

Changed messaging. A headline that converted was doing real work, even if nobody could say exactly why. Replace it with fresher copy that has never been tested, and you are trading a known asset for an unknown one, on launch day, with no fallback.

New friction. An extra click, a longer form, a login wall the old site never had. Each addition looks small in a design review and adds up in a funnel.

Speed regressions. New frameworks, heavier imagery, and video backgrounds add weight fast, and speed is not a cosmetic detail. A Google and Deloitte study of 37 major retail, travel, and luxury sites across more than 30 million sessions found that even a 0.1 second improvement in mobile load time lifted retail conversion by 8.4 percent and average order value by 9.2 percent (Think with Google, to re-verify). Run that logic in reverse and a redesign that quietly adds half a second is not a neutral trade. It is a cost.

Broken tracking. If your analytics and conversion events do not survive the migration intact, you will not see a dip. You will see nothing, which is worse, because you cannot fix what you cannot measure. Confirm every event fires correctly before launch, not after someone asks why the dashboard looks strange.

The redesign protection checklist

Before

• Capture a 4 to 6 week baseline for conversion, traffic, speed, and rankings (without it, nothing after launch can be judged)
• Rank your current top-performing pages and phrases (these get a deliberate reason to change, not a default one)
• Build a complete URL redirect map (the single most common cause of post-launch traffic loss)
• Confirm every analytics and conversion event on the new build (you cannot see a problem your tracking cannot report)

During

• Stage the rollout by segment, section, or traffic share (keeps the change observable instead of all-or-nothing)
• Hold new copy and layout against the baseline before widening exposure (protects a working asset from being replaced sight unseen)

At launch

• Watch speed on real mid-range devices, not just a lab test (small regressions carry a measurable conversion cost)

After

• Compare week one and week four against baseline, not against hope (the dip that matters is the one still there in week four)
• Investigate any drop against the five usual causes before touching the design again (most dips are fixable faults, not proof the redesign failed)

The routine I run on every redesign

1. Freeze a baseline. Four to six weeks, every metric that matters, dated.
2. List what already works, ranked, before anyone designs anything new.
3. Map every existing URL to its destination, with no exceptions.
4. Stage the release. Segment, section, or component, never everything at once to everyone.
5. Hold each stage against the baseline before widening it.
6. Watch speed and tracking as closely as you watch the visual result.
7. Give the launch a defined window, then compare against baseline, not against feeling.

None of this slows a redesign down as much as people fear. It slows down the part that was going to fail anyway, and it is precisely the discipline that comes from treating optimization, visibility, and conversion as one system instead of three separate handoffs, each blaming the other when the number moves.