This post will provide an overview of the options available for website owners to signal to search engines their content is localized – not duplicated; answer common questions when attempting to convey a regional presence when search engines only recognize country differentiators; and provide a list of tools you can use to test your implementation of Hreflang-x annotations.
The domain name of your website plays a critical role when determining your international content strategy. When it comes to domain names, Google differentiates between two types:
- ccTLDs or country code top-level domains: These are tied to a specific country. Users and search engines use this as a strong signal that your website is explicitly geared to serve a certain country. Examples of ccTLDs are .de for Germany and .cn for China.
- gTLDs or generic top-level domains: These are not tied to a country and are meant to serve content that is relevant to all users. Examples of gTLDs are .com, .net, .org, and .museum.
If you need to create a multilingual presence, meaning your website will be translated into various languages relevant to a native speaker located anywhere in the world, your situation is much easier!
There are two different approaches you can take:
- subdirectory (example.com/es/) – Recommended
- subdomain (es.example.com)
We recommend the subdirectory approach because it houses content within the same root domain. When a new page is published it is believed its page authority is influenced by the authority of co-existing content already hosted on that domain. This can decrease the level of effort needed to signal to search engines its relevancy for your targeted search queries.
Do not append a country specification for translated content, unless you intend to serve a unique experience for people located only in that country.
When it comes to creating a multiregional presence, there are three approaches you can take:
- subdirectory (e.g. example.com/en-gb/) – Recommended in most cases
- subdomain (e.g. es-mx.example.com)
- country code top-level domain, ccTLD (e.g. example.de)
The approaches above are listed in order of the level of effort needed to optimize your content for search engines. The first option is recommended in most situations for the reason listed above.
Subdomains are believed to be weighted independently from one another. For example, wordpress.com publishes the content of its users on subdomains. The strength of one subdomain does not influence the likelihood of another user’s content ability to rank. With this in mind, it would take twice the effort to build authority for each language-country subdomain.
ccTLDs operate as independent websites. This means you need to build separate link profiles for these websites because the content published on one will not benefit from the content hosted on your other ccTLD.
If Business Is Located Within Country
An exception to the recommendation above would be if you have a physical presence in that country. In that case, it is best practice to use a ccTLD and localize your content for that country.
If No Physical Presence Within Country
If your company’s website is meant to serve a unique experience to people depending on where they are located in the world, but you have no physical location presence in that country, then you must carry out the appropriate technical SEO steps to signal to search engines your content is, in fact, geo-specific, even if it’s hosted on a generic top-level domain.
For example, localizing English for those located in the UK. You could accomplish this by housing the content in a subdirectory (www.example.com/en/ versus www.example.com/en-gb/), and make use of the hreflang-x annotation to signal one URL is relevant for anyone who speaks English, whereas the latter should be served only to those searching on google.co.uk.
Note: If you choose to go down this path and set up subfolders for language-country combinations (such as /en-gb/), you must tailor your content. For example, the content housed within /en-gb/ must use the GB spelling of “localise” rather than its American-English counterpart. If you do not have the resources to do that, don’t bother appending a country to your translated content. It is not providing any advantage and is intensifying the level of work you need to do to get your site to rank.
If your situation requires the use of a generic domain (gTLD), but you intend to serve content to users located in specific countries, you must incorporate Hreflang-x annotations either within your page’s source code or your site’s XML sitemap. Hreflang-x annotations signal to search engines which URL is the best one to serve based on the user’s language preference (specified by their browser) and their location.
In a study published by SEMRush (a leading competitive research service for online marketing) in February 2017, they found that of 20,000 websites analyzed 58% had an Hreflang conflict within the source code of the page.
These errors create a poor user experience by having the wrong webpage appear in search results. This means your prospect starts their journey on your website on a page less relevant to them, which may motivate them to immediately leave your site. Getting Hreflang-x annotations right is mission-critical.
Google advises the following:
You may have specific URLs for English speakers in the UK (en-gb), Canada (en-ca), and Australia (en-au), but want all other English speakers to see your generic English (en) page. You can annotate this cluster of pages using a Sitemap file or using HTML link tags coded like this:
<link rel=”alternate” href=”http://example.com/en-gb/” hreflang=”en-gb” />
<link rel=”alternate” href=”http://example.com/en-ca/” hreflang=”en-ca” />
<link rel=”alternate” href=”http://example.com/en-au/” hreflang=”en-au” />
<link rel=”alternate” href=”http://example.com/en/” hreflang=”en” />
It’s a good idea to provide a generic URL for geographically unspecified users if you have several alternate URLs targeted at users with the same language, but in different locales.
For language/country selectors or auto-redirecting homepages, you should add an annotation for the hreflang value “x-default” as well:
<link rel=”alternate” href=”http://example.com/” hreflang=”x-default” />
Specifying the Hreflang Link Element
You must adhere to the rules!
Search engines recognize ISO 639-1 format for the language, and optionally, the ISO 3166-1 Alpha 2 format for the country. The specified link element must start with a language, then country (if a country must be declared), be separated by a dash (not underscore) in the URL, and be either a subdirectory or subdomain (not a webpage, such as /en-gb.html).
You cannot geo-locate your content by a region!
Search engines do not serve URLs based on regions (for example, the European Union), so do NOT attempt to specify English content for Europe with /en-eu/ as it will be ignored.
Geo-Targeting Content within Google Search Console
Geo-targeting content is different than deploying Hreflang-x annotations on a website. As cited in this SEO Roundtable discussion with Google’s John Mueller, once a web property has been verified in Google’s Search Console the site owner can geo-target that subdirectory or subdomain to specify a country preference. This goes beyond Hreflang-x annotations as geo-targeting sections of content can result in Google promoting that localized webpage within their local version of Google search.
For example, geo-targeting www.example.com/en-gb/ to the UK will cause that content to take priority in google.co.uk over any other English page (say one located within www.example.com/en-au/).
Common Hreflang Annotation Mistakes
It is so important that the hreflang value you provide is actually valid. Per Google Webmasters Support documentation, these are the two most common mistakes you should keep an eye out for:
- Missing confirmation links: If page A links to page B, page B must link back to page A. If this is not the case for all pages that use hreflang annotations, those annotations may be ignored or not interpreted correctly.
- Incorrect language codes: Make sure that all language codes you use identify the language (in ISO 639-1 format) and optionally the region (in ISO 3166-1 Alpha 2 format) of an alternate URL. Specifying the region alone is not valid.
Test Your Hreflang-x Annotation Implementation
Once you have created the code to place within the <head> section of your web pages, ensure that there are no errors by running your domain through a scan via these popular testing tools:
Then verify your website in Google’s Search Console to monitor any errors that may be found. If errors are found you will receive an email like this:
When you view the error report within Google’s Search Console you can identify what is wrong:
The error report shown above was caused by not having Hreflang annotations on the Chinese, Korean and Japanese translated webpages point back to the other languages that referenced them.
Remember: If page A links to page B, page B must link back to page A.
For Hreflang-x Annotations Specified within the XML Sitemap
If you prefer to specify your Hreflang-x annotations within your XML sitemap, you can create this markup using the popular resource, The Media Flow.
Knowing how to localize a global website can be challenging. There are many factors that play into how one company versus another executes its content hierarchy. If you’re undergoing this at your company, contact us to discuss your situation and we can help outline your options.
Need some technical SEO support? Check out our capabilities for Search Engine Optimization.