Redesigning a Site Without Losing Traffic: Stages, Risks and the SEO Migration Checklist

Five cases where a redesign is the wrong answer

Let us start by disqualifying some readers, deliberately: a redesign is an expensive instrument, and applying it to a problem it does not solve costs both the money and six months. Case one is "not enough leads" on low traffic. If three hundred people a month reach the site, design is not the issue: even a perfect page converting at 5 percent yields fifteen leads. The work belongs in acquisition channels rather than layouts, and a redesign only postpones that conversation by a quarter.

Case two is "the site looks dated" with not one number behind the phrase. Dated to whom? Your audience visits every few months and does not compare you against trends, unlike you, who look at it daily. The check takes an hour: open your analytics and see whether behaviour metrics differ from last year, whether bounce is rising, whether the mobile share shifted. If nothing changed, you are dealing with a team tired of its own product rather than a user problem.

Case three is weak conversion with high bounce specifically from ads. If organic converts acceptably while paid traffic leaves on the first screen, the problem is almost certainly a mismatch between the ad and the page: somebody clicked one promise and saw another. That is fixed with copy and page structure in a week, not with a quarter-long redesign. Case four is a slow site. Speed is fixed by optimisation: images, fonts, scripts, caching, server response. A redesign on the same platform often makes it worse, because it layers animation and heavy graphics on top of the old problems.

Case five is content that does not answer the customer questions. No prices, no delivery terms, no responses to objections, no proof. A new design of the same content gives you a beautifully presented absence of information. Reworking copy and structure costs 10 to 20 percent of a redesign budget and almost always produces a bigger lift. The correct sequence is: measure first, fix the cheap things second, and only touch the design if the problem survives both.

• Few leads on under a thousand visitors a month is a channel problem, not a design one.
• "Dated" with no metric movement is team fatigue, not an audience problem.
• Bounce only from ads means an ad-to-page mismatch, fixable in a week.
• A slow site is fixed by optimisation. A redesign more often worsens speed than improves it.

The real triggers: when a redesign is genuinely needed

The first and weightiest trigger is conversion falling on stable or growing traffic. Check it by segment: devices, sources, key sections, new versus returning. If the decline is even across every cut, has lasted more than a quarter, and neither campaigns nor prices changed, that genuinely signals a site that has stopped coping. If the decline is localised, say only on mobile in the catalogue, that is a defect in one template and is cheaper to fix in place.

The second trigger is structural mobile-first problems. Not "it is awkward on a phone" but "seventy percent of the audience is mobile and the site was designed for desktop and adapted afterwards". The symptoms: horizontal scrolling, controls smaller than a fingertip, catalogue filters that cannot be operated, forms with fields demanding precise taps. That usually is not adapted but rebuilt, because retrofitting a desktop layout to mobile produces a compromise that is bad in both scenarios.

The third is speed bottlenecked by architecture rather than images. If after compressing images, deferring loads, cleaning up scripts and configuring caching the site still paints the first screen in four seconds, there is nowhere further to push: the problem is the theme, the plugin set or the rendering approach. The fourth trigger is being unable to make changes. Every edit needs a developer, a campaign landing page cannot be assembled in a day, a new section takes a week. That is a hidden but constant tax: invisible in reports, extremely visible in marketing velocity.

The fifth and sixth triggers are external: a rebrand and a change of business model. A rebrand is self-evident, since a new identity needs a new expression, though even here an evolutionary route deserves consideration before a full rebuild. A model change is more serious: moving from catalogue to store, from services to subscription, from consumer to business changes the journeys, the structure and the functional requirements rather than the decoration. It is the one case where a revolutionary redesign is justified by default, because the product itself changes, not its appearance.

Evolution versus revolution, and why phased rollout is safer

An evolutionary redesign changes the site in pieces: the product card template first, then the catalogue, then the home page, then the informational pages. Each step is measured separately, so when conversion dips you know exactly which change caused it. It is cheaper in the moment, safer for organic search and stretched across the calendar. A revolutionary one changes everything at once: structure, visuals, platform. It delivers the "new site" effect faster and almost always brings a dip that is not always obvious how to climb out of.

The case for phased rollout is stronger than it looks, and it is about measurability rather than caution. In a big bang twenty variables change at once, and any result, rise or fall, becomes unexplainable. You do not know what worked, so you cannot repeat it. With a phased rollout each template goes live for a share of traffic, is compared against the old one, and the decision comes from numbers rather than from a feeling in a status meeting.

A technical caveat on split testing part of the traffic: the test has to be correct from a search engine standpoint. Splitting by cookie on one URL is fine. Serving one version to the crawler and another to the user by user agent is cloaking, and the penalty for it is out of all proportion to the value of the test. If variants live on separate URLs you need a canonical pointing at the primary version and a temporary 302 rather than a permanent redirect. And the test must be finite: an experiment running six months becomes two site versions, both of which need maintaining.

