Multilingual Search Engine Optimization

ADMIN BLOG

Seb

Admin

BLOG INFO

Blog Date

June 5, 2024

Location

UK, Manchester

Follow us on

OTHER ARTICLES

Table of Contents

Multilingual Search Engine Optimization

Conquering the World, One Language at a Time

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.

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. 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.

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.

Identifying Your Multilingual Scope

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 strategy and configurations. Here are the questions you should be asking:

  1. What languages are you looking to translate your content into?
  2. How will the content be translated [and ultimately what influence can you have on the (key)word selection]?
  3. Are you wanting to translate all of your website’s content or just certain webpages?
  4. 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.

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:

Google UK search results for "Nike gifts" in 2013

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.

Translating Your Content

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.

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.

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 U.S. 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.

Deciding on Your 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

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.

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.

Implementing 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):

  • <html lang="en"> for English
  • <html lang="en-GB"> for British English

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.

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.

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:

Example 1:
URLs:
– Global English: https://www.example.com/example-page/
– Global Spanish: https://www.example.com/es/página-de-ejemplo/

hreflang markup:
html
<link rel="alternate" href="https://www.example.com/example-page/" hreflang="en" />
<link rel="alternate" href="https://www.example.com/es/página-de-ejemplo/" hreflang="es" />

Example 2:
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:
html
<link rel="alternate" href="https://www.example.com/example-page/" hreflang="en-US" />
<link rel="alternate" href="https://www.example.com/en-gb/example-page/" hreflang="en-GB" />
<link rel="alternate" href="https://www.example.com/es/página-de-ejemplo/" hreflang="es" />

Example 3:
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:
“`html <link rel=”alternate” href=”https://www.example.com/example-page/” hreflang

Copyright 2023 © MCRSEO.ORG