Redesigns lose traffic with grim reliability, and the post-mortem almost always identifies the same cause: nobody was accountable for search until the site was nearly built. By then the information architecture is set, the URL structure is decided, the content has been trimmed to fit new templates, and the only remaining lever is a redirect map applied at the last minute.
The redirect map matters, but it is the smallest part of the job. A migration that preserves rankings is one where search constraints shaped the design brief. This is the sequence that works, and the specific places it usually breaks.
The most expensive migration failures are not broken redirects. They are pages that were quietly deleted because no one knew they earned traffic, and content that was shortened to fit a new template. Redirects are recoverable in an afternoon. Deleted content and lost depth are not.
Before Anything Is Designed
Start with a complete inventory of what currently earns value. That means every URL that has received organic traffic, earned an external link, or holds a ranking worth keeping. Pull twelve months from Google Search Console, a full crawl of the live site, your backlink data, and your server logs if you have them. Reconcile the lists. The URLs that appear in one source and not the others are exactly the ones that get lost.
From that inventory, produce a short document the design team actually reads: which templates carry ranking value, which pages must survive with their depth intact, and which URL patterns cannot change without cost. This is the artifact that prevents the "we consolidated those into a nicer overview page" conversation from happening after the fact.
Decide the URL Question Early
Changing URL structure during a redesign is optional and usually not worth it. Every changed URL is a redirect to maintain, a small loss of link equity, and a recrawl to wait through. If the existing structure is merely inelegant, keep it. Change it only when it is genuinely broken: session IDs in paths, unreadable identifiers, or a hierarchy that misrepresents the site.
If you must change it, change it once. A redesign that alters URLs, then alters them again after launch because the first structure did not survive contact with the CMS, chains redirects and doubles the recovery period.
Building a Redirect Map That Holds
Map every old URL to the single most equivalent new URL. Equivalent means it satisfies the same search intent, not that it lives in the same menu position. A one-to-one match to a genuinely similar page is worth far more than a tidy-looking redirect to a category index.
Rules that matter in practice:
- Use 301, not 302. Temporary redirects on a permanent move delay consolidation for no benefit. Confirm the actual status code served rather than trusting the CMS setting.
- Never bulk-redirect to the homepage. Search engines treat a mass redirect to the root as a soft 404 and it wastes whatever the old page had earned.
- Eliminate chains. Old to interim to new should be collapsed to old to new before launch. Chains compound across successive migrations and eventually break.
- Redirect the variants too. Trailing slash, uppercase, query-string, and protocol variants all exist in the wild and all have links pointing at them.
- Handle the pages you are deleting deliberately. If nothing equivalent exists, a 410 is more honest than a redirect to something unrelated.
Test the map against the real inventory before launch, not a sample. A script that requests every old URL against the staging environment and records the final status and destination will find the twenty percent that the spreadsheet got wrong.
Staging environments are the most common source of catastrophic migration damage. A staging site left crawlable can get indexed and compete with production; a robots.txt disallow or a noindex header copied from staging to production at launch can deindex the entire site. Verify the production robots.txt and a sample of live response headers within minutes of going live, not the next morning.
Launch Window
Launch when you can watch it. Friday evening is convenient for the business and terrible for anyone who has to notice a problem within hours. In the first day, confirm that the production robots.txt is correct, that key templates return 200, that redirects resolve in one hop, that canonical tags point at the new URLs rather than the old, and that the XML sitemap lists only new URLs and has been submitted.
Keep the old sitemap available for a short period. It gives crawlers a fast route to discover the redirects rather than waiting to rediscover the old URLs organically.
What Week Three Looks Like
Expect a dip. A migration of any size typically shows two to six weeks of instability while pages are recrawled and signals reconsolidate. Judging success in week one produces panic; judging in week two produces panicked changes. Set the expectation before launch that the assessment happens at week four, and hold to it.
What is not normal: traffic that keeps falling after four weeks, specific high-value pages that never recover while the rest does, or a rise in crawl errors that does not resolve. Those indicate mapping problems rather than reconsolidation, and the diagnosis is usually a redirect that resolves somewhere unhelpful or a template that lost its content depth.
The Content Regression Nobody Logs
The failure that hides longest is content shortened to fit a new design. A template with a tighter hero, fewer content slots, and a strict word budget can quietly remove a third of the body copy from hundreds of pages. Rankings decline gradually rather than at launch, so the redesign is rarely blamed. Compare word counts and heading structures between old and new for a sample of ranking pages before you sign off, and treat a systematic reduction as a defect rather than an editorial improvement.
The Content Freeze Nobody Plans For
Migrations create a window where the old site is no longer being updated and the new one is not live. On a long project that window can run for months, and it is invisible until you look at publishing dates afterwards and find a gap. Competitors kept publishing through it.
Plan for continuity explicitly. Either keep publishing to the old platform until cutover and port the new pieces, or accept the freeze and front-load enough work that the gap is short. What does not work is discovering in month four that nothing has shipped since month one because everyone assumed someone else was handling it.
Keeping the Crawl Efficient Afterwards
A migration typically leaves debris: old URLs still linked from templates, parameters the new platform generates, and pagination that did not exist before. Each of these consumes crawl budget that should be going to your real pages during the exact period you most need recrawling to happen quickly.
Run a full crawl in the week after launch and look specifically for internal links still pointing at redirected URLs. Those are cheap to fix and they are the difference between one hop and two on every path through the site. Check for orphan pages as well: templates that changed often drop links that were the only route to a page, and an orphaned page with rankings will lose them quietly.
The Uncomfortable Recommendation
If the redesign is being driven purely by aesthetics and the current site ranks well, the highest-return option is often to restyle within the existing structure rather than replatform. That is not the answer most projects want, and it is frequently the correct one. When a replatform is genuinely necessary, plan for six to twelve weeks of search work running alongside the build, and put someone's name against it from the first design review.
Planning a redesign or replatform?
We will baseline what you have, build and test the redirect map, and monitor the launch window so a design win does not become a traffic loss.
Get in Touch →