Are Google giving conflicting information about hreflang?
Posted by Luci Wood on October 30, 2017
A recent tweet by Google Webmasters, picked up by the ever-vigilant Barry Schwartz in a Search Engine Roundtable article, suggested that the hreflang attribute should not be implemented when the pages only include minor regional changes. In this instance – differences in the currency used across multiple English language speaking pages.
However, on Google’s own Webmaster website, the use of hreflang is recommended in the following scenario:
“Your content has small regional variations with similar content in a single language. For example, you might have English-language content targeted to the US, GB, and Ireland.”
As ever, Google’s information in this case seems to be fairly conflicting and somewhat confusing. As such, in this article we’re going to try and decipher what Google meant from this tweet, and provide some guidance on what you should do in a similar scenario.
Back up a minute – what exactly is hreflang?
Hreflang is a HTML markup that was introduced by Google back in 2011. Once added to the <head> of a webpage (or uploaded via an XML sitemap – recommended for larger/more complex websites), hreflang allows webmasters to tell Google that there is a relationship between unique or duplicated pages of content on their website that exist in different languages, or even the same language but targeted at different countries, such as the UK and Australia.
The HTML tags are displayed as such:
<link rel=”alternate” href=”http://example.com/uk/page” hreflang=”en-gb” />
<link rel=”alternate” href=”http://example.com/au/page” hreflang=”en-au” />
<link rel=”alternate” href=”http://example.com/ca/page” hreflang=”en-ca” />
These tags highlight that there are three pages of content – one in English and targeted at UK users, another English language page targeted at Australian users, and finally a third English language page, targeted at users in Canada.
These tags would need to be coded into all three URLs, thereby cross-referencing each other, in order to work effectively.
The country and languages used in hreflang tags need to use ISO 639-1 codes, and include the language code, followed by country code (e.g. en-au), in that order. However you can just target speakers of a certain language by leaving out the country code.
For example, <link rel=”alternate” href=”http://example.com/au/page” hreflang=”fr” /> would mean that the page would be displayed to anyone Google identifies as a French speaker, no matter what country they are in.
The X-default tag can also be used – this is effective if you have a primary version that you would select to surface in other countries around the world that perhaps don’t have their own customised versions.
For example, Australia and Canada may have their own versions of a webpage, but you might want the UK version to surface elsewhere around the world (e.g. in India). In this case you would use:
<link rel=”alternate” href=”http://example.com/uk/page” hreflang=”x-default”/>
<link rel=”alternate” href=”http://example.com/au/page” hreflang=”en-au” />
<link rel=”alternate” href=”http://example.com/ca/page” hreflang=”en-ca” />
So hreflang solves duplication issues?
Well, not quite. It’s important to emphasise that rather than seeing hreflang as a way to resolve duplicate content issues, it instead acts as a way to highlight the relationship between sets of pages for internationalisation purposes to Google.
This ensures that users in each country are presented with the correct version in the search engine results pages (SERPs).
Unlike the canonical tag, they also cannot be used to consolidate authority across the set of pages – links to a US version of a page do not necessarily count towards the equivalent UK version just because hreflang has been implemented.
This is one reason why keeping all content on one domain, and implementing a country sub-folder structure, rather than using country-specific domains (ccTLD’s) is recommended, particularly for lesser-known websites that haven’t built up a strong brand across the world.
Utilising subfolders means that authority is kept within one domain, and can be distributed to these international folders, provided the website has a strong internal linking structure flowing from the homepage.
So what’s the problem with currency variations?
Going back to the point made at the start of the article – one of the major differences between English speaking countries such as the UK, Canada and Australia, particularly on ecommerce websites, is the currency each of these uses. Therefore, it seems to make sense to have different versions for each country, and relate these various international versions together through the use of the hreflang.
However, Google’s latest tweet about the matter suggests that currency variations don’t require hreflang, and instead run the risk of being “folded” together. After all, the use of hreflang isn’t a directive to Google, only a signal which can be overruled if other, stronger signals are in play.
There definitely seems to have been confusion about this over time – for example, Deepcrawl’s guide to hreflang clearly states that using hreflang is suitable for regional variations in the same language, including currency.
Yoast.com’s hreflang guide also suggests the same, stating: “the difference on these pages might be as small as a change in prices and currency”.
Why might changing currency not be enough?
Whilst users in the UK, US, Canada and Australia may all speak English, the words they use to describe certain things can vary massively.
This means that it’s highly likely that, if you have a website which attracts users from all of these countries, you’ll want to have pages totally rewritten for each country’s dialect, in order to give them the best experience possible when browsing your website.
Looking again at Google’s tweet, the use of the word “identical” is prevalent here, as is their request to “make them (the pages) unique”.
“If they’re identical” to most, would signify that the pages need to be 100% exactly the same. The original tweeter asked what would happen if they were 90% the same. Different currencies on each = not identical pages. Perhaps this is a stock Google answer?
However without saying it explicitly, it seems that Google are also strongly “advising” that the original tweeter should ensure that his various English language websites are using the correct wording for each of his audiences in those countries in order to promote good user experience.
Ensure you are writing for users before coding for bots
It seems that Google’s tweet is another attempt in their ongoing commitment to reward websites that provide a good experience for users.
Here’s what we would suggest before considering implementing hreflang:
- Try to ensure that you provide some form of unique content across your country variations, even if it’s only wording in the local dialect
- Conduct keyword research for each country – some words will be searched for more often in certain countries
- If you are targeting two countries with the same language but different currencies, this should be OK provided you make other small tweaks to differentiate the content
- Monitor your International Targeting section in Google Search Console to ensure each variation is being discovered, and to monitor for any errors.
Hi Sean, Thanks for the insightful article. We’re currently facing a dilemma very similar to the one that the person who sent the tweet seems to be in. We have an international medical information website (think WebMD), ranking for both the US and the UK. At the moment, we’re just producing content catered for both countries. For example, our pages about specific medical treatments have a section for the US and a section for the UK (prices, best clinics, etc…). We know that ideally using the hreflangs would be ideal, as it would allow us to only have US-related content… Read more »
Hi Max
Thanks for your comment and I’m glad you found the article useful.
Your situation definitely sounds like the kind of thing we’d be able to help you with.
Please feel free to drop me an email directly at sean@Simon Schnieders.co.uk with more details and we can discuss further.
Sean