URL migration without an SEO shipwreck: measure before you redirect

A prettier URL is not yet a reason to migrate

Google updated its documentation on crawlable URL structures on October 23, 2026 and clarified its guidance on word separators: hyphens communicate word boundaries more clearly than underscores. The more important foundations remain unchanged. URLs should be technically crawlable, stable, understandable, and free from an unnecessary explosion of variants.

The dangerous response is: “Then we replace every underscore tomorrow.” An existing URL is more than a string. It may be indexed, carry external links, appear in campaigns, sit in customer bookmarks, and anchor analytics history. Every change is a migration with a transition period.

This guide therefore separates two jobs: designing clean URLs for new content and moving existing URLs only when the value justifies the risk.

What Google actually recommends

The updated URL documentation gives clear technical and editorial guardrails:

• separate words with hyphens rather than underscores when possible;
• use readable terms instead of long opaque IDs;
• use words in the audience's language;
• percent-encode reserved characters correctly;
• do not change primary content only through fragments such as #product;
• encode parameters in the common = and & form;
• remove unnecessary parameters;
• handle capitalization deliberately because URLs are case-sensitive;
• use an understandable regional structure such as /de/ or /en/.

These are recommendations for clarity and efficient crawling, not a promise that cosmetic changes produce a ranking jump. Most importantly, the documentation does not say that every existing underscore URL must be replaced immediately.

New URLs: boring is good

A strong new URL explains the content and hierarchy without exposing the internal data model. For a German guide to heat-pump costs, /de/ratgeber/waermepumpe-kosten/ is more understandable than /index.php?id=481&cat=7.

We use a small set of durable rules:

1. Lowercase paths and slugs.
2. Hyphens as word separators.
3. One language per locale path.
4. No session, tracking, or sorting ID in the canonical path.
5. No year when the page will be updated continuously.
6. No CMS category that is likely to be renamed soon.
7. One piece of content, one preferred canonical URL.

“Short” is not the goal by itself. /p/42 is shorter but less useful than /products/harbor-lamp/. Stability and meaning beat minimum character count.

Hyphen versus underscore: no need for panic

Google recommends hyphens because they signal a word boundary. Underscores have historically been used to mark terms that belong together, such as function names. For a new slug, the choice is simple: use a hyphen.

For an indexed address, the decision is different. We do not change /summer_clothing/ in isolation just to get /summer-clothing/. First ask:

• does the old URL receive organic clicks and impressions?
• does it have valuable external links?
• is it used in newsletters, PDFs, apps, or ads?
• are there larger structural improvements happening anyway?
• can both the old and new address be operated correctly for the long term?

If only the separator becomes prettier, the expected gain is usually too small for a migration. If taxonomy, language structure, or the platform is being cleaned up at the same time, the change may belong in a planned move.

Inventory URLs before changing them

A migration often fails because of forgotten addresses, not faulty redirect syntax. Build an inventory from several sources:

• XML sitemaps and a CMS export;
• current internal links from a complete crawl;
• Search Console pages and queries;
• web server or CDN logs;
• analytics landing pages;
• known backlinks;
• ads, emails, QR codes, PDFs, and app deep links.

Give each discovered URL a status, traffic level, primary language, intended destination, and owner. Do not discard variants with uppercase letters, slash differences, parameters, or old file extensions too early. They reveal real access paths.

The inventory becomes the acceptance checklist later. Anything unknown before the move is difficult to monitor reliably afterward.

The decision matrix: keep, consolidate, move, remove

Not every address needs a replacement. Put each one into one of four groups:

Keep: The content and address fit. No redirect required.

Consolidate: Several highly similar pages become one substantial destination. Old URLs may point to that relevant shared replacement.

Move: The content stays essentially the same but receives a new address. Create a direct one-to-one mapping.

Remove: The content no longer exists and has no meaningful successor. A real 404 or 410 is more honest than a redirect to the home page.

Google explicitly warns against sending many unrelated old URLs to one destination. That confuses people and may be treated as a soft 404. A redirect states content succession; it is not a broom for cleaning error reports.

The mapping is a contract

The central migration artifact is a versioned table containing at least:

• full old URL;
• full new URL or intended 404/410;
• redirect type;
• locale;
• old and new canonical;
• status of internal links, sitemap, and hreflang;
• test status;
• business owner.

For large sites, add priority, traffic, and backlinks. Editorial, engineering, and SEO review the mapping together. That prevents an old product advisor from landing on a product category merely because the paths look similar.

A good mapping is complete and deterministic: one old URL has exactly one intended outcome. Regular expressions may simplify implementation, but they do not replace the content decision.

301 or 308 — permanent and server-side matters most

Google recommends permanent server-side redirects for durable moves. 301 and 308 are suitable signals; the new destination is intended to appear in search results. A temporary 302 or 307 instead suggests that the source may remain the preferred address.

For a normal content migration, the practical order is:

1. direct server-side 301 or 308;
2. destination responds with 200;
3. destination canonical points to itself;
4. no intermediate hop;
5. no JavaScript redirect when the server can do it.

Whether 301 or 308 fits a stack can depend on HTTP method handling. For ordinary GET pages, it matters more that the status is permanent, consistent, and direct.

Redirect chains are technical debt

