Written by 4SYSTEMPublished on Updated on

9 min read

The migration of the URLs of a multilingual site is prepared by pairs of content, not by simple replacement of prefixes. For each page moved, the old address must lead to the correct theme in the same language. Canonical, hreflang, language selector and sitemap must then describe the new destinations, including when a page has no translation.

Your central deliverable is a bilingual table: it fixes the correspondences, the destinations of the language menu and the proofs expected before the switch. Redirects alone do not constitute a complete plan.

Establish inventory and editorial correspondence

Bring together the export of CMS, a crawl of the site, existing sitemaps and URLs found in server logs or Search Console. Don't limit yourself to menus: an old address may still receive visits or be referenced elsewhere.

For each URL, note the language, theme, HTTP status, current canonical, alternates, incoming internal links and the existence of a translated equivalent. Note protocol variations, host variations, trailing slash variations, and parameters that modify the content.

Assign a common identifier to translations of the same page. You thus avoid bringing two contents together based solely on the resemblance of their paths. Have correspondences approved by an editorial manager and exceptions by the technical manager.

The redirects guide 301 helps decide the future of pages. The bilingual batch adds verification of languages ​​and relationships between translations.

A URL migration table for a multilingual site

Completely fictitious example: https://atelier.example moves its French routes to /fr/ and replaces /en/ by /english/. The content remains French or English; the directory name does not serve as a hreflang code.

The paths below are abbreviated for reading. In the runtime file, old URLs, destinations, canonicals, and alternates are absolute URLs on this domain. The code en here designates English without regional targeting.

Old URLNew URLLanguageCanonical expectedExpected alternativesPicker destination
/maintenance//fr/entretien/en/fr/entretien/en: /fr/entretien/ ; in: /english/maintenance/English: /english/maintenance/
/en/maintenance//english/maintenance/in/english/maintenance/en: /fr/entretien/ ; in: /english/maintenance/French: /fr/entretien/
/assistance//fr/assistance/en/fr/assistance/en: /fr/assistance/ ; in: /english/support/English: /english/support/
/en/support//english/support/in/english/support/en: /fr/assistance/ ; in: /english/support/French: /fr/assistance/
/conditions-intervention//fr/conditions-intervention/en/fr/conditions-intervention/No English alternateEnglish option unavailable

Each old route receives a direct 301 to the new page, expected in 200. For each pair, the alternates are identical on both versions. The conditions page remains only French: do not attribute to it any supposed translation or English commercial equivalent. Have any contractual adaptation validated separately; marking does not guarantee any legal compliance.

Add an owner and editorial decision to each line. An unapproved destination blocks the affected batch, without automatic redirection to the home.

Canonical and hreflang: aligning different signals

For linguistic versions intended to remain indexable, retain a self-referring canonical here in each language. Google recommends, with hreflang, a canonical in the same language when this page exists.[24] Sending all English canonicals to French would contradict this editorial choice.

On /fr/entretien/, the expected annotations are:

<link rel="canonical" href="https://atelier.example/fr/entretien/" />
<link rel="alternate" hreflang="fr" href="https://atelier.example/fr/entretien/" />
<link rel="alternate" hreflang="en" href="https://atelier.example/english/maintenance/" />

The English page has its own canonical and uses the same alternates. Each version must refer to itself and cite its other versions with full URLs. hreflang links must be reciprocal; without cross-referencing, Google ignores the annotations concerned.[26]

On the French page without equivalent, keep the canonical to its new URL and do not announce an English alternate. Also check the initial HTML: the CMS must not produce a canonical different from that added by a JavaScript component.

These signals do not force the decision of Google. Redirects and canonical annotations are strong signals, while inclusion in the sitemap is a weaker signal.[24] Your job is to avoid their contradictions, not to guarantee the chosen URL.

Language switcher preserves context

The language picker must use editorial matching, not mechanical directory substitution. From the French maintenance, the English button leads to the English maintenance. By returning to French, it leads back to the interview, not to the reception.

For the page without translation, choose an explicit interface: hide the English option or display “Translation unavailable”. If you still offer navigation to an English section, name it as such. This link does not become an alternate and should not be presented as a translation.

