Translated slug migrations: a release sequence for preserving locale URL relationships

A practical release and validation guide for changing translated URL slugs without breaking redirects, canonicals, hreflang, internal links or XML sitemaps.

Renaming a URL slug in one language is usually treated as a redirect task. Renaming translated slugs across a multilingual site is different. The implementation team must preserve the relationship between equivalent pages while each URL moves to its correct new, same-locale destination.

That relationship spans several implementation surfaces: redirects, canonical links, hreflang annotations, internal links and XML sitemaps. If those surfaces are updated at different times or generated from different URL data, a technically valid page can still point to an obsolete peer, redirect to the wrong language or remain discoverable only through the old URL set.

This guide sets out a release sequence for that specific problem. The central idea is to treat the migration as a transition between two locale-aware URL relationship graphs. It is an implementation framework derived from Google’s guidance on URL changes, canonicalisation, internationalised versions and sitemaps, rather than an additional Google requirement. The focus is planning, sequencing and validation, not a general site-migration checklist.

Define the change as a locale relationship

Start with the content relationship, not a list of redirects. A translated page should be represented as a locale-specific node connected to its equivalents. For example, a product guide might move as follows:

  • English: /en/guides/choosing-a-standing-desk/ → /en/guides/how-to-choose-a-standing-desk/
  • French: /fr/guides/choisir-un-bureau-assis-debout/ → /fr/guides/choisir-un-bureau-assis-debout-ergonomique/
  • German: /de/ratgeber/elektrisch-hohenverstellbaren-schreibtisch-waehlen/ → /de/ratgeber/ergonomischen-schreibtisch-auswaehlen/

These are three URL changes, but they also form one multilingual relationship. The English page should redirect to the new English page, the French page to the new French page and the German page to the new German page. The new pages should then expose the intended peer set, using the new URLs rather than the old ones.

Google recommends preparing a mapping from current URLs to their corresponding new URLs before a URL change and determining the destination for each old URL. For a multilingual rename, the practical extension is to make that mapping locale-aware and include the relationships that a redirect list alone cannot describe. See Google’s guidance on site moves with URL changes and its documentation on localised versions.

Build a pre-release relationship matrix

The relationship matrix should be the release’s source of truth. It can live in a migration file, database export or deployment service, provided the routing layer, page templates and sitemap generator consume the same approved values.

At minimum, each record should contain:

  • an internal content or relationship ID;
  • the locale and, where relevant, regional target;
  • the old URL;
  • the new URL;
  • the intended canonical URL;
  • the expected hreflang peer URLs, including the page’s own URL;
  • the direct redirect target for the old URL;
  • the migration state, such as ready, exception or blocked;
  • an exception reason where the relationship is not one-to-one;
  • validation results for each implementation surface.

For the worked example, one record might be represented like this:

relationship_id: standing-desk-guide-001
locale: fr-FR
old_url: https://example.com/fr/guides/choisir-un-bureau-assis-debout/
new_url: https://example.com/fr/guides/choisir-un-bureau-assis-debout-ergonomique/
intended_canonical: https://example.com/fr/guides/choisir-un-bureau-assis-debout-ergonomique/
hreflang_peers:
  en-GB: https://example.com/en/guides/how-to-choose-a-standing-desk/
  fr-FR: https://example.com/fr/guides/choisir-un-bureau-assis-debout-ergonomique/
  de-DE: https://example.com/de/ratgeber/ergonomischen-schreibtisch-auswaehlen/
redirect_target: https://example.com/fr/guides/choisir-un-bureau-assis-debout-ergonomique/
state: ready
validation:
  redirect: pending
  canonical: pending
  hreflang: pending
  internal_links: pending
  sitemap: pending

This matrix makes a wrong-locale redirect visible before release. It also exposes defects that a conventional old-to-new redirect spreadsheet will miss: a French page whose hreflang still points to the old German URL, a new page with an English canonical or a sitemap containing the old URL as a preferred entry.

The matrix is an applied implementation model. Google’s documentation supports the underlying activities, including mapping changed URLs, maintaining reciprocal language references, updating canonicals and refreshing sitemaps, but does not prescribe this exact schema.

Separate ordinary renames from exceptions

A standard slug rename has a one-to-one relationship:

  • one old page;
  • one new page in the same locale;
  • one direct redirect;
  • one intended canonical;
  • one defined set of locale peers.

