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.