Test keyboard control, on mobile and after direct reloading of an English URL. A stored preference should not automatically send the visitor back to the home page when clicking. Don't transform either x-default in missing translation: this value serves as a fallback for languages not covered and was designed in particular for selection pages.[26]

Deploy 301, links and sitemaps together

Enable changes from the same table version: application routes, redirects, internal links, canonical, alternates and sitemap. Google recommends permanent server-side redirects and advises aiming directly for the final destination rather than chaining jumps.[32]

In this example, /en/maintenance/ leads directly to /english/maintenance/, without passing through a French variant. Integrate existing normalization rules to prevent a host or slash change from recreating a string.

Replace old addresses in menus, breadcrumbs, content links and picker. Publish a current sitemap containing the new canonical URLs, then submit it to Search Console. Keep the old inventory as a control reference, without using it to generate the new links.

If alternates appear in the sitemap, each entry must list all variants, including itself.[26] If HTML and sitemap coexist, compare their annotations. Finally, a deletion without relevant replacement does not justify a redirection to the home page: Google warns that these redirections can be assimilated to software 404.[32]

The acceptance testing follows a verifiable order

Here is a proposed validation protocol, separate from the documented rules of Google.

  1. Check destinations. Each new page responds to 200, presents the correct content and is not blocked by a staging rule. Check robots.txt, noindex directives, and access protections.
  2. Test old URLs. Save the 301 status, Location header and jumps to the final page. Compare language and theme with the approved line, not just the HTTP code.
  3. Read annotations. Compare canonical and hreflang at the table, then check the reciprocal returns on the other language. Inspect the HTML and rendering if necessary.
  4. Browse links. Click the picker in both directions, control the menus and parse the sitemap. Look for old routes, non-existent destinations and redirected alternates.
  5. Rule on the lot. Any loop, bad language, missing destination or canonical contradiction blocks the switching of the pages concerned.

Use this acceptance testing card: “Maintenance batch; old URL /en/maintenance/ ; target /english/maintenance/ ; expected 301 then 200; English canonical; alternates fr/en reciprocals; picker towards /fr/entretien/ ; proof required: trace HTTP, extract HTML, capture of the menu and version of the sitemap”.

Add the actual timestamp, the identity of the verifier and their decision after verification. The expected states in this example are not results of executed tests.

Monitor both languages and prepare a coordinated return

After opening, filter server logs by old routes, new routes and language. Look for errors, loops, unexpected redirects, and French destinations called from old English pages. In Search Console, compare the French and English groups to spot anomalies that the global view would hide.

Also monitor availability and server load: Google indicates that crawling may temporarily increase during a migration.[32] A successful test before switching therefore does not replace the observation of real requests.

Keep redirects as long as possible, usually at least a year according to Google.[32] Their removal should not depend solely on the disappearance of old menu URLs. Check for persistent queries and known external links.

Finally prepare a coordinated rollback: server configuration, routes, annotations, picker and sitemap return together to a coherent version. Don't revert to old pages while leaving redirects to new ones. Designate who authorizes this return and what defect justifies it.

Frequently asked questions

Can we switch one language before the other?

Yes, if the matches remain consistent during the transition. The migrated French page must announce the English address still active, and this must refer to the new French one. The picker follows this same intermediate state. Version this temporary configuration, then replace its references during the second switchover; do not publish alternates to pages that are not yet available.

What to do with the parameters used by campaigns?

Distinguish tracking settings from settings that change content. For the former, decide with the marketing team whether the destination should keep attribution, then test an old address that is actually in use. For the latter, address each useful variant in the correspondence. A rule that clears all settings may delete a selection or lead to the wrong content.

How to process a PDF available in only one language?

Maintain a relevant document destination in this language and control download links for migrated pages. Don't create a fictional English version to complete the pair. If the file requires canonicalization, use the HTTP header suitable for non-HTML documents.[24] Check the response of the file itself, because checking the page template is not enough.

Next action: have a first bilingual batch approved

Export the URLs of a topic and populate the table for its French, English versions and its exceptions. Get the destinations approved, then execute the acceptance testing before expanding the plan. If you wish to organize this preparation with a speaker, the web services and SEO of 4SYSTEM make it possible to address the technical and editorial scope and the necessary controls.

Sources

EN