A big bang is justified in two situations: the whole platform changes, so running two versions in parallel is technically impossible, or the business model changes and the old structure is incompatible with the new one. In those cases three things are mandatory: a full migration rehearsal on staging with real data volumes, a launch window in a low season rather than a peak, and a written rollback plan with criteria that trigger the rollback automatically rather than by vote.

Stages and realistic timelines

The market norms: a visual redesign with no change to structure or functionality takes one to two months, while a functional one with reworked journeys, a platform change or a catalogue migration takes three to six. Timelines shorter than the lower bound usually mean the audit, the content migration or the testing was removed from the process, and the price of that surfaces after launch.

The table shows both timeline columns, visual and functional. Note the two rows that get underestimated most often. Content migration: moving copy, images and metadata and setting up redirects for a five-hundred-page site is not an export and an import, it is weeks of work, especially when the URL structure changes. And post-launch stabilisation: two to eight weeks of observation during which the team has to be available and the budget must not be closed.

A note on the audit. The temptation to start with design is strong, especially once the decision is made, but the audit stage is what identifies which pages bring you traffic and money, and therefore which must not be touched without a compelling reason. Skipping it does not save two weeks, it moves them to the end of the project in the form of working out why organic traffic dropped.

The SEO migration checklist: before, during and after

Before launch, first and most important is a complete URL inventory assembled from several sources rather than one crawler. You need: a crawl of the site, the current sitemap.xml, server logs for three to six months, indexation and query reports from Yandex Webmaster and Google Search Console, a twelve-month analytics export, and a list of external links. Merging those sources almost always produces more URLs than the crawler alone, because it surfaces pages with no internal links that nonetheless receive traffic and link equity.

Second, fix the baseline before anything changes. Rankings for the core keyword set, organic traffic by section, conversions by goal type, speed in both lab and field data, the number of indexed pages, current 404s. Without that record, the post-launch question of whether things got worse or were always like that is unanswerable, and every argument becomes an exchange of opinions. Separately mark the top 20 percent of URLs that produce 80 percent of organic traffic: those migrate first and get checked by hand rather than by sample.

Third, a mapping of old URL to new URL, built one to one wherever possible. Redirecting every old address to the home page is the most expensive migration mistake: search engines read it as page removal and the accumulated signals are lost. If a page genuinely no longer exists and has no replacement, returning 410 is more honest than sending the user to the home page. Redirects must be permanent (301), with no chain longer than one hop and no loops, and they should be verified by script across the whole list rather than by eye on ten examples.

Fourth, preserve what the page ranks for. Titles, descriptions, H1s and body copy on pages with traffic migrate as they are. The temptation to rewrite everything alongside the redesign is strong, but then two variables change at once and no movement can be explained. If the copy really is poor, rewrite it six to eight weeks after the migration, once indexation has settled. The same applies to heading structure, internal linking and breadcrumbs: reproduce their logic rather than reinventing it.

Fifth, the technical layer. Schema markup (Organization, BreadcrumbList, Product and Offer, Article, FAQPage) is migrated and validated on the new templates. robots.txt gets its own check, because carrying a site-wide disallow over from staging is a classic that costs a week of indexation. Any noindex left from development is removed. Canonicals are made absolute and self-referencing, with no chains. Decide in advance what happens to pagination, filters and parameters. If there are language versions, hreflang is checked for reciprocity. A new sitemap.xml with correct lastmod goes to both webmaster tools immediately after rollout.

During launch: do not change domain, design, URL structure and platform simultaneously if you can stage them. Keep the https scheme and the www or non-www variant. Run the redirect list automatically on staging before rollout and on production right after. Measure production speed against the baseline for LCP, INP and CLS, because a new design with animation and large images can quietly wreck Core Web Vitals. Check that content is present in the HTML rather than appearing only after scripts run. And re-verify analytics goals, counters and ecommerce events: they break during migration most often and get noticed last.

After launch, eight weeks of observation, and this is not a formality. Monitor 404s daily for the first week and weekly after, because every new 404 with traffic means a missed redirect. Analyse the logs: where the crawler goes, and whether it is spending crawl budget on redirect chains and removed sections. Track indexed page counts by section, since a drop in one section localises a problem better than a total. Check core rankings weekly against the baseline. Check conversions by device and source. And as a separate task, ask key external linking sites to update to the new addresses: a redirect works, but a direct link works better.

And a rollback plan written before launch rather than during the panic. The old version stays operational for at least 30 days, a database snapshot is kept, and the restore path is rehearsed on staging and fits inside an hour. Rollback criteria are set in advance and in numbers, for example organic traffic down more than 25 percent for two consecutive weeks with no technical explanation. What counts as normal: a temporary 10 to 30 percent dip over two to six weeks when the URL structure changes. The warning sign is no recovery after 8 to 12 weeks.

