Expanding your site to more languages
Articles,  Blog

Expanding your site to more languages

Hi I’m Maile Ohye, and I work
at Google as a Developer Programs Tech Lead. In this video, our goal is to
help provide information to site owners hoping to keep
their site search engine friendly as they expand to new
languages or country-based language variations. We’ll begin by discussing some
of the potential search issues that are more common with
international sites. These are the scenarios that
you’ll hope to avoid during your global expansion. Next, we’ll discuss background
questions to share with your company before you expand your
site to a new language. Third, we’ll discuss two
common use cases of international expansion. Given these two examples, we’ll
explain how your site’s configuration can be more search
friendly using signals such as rel=”alternate”
hreflang. rel=”alternate” hreflang signals
that this page has relationship to an alternate
language version at the specified URL. Finally, we’ll wrap up
with best practices. Let’s begin with potential
search issues. I’d like to highlight three
potential issues that are more easily triggered as a webmaster
expands their site to new languages or
country-based language variations. In the first issue, imagine that
a searcher is in England on google.co.uk performing
a query for pretty items. The searcher might see search
results highlighting pretty items, including a .com URL. This seems like a fine result,
however, it becomes less relevant result if there exists
an equivalent .co.uk URL that’s tailored
for the UK user. Therefore, the first potential
issue is when search results omit a URL customized
for the user’s language when one existed. Another potential search issue
is when search results display two nearly identical URLs from
the same site, which may confuse users when only one
URL was more relevant. The third issue is when a site
owner expands their site to a new language or country-based
language variation, and search engines omit the new language
URL because they’re completely unaware that new pages
were created. These are the three potential
search issues that we’re hoping to prevent. Now that we understand some of
the issues that searchers, search engines, and site owners
face when working with international sites, let’s
discuss some of the important preparation questions before
embarking on global expansion of your site. Hopefully, these questions will
help set expectations for your business or within
your company. One. Is your entire company committed
to developing an experience tailored to users
of a different language or country-based language
variation? Global expansion doesn’t mean
just translate content and published new pages. It’s also about creating
a great experience for your new users. An experience tailored to their language, market, and culture. Second question. Is your team committed to not
just creating, but also reviewing and maintaining
content for the different users worldwide? It’s important to emphasize to
your coworkers that content creation alone isn’t sufficient
to build a solid international site. Your team will also need to
review the content to make sure it’s in the local user’s
language, and maintain the content over time so it
remains up to date. Last, is your team committed to
supporting customers, often post-sale, in a new country
or language? Even after you make a sale or
conversion, customers may want to email or call for support. Your company may need to support
personnel that speaks the new customers’ language,
understands their concerns, and is available during
their time zone. I mention this because one of
the most common questions I receive is something similar
to, we’re the number one ranking site in our country. Why aren’t we ranking as high
at our new target countries? It’s helpful to set proper expectations within your company. Global expansion can require
more dedication. Now let’s cover the two
main use cases for international sites. The first use case is when a
site has a regional variation of a single language. In this use case, on
www.example.com, the page is in American English
using US dollars. However, the site may have
a UK version of the page available at en-gb.example.com
On this UK version, the page uses is British English, and
the currency is in pounds rather than dollars. Again this is the use case of
the country-based language variations of the
same language. The second use case is what
a website expands internationally with full
translations of content. So the word car on one page is
coche on another page, and auto on yet another page. In this image, www.example.com
is written in English, while es.example.com is written
entirely in Spanish. These pages are fully
translated, so that my homepage becomes Mi
Pagina de Inicio. Hopefully, one or several of
these use cases will apply to the configuration on– or proposed– for your site. Given these use cases, how can
your international site be more search friendly? I’ll explain. In December of 2011, we
introduced support for rel=”alternate” hreflang as a
way for webmasters to specify the search engines, like Google,
how their global site is configured. By using rel=”alternate”
hreflang, you could signal to Google how you’ve expanded your
website to new languages or country-based language
variations. rel=”alternate” hreflang is
a signal, not a directive. And because it’s one of the
many signals used to serve users the most relevant results,
it’s possible that other inputs override the
rel=”alternate” hreflang specification. rel=”alternate” hreflang can be
listed in several places. Select only one option,
whichever is easiest for you. It can be placed in on-page
markup as a link attribute in the head of your document. rel=”alternate” hreflang can
also be included in the page’s link HTTP header. Another convenient way to
specify rel=”alternate” hreflang is in a Sitemap. The Sitemap will list all
language or country-based language alternates
for each URL. If your international expansion
spans across several sites, you can submit just one
Sitemap listing all alternates for each URL, as long as each of
the websites is verified in Google Webmaster Tools. Whether you specify
rel=”alternate” hreflang in on-page markup, HTTP headers,
or a Sitemap, you’ll include an hreflang value. This value can be a general
language, like en for English for all the English
users worldwide. Additionally, you could include
both language and country, such as en-GB, to
better target English speakers in the UK. If you choose to create a
country-based language variation, such as en-GB, we
recommend also having a general language version, like
en, to appeal to English speakers worldwide. What will happen in search
results if you don’t specify a general language, such
as en, and only include en-GB and en-US? What do English-speaking users
outside of those regions, say in Canada or Australia, see
in their search results? Or, what happens if you choose
not to specify rel=”alternate” hreflang at all? Well, in all of these cases,
will we’ll still do our best to find the most relevant
version of the page for the searcher, similar to our
behavior before supporting rel=”alternate” hreflang
in 2011. If you have a URL that doesn’t
consistently serve content in one language– perhaps it redirects to
different language pages based on the user’s IP, or it
dynamically serves different language content on the same
page, or it’s a page which only asks the user to select
their preferred homepage– then your hreflang value
can be x-default. x-default signals to search
engines that the URL’s language is broad, rather
than specific. An example where rel=”alternate”
x-default could be useful is in the
Google Play store. The Google Play page dynamically
serves content in different languages
on the same URL. The href values for
rel=”alternate” hreflang should specify canonical URLs. And in fact, to be most
efficient, they only need to be included on the canonical
URL, not the duplicates. In other words, given English
version of a page http://example.c
om/en/page?item=1&ssid123, which is a duplicate URL with
a session ID, there doesn’t need to contain hreflang values
to the corresponding, say, German page. It only needs to specify the
rel=”canonical” URL. For example,
example.com/en/page?item=1. Then, on this canonical URL,
include rel=”alternate” hreflang to the canonical
German equivalent page, example.com/de/page?item=1. If this sounds too complicated,
just remember to include only canonical URLs
whenever specifying rel=”alternate” hreflang,
and you should be fine. When you implement
rel=”alternate” hreflang, all alternates of the URL, including
the URL itself, should be declared, whether
that’s with on-page markup, Sitemaps, or HTTP headers. The alternate language versions
can be on the same or different domains. They can be on different
subdirectories, subdomains, ccTLDs, or gTLDs. If you have the option, however,
we recommend keeping the alternate versions in a
similar URL structure as that it our crawling and indexing
heuristics. When using rel=”alternate”
hreflang, you can still use Webmaster Tools Geographic
target future for your verified subdomains or
subdirectories that you’d like to target to a particular
country. With the Geographic target
setting, be aware that you could only target a verified
site to one country. So if you want to target users
from two different regions, but you only have a general
language page, geotargeting in Webmaster Tools won’t
be possible. For instance if you want to
target Portuguese users and Portugal, and Portuguese users
in Brazil, but you only have a general pt language page, you
won’t want to configure Geographic target in
Webmaster Tools. With only a general PT
Portuguese version, rather than pt-PT and pt-BR, you’ll
limit your audience to only one of your two desired
locations. Another important detail about
rel=”alternate” hreflang is that while it’s supported by
Google, it may not be treated by other major search engines
in the same manner. Now let’s return to our
use cases, and how the rel=”alternate” hreflang
configuration can look on your site. In the case country-based
variations of the same language, both of the
corresponding URL are listed for each page. Again, all variations are
specified on each page, not just the alternates excluding
the current page. We require listing all
alternates because it demonstrates a more bona
fide association. It’s much harder for an outsider
to try and join as a different language version
of your site. For the use case of full
translations, such as www for English and es for Spanish,
again, each page will contain all alternates, including
itself. For the use case of full
translations with country-based language
variations, it’s just as you would expect. Each page lists all alternates,
including itself. Now that you understand
the configuration of rel=”alternate” hreflang, let’s
review the benefits. One benefit is that, when
implemented correctly, rel=”alternate” hreflang helps
search engines like Google to understand the relationship
between the pages on your site, so we can more accurately
crawl and index your pages. Another benefit of using this
markup is that helps search engines to discover new URLs
as you expand your site. For instance, one page may have
four alternates listed. If we’re only aware of three
alternates, then we’ll schedule the fourth
URL to be crawled. Once the page is crawled, it
can then be indexed and available in search results. The last benefit I’d like to
cover is that by using the signal of rel=”alternate”
hreflang, we can serve searchers a more targeted
URL in their results. By doing so, users are often
given a more tailored experience on your site. The final portion of this
video deals with best practices when expanding
your site. The first best practice is to
strive to create shareable URLs in your site
architecture. This means that each URL
consistently serves similar information in the same
language, regardless of the user’s IP or language
preference. This greatly assists indexing
by search engines. And by creating shareable URLs,
if a user bookmarks your page or promotes your site on
their blog, their audience, whether in the US or in Germany,
will see the content that they intended. When it comes to autoredirecting
users, while that can be done from an
x-default URL to a language or country-specific URL, we
discourage autoredirecting, say, based on IP, from one
language URL to a different language URL. This implementation could
prevent all language versions from being crawled. If you’d like to suggest a more
targeted page to users based on their IP or language
preference, a common implementation is to display
a banner suggesting an alternate page. Another best practice is to
avoid placing language or country in a URL parameter. This is because URL parameters
are less consistent in behavior than domains
or directories. URL parameters are
often overloaded. The parameter may have started
as a placeholder for language. The parameter later incorporated
tracking or session IDs. When expanding your site to
include additional languages, it’s more search friendly to use
different ccTLDs, domains, subdirectories, or subdomains. This isn’t a requirement. But by keeping a more consistent
URL structure between languages, you help
our heuristics to more efficiently crawl and
index your site. Anywhere else, UTF-8 is our
recommendation for non-ASCII characters in the URL path,
file name or parameters. From a business development
standpoint, look to develop customers, fans, advocates,
and gain a following from users in your new language. I state this as a best practice
because I’m commonly asked, should I put effort in
getting links in the language or country where my
site is expanding? The higher level answer is that
you’ll want to do the same beneficial, above the board
business practices in your new language as
you executed in your original language. In general, building excitement
about your site, such as referrals and reviews
from happy existing customers, helps build awareness to new
potential customers. Another best practice is paying
attention to page speed, especially if your new
language pages are serving users from a greater
network distance. For example, if your servers are
located in Australia, but you hope to serve English users
in the United States, check that your American
users aren’t experiencing unwanted delays. Speaking of users in different
locations, strive to empower the individual user to find
their preferred language. Users often appreciate the
ability to switch a page to their language of choice, rather
than be locked into the language of their IP. The last best practice is referencing available resources. We have several articles
that may be of help. Working with multilingual sites,
multiregional sites, rel=”alternate” hreflang,
rel=”alternate” hreflang=”x-default”. And of course, you can also
be questions for fellow webmasters expanding their
site, or even post your question in the
internationalization section of the Webmaster discussion
forum. Thanks for your time and effort
in expanding your site to be search engine friendly. We wish you the best of luck as
you embark on new languages or country-based language
variations. Thanks for watching.


  • Ardit Caushllari

    Is there a list of the proper naming for sub directories/domains?
    For example which would be suitable for a Albanian version of the website:
    1: example.com/al/
    2: example.com/sq/ (which is Shqip, Albanian in Albanian 😛 )

  • Christopher Semturs

    hreflang annotations work cross-domain, and a cross-domain signal is valuable. Bear in mind that it needs to be in the sitemaps for all domains involved (e.g. google.com vs. google.com.au vs. google.ch, …).
    The primary URL on the sitemap does need to be a verified one for the sitemap (E.g. sitemap linked from the robots.txt on the same domain). The others can be anything, they are only trusted if there's a link back from the other sitemap as well.

  • Komarovski

    Okay, and what about html5? If I'm using this (html lang="en") atribute for each language version of my website, do I still need to use tag (link ahreflang="en")?

  • Catfish Comstock

    Google doesn't recognize the lang attribute. you need to use href lang is you have multiple sites with the same languages in different regions that are on the same TLD. If you have different TLDs for each region then you shouldn't need to worry about it.

  • Catfish Comstock

    Check the middle of this page: support. google. com/ webmasters /answer/182192 ?hl=en&ref_topic=2370587 (had to separate it because Google's platform is too stupid to allow my to post links from their own support site to clarify the issue ( #FAIL )

  • Christopher Semturs

    I disagree. Especially across domains (e.g. a company in different countries, having a different TLD for each of them) this annotation as an added signal is quite valuable.

  • Ryan Fishkin

    Could I use a wildcard directive for the entire site if I wanted to geo-target two countries and languages. Say GB and EN so it could be example.co m/*-en-gb & example.co m/*en-us or do I need to set up a hreflang for each and every page on the site?

  • alvin linton

    I get the general idea although I am not an IT professional.How do I know if I need rel="alternate"hreflang on my page as a small businessperson?.

  • Alejandro Arbiza

    If you are targeting audience in more than one language; then you might benefit from this. If -on the other side- you offer content in only one language and you are not planning to expand to other languages, then you don't need it.

  • Christopher Semturs

    think about the markets relevant for you. Do a google search on that market (e.g. if you target english-speaking users in canada, go to Google Canada, switch to English and issue your search). If your foreign ranks higher than the canadian version of your page you might need hreflang.

  • Christopher Semturs

    hreflang is also useful for the scenario 'one language several regions' (e.g. en-ca vs. en-au vs. en-us vs. en-uk).

  • Patel Vidhu

    I have only English website. If your website is very big and millions of user from all around the world came to it every month then only you will need different version of website.

  • lovekeys

    Great bundle of answers 🙂 thanks!
    You could help me even more by integrating the further references in the description below or integrating clickable links into the video.

  • Gintare Stravinskaite

    Hi, I got multistore. CMS pages have different URLs, but products have the same global link, although content is slightly different. Do you have any suggestions how could I add href in such case? Thanks a lot!

  • Zuaibh Malik

    i keep getting this error in my webmaster tool international targetting its called no retun tags (for all languages) on all my languages basically i want all english speakers over the world to see my website can anyone help me please website is www. eliquidsnow. com

  • Ellie Wong

    This is for people who write html….boring…I have 1500 page sites for art and just use auto translate…

  • Matija Rupčić

    Does anyone know if we can have two "different" websites (blogs in this case) on one domain? for example, the blog covers same topics internationaly (english) and country/language specified but there is specific adaptation for country targeted users! i don't know how to explain but for example, you are going to advertise different products for the international users and different for this one particular country. is this even possible or is it better to just develop two different sites?

  • Cityfinances

    I have question. In which language my brand will appear? If I set-up hreflang in Latvian, but I am using brower in English, and I am searching my brand in Latvia.

  • Mitch P

    It does No Longer Wonder me, why Google is such a screwed up search engine.
    Uh, wait, it isn't an SE for a long time already, just a dictating business tyrant.
    Time for some other smart kids to come up with a SE, I mean "Search Engine".
    Screw you, Google!

  • mariocarnival

    Something is not clear. If you have a bunch of pages: home-en-us.html, home-en-ca.html, home-en-au.html, home-en-nz.html, home-en-gb.html… etc… and if all of them have link="alternate"… Google will choose one canonical URL from all of the, right? Yes, because the contents in all of them are 95% similar, just change little amount of words, right? Google read them as "same" content, for Google all of them are same. Is it like that? In your example you gave link="alternate" to all of the, why you didn't give ONE canonical to any of them?

  • Liayelau

    That makes sense for different language, but what about English US and GB? I thought that duplicate content was a big no no… If we have www.example.com and www.example.co.uk having the same content and add the proper hreflang on each page of each website, does it mean that Google would actually understand that the .co.uk site has been created for UK visitors and the .com for the US (and therefore "accept" that the content is duplicated?)

  • Paulo Godoy

    I use a ccTLD for my website and I want to use it as a gTLD.

    Will Google punish me for using a ccTLD instead of a gTLD (e.g. .com) for a multicountry AND multilang site?

    The URL structure I'm aiming for looks like this (examples):

    mysite.it/ca/en => Italian TLD, Region/Country Canada, Language English
    mysite.it/ca/fr => Italian TLD, Region/Country Canada, Language French
    mysite.it/de => Italian TLD, Region/Country Germany, Language German
    mysite.it/es => Italian TLD, Region/Country Spain, Language Spannish

Leave a Reply

Your email address will not be published. Required fields are marked *