Testing a Button, Treating an Entire Website Redesign as a Sure Thing
Written by Evren BalPublished Updated · 8 min read
A team can treat a button-copy change as a hypothesis and build a test plan around it. The same team can launch a new website containing hundreds of decisions in a single night.
Should the button say “Get a quote” or “Get your quote now”? Should a form have four fields or six? Digital marketing, CRO, UX, product, and web teams may have an opinion, but they do not treat that opinion as evidence. When possible, they test, measure, and then decide.
Once the work becomes a full redesign, the design, navigation, copy, forms, URL structure, CMS, and measurement setup can all change together over several months. Then the old site is switched off and the new one goes live for everyone.
Our new website is live.
Why are teams that ask “Are we sure this is better?” about a button so much quicker to assume that a new site made up of hundreds of decisions will be better?
💡 TL;DR: Key Takeaways
- The old site may need to be replaced. That does not validate every decision in the new one.
- A website redesign is not one change. It combines design, migration, and business workflows.
- The main approach is to separate changes, define preserved behavior as a contract, and measure each stage against its own outcome.
The old site may be bad. That does not make the new site good
The old site may be slow, difficult to use on mobile, or no longer right for the brand. Publishing may have become painful. Accessibility or security debt may have accumulated. In some cases, replacement is overdue.
But “we need to replace the old site” and “the hundreds of decisions in its replacement are right” are different statements. The first does not prove the second.
The old site's problems are visible and familiar. The new site's problems have not happened yet. A cleaner design, faster technology, and better copy create a reasonable expectation. A reasonable expectation is not evidence.
A website redesign is not one change
Ronny Kohavi and his colleagues' work on large-scale experiments at Microsoft reports that about one third of the ideas tested improved their intended metrics. That does not mean one third of website redesigns succeed. The research covers ideas in Microsoft products and predefined success metrics. It does show that ideas experienced teams consider reasonable often fail to produce the expected result. That is the useful boundary of the paper.
When you change a button, the thing under test is clear. When you replace a site, the visual design may change along with the information architecture, page hierarchy, content, URLs, analytics events, consent behavior, advertising conversions, CRM fields, and integrations.
If form submissions fall, the cause could be the new flow, one extra field, a browser validation bug, a missing conversion event, or a broken CRM connection. Change all of them on the same day and you no longer know where to start. Even if the site performs better, learning which decision helped becomes harder.
A website redesign is therefore as much a migration as a design job. Google recommends avoiding simultaneous changes to elements such as the domain, CMS, and page layout. It also advises teams to test the new site in advance, map old URLs to new ones, and monitor traffic after the move. The official site-move guidance is written for search, but it supports a broader project lesson: diagnosis becomes harder as the number of simultaneous changes grows.
The main approach: progressive redesign
I think the answer starts by treating the site as a sequence of related but separable changes. We can call this progressive redesign.
First separate what actually has to change. Is the CMS no longer adequate? Is the design the problem? Is the information architecture sending people to the wrong place? Is the brand changing? Has the URL structure become a technical constraint? Each may be a valid reason to act. They do not all have to change on the same day.
If the CMS must change, the new platform can first reproduce the current site's important behavior. Once that move is verified, the navigation can change. Important landing pages can follow. Form fields and flow can become another stage.
That sequence will not work in every project. A new backend may not support the old frontend. Two parts of the information architecture may be impossible to separate. A rebrand may not allow two visual identities to coexist. You can still separate what is separable and explain why the rest has to move together.
Define what stays fixed, then sequence what changes
Redesign requirements usually describe what the new site will do. They should also state what must not change in the first stage.
Keep existing URLs when there is no reason to replace them. If they must change, map every important old URL to its new destination in advance. The same user behavior should produce the same analytics event. A successful form submission should create the expected CRM record with the correct source and campaign data.
These should become contracts that can be checked before and after launch. “The form works” is a weak acceptance criterion. “The form returns a successful response, creates one lead with the correct fields in the CRM, and fires the conversion event only after a successful submission” is more useful.
The first success measure for a technical migration is not a higher conversion rate. It is preserving the business behavior the old system already produced. Navigation, page messaging, and form length can then change as separate behavioral decisions.
This separation also makes reversal easier. If the new CMS works but the new navigation does not, you can correct the navigation decision without rolling back the entire migration.
Measure the right thing at each stage
During a technical migration, watch 404 and 5xx errors, crawlability, canonical tags, analytics events, form success rates, and the integrity of CRM records. The aim is continuity, not proof of growth.
For a behavioral change, conversion, task completion, navigation use, or qualified-lead rate may matter. Continue watching guardrail metrics such as organic traffic, error rate, and form delivery.
Not every step needs an A/B test. You do need to retain some ability to understand which change may have produced which result. Campaigns, seasonality, and search-engine reprocessing prevent perfect causal attribution. Recording each stage and its date still reduces uncertainty.
Gradual rollout is a tool, not the model
A canary release exposes a change to a small part of production before expanding it. Google SRE's guidance shows its value in high-traffic services where signals such as error rate or latency appear quickly.
Not every website has those conditions. A low-traffic B2B site may take a long time to produce a meaningful control group. Organic visibility is difficult to split by user percentage. Search engines need time to process URLs, while brand perception and information architecture change more slowly than server errors.
Google's site-move guidance adds an important nuance. It recommends sequencing different kinds of change, yet generally advises moving all URLs at once on small- or medium-sized sites. Larger sites may be able to move section by section.
Progressive redesign separates project decisions. Gradual rollout is one release tool when the technology and measurement make it useful. Sometimes the cost of separating changes will exceed the benefit. The Google Drive and Spotify cases describe how teams can research and manage user reactions to major interface changes. My takeaway is not to treat the first reaction as a lasting verdict on quality. The job is to make visible which uncertainties you are carrying together and why.
What should you do tomorrow morning?
Before writing a more detailed feature list for the new site, break the project down in a table like this:
| Area | First decision | Contract to preserve | How to verify |
|---|---|---|---|
| CMS and infrastructure | Must it change? | Important URLs and content remain intact. Forms and measurement behave as before. | Compare crawls, inspect errors, and test forms and events. |
| URLs and content | Do they really need to change? | Each important old URL remains or redirects to a meaningful replacement. | Check URL mapping, status codes, canonical tags, and internal links. |
| Navigation and design | Which business outcome should change? | Important content, actions, and measurement points do not disappear. | Measure task completion, conversion, organic traffic, and accessibility. |
| Forms, measurement, and CRM | Why should they change in the first stage? | A successful submission creates one business record with the correct fields. | Run end-to-end submissions and check CRM, error, and success records. |
Put every row into one of three groups: must change now, preserve in the first stage, or test later. Then record the baseline, acceptance criterion, and stop condition for each stage. Move forward because the previous stage preserved its contracts, not because the next date has arrived.
The site may be ready. That is not evidence that it is better. The launch meeting needs two more questions:
Which change are we releasing?
Do the behaviors that should remain unchanged still work?
If this article was useful
Linking to it from a relevant page on your website or sharing it on social media genuinely helps it reach more people. Thank you for your support.
Linking and brand guidelines →About this article
- Use of artificial intelligence
- AI-assisted — The idea, central argument, and intended meaning of this article were provided by Evren Bal. AI-assisted tools were used to verify Google's official site-migration guidance, support the editorial rewrite, and prepare the English translation.
Change history
- · Substantive update — Reframed the main approach as progressive redesign and brought migration, preserved contracts, measurement, and practical next steps into one tighter sequence.
