Multilingual SEO best practices
Many moons ago — over a decade ago to be precise — I took on a mammoth project that I still reference to this day, and acts as evidence that the best practices of multilingual SEO have not changed much in this time. We’ll use this to illustrate the best ways to approach localization and multilingual SEO.
What is multilingual SEO?
Multilingual SEO is the process of localizing your website into more than one language. It also is a language-led approach, meaning you prioritize language over locale (country or region) in your user targeting and information architecture configuration.
How does it differ from international SEO?
Where multilingual SEO differs from international SEO is that your targeting and site configuration is typically focused on languages only.
If you are aiming to have one version of English and one version of Spanish globally, then you are talking about multilingual SEO. Multilingual SEO needs to include more than one language.
If you are looking to have multiple versions of your website in the USA and the UK, then you are talking about International SEO. International SEO does not need to include more than one language, though it commonly does.
Multilingual SEO “in practice”
I’ve managed an abundance of multilingual websites and localization efforts over the past 15 years, however, my experience with Nike was definitely the most interesting and challenging.
As Nike’s EMEA SEO lead, I managed 26 ecommerce experiences in nine languages. And with such a vast multilingual region, there was no shortage of daring and complex projects to sink your teeth into, including the deployment of four new languages, the global introduction of “hreflang” markup when it was still not widely adopted, and the integration of FC Barcelona’s ecommerce experience into Nike.com, along with the launch of the Catalan language to support it.
Along with each of the four best practices below, I’ll include a companion “in practice” section to help further illustrate the recommended approach and hopefully provide learnings from my mistakes experience.
1. How to approach multilingual SEO?
First, you need to determine the scope of your project — which is not necessarily specific to SEO — but will greatly inform the decisions you make for your multilingual SEO approach and configurations. Here are the questions you should be asking:
What languages are you looking to translate your content into?
How will the content be translated [and ultimately what influence can you have on the (key)word selection]?
Are you wanting to translate all of your website’s content or just certain webpages?
And lastly, how will you ensure that this translated content will be served in the correct search engine and avoid duplicate content risks?
The answers to these questions will help guide your SEO decisions, but there are pitfalls to avoid and best practices to follow for each, which we’ll dive into next.
In practice: The challenge and approach
Nike.com has unique commerce experiences for each language and locale they operate in. At the time of my tenure working with the company, it was a very complex environment that search engines were struggling to understand. Customers reported finding Nike URLs in incorrect languages across incompatible search engines around the world.
For example, product URLs for "U.S. English" were ranking in Google.co.uk, which led UK-based customers to pages in U.S. dollars, creating a poor user experience. In SEO terms, we were effectively competing against ourselves, also known as keyword cannibalism.
Here’s a screenshot of Google.co.uk search results from 2013 for “Nike gifts” with two U.S. English pages outranking the UK English page:
To fix this, we undertook an extensive analysis of this cross-contamination in search engines across all localized variations of Google. This revealed we had a bigger problem than initially thought, and needed to employ a relatively underutilized (at the time) HTML meta element called “hreflang” to help direct search engines on which content to index in which localized search engine.
To get this implemented, we had to convince not only the marketing team to buy into the benefits of adopting this new meta tag, but also the technical team to undertake a major technical implementation impacting every page on the website, which required the creation of new logic in an already complex environment.
Forecasting its impact on organic channel performance definitely helped, as did illustrating the positive impact on user experience through landing customers at their desired destination.
2. Translation and keyword research
Where to start with translation can be a very daunting task. Starting with which languages you'd like to translate your content into is certainly a good place to start.
If it’s not already obvious which languages you need to serve your customer base, then the answers likely lie within your analytics data and customer feedback. Dig into highly trafficked yet under-converting regions, or have a look at what localized languages your competitors have already implemented. We won’t dive any further into market opportunity analysis, and instead keep the focus on SEO.
At this stage, it would be advisable to loosely or firmly determine how much of your website you are planning to translate, whether it’s all of your website’s content or just certain webpages. We’ll dive into this more deeply in the information architecture section below.
Once you’ve determined the scope of your localization, finding a partner or software provider to help you with translation is a logical next step, if, of course, you don’t have the resources internally.
If you use Contentful, we offer a number of translation app integrations in our Marketplace to help you get started on your localization journey. Additionally, our AI Content Generator created by Contentful and powered by OpenAI can help you generate content elements or SEO metadata, but more importantly, can localize any content into nearly 100 languages. This can greatly help improve go-to-market time for scaling content and localization. Learn more about it here.
How to do keyword research in another language?
Now that you know what languages you’re tackling, it’s time to get translating. At this point, your in-house team or translation partner will begin translating your content.
It would be ideal to share your top performing organic keywords (hopefully you have this already) with this team or partner. If it’s a software solution you’re working with, many of these platforms offer functionality to input keywords. The goal of this exercise is to identify the primary keywords for each language, just as you have for your native language.
If you’re able, don’t simply take the software or partners' word for it. Ask for translation variations of each translated keyword. You can then take those variations and run them through Google Ads Keyword Planner (or your keyword research tool of choice) to determine the variation with the most significant search volume. Make sure to review these findings with your partner.
Some software solutions have the option to input these variations as default selections (I’ve seen it called a “glossary”), meaning that if this keyword ever comes up for translation, the predetermined variation will be selected. At scale, this is critical and can have a massive impact on organic search performance.
In practice: Translation and keyword research
When I began working with Nike, there were five languages globally: English, French, German, Italian, and Spanish. I had the privilege of overseeing the localization of the website into four new languages: Catalan, Dutch, Greek, and Polish.
As a native English speaker — and having studied French and Spanish — optimizing romance languages was not too daunting, but I won’t lie in saying that managing languages with an entirely unique alphabet other than your own is definitely challenging, as it was with Greek. However, with time, these alphabets and languages begin to become hugely familiar, even if you can’t pronounce them to save your life.
Here’s an example of why you shouldn’t automatically accept your partner’s translations:
Our partner had taken the English term “shoes” used throughout the US English localized property and translated it to “calzado,” which is the Spanish word for “footwear.”
“Zapatos” (“shoes”) would have been a much better choice with five times the monthly searches than “calzado” in Spain alone.
However, when we’re talking about athletic shoes, the most appropriate translation would be “zapatillas” (“sneakers”), which happens to have nine times the monthly searches in Spain.
After switching to “zapatillas” throughout the Spanish-language properties, we saw a significant improvement in organic search performance in Spain and throughout Latin America.
3. Information architecture
In the approach process outlined above, you likely determined roughly how much of your website you are planning to localize. It’s now time to firm that up to decide if you will translate all of your website’s content or just certain webpages. The latter can involve simply deploying a unique landing page in another language or translating a mix of your homepage and other key webpages.
Not translating your entire website may seem like a less daunting and simpler option, however, this approach can add its own level of complexity and challenges. For instance, if you decide to only localize your homepage and a few other pages, this will likely not cover all the items in your website’s navigation menu or even all the links within each of your chosen page’s content. How will you indicate to users that this content is not available in their language to avoid a poor and confusing user experience?
If you can’t translate all of your website due to budget or other restrictions, a simpler approach can be to batch your site into sections to be translated en masse, which will help improve logic decisions and user experience through micro consistency in each of these site sections.
If this is your first time deploying another language than what your website is currently in, decisions need to be made regarding the configuration of your website architecture. This includes an age-old question about using ccTLDs, subdomains, or subfolders (also called subdirectories) for each of your localized web properties.
Configuration | What it means | Pros for SEO | Cons for SEO | Recommended? |
|---|---|---|---|---|
ccTLDs | Using a “country code top-level domain” (ccTLD), e.g. exmple.de (de = Germany) | Good for ranking in a country/region, but more prohibitive when broadly targeting a language outside of ccTLD | No inherent connection to your native property, e.g., example.com, and thus no shared SEO benefit | No, this approach doesn’t support multilingual SEO at all and is prohibitive in sharing SEO equity |
Subdomains | Using a subdomain to indicate language or locale, e.g. de.example.com (de = German or Germany) | Slightly cleaner URLs than subdirectory, but that’s where the benefits end | Each subdomain typically treated as a unique web property from root domain and thus splits benefit | No, this approach is limiting in terms of sharing SEO equity |
Subfolders | Using a subfolder to indicate language and/or locale, e.g. example.com/de/ (de = German or Germany) | Consolidates any and all earned SEO equity at the root domain and is simple to include locale as needed | Once was slightly weaker at signaling to search engines until hreflang markup arrived | Yes, this is the gold standard in SEO as it consolidates equity and easily adaptable to any requirements |
Recommended URL structure
As illustrated above, the recommended multilingual SEO configuration for URL structure is to use subfolders. ccTLDs do not support broader language targeting well at all since they are focused on a country-centered domain.
Subdomains are often interchangeably used for language or locale, but less so used in conjunction, e.g., “fr-ca.example.com” for a French-Canadian website. Additionally, as with ccTLDs, SEO equity is not consolidated at the root domain as each ccTLD or subdomain are treated as unique web properties.
Subfolders consolidate SEO equity at the root domain and allow for greater flexibility when choosing to target language, locale, or both.
In practice: Information architecture
Nike’s decision to use a subfolder structure predates my time working with the company and has proven to be a long-standing good decision. However, when I first started working with them, they had an entirely Flash-based website, with an HTML version served to search engines. That’s another story.
During my tenure, Nike used a single subfolder to mark both language and locale:
English for Canada: nike.com/en-ca/example-page
French for Canada: nike.com/fr-ca/example-page
French for France: nike.com/fr-fr/example-page
They’ve since simplified the approach, perhaps to clean up unnecessary concatenation:
English for Canada: nike.com/ca/example-page
French for Canada: nike.com/ca/fr/example-page
French for France: nike.com/fr/example-page
It definitely is cleaner, and I like it, but there are some pitfalls. Since English is the primary language in Canada, they have gone with locale only for Canadian English, and locale + language for French Canadian, which might bother our French Canadian friends relegating them with an additional subfolder.
Additionally, this is most certainly a country-led approach in terms of information architecture, which isn’t a great fit for those with a language-led approach, as would be the case with multilingual SEO. Nothing wrong with that, of course, just depends on the needs and requirements for your business.
4. Multilingual markup
It’s now time to talk about code, and more specifically how we can use markup to signal to search engines what localized search engine they should serve your localized content in.
You want your German language page, for example, to be returned for German language searches in Google.com, as well as Google.at (Austria), Google.be (Belgium), Google.de (Germany), Google.lu (Luxembourg), and Google.ch (Switzerland).
There are two markup elements to assist with this: the “HTML lang” attribute and “hreflang” markup. The former should always be used regardless of localized variations of any URL, whereas hreflang is not needed until you localize. Both require one language code (in ISO 639-1 format) and optionally a region code (in ISO 3166-1 Alpha 2 format):
For example, if your site is in English and you only have one variation of your site, then you would simply use en for your language declaration. Note this language declaration is always spelled out in lowercase letters.
Alternatively, if you have variations of your site in both UK English and U.S. English, then you would use the respective language (lowercase) and region (uppercase) codes, separated by a hyphen, e.g. en-GB for British English and en-US for American English.
Okay, so this will help search engines know what language my page is?
Not exactly. Google has stated that it does not use the HTML lang attribute or hreflang markup to determine the language of the page. Instead, it uses its algorithm to make that determination. While that might be the case, utilizing both of these elements helps them match the correct content to the localized search engine, and ensures websites manage and mitigate duplicate content risk.
What is the “HTML lang” attribute?
The HTML lang attribute declares the language and optional region for the page. For instance, an English-language only example would be <html lang="en">, whereas a language and locale example for UK English would be: <html lang="en-GB">.
What is hreflang markup?
The hreflang link attribute is a HTML meta element designed by Google that’s used to specify the language of a webpage to search engines. It can also optionally specify the geographical targeting along with the language, which is particularly useful for URL variations of the same language, e.g. UK English, American English, and Canadian English. The benefit of the markup is serving the correct localized content to wherever users search.
“X-default” hreflang attribute
This attribute can be used to specify the preferred global language of your website to be served to markets where you don’t have a localized version of your website. For example, if you don’t have a localized version of your website to serve New Zealand, which version of your website should search engines serve in this geographical region? In this case you would likely specify your global English version of your website be the “x-default” which would then be served in google.co.nz.
Let’s look at some hreflang examples:
hreflang language-only example
Example URLs:
Global English: https://www.example.com/example-page/
Global Spanish: https://www.example.com/es/página-de-ejemplo/
hreflang markup:
hreflang language-only example with x-default
Example URLs:
Global English: https://www.example.com/example-page/
Global Spanish: https://www.example.com/es/página-de-ejemplo/
hreflang markup:
hreflang language and locale example
Example URLs:
U.S. English: https://www.example.com/example-page/
UK English: https://www.example.com/en-gb/example-page/
Global Spanish: https://www.example.com/es/página-de-ejemplo/
hreflang markup:
hreflang language and locale example with x-default
Example URLs:
U.S. English: https://www.example.com/example-page/
UK English: https://www.example.com/en-gb/example-page/
Global Spanish: https://www.example.com/es/página-de-ejemplo/
Rest of world: https://www.example.com/example-page/
hreflang markup:
For more details about hreflang and how best to implement this in Contentful, be sure to see our international SEO guide.
What if I don’t bother with hreflang markup?
Failure to utilize hreflang can result in serious performance impact, including the following:
Duplicate content penalties from search engines,
Cannibalization, meaning your own content competes against itself in search results, and
Incorrect content served in the localized search engine, e.g., U.S. English content served in Google.co.uk (Google UK), when you have localized content for the target localized search engine.
In practice: Multilingual markup
If I recall correctly, the implementation of hreflang into the global property took nine months to plan, execute, and deploy. Nike has since switched to a dynamic script injection method of employing hreflang (see all methods of implementing hreflang in Google’s documentation), and as highlighted above, the original implementation managed to exceed expectations by dramatically cleaning up Nike's cross-contamination in search engines and significantly improving performance across EMEA and beyond.
Wrapping up
Faced with localization of your website can be daunting, especially when you’re deploying multiple languages, but hopefully these best practices have helped simplify the approach and make it seem less intimidating.
Multilingual SEO, being a language-led approach, is also a simpler approach than a country-led approach, allowing for greater flexibility and expansion over time. Just don’t forget to include multilingual markup in your approach, it was, after all, designed by Google.
For an in-depth walkthrough on maximizing your visibility in organic search with Contentful, see our SEO Guide.
