Some SEO for multilingual Drupal sites

First of all, before any kind of SEO, what you need in the first place is high quality content in every language. The kind of content users want to see and people may link to because it is useful and it adds something valuable to the World. In the second place, your site must be optimized for the people that use it, not for search engines. Search engines like Google do a nice job of listing first the best content for users to read.

That said, there are some tips that may help your multilingual Drupal site, that is plenty of high quality content and optimized for users in the first place, work better with search engines and help people find it -provided it is what they're looking for-. Most of this is valid for Drupal, Wordpress or whatever CMS you use, but the tools I am talking about are Drupal specific, which are the ones I've been building for some years...

I am the author and main maintainer of Internationalization module which is the one powering almost every multilingual Drupal site out there.

Content, content, content... and translations.

Check the quality of your translations. Content may be well written in the main site language but very often translations are poor and sometimes, still worse, they use machine-translation (more about machine translations below).
The completion of your translations is also something to take into account. People often underestimate the work it will take to maintain the multilingual content up to date and as a result, translations of old content may get outdated or translations of new content may be missing.
You can use some helper module like Translation Overview to check the status and handle the workflow of your translations. A few custom built views may also do the job.
Also too often people invest a lot of time and work in using the right keywords and wording for content in the source language but then they think any quick translation of a carefully picked English word will do the job in other language. That's not exactly true, not to say it's completely stupid.

Check the status and quality of your translations.
And since this is the most important tip by far in this article, I'll say it again:
Check the status and quality of your translations.
Ok, once you've done that, here you are some other easier tips:

About machine translations

Machines are already better than humans at playing chess, yes, but really, not for translating human readable content (I hope we agree on that). Though some people may think that having machine-translated content is better than nothing, the problem is that doesn't really add value for anyone at all. You better link to the translation service's page providing a translation of your site. If users want a crappy machine translation they can get it by themselves and usually the browsers already offer that option.

If you don't believe me, please believe Google: "Use robots.txt to block search engines from crawling automatically translated pages on your site. Automated translations don’t always make sense and could be viewed as spam. More importantly, a poor or artificial-sounding translation can harm your site’s perception."

Do not provide machine-translated versions of your site.

Use consistent URLs for your multilingual content

As each content on the web must have a unique distinct URL to be discoverable and manageable by search engines, each language version must have a different URL too. Thus using session or browser language detection can harm both your search rankings and the user experience.
When users click a link from a search results page or shared through Facebook or Twitter, they expect to find the page and the content they searched for, or they were pointed at, not being redirected to a different page/content that may not contain exactly what they're looking for. Sure they are smart enough to click on the language icon if they wish to see that content translated.

Use only URL language detection method on your Drupal site.. The only exception may be using Browser language detection on the front page + redirection (not available by default on Drupal) but for that to work well with search engines and link sharing you must use then a language prefix for every language (Otherwise neither users nor search engines can link consistently to the same page)

Content translation vs Field translation

Though you may have some other reasons for using either content translation (Drupal core translation module) or field translation (Entity translation), the first one has a number of advantages when it comes to SEO:

  • It allows full workflow control on the status of each translation (and will work with all contributed workflow modules).
  • It will work seamlessly with most othr SEO modules that provide per node options, like Metatag, Page Title, etc...
  • It gives content editors full control on every node option for each language (paths, menus, etc...) which is obviously good if content editors can/want to make some SEO adjustments.

Use content translation (a different node for each language)

Images can be localized

Besides the fact that many images (containing texts, locale or cultural references) can be -therefore they should be- localized, using a different image for each translation will allow translating the file name, title, description, etc.. This is good for search at the expense, of course, of needing to upload some files twice. Nothing is really free, we are focusing on SEO here.
Syncronizing or reusing fields accross translations may be a convenience for content edition but too often it may be limiting for true multilingual search engine optimization. So I don't say you don't use it, just balance the pros and cons.

Use localized images when possible.

Enable hreflang attribute for pages

