url structure change seo
The domain stays, the paths change. Simple in principle, and the migration type that produces the most mapping ambiguity — because two taxonomies almost never line up one to one.
Primary riskOld and new taxonomies rarely reconcile, and every unresolved mismatch defaults to a catch-all rule at the last minute.
A URL structure change is technically the simplest migration on this list. The domain stays. The server stays. Often the content stays untouched. The entire risk sits in one place: deciding where each old URL goes.
That sounds mechanical, and for perhaps 85% of URLs it is — a pattern rule handles them. The remaining 15% is where migrations are won or lost, because those are the URLs where the old taxonomy and the new one genuinely do not reconcile.
New URL structures are designed for the site as it should be. Old URLs reflect the site as it grew.
Somewhere in your inventory is a product that lived in two categories. A blog post filed under a topic that no longer exists. A landing page from a campaign three years ago that still earns links. A category with four products, three of which have been discontinued.
None of these have obvious destinations in the new structure. Each needs a human decision, and each decision needs someone who understands the business rather than the crawler.
Here is how a migration that was going well produces a 40% traffic drop.
Two weeks before launch, someone notices a few thousand URLs have no mapping. The deadline is fixed. The fastest way to make the 404 report clean is a catch-all rule sending anything unmatched to the homepage. The 404 report goes green. Everyone moves on.
Google treats a redirect to an irrelevant page as a soft 404. The old URL loses its rankings, and the homepage gains nothing, because it does not answer the query the old page answered. The report looked better and the outcome got worse.
The correct response to unmapped URLs is a decision, not a rule. Map to the closest relevant page or return 410 Gone. A deliberate 410 is a clean signal; an undecided catch-all is a slow loss.
If the structure change is happening alongside a domain change or a replatform — which it usually is — the mapping problem compounds rather than adds. Every URL is now changing on two axes at once, and diagnosing a drop afterwards becomes guesswork.
Where the timeline permits, separate them. Change structure on the existing platform, confirm recovery over three or four weeks, then replatform with URLs held constant. It costs weeks. It saves a quarter of arguing about which change caused what.
Where the timeline does not permit — and often it genuinely does not — the mitigation is a much stricter parity process, because you lose the ability to isolate variables after the fact. The technical scope page covers what that parity check has to compare.
If the domain is changing too, domain name change covers the additional steps. If this is part of a platform move, replatform is the page that applies. The complete engagement covers running all of these together.
What you see Deep pages redirect to the homepage. Their rankings vanish rather than transferring, and Google treats the redirect as a soft 404.
What fixes it Every URL with traffic or links gets a named destination. Where nothing relevant exists, return 410 deliberately rather than redirecting to something irrelevant.
What you see A rule maps /category/* to /shop/*, but a few hundred URLs predate that pattern and 404 silently.
What fixes it Test the rule against the actual URL inventory rather than against the pattern. The exceptions are always there and always in the oldest content.
What you see Navigation works because redirects catch it, but every internal click costs an extra hop and crawl budget drains into the redirect layer.
What fixes it Update internal links at the source. Redirects are for traffic you do not control, not for your own navigation.
What you see Both paths return 200. The site now has two copies of every page competing with each other.
What fixes it Old paths must redirect, not serve. A canonical tag alone is a hint; a 301 is an instruction.
| Change | Mapping difficulty | Main risk | Approach |
|---|---|---|---|
| Removing dates from blog URLs | Low | Collisions between posts with the same slug in different years | Pattern rule plus a tested collision list |
| Flattening a deep hierarchy | Low to medium | Losing breadcrumb context and internal link structure | Pattern rule; rebuild internal linking deliberately |
| Changing category taxonomy | High | Pages that belonged to two old categories now belong to one, or none | Manual mapping for anything with traffic or links |
| Merging product variants into one URL | High | Several ranking URLs consolidate into one, losing some rankings by design | Decide which variant wins each query before mapping |
| Adding a language or region prefix | Medium | The unprefixed URL keeps ranking and competes with the prefixed one | Redirect the root path and set hreflang together |
| Switching to slug-only URLs | Medium | Slug collisions across previously distinct sections | Generate the full mapping first; the collisions appear immediately |
The mapping is the whole job. Everything else about this migration type is straightforward.
Every indexable URL, not a sample. The URLs that break are always the ones outside the mental model of whoever designed the new structure.
Output Full URL inventory
Both, separately. The highest-linked URLs frequently have almost no traffic, so a tier list built from traffic alone misses the pages carrying the most equity.
Output Tiered inventory
Most URLs map cleanly by rule. Write the rules first so the remaining exceptions become a visible, countable list rather than a vague concern.
Output Rule set with match counts
What is left after the rules is the real work: pages whose category no longer exists, merged variants, retired content. Each needs an owner and a deadline.
Output Exception map with owners
Pages with no relevant destination should return 410 Gone rather than redirect somewhere irrelevant. Make that a decision, not a default.
Output Documented removal list
Final status code and hop count for each URL in the priority tiers, run against staging before launch and against production immediately after.
Output Redirect test results
Every URL that has organic traffic, external links, or both. Beyond that the return diminishes quickly. What matters is that the decision is deliberate: a URL that returns 410 because you decided it should is fine, and one that 404s because nobody checked is not.
Redirect to the closest genuinely relevant page — usually the parent category — or return 410 Gone. Do not redirect to the homepage. Google treats an irrelevant redirect as a soft 404, so the ranking is lost either way and you have added a hop for nothing.
At least a year, and there is rarely a good reason to remove them at all. External links keep sending traffic through old URLs for far longer than most people expect, and the cost of keeping a redirect rule is close to zero.
You can, and it makes diagnosis harder. If traffic moves, you will not know whether it was the structure change or the template change. If the timeline allows any separation at all, ship the structure change first and confirm recovery before touching templates.
Send the launch date and what is changing. We will tell you which parts of this page apply to your situation and which do not.