Direct answer
What to do first
Choose targeted CRO when the evidence points to a bounded, repairable obstacle in a valuable journey: a weak message, a broken form state, a confusing step, or a page-level issue that can be changed safely. Consider a redesign when the constraint is structural—critical journeys cannot be supported by the platform, information architecture has become incoherent, or changes in one area repeatedly break another. Start with a defined outcome, check the measurement, inspect the journey, and state what would change under each option. If a rebuild changes URLs, make the redirect map, testing, monitoring, and search-risk controls a named part of the scope rather than an afterthought.
Start with the decision, not the design mood
‘The website feels dated’ may be a useful prompt to investigate, but it is not yet a commercial case for rebuilding it. A visitor does not experience the site as a design committee does. They arrive with a task: compare an offer, understand a service, find a price signal, request a quote, or complete a purchase. The first job is to identify the task and the point at which it becomes harder than it should be.
Frame the decision around a specific outcome. For example: are qualified visitors reaching the right service page but abandoning the enquiry form, or are they failing to find the relevant service at all? Those are different problems with different scopes. A redesigned homepage will not necessarily repair a form rule buried in a high-intent journey; a button change will not fix a navigation model that repeatedly puts customers in the wrong place.
Write down the observation without smuggling in the diagnosis. ‘Mobile users who begin the quote form are less likely to submit it’ is an observation. ‘The layout is the reason’ is a hypothesis. That distinction stops a team from buying a full visual change when it has not yet established where the commercial constraint sits.
- Name the audience, traffic source, journey, and business outcome under review.
- Describe the observed problem in plain language before proposing a solution.
- Separate what is known from the explanation that still needs checking.
Classify the constraint before choosing the scope
Targeted CRO is appropriate when the evidence points to a contained problem that can be repaired and evaluated in place. That may mean clarifying an offer, correcting a validation error, reducing needless form effort, improving a product-detail decision, or aligning a landing page with the promise that brought the visitor there. The work can still be important; ‘targeted’ describes the scope, not the value of the journey.
A redesign deserves consideration when a critical requirement cannot be supported by the current platform or when the site has become a patchwork that obstructs several journeys. Examples include an information architecture that no longer reflects the offer, a publishing setup that makes necessary content or interaction changes unreliable, or shared patterns that force the same compromise across key pages. NN/g makes the same distinction: isolated issues often suit incremental change, while severely outdated technology or incoherent architecture can justify a larger overhaul [2].
Do not use the label ‘structural’ to make a preference sound inevitable. Ask the technical and commercial owners what the current system prevents, which journeys are affected, what a workaround costs, and what would prove the constraint has been removed. If no one can answer those questions, the honest next scope is investigation.
- Repairable friction is bounded: the affected step, component, or message can be changed without reworking the system around it.
- Structural constraint is connected: a critical journey depends on a platform, content model, navigation pattern, or operating process that cannot reliably meet the requirement.
- Uncertain scope is a discovery problem. Fund the diagnosis before pricing either a rebuild or a list of isolated fixes.
Use the funnel to find a step, not to assign blame
A funnel can focus the review, but it cannot tell you why someone stopped. In GA4, funnel steps are conditions you define. An open funnel lets users enter at any step, while a closed funnel requires entry at the first step; users are counted only when they complete the specified sequence. Those settings can change who appears in a step, so confirm the setup before treating a reported drop-off as evidence against a page [1].
Once the measurement is credible, pair it with direct inspection. Walk the journey as a new visitor would. Check the mobile state, loading behaviour, field rules, error messages, content needed to decide, and handoff after submission. Then compare those observations with the questions sales or support teams hear. The aim is not to collect a long defect list. It is to find the few constraints that materially affect a valuable action.
Illustrative diagnostic, not a client finding: an agency sees paid visitors reach a service page but few proceed to the booking step. The team first checks whether the booking-click event is present and consistently defined. It then finds that mobile visitors must open several dense sections before seeing what the consultation covers. That is evidence of a possible decision barrier, not proof that the page needs a new visual system. The next move could be a focused content and layout change, a research session, or further analysis of source-to-page fit.
- Validate the conversion event and the steps that should lead to it.
- Compare relevant segments, such as traffic source, device, journey type, or customer intent, only where the definitions are consistent.
- Review the journey on the actual devices and conditions that matter, then bring in customer, sales, or support evidence where it can challenge the analytics story.
Compare options by what they actually require
A choice between CRO and redesign often becomes muddled because each option is described at a different level. One proposal names a few page edits; the other promises a new website. Bring them onto the same page. For each option, state the outcome it is meant to support, the evidence behind it, the affected journeys, the systems it touches, the dependencies it creates, and how the team will know whether the change solved the stated problem.
A focused conversion scope should not quietly inherit every visual preference discovered during review. Equally, a redesign scope should not hide measurement, content decisions, redirect handling, or operating ownership behind the word ‘build’. That work may be necessary, but it changes the risk, sequencing, and people required to make the project usable after launch.
The useful comparison is not small project versus big project. It is reversible, bounded change versus coupled change across the site. If the organisation needs a new platform for reasons beyond conversion, say so. Conversion evidence can then shape the priority journeys and acceptance criteria rather than being used to pretend the rebuild is a test.
- For targeted CRO, state the affected journeys, pages or components, evidence to collect, changes in scope, measurement plan, dependencies, and rollback or correction path.
- For a redesign, state the platform and information-architecture decisions, shared components, content migration, analytics continuity, accessibility review, and any URL or redirect work separately.
- For a hybrid approach, fix verified high-intent friction now while discovery establishes whether a structural change is warranted.
If URLs change, treat migration as its own risk
Not every redesign changes URLs, but when it does, the migration is part of the decision—not a technical tidy-up at the end. Google recommends preparing and testing the new site, mapping current URLs to their new destinations, setting server-side permanent redirects where possible, updating internal links and sitemaps, and monitoring traffic on both old and new URLs [3].
Avoid introducing avoidable ambiguity. Google advises changing one thing at a time where practical; it also distinguishes between whole-site and sectional moves based on site size and circumstances [3]. That does not mean every redesign must be slow. It means the team should be able to tell whether a traffic, crawl, or conversion problem came from a URL move, a platform change, a content change, or the redesigned journey itself.
A migration plan should name an owner for the URL map, testing, launch checks, and follow-up monitoring. Google notes that significant moves can bring temporary ranking fluctuation while the new URLs are crawled and indexed, and the timing depends on factors such as site size and server capacity [3]. Build that uncertainty into the operating plan; do not turn it into a prediction of search performance.
- Create a map from every important old URL to its relevant new destination before launch.
- Test redirects, canonical annotations, internal links, crawl access, analytics, and key conversion journeys on the new site.
- Keep the old and new URL sets visible in monitoring so unexpected errors, traffic shifts, and indexation issues can be investigated.
Make the smallest change that can resolve the right problem
The strongest answer is often neither ‘redesign everything’ nor ‘just test it’. It is a clear statement of the constraint, the evidence behind it, and the least disruptive scope that can remove it. That makes it easier to protect high-value journeys, involve the right owners, and avoid paying for changes that look decisive but do not address the customer’s task.
Before committing, write a short decision record. Include the outcome, the affected audience and journey, the observations, the leading explanation, alternatives considered, dependencies, and the evidence you need after release. If that record points to a specific repair, run a focused CRO programme. If it points to platform or architecture limits, redesign with those constraints and migration duties visible from the start.
A fresh interface can be valuable. It just needs a business and user case stronger than internal boredom. Let the evidence set the scope, then judge the finished work against the problem it was funded to solve.
- Choose targeted CRO when the constraint is verified, bounded, and safe to change without remaking the surrounding system.
- Plan a redesign when the evidence shows that critical journeys are limited by shared architecture, platform capability, or a connected content model.
- Pause for discovery when the team has a symptom but cannot yet state the constraint, audience, journey, or acceptance criteria.
Common questions
How do I tell if landing-page CRO is enough?
Start with one meaningful journey and a defined business outcome. If the obstacle is confined to a page, form, message, interaction, or component that can be changed without destabilising the rest of the journey, targeted CRO is usually the cleaner scope. Confirm the observation with tracking, journey review, and customer or operational evidence before naming a cause. If the same constraint appears across journeys because the platform or structure cannot support the required experience, assess redesign scope instead.
When is a redesign more sensible than ongoing CRO?
A broader redesign becomes a serious option when critical requirements cannot be met reliably within the current technology or information architecture, or when prior targeted work has exposed connected constraints across the site. NN/g recommends setting clear goals, using user and conversion evidence, and applying the least amount of change that can solve the problem; a major overhaul is not justified by visual fatigue alone [2].
Will a redesign protect or improve organic search performance?
No. A redesign is not an organic-search safeguard or an automatic gain. If URLs change, treat the work as a site move: map old URLs to relevant new destinations, implement and test redirects, update internal links and sitemaps, and monitor the move. Google notes that significant moves can bring temporary ranking fluctuation while pages are recrawled and reindexed [3].
Sources and context
- [1][GA4] Funnel exploration
Official Google Analytics documentation explaining that funnel results depend on the defined steps, ordered progression, and whether the funnel is open or closed.
- [2]Radical Redesign or Incremental Change?
NN/g guidance on choosing incremental versus radical redesign, including the use of user and conversion evidence and the role of technology or information-architecture constraints.
- [3]How to move a site
Official Google Search Central guidance for URL-changing site moves, including planning, URL mapping, permanent redirects, internal links, sitemaps, testing, and monitoring.
