CRO testing after a redesign: prove it, then reset the target

Stage eight of eight. The question it answers: how will we know, with data, that any of this worked?

A digital lead evaluating agencies asked for a simple thing: for the last couple of redesigns you did, show us the goal you set and the performance afterward. It is the right question. It is also the one most agencies cannot answer, not because the redesigns failed but because nobody wrote the goal down in a form that could be read again, and nobody instrumented the site so the reading would be trustworthy.

We have been on the receiving end of that question and it is uncomfortable. The honest response is that proof is a stage, not a report, and it starts eight stages earlier.

Proof is only possible if the target was set

Stage eight reads the numbers stage one wrote down. If stage one produced a baseline with definitions, sources, a trust check, and an owner per metric, the proof stage has something to validate. If stage one produced adjectives, the proof stage produces opinions.

This is why the framework is drawn as a loop between the first and last stages. On a London university's program, the baseline was rebuilt before anything else because the reported numbers were inflated by non-human traffic and the tracking had gaps. Only once the baseline was honest could a post-launch program be designed to move it. The board package that funded the redesign included the day-one targets and a three-month optimization program precisely so that the proof would have terms.

Test the journeys the redesign changed, not everything

A redesign changes some journeys structurally and leaves others alone. Conversion rate optimization testing after launch has to respect that line, or every movement on the site gets credited to or blamed on the new design.

The baseline from stage one recorded which funnels the redesign would change. Those are the journeys the A/B testing program targets first: the growth audience's entry path, the restructured navigation, the location step for a multi-location business. The funnels the redesign did not touch belong to the internal team's ongoing program, and their movement is context, not proof.

On a certification body's program the conversion baseline was separated per funnel for this reason. A structural change to the learning journey should register in the learning funnel and nowhere else. If it registers everywhere, something other than the redesign moved, and the proof stage has to say so.

Test hypothesis card for conversion rate optimization testing: the journey changed, the baseline metric, the hypothesis, the variant, the success threshold, the duration, and the decision it informs.

Usability testing answers the question A/B testing cannot

A/B testing on a website tells you which variant moved a number. It does not tell you why, and it cannot run on the parts of the site with too little traffic to reach significance, which for a multi-location brand is most location pages.

Usability testing fills the gap. Tasks are drawn from the journeys mapped in stage three: find the right product for this problem, find the nearest location, start an enquiry as a professional. Participants are recruited per audience, the way the research was. The measures are comprehension, navigability, and findability against the structure derived in stage four. On the certification body's program the client's own team asked for a usability layer as external feedback from selected stakeholders, and quick-turn testing per region was planned to check comprehension and findability and refine the information architecture. Heat-map review of the rebuilt pages sits alongside, showing where attention pools and where it dies.

Plan for the dip, and say so before launch

Most relaunches see traditional search visibility fall before it recovers. Redirects settle, search engines re-crawl a new structure, and rankings that depended on the old URLs take time to transfer. A proof stage that does not plan for this will report failure in month one and success in month four, and lose its audience in between.

On the certification body's program the expectation was set explicitly in discovery: traditional visibility would dip after launch with a projected recovery, and the AI-readiness gaps would be worked ahead of release so the dip was not compounded. That is the shape of honest expectation-setting. Name the dip, estimate its duration, list the mitigations already in place, and agree the date on which the proof will actually be read.

Run proof in cycles, not as a report

The post-launch program on the university project was structured in three-month cycles: test, read, decide, repeat. The first cycle validates the day-one targets and the journeys the redesign changed. The second cycle tests what the first revealed. By the third, the program has become the internal team's ongoing conversion work, running on a structure and a baseline worth optimizing.

That handover is the point. The proof stage is where the redesign's temporary team leaves and the client's permanent team takes over, and it only works if what they inherit is instrumented, baselined, and drawn.

Post-launch proof in three-month cycles: validate day-one targets, test the changed journeys, read against the baseline, decide, and hand the program to the internal team.

A validated result resets the target

When a cycle validates a result against the baseline, the redesign is not finished. The target is. A validated number becomes the new baseline, the ambition is restated against it, and the eight stages run again from the top, faster this time because the audiences, journeys, structure, and system are already in place. What remains is the two continuous programs, discoverability and conversion, and a better starting point.

That is the honest answer to "here was the goal, here was performance after." Not a slide with a percentage. A baseline, a program, a reading on an agreed date, and a new target.

What the proof stage hands over

The validation report: each baseline metric, its read on the agreed date, and the journeys the redesign changed versus the ones it did not.
Test hypothesis cards and results for the changed journeys.
Usability test findings per audience against the stage-three tasks.
Heat-map review of the rebuilt pages.
The dip plan: expected duration, mitigations, and the reading date.
The cycle calendar and the handover to the internal program.
The reset target for the next pass.

What breaks when the stage is skipped

Nobody can answer the question the next evaluation will ask.

Everything that moved gets attributed to the redesign, including what the internal team did and what the market did.

The dip is reported as failure, and the program loses its sponsor before recovery.

The agency leaves, the internal team inherits pages, and the redesign's structure is optimized away within a year.

Where this sits in the sequence

Stage eight closes the loop to stage one and depends on stage six for the instrumentation and stage three for the tasks. It hands the internal team the two continuous programs, and it hands the business a reset target for the next pass through the eight stages.

Questions we get asked about conversion rate optimization testing

How do you prove a website redesign worked?

By reading the baseline set before the redesign, on an agreed date, for the journeys the redesign changed. If the baseline was never set or the tracking was never trusted, it cannot be proven, and the honest thing is to say so and set the baseline now for the next cycle.

What should you A/B test after a redesign?

The journeys the redesign changed structurally, first. The growth audience's entry path, the restructured navigation, the steps that were untracked before. Leave the funnels the redesign did not touch to the ongoing program, and treat their movement as context.

When should usability testing happen?

Before launch, on the prototype, against the tasks from the journey stage; and after launch, on the live site, where traffic is too low for A/B tests to reach significance. For a multi-location brand that is most location pages.

Why does search visibility drop after a redesign, and how long does it last?

Redirects settle, the new structure is re-crawled, and rankings tied to old URLs transfer over time. The duration depends on the size of the estate and how well the redirect map was done in the structure stage. Plan for it, name it before launch, and agree the date the proof will actually be read.

Conversion Rate Optimization Testing After Launch: Prove The Redesign, Then Reset The Target