• URL inventory from the crawler, sitemap, server logs, webmaster tools, analytics and the backlink list.
• A one-to-one 301 redirect map with no chains. Mass redirects to the home page lose the signals.
• Titles, descriptions, H1s and body copy on trafficked pages migrate without rewriting.
• robots.txt, noindex, canonical, hreflang, schema and sitemap get checked item by item before rollout.
• Speed before and after: LCP, INP and CLS in field data, not only in the lab.
• Eight weeks of monitoring: 404s, logs, indexation, rankings and conversions by segment.
• A rollback plan with numeric criteria and the old version available for at least 30 days.

Redesign cost and what a comparable quote contains

Cost is driven not by page count but by the number of unique templates. A five-hundred-page site with six templates is cheaper than a thirty-page site where every page is unique. The second factor is the volume of content to migrate and whether the URL structure changes. The third is the platform: working inside the existing CMS is several times cheaper than moving to a new one, because a move includes data migration, reconfigured integrations and retraining the team.

Indicative Russian market levels look like this. A cosmetic refresh on the current platform, meaning updated styling, typography and some blocks without structural change: 100,000 to 300,000 RUB. A visual redesign with new templates and reworked key pages: 300,000 to 800,000 RUB. A functional redesign with a platform change, reworked journeys and catalogue migration: 800,000 to 2,500,000 RUB and up. Veltos.Tech prices work on an existing site from 35,000 RUB and UX/UI work from 60,000 RUB, which covers point tasks such as reworking a single template or landing page.

For proposals to be comparable, six things must appear in the quote. A list of unique templates with what each includes. An explicit statement of who does the content migration and builds the redirect map, because that is weeks of separate work and it is regularly left out of scope. Whether a pre-migration SEO audit and post-launch support are included. What happens after launch, meaning how many weeks of support the price covers. A rollback plan and a warranty period. And a definition of done: the criteria by which you accept the work.

A practical seriousness test: ask what the vendor will do if organic traffic drops 30 percent two weeks after launch. An answer of "that does not happen" means they have never migrated a site with traffic. A correct answer contains the words logs, redirects, indexation, compare against the baseline and rollback plan. That single question saves more than comparing prices across three proposals.

How to prove the redesign worked

Metrics are recorded before launch, or there will be nothing to prove. The minimum set: conversion on key actions split by device and source, organic traffic by section, core rankings, field speed data, mobile share, revenue by channel, and cost per action in paid channels. Record them over at least three months before the migration, ideally a year, so seasonality is visible.

The measurement window is at least eight weeks after stabilisation, not after launch. The first two or three weeks post-migration are noisy: indexation is rebuilding, some pages temporarily lose position, and user behaviour is distorted by novelty. Drawing conclusions in that period is pointless, and decisions made emotionally in week one usually create the real problems. Compare year over year for the same period rather than against the previous month.

On attribution honesty. If you changed the design, rewrote the copy, altered the structure and increased the ad budget simultaneously, the result cannot be attributed to design, neither the rise nor the fall. This is not pedantry: your next decision will rest on that conclusion, and an error here costs you the next project. Which is exactly why a phased rollout beats a big bang not only on risk but on the knowledge the team retains.

And two safeguards against self-deception. First, do not celebrate a falling bounce rate if traffic fell alongside it, because that often means the audience arriving on specific queries left and only brand traffic remains. Second, look at segments rather than averages. Overall conversion may be up 5 percent thanks to desktop while mobile, where seventy percent of the audience lives, is down 10 percent, and the average looks respectable right up to the moment you open the breakdown.

Frequently asked questions

Related services

• UX/UI design for websites and appsWe design interfaces that survive contact with production: research, structure, UI kit and a clean handoff to the developers. Everything lives in Figma as components with real states and real breakpoints, not as a folder of flat mockups. The same process covers landing pages, corporate sites, e-commerce, web apps and mobile.
• Website support and improvementNot every project needs a rewrite. It is often cheaper to fix the speed, clear the technical SEO errors, add the missing sections and integrations, and end up with a working site without paying for a new build.
• SEO and GEO website promotionSearch traffic is the one acquisition channel that keeps working after the ad budget stops. We run two tracks in parallel: classic SEO for Yandex and Google, and GEO, the work of getting your pages quoted inside AI Overviews, Yandex Neuro, ChatGPT and Perplexity, where a growing share of queries now ends. It starts with an audit, never with buying links.

Read next

• A Slow Site Loses Money: Core Web Vitals and ConversionSite speed is not a technical metric, it is a line in the revenue report. Core Web Vitals explained in plain language, how to find the real cause of a slow page, and a fix list sorted by return per hour of work.
• SEO in Yandex in 2026: what changed and what no longer worksLink buying is dead weight, templated copy pushes pages into the low-value bucket, and behaviour manipulation is no longer a grey tactic but a way to lose the site. Here is what actually drives Yandex rankings in 2026.
• UX Research Without a Lab Budget: What Actually Produces ResultsMost teams do not need a research department, they need to stop guessing. Methods ranked by cost and payoff, the five-user rule and its important caveat, and how to turn findings into decisions without a sixty-page report nobody reads.