Ultimate Guide To Migrating a Multi-lingual Website

Introduction

Multi-lingual websites are just like every other website - with one critical difference.

Each page is duplicated and displays content based on the selected language or region.

There are a few key ways to structure websites for multiple languages.

1. Country-Code Domains (ccTLD): example.de, example.co.uk etc.
2. Language Subdomains: en.example.com zh.example.com.
3. Query Strings: example.com?lang=de, example.com?lang=en
4. Language Subdirectories:  example.com/en, example.com/zh

This article will outline the approach for the most common multilingual site type you will encounter - Language Subdirectories.

It will also outline the process for doing a major site overhaul or migrating such a site to a new CMS.

For completeness we will first take a look at when you might see the ccTLD and Language Subdirectories and their characteristics.

Then we will dive into the nitty gritty of the how to do the migration.

Multi-lingual Site Structures - A Closer Look

Country Code Domains (ccTLD) (global companies)

Country code domains are typically (and often only) used by large global brands and e-commerce sites.

Examples: example.de, example.co.uk etc.

This structure is costly and complex to maintain because each language has it's own unique site and hosting - there is no easy 'global' control.

The key benefit of this structure different languages and regions can have completely uniques - meaning companies can tailor the UX (and more) for different markets - lots more than just changing the language.

You will likely not have to migrate one of these sites as companies that choose this structure often have large internal teams that will handle it. However if you do need help with this kind of migration, please contact us directly.

Language Subdomains (not often used)

Language Subdomains are also an option, but these are not typically used because they increase technical overhead and do not automatically share SEO authority with the main domain.

Examples: de.example.com, en.example.com

You might be asked to do rebuild a site that has this structure. You'll need to know if each subdomain will be translated to their respective new subdomain, or if the entire structure will be changed to Language Subdirectories)

Examples: de.example.com -> example.com/de

If you do come across this scenario and need help with this kind of migration, please get in touch!

Language Subdirectories (recommended)

Language subdirectories are the most common and widely recommended approach to making a website multi-lingual.

Each language is accessed by sub-path, meaning the site is managed from a single code base

The path is connected to a specific language which contains all the translations and is often managed by CMS like Webflow, or apps like Langify (on Shopify) or via JSON files.

Examples: example.com/de, example.com/en

The benefits of this structure include reduced complexity and shared SEO authority. This is the approach we advise for 95% of websites and what we will be focusing on today.

Query String Parameters (bad practice)

For completness, it's worth mentioning that you will see some websites change language by togging a URL parameter / query string.

Examples: example.com?lang=de, example.com?lang=en‍

This is an outdated practice which is not great for SEO as it does not render on the URL, but is updated on the page.

Now back onto the steps to migrating your multilingual website.

Preparing Your Multilingual Site For Migration

Step 1 - Conduct A Thorough Audit

The first step is to do a site audit and understand the structure of your current website. You need to know what languages site has and how the languages are structured.

NOTE: This guide is specifically for Language Subdirectories! It is not applicable to ccTLD, Language Subdomains or query strings. If you need help, please get in touch.

You can find out the general structure of the languages by looking at the URL of the website and noting how it is structured.

If you site is a using Language Subdirectories, you can typically find all the languages by looking at the sitemap, typically on example.com/sitemap.xml (or equivalent).

‍Each language should have it's own sitemap so this will give you a good high level overview of all the languages / locations involved.

Alternatively you can crawl your site with Screaming Frog or enter your current site URL along with your staging domain into Rapid301 to see how many languages there are.

Here are some common language path structures:

1. Country code only (en, de, fr)
2. Country-Region code, typically for countries with multiple official languages (en-us, en-ca, fr-ca)
3. Country-Region currency combination (en?currency=USD, en-us?currency=USD)

In cases of Country code only and Country-Region code, these paths are unique and often not interchangeable - unless a redirect has already been set up!

This is a common 'gotcha' so be careful. Just because a path has a /en-us sub-directory, it does not mean that /en will resolve!

Sometimes it will if a redirect has been setup, but if it hasn't it will lead to a 404 path.

At this point you should have your sitemaps and languages and it's time for Step 2.

Step 2 - Strategise How To Map Existing Structures To New Ones

Now that you know which languages are on your old site, it's time to prepare the new site and decide if you will keep the same localisation structures or change them.

Here are some examples of how the structures can be mapped (specifically for Language Subdirectories):

1. /en -> /en
2. /en-us -> /en-us
3. /en -> /en-us
4. /en-us -> /en

Depending on the platform you use, this structural decision or may not be up to you. Regardless, it will affect the way you handle redirects.

If you get to choose the subdirectory structure, here are some best practices:

