The migration that "shouldn't affect SEO" always affects SEO
Imagine a team decides /products.php?id=4471&cat=12 should become /products/oak-dining-table. Everyone agrees it's overdue — the new URLs are cleaner, more shareable, better for the redesign. Marketing signs off because it's "just a URL change, the content's the same." Weeks after launch, organic traffic is down sharply and nobody planned for it.
This is the most avoidable ranking loss in SEO, and it happens constantly, because a URL migration looks like a technical footnote instead of what it actually is: you're asking Google to transfer years of accumulated trust from one set of addresses to another, address by address, with no room for "close enough."
Done with discipline, a migration is close to invisible — a brief dip that recovers within weeks. Done casually, it's a multi-month hole in your traffic that a redesign should never have caused. The difference is almost entirely in three unglamorous artifacts: the redirect map, the canonical tags, and the sitemap. Get those right and the rest of the migration is normal engineering work.
Build the redirect map before you touch a single URL
The redirect map is a spreadsheet, not a rule. Every old URL gets one specific new URL. Not a pattern, not a fallback to the homepage, not "the redirect will figure it out" — a row per URL, old to new, checked by a human.
This matters most exactly where it's most tempting to skip it: query-string URLs. ?category=lighting&sort=price_asc&page=2 isn't one URL, it's a combinatorial explosion of them, and most of those variants have no real ranking value — they're crawl noise your CMS generated by accident. The discipline is separating them into two buckets:
- URLs that actually rank and get traffic. Pull these from Search Console's Performance report and your analytics, not from a database export. If a parameterized URL has earned impressions and clicks over the past 12-16 months, it gets an explicit, one-to-one redirect to its clean equivalent.
- URLs that are pure noise. Faceted filters, session IDs, tracking parameters, sort orders. These should 404 or redirect to their nearest category page — they never earned equity worth preserving, and mapping thousands of them individually wastes time you should spend on the ones that matter.
Skipping this triage is how teams end up either redirecting everything to the homepage (which Google treats as a soft 404 pattern once volume gets high enough) or trying to 301 every parameter combination that ever existed (which balloons your redirect map into something no one can maintain or verify).
Redirects: one hop, the right code, no exceptions
Once the map exists, the rules for implementing it are simple and unforgiving:
- 301, not 302. A 302 tells crawlers the move is temporary, which affects which URL Google treats as canonical and how quickly it switches over — Google has said 301s and 302s pass ranking signals similarly, so the real cost of a 302 here isn't lost equity, it's a slower, less certain transition. For a permanent URL structure change, 301 is still the correct, unambiguous signal to send from day one.
- One hop, always. A redirects to B, not A to B to C. Chains dilute signal with every extra hop, slow down crawling, and are one of the most common things that turn up broken in migrations someone else already "finished." Run your full redirect map through a crawler like Screaming Frog before launch specifically looking for chains and loops.
- Update internal links too. A correct redirect doesn't excuse leaving your nav, footer, and in-content links pointing at old URLs. Every internal link that still points to a redirect is a wasted crawl request and a slightly weaker signal than a direct link. Fix the links; let the redirect be a safety net, not the primary path.
- Keep redirects live well past Google's stated minimum. Google's own guidance calls for at least a year of redirect maintenance after a site move. Old backlinks, bookmarks, and cached links don't expire on your schedule, so treat a year as a floor, not a target — pulling redirects right at that mark is a common way to lose equity from links that are still out there.
Canonical tags do cleanup the redirect map can't
Query-string sites almost always have duplicate-content problems the migration should fix, not carry forward. If /product?id=4471 and /product?id=4471&ref=email both exist, both need to resolve — after redirect — to the same clean URL, and that clean URL needs a self-referencing canonical tag. Don't let the old parameter variants survive as canonicalized-to-self pages; that just moves the duplication problem into your new URL structure instead of solving it.
Audit this before launch, not after: pull every indexed URL from Search Console's Pages report (under Indexing), group them by the clean destination they should collapse into, and confirm the canonical tag on that destination points to itself, not back toward a legacy pattern a template accidentally preserved.
Sitemap sequencing matters more than people think
The order you touch your sitemap in actually changes how fast Google reprocesses the migration:
- Before launch: confirm your current sitemap accurately reflects what's live today. A stale pre-migration sitemap is a bad baseline to diff against later.
- At launch: publish a new sitemap containing only the new, clean URLs — no redirected URLs, no parameter variants. Submit it in Search Console immediately.
- For 2-4 weeks after: keep the old sitemap accessible (not deleted) so Google's crawler can still find and process the redirects it lists, rather than discovering them only through slower incidental crawling.
- After that window: retire the old sitemap. The redirects themselves stay live; you just stop actively pointing crawlers at the old map once it's served its purpose.
Watch the Pages report daily during this window for "Page with redirect" counts climbing and "Not found (404)" counts staying flat. A 404 spike mid-migration means a gap in your redirect map, not something Google will just work around.
What the ranking dip actually looks like when you did it right
Even a flawless migration causes a real dip — that's not a red flag, it's Google re-crawling and re-associating signals with new addresses. What a healthy migration looks like: rankings soften for a few weeks, then most positions recover, and within a couple of months you're at parity or ahead (clean URLs plus whatever else shipped in the redesign) — though the exact timeline varies with crawl frequency and site size. What an unhealthy one looks like: the dip keeps deepening well past the first month, 404s show up in the Pages report, and traffic hasn't recovered by month three. That gap between "expected dip" and "traffic-costing mistake" is entirely explained by the redirect map, canonical audit, and sitemap sequencing above — there's rarely a fourth mystery cause.
Bottom line
A URL migration is not a redirect rule and a prayer. It's a spreadsheet mapping every URL that earned traffic to exactly one new destination, a canonical audit that closes the duplicate-content gaps the old structure was hiding, and a sitemap sequence that tells Google what changed without burying the signal in noise. Do those three things with discipline and the dip is a few weeks, not a few quarters. If you're planning a URL structure change and want the redirect map built and verified before launch instead of patched after the traffic drop, our SEO team scopes exactly this kind of migration before launch, not after the traffic drop.