Do not force every record into that model. Mark the following situations as exceptions and give each one a documented decision:

  • Missing translation: the equivalent page does not exist in one locale.
  • Split: one old page becomes several new pages.
  • Merge: several old pages become one new page.
  • Locale change: the content is deliberately moved to another language or regional area.
  • Retirement: there is no suitable replacement and the old URL should not be redirected to an unrelated page.
  • Fallback: a documented product or content decision uses an alternative language or x-default destination.

A missing translation should not automatically redirect to a merely related language page. The page may need to remain live, point to a genuine same-locale substitute, be retired or use an explicitly approved fallback. Google discusses substitute-language canonicals and x-default, but that does not make an arbitrary related-language page a suitable destination. Google’s canonicalisation guidance should be read alongside the documentation for international versions.

For ordinary renames, same-locale redirects should be the default safeguard. A cross-locale redirect may be correct when the content or locale has genuinely changed, but it should require a recorded decision rather than being used because the translated destination was unavailable.

Use a release sequence that keeps dependencies visible

Google recommends updating the relevant URL signals as part of a URL change, but it does not prescribe a mandatory order for every individual signal. The following sequence is a practical implementation recommendation for reducing inconsistent intermediate states.

1. Freeze and approve the relationship model

Complete the matrix before changing production routes. Resolve duplicate records, missing peers and locale exceptions. Also agree the normalisation rules for trailing slashes, case, query parameters, hostnames and encoded characters.

At this stage, every ordinary record should have a unique old URL, a unique new URL and a same-locale redirect target. Any record without those properties should be blocked or explicitly classified as an exception.

2. Build the new page state before exposing it

Make the new URLs resolvable in a staging or controlled environment. Render each page and check that it contains the intended content, locale metadata and link output.

For a fully translated page, the practical default is a self-referencing canonical at the new URL for that locale. This is an implementation acceptance criterion, not a guarantee that Google will select that URL as canonical. Google distinguishes canonicalisation from hreflang and generally recommends a same-language canonical where one exists.

3. Deploy direct permanent redirects

Each old URL should redirect directly to its final intended destination. Google recommends permanent server-side redirects such as 301 or 308 where technically possible, and advises avoiding redirect chains. A direct French-old-to-French-new redirect is preferable to a route that passes through an intermediate URL.

Activate redirects only when the target pages and their routing are ready. If the platform supports an atomic deployment, release the route and target state together. If not, test target availability first and use a controlled release window.

The redirect list is not a substitute for updating page output. Redirects handle requests to old URLs; they do not correct stale canonical links, hreflang references, internal links or sitemap entries.

4. Release canonical and hreflang output

New pages should emit the new canonical URL and the active set of new locale peers. Each hreflang version should identify itself and the relevant alternate versions, with reciprocal references between the pages. The URLs should be fully qualified.

For the example above, the new French page should reference the new English and German URLs, not the old versions. The new English and German pages should also reference the new French URL. Google’s internationalisation documentation explains the requirement for self-reference and return links.

HTML annotations, HTTP headers and XML sitemaps are supported implementation methods for hreflang. They are equivalent methods, not a requirement to duplicate annotations across every surface. If more than one method is used, generate each from the same relationship data and test for conflicts.

5. Replace internal links

Update links in navigation, locale switchers, templates, related-content modules, breadcrumbs, structured components and editorial content. Validate same-locale content links separately from locale-switcher links: they have different purposes and can fail independently.

Google recommends updating internal links as part of a URL move. This does not remove external links to old URLs, so old-URL requests may continue after the release. The aim is to stop the site itself generating avoidable requests through the old URL set.

6. Publish the new sitemap state

Publish sitemaps containing the new URLs and remove renamed old URLs as preferred live entries. If the sitemap includes alternate-language annotations, those annotations should use the new peer set. Sitemap membership should agree with the canonical and hreflang output.

Sitemaps help search engines discover URLs and can describe alternate language versions, but they do not guarantee crawling or indexing. Google also treats sitemap inclusion as a weaker canonicalisation signal than redirects or a canonical link. See the documentation for sitemaps and canonicalisation.

