SEO for Multilingual eCommerce Websites

During the last 5 years of doing SEO for eCommerce websites, I noticed that most store owners have a hard time with optimization for multiple languages. In this article I’ll try to explain some common misconceptions and tell you how to avoid 7 most common mistakes!

Let’s start with the most common misconception about multilingual SEO:

You need to translate your entire website into the targeted language!

OK, it’s true it might help, but that’s not really what makes you rank for a competitive keyword in another country. If translating your website was that important, how would you optimize for UK vs Australia vs USA?

The algorithm that decides what ranks in which language at Google is far more sophisticated than that. It takes into consideration a lot of factors including onsite elements such as rel=”alternate” hreflang=”x” implementation, internal cross-linking, having the right ccTLD, and external factors such as backlinks from relevant websites in the targeted market and more.

In some languages, you can often find things on Google ranking high in English instead of the language of the market in question. This happens because Google is trying to serve the most relevant result for the query and sometimes language is just not a factor searcher is concerned with at all.

7 deadly mistakes of multilingual eCommerce SEO:

1. Serving translations without changing the URL

I often encounter this on Magento based eCommerce websites (which is the most popular open source eCommerce platform in the world).

Let’s say your store has English and French translations. If your product URL is example.com/product-name-123.html, It can’t be the same for both English and French version. Change that URL key for French version into French translation of that product name. Same goes for your content pages.

2. Not having, or poorly implemented rel=”alternate” hreflang=”x”

Rel alternate is one of your most powerful weapons when it comes to technical multilingual SEO.

You can read more about rel alternate and how to implement it on this official Google’s page, but I’d like to address some implementation facts that are commonly overlooked:

Each page needs to have rel alternate reference to all translations including itself.

You need to reference the exact page you’re targeting, not the root of the language, meaning:

Good implementation: example.com/product-name-in-english.html rel alternate to example.de/product-name-in-german.html

Bad implementation: example.com/product-name-in-english.html rel alternate to example.de

3. Auto redirect based on IP / Accept Language headers or similar method

This is Google’s official advice regarding automatic redirects of users to the version of page in their language:

“Avoid automatic redirection based on the user’s perceived language. These redirections could prevent users (and search engines) from viewing all the versions of your site.” – Google

You might be wondering how come Google does automatic redirect when you visit google.com from some other country and then gives different advice? Well, Google often doesn’t follow its own advice so nothing strange here.

In case you decide to disregard this advice and go for automatic redirection anyway, Google introduced this new addition to the rel alternate – x-default hreflang – that you need to set in order for Google to determine which is your default language. Also note that Yandex, the largest Russian search engine also supports this new trick.

4. Mixing rel alternate and rel canonical

If you have properly implemented rel alternate, look at your rel canonical implementation as there might be some issues here as well.

Don’t use canonical to point translated versions of the website to your “default language”. Meaning:

Good implementation: example.de/product-name-in-german.html canonical points to example.de/product-name-in-german.html

Bad implementation: example.de/product-name-in-german.html canonical points to example.com/product-name-in-english.html

5. Noindexing or disallowing translated pages through robots.txt

Even if you didn’t implement all of these weapons you have at your disposal for multilingual SEO, Google says :

“There is generally no need to “hide” the duplicates by disallowing crawling in a robots.txt file or by using a “noindex” robots meta tag.” – Google

In case you did properly implement rel alternate, noindexing or disallowing a translated website would be like shooting yourself in the foot.

6. Not cross-linking the translation pages or cross-linking in a wrong way

Translation pages should be linked through internal hyperlinks, accessible both to users and search engines. People often represent those with country flags or use text link with name of the language instead.

Make sure you don’t link all the pages in one language to the homepages of other languages but to appropriate version of the URL in a different language instead, meaning:

Good implementation: example.com/product-name-in-english.html links to example.de/product-name-in-german.html

Bad implementation: example.com/product-name-in-english.html links to example.de

7. Country folder vs country subdomain

OK, this one might not be as deadly as previous six, but it’s a common decision you need to make. Should you have translation URLs in folders (example.com/de/) or subdomains (de.example.com).

In most cases it will make very little difference and you can go either way. There is one thing to consider, though. Do you have a separate mobile theme on a subdomain (mobile.example.com or m.example.com)? In case you do, it would make your life much easier in handling canonicals if you go with the folder language structure since it would be easy to have mobile versions for all languages and implement rel alternates and rel canonicals properly (mobile.example.com/de/, mobile.example.com/en/ etc.).

Do you have any other tips for multilingual eCommerce websites that you’d like to share in the comments below?