A data-driven redesign starts with the problem the website needs to solve. Search data, analytics, user feedback and technical checks help a team decide what to change, what to keep and how to measure the result. They do not remove uncertainty or guarantee better rankings, more leads or higher revenue.

Key takeaways

  • Agree the business and user problem before choosing a visual direction.
  • Use each data source for the question it can answer. Search Console measures Google Search performance, while analytics and user research help assess journeys and key actions.
  • Record a baseline, prioritised scope, owners and acceptance criteria before development.
  • Protect useful URLs and content during a migration, then monitor for errors and search fluctuations after launch.
  • Use a suitable testing method to compare design alternatives. Search Console is not an A/B testing tool.

What a data-driven redesign means

Data should help the team make and test decisions. It is not a substitute for judgement. A metric can show where a problem may exist, but it rarely explains the cause on its own.

For example, a page with many impressions and few clicks may have a title that does not match the query, a result feature that takes attention, or an audience that is not looking for the offer. Check the query, page, search result and business context before deciding what to change.

The same principle applies to website analytics. A drop-off in a form may point to unclear questions, a technical error, low-intent traffic or a tracking problem. Test the form and speak with users before treating one chart as a complete diagnosis.

Start with a baseline

Write down the problem, who experiences it and what evidence would show improvement. Record the date range and any limits in the data. If the website has seasonal demand or a recent campaign, note that too. A simple before-and-after comparison can otherwise confuse a redesign effect with a change in demand.

Use sources that answer different questions:

  • Google Search Console shows how the site performs in Google Search. Its Performance report includes clicks, impressions, click-through rate, average position and query or page views. Average position is an aggregate metric, not a fixed rank for every searcher. Search Console does not report competitor rankings, on-site behaviour or business conversions.
  • Web analytics can help assess traffic sources, page journeys and configured business actions such as form submissions. Define the events you need and check that they are recorded correctly. Handle analytics and personal data according to the organisation’s approved privacy and consent requirements.
  • User evidence can come from interviews, support enquiries, usability sessions, accessibility checks and feedback from sales or service teams. These sources help explain why a journey is difficult, but a small sample may not represent every audience.
  • Technical checks should cover crawlability, indexation, page speed, mobile behaviour, accessibility, security, integrations and content-management constraints.

Keep the baseline focused on the decisions the project needs to make. More dashboards do not automatically produce better decisions.

Turn evidence into a scoped plan

Create a list of problems and opportunities. For each item, record the evidence, affected users, business impact, proposed response, dependencies, owner and a way to verify completion. Separate confirmed defects from hypotheses that still need testing.

Prioritise work by user need, business importance, risk and effort. Do not add a feature solely because a competitor has it or a stakeholder prefers it. Confirm that it solves a real task and fits the organisation’s operating model.

Before design or development begins, document:

  • the pages, templates, content and integrations in scope;
  • the work that is excluded or depends on another supplier;
  • who approves content, design, access and launch;
  • how accessibility, performance, security and SEO will be tested;
  • who owns domains, hosting, analytics, licences and source files; and
  • acceptance criteria for each deliverable.

This gives the team a shared reference when priorities change or new requests appear.

Use research to shape content and design

Map the main audiences to the tasks they need to complete. Then organise navigation and page content around those tasks, using terms visitors understand. Internal departments and campaign names may not be useful navigation labels.

Review high-value pages, search queries, internal links and existing content before removing or combining URLs. Sketch page structure and test important tasks with representative users. A prototype can expose unclear labels or missing information before the team commits to a full build.

Treat design ideas as hypotheses. State what the change is expected to improve and how you will check it. A clearer call to action may improve task completion, but the outcome depends on the audience, offer, traffic and implementation.

Plan the SEO migration

Keep existing URLs where there is no good reason to change them. If routes must change, build a URL map from each old page to its closest relevant new destination. Configure permanent redirects, update internal links and canonical references, publish an accurate sitemap, and check that important pages can be crawled and indexed.

