WPML is the most popular plugin to make WordPress a multilingual CMS: hate it or love it, it still is the one of the few complete suites to translate any detail in your website, making a good job by itself, without the need of any third-party software as, for example, its cousin Polylang.
Sito.Express went multilingual a couple of months ago. Go multilingual is a delicate task, because there are many key factors you have to take into consideration. Which language to choose as default? Which permalink structure should you adopt? Should to translate all the content 1:1, or provide different contents according to each language preference? And so on.
In this broad scenario, plugin options is one of the most trivial aspects to double check with WPML (or Polylang), as it can deeply influence your website indexing on search engines: this can be either good or bad, according to the choices you made. Wrong settings? Bad SEO!
WPML Browser Language Redirect: a blind feature that does not keep an eye on user experience (UX) and SEO
The Browser Language Redirect function in WPML seems to be a useful function at a first sight, as it promises to redirect the user to the correct language, by checking the browser, when visiting our website. However, we discovered that this function is designed for a very specific and pretty rare use case, while messing a lot on our SEO. Let’s check how.
When we promote our website using printed media (newspaper, flyer, business card, a banner in a fair…) we’d likely promote just the domain name, right? “Come and visit Sito.Express!”. Isn’t it that obvious? Yes indeed!
We’d not even think about using the language in this kind of promotional material, ever: no one would write /it/ or /en/ on the business card! No one!
This is why many of you keep the Browser Language Redirect function enabled on WPML. This function is in WPML > Languages: let’s see how it looks like.
Keeping the Browser Language Redirect disabled means that a user visiting the main domain would just be redirected to the default language, with no additional checks. In our case (to be honest, in most cases) the default language is English: our italian users, aka the vast majority, needs to change the language manually after visiting the main domain. That’s one more click. That’s (sometimes) bad!
While the Browser Language Redirect might prevent this situation, it just messes up you website indexing, dramatically damaging all your SEO work in few weeks! Now, that’s what I’d call a deal breaker.
The Browser Language Redirect function is thought to always redirect the user. It ain’t smart.
Take this use case: an english guy is reading a post he’s found after googling around. The post is interesting so he decides to share it on WhatsApp (or Facebook, same) with a friend of his who’s italian. The italian guy now clicks the link from his PC: that’s where the Browser Language Redirect takes action, redirecting the italian guy to the italian version of the post, if it’s there. Cool, hu?
This logic is not total nonsense. Hower, in our (quite long?) experience we’ve seen this function used just to redirect the user when visiting the main domain. As for other entry points, this redirect does more harm than good: if we’re googling, Google will choose the right language for us. If we have an english friend, well… there’s a high chance we understand english well enough too.
So, going back to work, the actual drama is that BLR is like dinamite to your SEO!
WPML Browser Language Redirect: a canonical nightmare
When we activate the Browser Language Redirect function in WPML, the developers embedded a warning themselves: they knew that browser language redirect may affect your site indexing! However, the linked post doesn’t sound that alarming. There’s no explanation about how it affects your site indexing, and it just tells us we may face some issues with redirects, and that in any case it’s better to do nothing because telling Google not to follow those redirects would be even worse.
Well, being more specific, this is what will happen:
Google detects the Canonical of any default language URL as the canonical of any corresponding other language URL, causing all non-default language URLs to be marked as duplicated content.Sito.Express
That’s it. Evil, literally speaking
How come all non-default language links become duplicates?
We noticed this issue by looking the coverage report in Google Search Console. After going multilingual with WPML, we needed just few days to see some content being flagged as “Submitted URL not selected as canonical”.
This is what Google Bot saw on any “duplicated” link:
That’s the only possible explanation, because WPML devs say their plugin does not mess with canonicals, and that’s confirmed by our DOM: the only weird thing is that Google Bot doesn’t say anything about the redirect, which would likely allow website owners to detect the issue quicker.
Then, we disabled the Browser Language Redirect. Surprise! No more errors in Google Search Console.
So, is it possible to redirect the users visiting the main domain to their language?
After discovering how exactly the Browser Language Redirect damages your SEO, there’s still a problem to solve: many people will visit your website by typing the main domain themselves. How can we redirect them to the proper language?
We’re currently working on a possible solution that we’ll share with you soon! 😉
4 thoughts on “WPML Browser Language Redirect & Canonical: how to break all your SEO”
“We’re currently working on a possible solution that we’ll share with you soon!” – Did you come up with a good solution?
Hi Per, thanks for reaching us! I did find a solution, unfortunately I couldn’t find the time to write a post about it because of too much work. However, I think I’ll find an hour this week or the next to share the solution here!
could you point us in the right direction?
Hi Phillipp, sorry but it has been a really tough time and I still haven’t had a chance to restart writing posts here… hope things will clear up in March because I really like to share my experience.
Anyway, the possible solution would be to:
1. Set WPML to have all URLS with /language-slug/, even for the main language. In this way “mydomain.com” shouldn’t be present in sitemaps (Yoast, AIOSeo, others)
2. Tell WPML to show a static homepage (index.html or whatever) on the main domain and create the file within our main site directory
That’s pretty much it, I haven’t had any issue in GSC since then