This attribute specifies the base language of the resource designated by href. Though the hreflang attribute is added as default by Drupal to all cross-language internal links on your site, it can also be used for "alternate page links" in he header. This will inform search engines where to find the translation version of the page and it will be lesss likely that they mark pages that are translations of each other but with very similar content as duplicates.
There's this tiny Internationalization SEO hreflang module that does exacly that and is hidden into this Internationalization contributions package. And then you'll get on the header section of your pages something like:

<link rel="alternate" href="http://example.com/" hreflang="en" />
<link rel="alternate" href="http://example.com/es" hreflang="es" />

Enable Internationalization SEO hreflang module.

Double check compatibility with other SEO modules

There are many other modules for SEO of Drupal sites, and what is good for single language sites is usually good for multilingual sites, only not all of them work well with multilingual content. So for each one of them you'll need to check whether they are doing their job well for every language and they don't do things like adding English keywords to translated versions of the page. About these just some quick tips:

  • Multilingual site maps: If using XML sitemap, enable the XML sitemap internationalization and create a different sitemap for every language.
  • Pathauto has a number of issues with multilingual sites and path alias may get the wrong language in some cases. It will need careful configuration and some tweaking.
  • (Again) When translating content (nodes), most other SEO modules have better compatibility with the content translation feature.

Check that other SEO modules work well with multilingual content, some of them need specific configuration.

Language redirection module

Having mixed interface and content language is a feature of Drupal multilingual modules in general. It is also very convenient for content editors or readers that see occassionally a page in a different language -maybe because they want to, maybe because it's not yet translated-. But on the other side it may create too many mixed language versions of your page that search engines may not like, so it makes sense to disable the feature for anonymous users.
This is exactly what Translation redirect module does. It is contained in the Internationalization package and you just need to enable it. Be warned it is not a usability module, it is a SEO module thus it will just work for anonymous users, which is exactly what search engines view of your site.

Enable Language redirect module.

Decide your default language

Which is your site's default language is an important decision that must be made at the very beginning. The default language of your site is also its primary language and it is the language for which your site will be slightly better optimized for search engines.

  • When using path prefixes, you can skip the path prefix for this language, that will produce URLs that are a bit shorter for that language. It will also render a bit faster, not needing to translate certain strings.
  • It is the language used as the "source translation" in most cases, so workflow tools will work better when your default language is also the most usual source language.

Changing it later is possible but that will cause a number of issues like needing to retranslate some custom strings that are assumed to be translated from the site's default language to other languages.
The idea is the default language for your site should match your primary or most important market. However note this is only for SEO, other considerations may be taken into account, like the preferred language of your content creators or site team in general.

Take your time to decide the default language of your site.

Multiple domains vs Language prefixes

Yes, domain names are used by search engines to determine search results. So you may get improvements in rankings for specific search terms and languages by using different -properly localized- domain names.
The good news is Drupal supports using a different domain for each language out-of-the-box, and all the language links are just resolved automatically. The bad news is that it may be not very good for your site branding and you will loose the ability for users to keep logged in accross domains.
However, if you want to use this option, consider also using the Domain module or even using completely different sites for each domain that may make more sense -or not- depending on your content workflow or whether you want content translations to be cross linked.

Using a localized domain name may have some advantages, but only in a few cases.

If you've read all this I hope you've got the right conclusion at the end. Just in case, it may be this one: If you want multilingual SEO, do not hire a SEO expert; hire good translators instead.

Thanks for reading anyway. I'd appreciate your comments. Gracias.

Comments

Jose,
Nice article. I think you really know your stuff. But, as the CEO of Volacci, a company that is known for its Drupal SEO expertise and also works with translators to provide International SEO, I think your final conclusion is unfairly prejudiced against good, quality digital marketing companies that are following good guidelines for translation and SEO.

I could summarize your article as "Content is King, no matter what language it's in" and in that we are on the same page.

Our process is something like this:

  1. SEO the English version.
  2. Work with a translator to research keywords and translate the content to the target language.
  3. Work with the translator (sometimes a different translator) to optimize it again in the target language.

From a technical standpoint, there is quite a bit more to it. For example, the domain name issue that you alluded to helps more in some geographies than other. To be sure, there are many additional steps - again technical ones - that we go through when starting a project.