Publishing the sitemap after the page and redirect state is ready reduces the chance of advertising URLs that still return the wrong response or emit stale relationships. A staged rollout can be appropriate, but it must define which old and new URLs are active in each batch. Otherwise, the site may expose a mixture of relationship states that is difficult to interpret.

Validate assertions before release and observations afterwards

Keep two categories of checks separate. Pre-release assertions test what the implementation is intended to do. Post-release observations test what the live site, crawlers and search systems are actually doing.

Pre-release assertions

  • Every ordinary old URL has exactly one final destination.
  • Every redirect target is in the same locale unless an approved exception exists.
  • No redirect points through another renamed URL.
  • Every new URL resolves successfully in the release environment.
  • Every new page has the intended self-referencing canonical.
  • Every hreflang set contains the expected self-reference and peer URLs.
  • Every peer relationship is reciprocal.
  • Internal-link generators output new URLs rather than old URLs.
  • Locale switchers use the intended new peer URLs.
  • The sitemap contains the approved new URL set and no unintended renamed old URLs.
  • Exception records have an owner, reason and expected outcome.

These checks can be automated from the matrix. A content-ID-generated relationship graph is a useful architectural hypothesis: generating redirects, canonicals, hreflang and sitemap entries from one source may reduce inconsistencies compared with maintaining separate lists. That idea should be tested on the platform rather than presented as an established outcome.

Post-release observations

After deployment, test representative URLs from every locale and migration state:

  • request old URLs and record the status code, redirect count, final URL and final locale;
  • fetch new pages and inspect rendered or source HTML for canonical and hreflang output;
  • extract internal links from templates and representative page types;
  • download and parse XML sitemaps for membership and alternate annotations;
  • review server logs for unexpected old-to-old, cross-locale or repeated redirect patterns;
  • use representative Search Console inspections or performance views where available to monitor processing, indexing and locale-level symptoms.

These checks provide evidence about the live implementation. They do not prove that Google has already processed every changed URL. URL changes are processed asynchronously and old URLs may continue to be crawled, particularly when external sites still link to them.

Set acceptance criteria and a containment path

A locale batch should not be considered released merely because deployment has completed. A practical acceptance decision might require:

  • 100% of ordinary old URLs return the intended direct permanent redirect;
  • 0% of tested redirects resolve to an unintended locale;
  • 100% of sampled new pages return the expected canonical;
  • 100% of sampled hreflang relationships are self-referencing and reciprocal;
  • 0 unintended old URLs are emitted by internal-link output;
  • sitemap membership matches the approved new URL set;
  • all exceptions are documented rather than silently absorbed into generic rules.

These are proposed implementation acceptance thresholds, not Google requirements. The exact sample size and release-batch size depend on crawl volume, deployment capability and tolerance for mixed states. A smaller batch can limit the blast radius of a bad mapping, while a staged release can prolong the period in which old and new relationship states coexist. Decide that trade-off before deployment.

If a batch fails, contain it rather than simply removing every redirect. First preserve access to valid target pages, correct the relationship data, stop further batches and restore the previous output where the platform allows it. Then retest redirects, rendered signals, internal links and sitemaps before resuming. A rollback plan that leaves old URLs inaccessible or creates a second redirect layer can turn a mapping defect into a wider migration problem.

What this process cannot guarantee

A consistent relationship graph improves implementation control; it does not guarantee unchanged rankings, traffic, impressions, canonical selection, crawling or indexing. Google may select a different canonical, process hreflang incompletely or take time to recrawl changed URLs. Sitemaps remain discovery and preference hints rather than indexing guarantees.

External websites cannot be updated by the implementation team, so requests for old locale URLs may persist. Keep valid redirects in place for as long as possible; Google generally recommends retaining them for at least a year after a URL change. That is guidance, not a guarantee that every external reference or search signal will have transferred by then.

Conclusion

The important distinction is between changing translated slugs and preserving translated URL relationships. The implementation unit is not an isolated redirect. It is the locale-aware record connecting an old URL, its new same-locale destination, its canonical, its peer set, its internal links and its sitemap representation.

Build that relationship model first, release the new page state before advertising it, use direct redirects, update each signal deliberately and validate assertions separately from live observations. This gives the team a controlled transition from the old URL graph to the new one, while keeping exceptions visible instead of hiding them inside pattern-based rules.

Share this article

Found this useful? Pass it on.

Share on LinkedIn · Share on X