After several redesigns, old → less old → new → new with slash appears quickly. Google can follow several hops but recommends direct destinations and short chains. Every extra stop adds latency, increases the chance of failure, and burdens operations.

During the next move, do not write redirects only from the most recent structure. Point every known historical URL directly to the final destination. Then test:

curl -I https://example.com/old-path

The expected result is exactly one permanent redirect followed by a 200 page. An automated check should flag loops, multiple hops, external destinations, and redirects to error pages.

Canonical, sitemap, and internal links must tell one story

A redirect is not enough when other signals disagree. After the move:

• internal links should point directly to new URLs;
• every new page should have a self-referencing canonical;
• the new XML sitemap should contain only canonical destination URLs;
• hreflang should connect the new locale URLs;
• structured data and Open Graph URLs should be updated;
• old URLs should disappear from navigation, footer, and content;
• temporary noindex rules should be removed.

Google describes sitemap, canonical, and redirects as signals with different strengths. They do not work identically, but they should identify the same preferred URL. Contradictions prolong the transition and make diagnosis harder.

Control parameters instead of banning them

Parameters are not inherently bad. Filters, pagination, and campaign measurement may require them. Trouble begins when combinations create an effectively infinite set of nearly identical crawlable URLs.

Separate them by purpose:

• content-relevant: changes visible, independently useful content;
• presentational: changes sorting or view while content is mostly the same;
• measurement: UTM or referral parameters;
• stateful: session, basket, or personal view.

Only the first group is a candidate for indexable URLs. Measurement and session parameters do not belong in canonicals or internal navigation. For faceted navigation, explicitly choose which combinations may be crawled instead of linking every possible filter sequence.

JavaScript routing needs real addresses

Google advises against using fragments to change the main content of a page. /products#lamps and /products#chairs are not reliable independent content URLs in modern routing.

A single-page application should use the History API and real paths for indexable states. Every important URL must:

• open directly;
• return the same content after a reload;
• provide a useful server or static-export response;
• have its own title, H1, canonical, and status code;
• be reachable without previous client navigation.

Tabs, accordions, and purely local UI states may use fragments. The test is simple: should this exact state be discoverable in search and shareable? Then it usually deserves a real URL.

Do not merely translate locales — connect them

Google lists locale directories such as /de/ and /en/ as an understandable option for international sites. Consistency matters:

• every language has a stable URL;
• hreflang links corresponding translations in both directions;
• canonical stays within the same language unless there is a true duplicate;
• the language switcher opens the equivalent content, not always the home page;
• sitemap and navigation use the same locale paths.

During a migration, every language version needs its own mapping. A German legacy path should not point to an English page for convenience when a German successor exists.

Rollout: test first, then switch during lower traffic

Google recommends thoroughly testing the new site, preparing the mapping, and timing the move for a lower-traffic period where possible. A shared cutover can be clearer for small and medium sites; very large sites may migrate section by section.

Our sequence:

Before: Crawl staging, test the complete mapping, inspect canonicals and status codes, prepare the new sitemap, and save the monitoring baseline.

Cutover: Publish redirects and new pages together, clear internal caches, submit the sitemap, and sample every major template.

First 48 hours: Watch 404/5xx responses, redirect loops, crawl rate, server load, and the most important landing pages closely.

Following weeks: Compare indexing of old and new URLs, clicks, impressions, canonical selection, and backlinks. Google says temporary ranking fluctuations are normal.

Do not delete redirects after the first green dashboard

Google recommends keeping redirects for as long as possible and generally for at least one year. From a user perspective, operating them indefinitely can be sensible while old links, bookmarks, PDFs, or QR codes still exist.

After launch, update every link you control to the direct destination. Redirects remain a safety net rather than the normal navigation path. This reduces latency and server load without cutting off old entrances.

A calendar reminder to “remove redirects after three months” is not a cleanup strategy. The decision needs data about remaining requests and external references.

Acceptance checklist for a safe URL migration

• Every old URL has a relevant destination or an intentional 404/410.
• Permanent moves use direct server-side 301/308 responses.
• There are no loops and no avoidable chains.
• New destinations return 200 and self-reference in canonical.
• Internal links, hreflang, structured data, and social metadata are updated.
• The sitemap contains only new canonical URLs.
• robots.txt and noindex do not block the new pages.
• Capitalization and slash rules are consistent.
• Filter and tracking parameters do not create an indexable variant explosion.
• Search Console, logs, and analytics are compared with the saved baseline.
• Redirects stay active for at least one year and longer when real traffic remains.

Stable URLs beat perfect URLs

Google's updated guidance makes the convention for future pages even clearer: readable words, hyphens, few parameters, and genuinely crawlable paths. It does not suddenly make an existing underscore URL worthless.

Our pragmatic advice is to build new addresses cleanly and change old ones only for a demonstrable product or structural reason. When a migration is necessary, treat it as a release — with an inventory, mapping, tests, a direct rollback, and several weeks of monitoring. That creates a better information architecture without casually throwing established discoverability overboard.

Sources

• Google Search Central: Latest documentation updates
• Google Search Central: URL structure best practices
• Google Search Central: Redirects and Google Search
• Google Search Central: How to move a site with URL changes
• Google Search Central: Canonical URLs