Again, I think we're mostly on the same page. I'm a huge fan of the I18n modules that you maintain and really appreciate your work in the Drupal community.

Instead of "If you want multilingual SEO, do not hire a SEO expert; hire good translators instead." you might say, "If you want multilingual SEO, hire an SEO who has a track record of working with translators on international websites."

Perhaps it was just lost in translation?

Well, Ben, I agree you may need both, the SEO expert and the good translators. Actually the first advice of the SEO expert could be getting better translations sometimes :-)

Anyway I know multilingual SEO is a way harder issue than a few tips and tricks, like these ones, certainly harder than single-language SEO, and I admit I'm no expert on the matter, just happen to know the basics. That implications about the domain names are really interesting specially in this world of mobile and geo-located searches so if you wanted to share some interesting data about that I would link it from this piece too - I never use "nofollow" ;-)

But, you know, this is the kind of quick DIY SEO guide with some Drupal specific tips and all I want to do is emphasizing the need to get good translations, which is what people too often forgets about, so ok with your statements too, just allow mine as a "poetic license". Same as if someone says "Don't hire a web delvoper, just install Drupal"....
(Nope, there's no translation, there may be an English to Spanish one if I have time in the future though...).

Thanks for your comments. Good to know real Drupal SEO experts occasionally read my blog too. Nice module your "SEO Checklist" btw.

Jose

What about the method of localization? If it's a good one it will be easier to translate a website and thing about seo and metas. I recommend using a localization service as a professional method, more specifically https://poeditor.com. It will ease up the work a lot.

Grena

I think for the localization part we have other/better tools fully integrated with Drupal like https://localize.drupal.org or https://drupal.org/project/l10n_server

Jose

I wanted to have the hreflang attributes on my website. I've got the main content on my pages which is always English and then menu's in the sidebars etc. which are translated.

Following two of the Google blog posts, one for this exact situation (http://bit.ly/JPAdHe) which I think they generalised it out (http://bit.ly/1chuCoU), it looks like the ideal set-up was to have the hreflang attributes on every page.

Was there any reason for the if clause on the i18n_hreflang_i18n_translate_path function which means the module only runs on the front page?

function i18n_hreflang_i18n_translate_path($path) {
if ($path == '') {
}

Dominic

Nope, that code doesn't mean that, you should see the hreflang in most content pages (node, taxonomy, etc..) provided you have enabled the corresponding i18n modules (i18n_node, i18n_taxonomy, etc...)

Jose

Shoot now I'm totally lost. I couldn't get Hreflang to any pages (basic apart from the front without removing the

if ($path == '') {
}

on the hreflang translate path function. I've got the block, field, menu, string and multilingual content modules enabled.

Am I missing something really obvious? How else are the paths generated if they don't come from the translate_path function?

(Note: It's working fine for me, just trying to understand how it should work.)

Dominic
Jose

Hi there thanks for your tips, i still have a question, i use xmlsitemap in my multilingual site, i generated the sitemap.xml in different language in the same name and path is that a good way? please do tell me, thank you!~

frank

Hi José,

I just came to this post and found out it's very interesting. My question is, do you still recommend (SEO-wise) Content Translation module instead of Entity translation? It's been a while since you posted so I don't know if you have faced new projects in different ways…

I've just seen a recent video which recommends the other way around…

José Fernández

Yes, it is just more flexible and on top of that it is the core translation system, which means 100% of contrib SEO modules will work with it.

Jose

Ok, thanks for your time.

José Fernández

While there are still some issues with Entity Translation + SEO, I have found that things have come a *long* way in the last year. In 2014 and before, I certainly recommended core Content Translation instead of Entity Translation but now I'm finding that I can get Entity Translation to work (thanks to the community's efforts). There are still some patches that might be required (e.g. for xmlsitemap) but I've found Entity Translation to be sufficient for most sites I've encountered in the last ~6 months. The main issue I've seen has been with Field Collections though maybe there are some other key issues that I haven't seen since we weren't using a particular module. For our recent projects, we try Entity Translation first and only switch to Content Translation if there are important modules that don't play well with ET.

just found out about this, is it really influential for seo? so curious to try it, thank you.