In-depth practical guides

Prepare a multilingual website migration

Map destinations by language, preserve journeys and test routes: prepare URL changes without losing useful content.

Updated :

Does every old journey reach the right content in the right language?

A multilingual migration involves more than menu pages. Parameter-based profiles, categories, search, forms, downloads and media may use different addresses. Inventory content, language and dependencies. This guide prepares a migration and its checks; it does not assume the website being viewed needs an address change.

  1. Inventory URLs and usage

    Compare internal crawling, sitemap, publishing-system content and known journeys. Include parameters identifying profiles. Record language, type, status, known incoming links and planned destination; distinguish identity parameters from filter states.

  2. Map equivalents by language

    Map retained content to its genuine equivalent in the same language. For merges, confirm the destination retains useful information. If no relevant replacement exists, document retirement instead of automatically redirecting everything to a homepage.

  3. Prepare publication signals

    Update internal links, canonicals, language alternates and sitemap to final destinations. Verify declared equivalents exist and correspond. Also check files, images and downloads outside HTML pages.

  4. Test journeys in the prepared environment

    Open categories, profiles, search and forms in every language. Switch language from a specific profile and check identity retention. Test keyboard use, mobile viewports and Arabic layout; inspect HTTP responses and destinations, not only menus.

  5. Define redirects and retirements

    Test old URLs against the planned configuration and record destinations. Prefer a direct path to final content. Check loops, unnecessary chains and language mixing. Removed content without an equivalent should return a state consistent with removal.

  6. Plan monitoring and recovery

    Keep validated mappings and the last working state. Define blocking criteria, responsibility and rollback steps before changing anything. After authorised publication, monitor errors, journeys and indexing signals without promising a universal stabilisation time.

Situations and decisions

Typical situations for preparing a check. They do not describe completed assignments or actual observations.

A profile keeps its slug but loses a parameter

Verify the same profile, not merely the page template. Test several IDs, encoded characters and an unknown value. One template URL cannot replace every profile.

A translated version has no equivalent

Check whether content is absent or wrongly connected. Create useful translation when justified; otherwise document the gap. Do not declare a section with another purpose equivalent.

A form changes language after an error

Check action, context fields and validation returns. Preserve language and test values needed for correction. Test the complete journey to the observed state with an authorised test destination.

Record to retain

  • URL inventory with identity, language, type and retention decision.
  • Old-to-final URL mapping and justification for merges or retirements.
  • HTTP results, canonicals, language equivalents and tested journeys.
  • Verified configuration, monitoring criteria, responsibilities and recovery procedure.

Official references

Related protocols

Frequently asked questions

Should every translated slug change?

Not automatically. Choose a structure consistent with content and journeys. Additional changes increase mappings to maintain; establish their value beforehand.

Can every page redirect to the homepage?

A generic destination usually does not restore expected content. Seek a relevant same-language equivalent. Without replacement, handle retirement explicitly instead of hiding information loss.

Is the sitemap a sufficient inventory?

It is a starting point. Compare linked pages, parameter-based profiles, files and application journeys. Useful content may be absent while stale entries remain.

When should final checks run?

Before publication on the prepared configuration, then afterwards on actually served URLs. Compare both states. Late changes to routes, content or dependencies require affected checks to be repeated.