If you can, separate them, because doing a migration and a redesign at the same time couples two large changes and makes any problem hard to diagnose. Start from what each one actually is. A migration changes your URLs, platform, or hosting; a redesign changes your content, structure, and layout. Each can affect rankings on its own, so if you do both together and traffic drops, you cannot tell whether the cause was the migration, such as a missing redirect, or the redesign, such as restructured or thinned content. Separating them isolates the variables: migrate first while keeping the content and structure as close to identical as possible, confirm rankings held, and then redesign on the stable new platform, so any change after the redesign points clearly at the redesign. The cost of separating is real, two projects and more total time, which is why combining is tempting and sometimes chosen deliberately. If you must combine them, you are not doomed, but you have to be far more rigorous. WPBuildAI scans your site and returns the URL list, content, and structure, giving you the baseline to keep content stable through a migration even when a redesign is planned.
Doing both at once makes diagnosis harder at exactly the moment you need it, and there is now an extra dimension to untangle: Google added Search Generative AI performance reports to Search Console on 3 June 2026, so AI visibility and classic rankings can now move independently of each other.
Two changes with different mechanisms
The reason this question matters is that a migration and a redesign affect your rankings through different mechanisms, even though they often happen together. A migration is about where things live: the URLs, the platform, the hosting. Its risks are missing redirects, lost metadata, broken internal links, the kind of failures described in site moves with URL changes. A redesign is about what things are: the content, the structure, the layout. Its risks are restructured or thinned content, changed headings, removed pages, and lost internal linking. Because the mechanisms differ, the two changes are genuinely separate sources of risk that happen to be bundled. Seeing them as two distinct things, not one project, is the key to deciding how to sequence them.
Why combining hides the cause
The core problem with doing both at once is attribution. Imagine you migrate and redesign together, launch, and traffic falls. Now you face a question with no clean answer: was it the migration, perhaps a set of URLs that lost their redirects, or the redesign, perhaps a content restructure that thinned your strongest pages? A coupled change hides its own cause, because the two possible culprits changed simultaneously, so you cannot isolate which one to fix. You end up investigating everything at once under pressure, which is slow and error prone. Since traffic concentrates on a minority of pages, as the Ahrefs study shows, a drop on those pages is costly, and not knowing whether to look at redirects or content wastes the time you can least afford to lose.
What separating them looks like
Separating the changes means sequencing them so each is verifiable on its own. The usual order is to migrate first, carrying your content and structure across as close to identical as possible, so the only meaningful change is the URLs, platform, or hosting. You confirm rankings held through that move, which is a clean test because content was held constant. Then, on the stable new platform, you do the redesign as a second project, so any change after it points clearly at the redesign rather than the move. An alternative order, where it fits, is to do content work first on the old platform, then migrate, but the principle is the same: change one dimension at a time. This is also where understanding the difference between a redesign and replatforming helps you decide which dimension you are actually changing.
The honest cost of separating
It would be dishonest to pretend separating is free. It means two projects instead of one, more total time, and often more cost, because you launch twice, test twice, and coordinate twice. For a small site, or under a tight deadline, that overhead can be hard to justify, which is the legitimate reason teams combine the two. So the recommendation is conditional: separate them if you reasonably can, because diagnosability is worth a great deal when something goes wrong, but recognize that combining is a real choice with a real efficiency benefit, not simply a mistake. The right answer depends on your risk tolerance and resources. What is not optional is being clear eyed: if you combine to save time, you are trading away the ability to diagnose, and you should compensate accordingly.
If you must combine, raise the rigor
When you do combine a migration and a redesign, the way to manage the coupled risk is to minimize the number of things that can go wrong, so that fewer variables are in play even though you cannot fully separate them. That means full redirects for every changed URL, strict content parity wherever the redesign allows, preserved metadata and internal links, and thorough testing before launch, the discipline described in testing a migration before going live. A content audit beforehand, as in a content audit before a migration, lets you make deliberate content decisions rather than accidental ones, so any content change is intended and recorded. The goal is that if a drop happens, you have already eliminated the avoidable causes, narrowing the investigation even on a combined project. Rigor substitutes, imperfectly, for the separation you gave up.
Keep a baseline either way
Whichever path you choose, capture a baseline of the old site before you change anything, because it is what lets you measure and diagnose afterward. A record of your URLs, content, and structure gives you something concrete to compare the new site against, so you can see what changed and whether it held. Web Almanac 2024 (HTTP Archive) is a reminder that sites carry more content and URLs than anyone remembers, so a baseline from memory is unreliable. With a real baseline, even a combined migration and redesign becomes more diagnosable, because you can check content parity and URL coverage against what existed. WPBuildAI provides this baseline by returning your URL list, content, and structure, which is the reference point for keeping content stable through a migration and for judging a redesign against what came before.
Steps to decide and sequence
- Recognize them as two changes: URLs and platform versus content and structure.
- Prefer to separate, migrating first with content stable, then redesigning.
- Confirm rankings held after the migration before starting the redesign.
- Weigh the cost of two projects against the value of diagnosability.
- If combining, raise the rigor: full redirects, content parity, thorough testing.
- Capture a baseline of URLs, content, and structure either way.
Worked example: separating to stay diagnosable
Imagine a company that wants both a new platform and a fresh design. Rather than doing both at once, they sequence. First they migrate to the new platform, deliberately keeping the content, structure, and metadata as close to the old site as possible, and 301 every changed URL. They confirm over a few weeks that rankings and traffic held, a clean result because content did not change. Then they begin the redesign on the now stable platform, reworking layout and structure. When one section dips afterward, they know immediately it relates to the redesign, not the migration, because the migration was already proven, so they look at the restructured content and find a thinned page, which they fix. The problem was diagnosable because the variables were separated, which is exactly what makes a post redesign SEO drop solvable rather than mysterious.
Limitation: separating reduces risk, it does not remove the work
It is fair to be clear about what sequencing does and does not do. Separating a migration from a redesign makes problems diagnosable and reduces the chance of a confusing, hard to fix drop, but it does not remove the work of doing each carefully; a migration done badly still loses rankings even if no redesign is attached, and a redesign done badly still thins content even on a stable platform. Sequencing is about attribution and risk management, not a guarantee of success for either step. And combining is not always wrong; for some sites the efficiency genuinely outweighs the diagnostic cost. So treat this as a framework for an informed decision, weighing diagnosability against resources, rather than a rule that combining is forbidden.
Common mistakes
- Treating a migration and a redesign as one project without considering separation.
- Combining them and then being unable to attribute a traffic drop.
- Separating in principle but changing content during the migration step anyway.
- Combining without raising the rigor to compensate for the coupled risk.
- Skipping a baseline, so there is nothing to diagnose against afterward.
Key points
If you can, separate a migration from a redesign, because they affect rankings through different mechanisms, URLs and platform versus content and structure, and doing both at once makes any traffic drop impossible to attribute. Migrate first with content held stable, confirm rankings held, then redesign on the stable platform, so problems point clearly at one cause. The cost is two projects and more time, which is a legitimate reason some teams combine them, so treat this as an informed trade off rather than a rule. If you must combine, raise the rigor with full redirects, content parity, preserved metadata and links, and thorough testing, to minimize the variables you cannot separate. Capture a baseline of URLs, content, and structure either way, since it is what makes the result diagnosable. WPBuildAI scans your site and returns the URL list, content, and structure, giving you the baseline to keep content stable through a migration even when a redesign is planned. Send your web address for a free analysis.
Not affiliated with WordPress, Lovable, Webflow, Shopify, Wix, or Squarespace.