1. The ROOT domain should be in the language of the main market. (without any code)
2. ‍Use ISO Country Codes (e.g., /us, /fr, /jp) for clear and recognised geo-targeting.
3. Avoid Mixing Language & Country Codes (e.g., /en-us/ vs. /us/) unless the same country has multiple official languages (e.g /en-ca, /fr-ca)‍
4. Use Region-Based Subdirectories Only If Necessary (for legal or tax differences).‍
5. Currency-Based Subdirectories Are Rarely Needed – It’s better to handle currencies dynamically with query strings (e.g us?currency=USD)

Step 3 - Rebuild The Site & Set Pages / URLs.

Now that you have the general language structure of your site, it's time to build our your new website according to the structure and migrate your content across.

Note that each time you create a page / URL, there is only one best practice to follow.

Whenever possible, ensure that your URLs are written in their respective language (but only if they use the latin alphabet - script languages are handled differently).

This means any words URLs for locales in English, German, Italian, Spanish etc subdirectories should translated into their languages, like so;

1. English -> example.com/shoes‍
2. German -> example.com/de/schuhe‍
3. Italian -> example.com/it/scarpa
4. Arabic -> example.com/ar/ahthiya

For non-script languages (Arabic, Chinese, Japanese etc), it is strongly advised against translating to the script form of the language as this as it requires encoding (though it is technically possible).

Do not translate like this.

1. Chinese -> example.com/ch/男鞋
2. Arabic -> example.com/ar/أحذية

Because when you copy the URLs they do not maintain their readability, and instead look like this %D8%A7%D9%84%D8%A3%D8%AD%D8%B0%D9%8A%D8%A9

Instead, 'translate' them to their latin equivalent like this:

1. English -> example.com/shoes‍
2. Chinese -> example.com/ch/nanxie
3. Arabic -> example.com/ar/hidha

We will assume you have fully rebuilt the site and ensured all URLs are in their respective languages.

Step 4 - Preparing For Launch & 301-Redirects

Chances are that the site structure of the new site is quite different from that of the old site.

Now it's time to ensure that we don't break any old links that may have been shared so that we can keep our SEO rankings intact and link juice flowing.

‍To do this we need to setup 301-redirects.

301-redirects ensure that anytime someone lands on an old URL that does not exist on the new site, that they are properly routed to the correct page.

‍Here's how to map 301-redirects (the old/slow way)

1. Get the sitemaps of the OLD site and the NEW site using SEO tools like Screaming Frog or ahrefs.
2. Create the migration document (OLD URL in left column, NEW URL in right column)
3. Map the most relevant URL on the NEW site to that on the OLD site and add it to migration document.
4. Repeat step 2. and step 3. for every URL on the old site.

You can manually match these paths up (one-by-one) or try and use scripts to help with this, but that takes hours, sometimes days depending on site size.

Download a FREE checklist to track your migration and (read the full guide)

Here's how to map 301-redirects (the new/efficient way)

1. If you have already have sitemaps from Screaming Frog, upload them here and have thousands processed in seconds.
2. If you don't have the sitemaps, enter your current and staging site here to have your sites crawled and the 301 redirect mapping document created.

If your sites URL structures are similar, this process should get you 90% of the way there in seconds.

Then you just need to review the output and make any necessary overrides, export them and go to the next step!

NOTE: The accuracy will depend on how closely related the old and new url are. This means that if you completely change the language the automation may hallucinate, which is why it is important to keep them a similar as possible! If you ned help, please get in touch.

5. Go Live And Monitor - Launch Phase

Once you have the redirect document, here's the step-by-step process you need to follow to launch your website seemlessly.

1. Add/upload  301-redirects your development platform or server - typically you can upload a .csv or add them to your .htaccess file.
2. Swap the domain over to the new site and wait 10 minutes.
3. Check the status codes of all the websites within your Rapid301 project.
4. Ensure your site has a robots.txt file and generate a sitemap (this makes it easy for search engines to crawl your site)
5. Add the new sitemap to Google Search Console.‍
6. Monitor over the next 72 hours to ensure the migration went smoothly, do any little spot fixes.

Conclusion

Multilingual sites are quite complex and it can be a lot of work to migrate them to a new CMS or do a major rebuild.

Let's do a quick recap of the high level points that were covered:

1. Multilingual sites can be structured in various ways; ccTLD, Language Subdomain, Language Subdirectory, Query Strings)
2. Language Subdirectories are highly advised as it provides the most SEO benefits out of the box and is the most cost-effective to maintain.
3. The first step when planning a migration of a multilingual site is to get the sitemaps and analyse it's structure.
4. When creating URL slugs for different language, ensure they are in the target language and use the latin alphabet to avoid encoding issues.
5. To keep SEO rankings and 'link juice' you need to setup 301-redirects. that map the new URL to the old URL.
6. Keeping the URL slugs as similar as possible will enable you to leverage tools to save time by automating this process.
7. Thoroughly check the 301-redirects before uploading and monitor closely for 72 hours after launch to ensure there are no 404's.

That's about all there is to multi-lingual website structure and migration strategies for Language Subdirectories.

If you need any help with your migration, please contact us and don't forgot to click the button below