Do not send many unrelated old URLs to the homepage. Do not assume that submitting a sitemap will make every page appear immediately. Google says that significant moves can cause temporary ranking fluctuations while it recrawls and reindexes pages, and processing time varies with the number of URLs and server capacity.

Test the new site before launch. After launch, inspect representative URLs, redirects, canonicals, robots directives, sitemap entries, analytics events and key user journeys. Use Search Console and analytics together because they answer different questions. For a detailed post-launch checklist, see Ulement’s post-migration SEO audit guide.

Test changes with the right method

Search Console can compare search performance across date ranges, pages, queries and other dimensions. It cannot isolate the effect of a design change from seasonality, campaigns, algorithm changes or other concurrent work. Do not describe a pre- and post-launch comparison as an A/B test.

For an A/B test, use a testing method that assigns comparable users to variants and measures a defined outcome, such as a completed enquiry. Choose a test duration and sample size that suit the traffic and conversion rate. Follow Google’s testing guidance: do not show different content to Googlebot and users, and remove test variants and scripts when the experiment ends.

Some redesigns are too large or interconnected for a clean A/B test. In that case, combine a documented baseline with usability checks, quality assurance, staged releases where practical, and post-launch monitoring. Record other changes that could affect the result.

Review after launch

Check the technical launch first: redirects, server responses, canonical URLs, indexability, sitemap processing, key templates, forms and tracking. Then compare results with the baseline over a period that reflects the site’s traffic and demand cycle.

Use Search Console to investigate changes in Google Search clicks, impressions, CTR, queries and pages. Use analytics to assess configured key events and user journeys. Investigate specific URLs and queries rather than reacting to one site-wide number. Fix confirmed faults first, then decide whether content or design needs further work.

No reporting schedule can prevent ranking changes or guarantee a recovery timeline. Assign an owner to review the evidence, keep a record of fixes and agree when a result is meaningful enough to change direction.

Common mistakes

Letting the highest-paid opinion decide

Senior stakeholders have important context, but personal preference alone is not evidence. Make the decision criteria visible and record why a change is being proposed.

Treating metrics as explanations

Clicks, bounce rates and conversion counts describe observed activity. They do not automatically explain user intent or cause. Check tracking quality and use research to interpret the numbers.

Copying competitor features

A feature may depend on another company’s audience, processes or technology. Validate the need in your own context before adding its cost and maintenance burden.

Treating a redesign as a ranking guarantee

Good migration planning can reduce avoidable risk. It cannot guarantee unchanged rankings, traffic or lead volume. Search systems and user demand can change independently of the project.

Conclusion

A useful redesign plan connects user needs, business priorities, technical requirements and measurable checks. Agree the problem and baseline first. Put scope, ownership and acceptance criteria in writing. Then design, test, migrate and review against evidence without promising an outcome the data cannot guarantee.

For the delivery stages and planning dependencies, see Ulement’s website design project timeline.

Frequently asked questions

How do I know whether a redesign is justified?

Start with a defined user or business problem, then check whether the current site is contributing to it. A visual refresh alone may not require a full rebuild.

What should I measure before a redesign?

Choose measures that match the problem. This may include Search Console clicks and impressions, relevant analytics events, task completion, support enquiries, accessibility findings or technical errors. Record how each measure is collected.

Can a redesign preserve all search rankings?

No one can guarantee that. URL mapping, relevant redirects, accurate canonicals, crawlable pages and careful monitoring reduce avoidable migration errors, but Google may recrawl and reprocess pages over time and rankings can fluctuate.

Can Search Console run an A/B test?

No. Search Console reports search performance. Use an experimentation tool or a suitable testing method to compare user behaviour across variants.

Sources checked on 20 October 2026: Google Search Console documentation on performance reports, clicks, impressions and average position, website testing in Search and site moves with URL changes; Google Analytics documentation on key events and conversions.