I18n SEO Localization


#1

I use tap:i18n for translation.
Is there a best practice to tell google about my different language localizations.
Do I have to manually add hreflang headers?


#2

Neither tap:i18n nor the other localization packages on atmosphere provide any means of seo helpers.

But they all provide some form of information to the app, about what locale they are currently delivering for.

So, you can take that information and update the necessary SEO oriented tags, analytics calls and the likes. Since meteor has basically a reactive frontend, everything will update in real time to reflect the app’s current state, as long as you don’t break reactivity.

Google, then, will index and cache your pages accordingly, provided, your routes contain locale information and your app does serve an offline version (with spiderable or something similar).


#3

So if I use localization in my Meteor app I have to use iron router and define all routes for each language (or use iron-router-i18n) ?

Is this the only way to do this ? I dont really like this approach :frowning:


#4

Well, you don’t need to have a router for internationalization, but if you want google to index your “pages” tagged by their relevant language, you have to have the language information set within the URL. That’s how google works and is not related to meteor or routing in general.

And the best way to let google know of the apps current language state through the url is to use a router. Iron router is an option. You can use any router or even basic html pushstate.


#5

How about using GET params to set a language session var to set the i18n language? Will Google recognize this form of language setting? Or Google wants it to be part of the domain name like en.domain.com?


#6

You can use url parameters no problem. Get paramaters are part of the url all the same. Google won’t care. So you can do any one of:

but

is a problem because that kind of subdomain usage is in reality a different domain and a different site for both google and meteor. Therefore you won’t really get much benefit from using an internationalization package there. And yes it would still be possible to use google’s language directives (meta tags) to instruct google that other language versions of your site are at different domains, but that is bad SEO anyway.


#7

I’ll just point out that a URL may be reduced to its canonical form by ignoring query parameters, so take that in account


#8

@serkandurusoy
Google suggest not to use URL parameters for country and region:

suggestions according to the same video:

I think I will go with:
www.example.com for the English version
www.example.com/de for the German version


#9

Well it is a matter of consistency and the video actually emphasizes that, meaning if you start out with url parameters but later on decide using url parameters for additional display options, it will then become a problem.

So my reply to the original question, within the context of the question that if url parameters would work, is valid.

But SEO is more of an artform than science and it certainly is better to use path information. And even better when coupled with language directives.

And in your case, perhaps you may even want to consider using domain/en format for your English version as well for a few reasons

  • consistency with other languages
  • easier to change default language down the road (I’ve seen this happen)
  • better url hinting of the language, not only for google, but also for the visitor

Of course, you should not forget to redirect from your root to /en and also update your root sitemap to point to separate language sitemaps.