If you work with multilingual and/or multi-country sites, you can help Google to recognize their relevant audience though different configurations:
by having language/locale specific URLs, effectively localizing the Web content of each one of your versions to their targeted audience, allowing the crawling of all pages versions (avoiding automatic redirects), using ccTLDs or sub-directories or sub-domains in gTLDs that are geolocated to their relevant country (by using the Google Search Console “geolocation” feature), as well as by using hreflang statements.
Because of this, when doing SEO for many languages and/or countries it’s important to provide as many aligned signals through these configurations about your pages targeting as possible, among them hreflang annotations, to make it easier to Google to show your pages in their relevant search results to the right audience.
However, hreflang implementation can become complex when working with a high number of languages and countries, with enterprise level platforms that provide little flexibility to implement changes, or even in smaller environments but without much development support, that can end-up causing some common tagging issues that will later trigger errors,
There are already a few great hreflang guides such as the one of Yoast as well as references where many specialists have had the opportunity to contribute with their own experience, like the ContentKing one, in which I had the chance to participate.
However, to minimize errors in complex environments, it’s important to establish an hreflang implementation process that doesn’t only considers the required steps to just include them based on the selected implementation method to minimize errors, but the overall process steps, from the identification of those international versions to prioritize in the hreflang implementation to the development of best practices that should be continously followed.
I shared a summary of the process I usually follow in Twitter, however since this is not a trivial topic, here’s a complete overview of this hreflang implementation process:
1. Assess the languages and countries hreflang implementation scope
Start by identifying the scope of your hreflang implementation: Which of your languages and/or countries versions are you going to specify? Which of their pages have versions across more than one of them, that will need to be annotated?
Although in an international Web environment, when you target many languages and countries, you ideally want to specify all of your pages languages and alternatively, countries targeting -and if you can, you should do it-; sometimes you will need to prioritize their implementation due to resources and timing restrictions.
Besides only really needing to tag those pages that exist across more than one of the languages and/or countries that you target, if you need to prioritize start with those set of pages that are including content in the same language but targeting different countries, likely featuring very similar content that can made them rank for the same terms in non-relevant countries, eg: pages in English targeting Australia, the US and the UK.
You should also prioritize those pages that although might be in different languages, might end-up also easily ranking for the same or very similar queries, like those of branded searches, eg: the home pages across the US, Spain, France, Germany.
If you can’t start with all of these, you can also start prioritizing the minimum: those pages with international ranking issues, shown in non-relevant countries or languages search results, eg: Pages from the UK version that are ranking in the US search results when there are relevant pages alternatives for the US that should be ranked instead.
An easy way to identify if you’re already attracting organic search traffic and rankings from non-relevant countries -for which you already have other relevant Web versions that are properly translated and geolocated through the other configuration settings discussed above- is through the “countries” segment of the Google Search Console “Performance” report.
Check what’s the share of your Website rankings coming from countries that you’re already targeting with other Web versions, identifying the queries and content bringing those impressions and clicks per country.
If you’re already targeting those queries with relevant localized content placed in another Web version that is already targeting that country then it means that there are likely difficulties to identify their geolocation, and because of this, you should prioritize them in your hreflang implementation process.
Something similar can be also done by checking third-party ranking indexes like the ones ofSEMrush, Ahrefs and Sistrix, that will show the terms for which your different international Web versions are ranking across all the countries they support.
In some cases these might be non-relevant queries or terms that you’re not targeting and don’t want to target with the Web content that you have for those countries, however, in others you might identify that you’re already targeting some additional relevant terms with non-relevant Web versions.
This analysis will help you to identify those set of languages and countries pages that need to be prioritized to use hreflang based on the identified international misalignment they already suffer from in Google’s search results.
As a result it’s recommended to create a list with all of the URLs for the different languages and country versions that you want to specify with hreflang, making sure to also add their other countries and languages URLs alternates, as shown in the example below.
2. Choose the hreflang implementation method
After establishing the pages to specify with hreflang, you can then assess the best fitting hreflang implementation method following Google’s hreflang specification: whether by including hreflang through tags in the HTML head, by using XML sitemaps, or via the HTTP header.
Although Google will take into consideration any of these supported methods it’s recommended that you select the one you want to use based on your site and project requirements as well as restrictions and be consistent with it:
- Tags in the HTML head
It’s better to use this method in sites with a small number of languages and/or countries versions to tag, when using a platform that easily allows to add and edit the tags in the pages html head.
- XML sitemaps
XML sitemaps are usually the best method to use with bigger sites with many languages/countries versions which can end-up being too complex to specify in the HTML head, as doing it so would add too many extra lines of code, increasing the page size. This is also the best alternative whenever there’s no way to edit the HTML head to add the hreflang tags there.
- The HTTP header
It’s better to leave this method when specifying hreflang for non-HTML documents like PDFs, DOCs, etc. as it is easier to be overlooked and can be more difficult to validate.
3. Specify the hreflang code pattern
After deciding the best hreflang implementation method to use in your case, the next step is to avoid non-supported placements, tags, attributes or values, by having as a reference Google’s official specification, in order to annotate each one of the relevant pages versions with their language and alternatively, also country value while referring to their alternate versions for which their language and alternatively country value should be also specified, and which should specify back too, as shown below:
Start by obtaining the hreflang code “pattern” to be used, understanding the syntax to be followed and where it should go in each case based on the chosen method, if it should be placed in the HTML head or to be included in XML sitemaps.
Google formally uses the ISO 639-1 format for the hreflang language values and the ISO 3166-1 Alpha 2 for the regions, so it’s also important that you verify using these ISO specifications which are the values that you should use for each one of your targeted markets and include them as attributes as described in Google’s hreflang specification based on the selected implementation method.
Additionally, if you have a language or country version (or a “global”, generic one) that should be used as the “default” or fallback for non-specifically targeted countries or languages visitors, you can also use and specify these URLs with the “x-default” value, as described by Google here too.
To facilitate this task a while ago I created a free hreflang code generator tool that can be used to obtain the code patterns to use as an input or reference in your HTML and XML sitemaps implementations.
This will allow you to generate the relevant hreflang annotations, including the relevant values for each one of your URLs languages/countries versions and replace the URLs based on the page, as shown below, that can be used to coordinate their inclusion with the development team
On the other hand, if you have a big, complex Web structure with many international Web versions that are difficult to map then I’d recommend that you take a look at enterprise level hreflang generators such as the HREFlangbuilder.
4. Validate the hreflang implementation in a test environment before launch
As with any other SEO related execution, it’s recommended that hreflang annotations are first implemented in a test environment to crawl and validate them before their release.
You can use SEO crawlers like Deepcrawl, Sitebulb, Screaming Frog or Ryte, that include an international SEO section that includes hreflang validation, to crawl the relevant set of pages where the hreflang has been implemented (whether doing a site or XML sitemap crawl) to identify any potential errors, verifying the existence of the correct hreflang annotations in every relevant page, the inclusion of a return tag, the usage of the correct values for every page, etc.
5. Monitor and troubleshoot the hreflang implementation after launch
As soon as you launch the hreflang annotations, recrawl your site, making sure to include in the include all of the relevant pages of the different international versions where hreflang has been implemented, to identify and fix any potential change that might have happened during the release and could cause issues in the live site that you couldn’t have identified before. You can also validate individual set of pages with Merkle’s SEO hreflang tag testing tool or Sistrix’s hreflang validator, which are free.
After fixing any remaining issues you should start monitoring the hreflang implementation continuously through the Google Search Console International Targeting report to identify any remaining problems, as well as to quickly fix any new issue that might arise when publishing or changing the URLs of the site relevant languages and countries.
Hreflang errors shown in the international targeting “language” report are grouped by those found in pages belonging to the same languages/countries versions, -for example, the US in English pages or the Spain in Spanish pages with problems-, and then by type of error found in each language/country version -such as the “no return tags” when the URLs of an alternate page is not found, or “unknown language codes” when a non-supported value has been added-, showing first those with the highest number of issues. It’s then recommended to start the troubleshooting directly with those language/country versions showing directly the highest number of problems.
Additionally, to facilitate the source of the issues, when selecting each type of error identified in each language/country version, you’ll be able to see which are the affected pages, showing up to a 1,000 URLs, paired with their alternates URLs affected by the issues.
Because of this when implementing hreflang annotations through XML sitemaps it’s highly recommended to generate them following certain organization criteria that facilitates the identification of URLs in them, in case there are issues and a need to spot and change them. For example, following a hierarchical organization: by country, language, category, etc.
Something similar should be also done to identify any potential new languages and countries search results misalignment issues in Google’s Search Results via the Google Search Console Search Analytics or the new Performance report and ranking indexes like SEMrush, Sistrix or Ahrefs -that were shown above-.
The same can be also done by validating the language and country source of every international site through Google Analytics “Geo” Report, to verify that there’s no organic traffic coming from non-relevant ones, and if so, to identify which pages are attracting the traffic and if these pages have a relevant alternate, making sure that they are specified with the hreflang annotations.
6. Establish hreflang best practices guidelines to be followed whenever a new page is published
Last but not least, after launching the hreflang annotations, it’s critical to document all the steps that have been followed in the implementation process so they can serve as a reference and establish best practices based on them, to follow the specified steps and criteria whenever a page is eliminated, changed or published, considering aspects such as:
- Which international versions were included/excluded and why?
- Which pages of those international versions were included/excluded and why?
- Which implementation method was chosen and why?
- Which tools were selected to generate, test and monitor hreflang annotations and why?
- When and where the hreflang implementation should be tested before any release?
- Who should specify, implement, validate and approve any hreflang related work?
- How often hreflang annotations should be checked and who will be in charge to fix any new identified issue?
- etc.
By following this, or a similar process that considers every decision and action related to hreflang implementation and maintenance you’ll be able to have a cost-effective process that minimizes issues. I hope this one helps!