TL;DR: Hreflang tags tell Google which language or country version of a page to show to which searcher. Every version must list all the versions in the set, itself included, using full URLs and valid codes, and every page it points to must point back, or Google ignores the tags. Add them in the page head, in an HTTP header or in your XML sitemap (Google treats the three as equivalent, so one is enough), then check the finished set instead of assuming your platform or plugin got it right.
What Hreflang Tags Do
If you have the same page in more than one language, or in several regional versions of one language, hreflang tags tell Google how those pages relate. Google says it might find the alternate versions on its own, but that it is usually best to tell it explicitly, and hreflang is how you do that.
Google describes three situations where this applies: a page where only the navigation and footer are translated, small regional variations of similar content (English for the US, Great Britain and Ireland, say), and fully translated sites, such as German and English versions of every page. The aim is to get the right person to the right version, so the searcher in Germany lands on your German page, and the visitor in the US sees the page written for them.
It also matters when two versions are close to identical, such as UK and US English pages. Google says localised versions only count as duplicates when the main content stays untranslated, and that when it chooses between duplicate URLs it prefers ones that are part of an hreflang set. That makes hreflang worth having on regional pages with near-identical copy. A site with one language aimed at one country usually does not need it.
How a Hreflang Tag Is Built
Each version of a page carries a set of tags, one for every version including itself. This is a complete set for a page that exists in UK English, US English and German, with an international version of the page as the fallback for everyone else. The example.com addresses are placeholders, so swap in your own URLs before copying anything.
<link rel="alternate" hreflang="en-GB" href="https://www.example.com/uk/widgets/" /> <link rel="alternate" hreflang="en-US" href="https://www.example.com/us/widgets/" /> <link rel="alternate" hreflang="de" href="https://www.example.com/de/widgets/" /> <link rel="alternate" hreflang="x-default" href="https://www.example.com/widgets/" />
These four lines go inside the <head> of all four pages: the UK, US and German pages and the international fallback page. Each part of a line does one job:
- rel=”alternate” marks the link as another version of this page.
- hreflang says which language, or language and region, that version is for.
- href is the address of that version. It must be fully qualified, including https://. Google’s examples of what not to use are //example.com/foo and /foo.
The rules that make or break it
- List every version, including the page itself. Google says each language version must list itself as well as all the other versions.
- Link back. If two pages don’t both point to each other, Google says the tags will be ignored. When you add a new language, every existing page needs updating, not just the new one.
- Use real codes. The language is an ISO 639-1 code (en, de, fr) and the optional region is an ISO 3166-1 Alpha 2 code (GB, US, DE). A language on its own is fine, but a region on its own is not. Google does not support codes such as es-419, and says reserved codes like EU, UN and UK have no effect on Google Search, so use en-GB, not en-UK.
x-default
x-default is a reserved value for visitors whose language or region does not match any of your versions. Google recommends a fallback page and says x-default was designed for language selector pages, though you can use it on any page. It is a recommendation, not a requirement. Point it at a page that works for anyone, such as a language selector or your main international version.
Hreflang and Canonical Tags
Canonical tags and hreflang answer different questions. A canonical says which URL is the main one when the same content sits at several addresses. Hreflang says which version suits which audience. They need to agree. Google’s duplicate-URL guidance says to specify a canonical page in the same language, or the best possible substitute, so in practice each version should canonicalise to itself. If your French page’s canonical points at the English page, you are telling Google the English page is the one to keep while the hreflang set says the French page deserves its own place, and those signals conflict, so make each page’s canonical point to itself.
Three Ways to Add Hreflang
Google treats the HTML, HTTP header and XML sitemap methods as equivalent and says to use whichever is most convenient. Using more than one gives no benefit in Search, so pick one. A common approach is head tags for ordinary web pages, headers for files that have no HTML head (PDFs, for example) and a sitemap when you have a lot of pages or cannot easily edit the templates.
In the page head
This is the set shown above. It goes in the <head> of every page in the set.
In an HTTP header
A PDF has no head to put tags in, so the same information goes in the HTTP response header instead. Each of the three PDFs sends the identical header below (one line, wrapped here). It is set on the server, so it is normally a job for whoever manages your hosting.
Link: <https://www.example.com/downloads/brochure-uk.pdf>; rel="alternate"; hreflang="en-GB", <https://www.example.com/downloads/brochure-us.pdf>; rel="alternate"; hreflang="en-US", <https://www.example.com/downloads/brochure-de.pdf>; rel="alternate"; hreflang="de"
In an XML sitemap
In a sitemap, every URL gets its own entry listing every version, itself included. The file gets long, but it keeps hreflang out of your page templates. The xhtml namespace in the opening tag is needed for the xhtml:link lines. This is the same four-page set as above. If sitemaps are new to you, our guide explains what a sitemap is and how search engines use it.
<?xml version="1.0" encoding="UTF-8"?> <urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9" xmlns:xhtml="http://www.w3.org/1999/xhtml"> <url> <loc>https://www.example.com/uk/widgets/</loc> <xhtml:link rel="alternate" hreflang="en-GB" href="https://www.example.com/uk/widgets/" /> <xhtml:link rel="alternate" hreflang="en-US" href="https://www.example.com/us/widgets/" /> <xhtml:link rel="alternate" hreflang="de" href="https://www.example.com/de/widgets/" /> <xhtml:link rel="alternate" hreflang="x-default" href="https://www.example.com/widgets/" /> </url> <url> <loc>https://www.example.com/us/widgets/</loc> <xhtml:link rel="alternate" hreflang="en-GB" href="https://www.example.com/uk/widgets/" /> <xhtml:link rel="alternate" hreflang="en-US" href="https://www.example.com/us/widgets/" /> <xhtml:link rel="alternate" hreflang="de" href="https://www.example.com/de/widgets/" /> <xhtml:link rel="alternate" hreflang="x-default" href="https://www.example.com/widgets/" /> </url> <url> <loc>https://www.example.com/de/widgets/</loc> <xhtml:link rel="alternate" hreflang="en-GB" href="https://www.example.com/uk/widgets/" /> <xhtml:link rel="alternate" hreflang="en-US" href="https://www.example.com/us/widgets/" /> <xhtml:link rel="alternate" hreflang="de" href="https://www.example.com/de/widgets/" /> <xhtml:link rel="alternate" hreflang="x-default" href="https://www.example.com/widgets/" /> </url> <url> <loc>https://www.example.com/widgets/</loc> <xhtml:link rel="alternate" hreflang="en-GB" href="https://www.example.com/uk/widgets/" /> <xhtml:link rel="alternate" hreflang="en-US" href="https://www.example.com/us/widgets/" /> <xhtml:link rel="alternate" hreflang="de" href="https://www.example.com/de/widgets/" /> <xhtml:link rel="alternate" hreflang="x-default" href="https://www.example.com/widgets/" /> </url> </urlset>
Setting It Up on WordPress, Shopify and Wix
Platforms that handle multiple languages usually add the tags for you. That saves work, but automatic is not the same as correct, so check the output on a few pages using the steps further down.
WordPress. A multilingual plugin does the work here. Polylang says it adds hreflang tags to translated pages by default, builds the codes from each language’s WordPress locale, and adds x-default only to a homepage that redirects visitors automatically. Putting x-default on other pages needs a custom code snippet. Polylang does not say whether this applies to the free or the Pro version, so check the output on the one you run.
Wix. Wix says that, by default, it adds hreflang and x-default tags to the code of your multilingual pages when you use Wix Multilingual. Its help article does not describe a setting for changing them.
Shopify. Stores that use Shopify Markets get hreflang tags automatically, built from each market’s domain and language settings, as Shopify’s theme documentation explains. The setting is on by default, and Shopify’s changelog says you can switch it off under Online Store, then Preferences, in the Social sharing and SEO section. Its Markets SEO help page warns that turning it off can negatively affect your store’s SEO.
Shopify also advises against adding your own tags on top of the automatic ones, because that can create duplicate or conflicting annotations, so if an app or your theme already outputs hreflang, Shopify’s advice is to turn the automatic tags off so only one source remains. Its help page warns that switching them off without another implementation in place can hurt your store’s SEO. Markets that share one URL, with no language or region difference, get no alternate-version tags.
Subdomains, Subfolders or Country Domains
Hreflang works with any of the three. Google lists hreflang alongside country-code domains and server location as signals it uses to work out who a site is for, and says you should still tell it about every locale or language variation. Its own comparison does not pick a winner. A country domain (example.de) gives the clearest geotargeting but can be expensive and hard to get. A subdomain (de.example.com) is easy to set up and allows different server locations. A subfolder (example.com/de/) is easy to set up and low maintenance, but means one server location and makes it harder to separate sites. Google does not recommend URL parameters such as site.com?loc=de.
Choose on practical grounds: budget, who runs each site, hosting and how separate the markets need to be. Then apply hreflang the same way, whichever you pick.
Common Hreflang Mistakes
Most hreflang problems are one of these, and each can be spotted in page source or a testing tool.
| Mistake | What goes wrong | How to spot it |
|---|---|---|
| Missing return link | Google says that if two pages don’t both point to each other, the tags will be ignored. | View source on both pages. Each should list the other’s address. |
| Page doesn’t list itself | Google says each version must list itself as well as all the others. | Search the source for the page’s own address next to its own language code. |
| Relative URLs | Google requires fully qualified addresses, including https://. | Look for href values that start with / or //. |
| Wrong codes | A region on its own, unsupported codes such as es-419 and reserved codes such as UK are not recognised or have no effect. | Check each value reads language first, then region: en-GB, not en-UK or GB. |
| Canonical points at another language | The canonical tells Google to keep a different page from the one the hreflang set says to show. | Check each page’s canonical matches its own address. |
“The most common mistake isn’t incorrect hreflang. It’s no hreflang at all. On one multi-region retail site, the UK and French stores had no tags, only an empty hreflang sitemap that made the job look finished. The French site uses translated URLs, so the tags can’t be generated by matching page paths, and that is what’s holding up the fix.” – Kezia Humphries, SEO Account Manager
Top Tip
Pick one page from your set and open its page source. Search for hreflang and check five things in a couple of minutes: the page lists its own URL, every address starts with https://, any UK version is tagged en-GB and not en-UK, the x-default address is a page you want visitors to land on, and the pages it points to list this page in return. If the search finds nothing, check the HTML Google received using URL Inspection in Search Console before deciding the tags are missing.
Pick one page from your set and open its page source. Search for hreflang and check five things in a couple of minutes: the page lists its own URL, every address starts with https://, any UK version is tagged en-GB and not en-UK, the x-default address is a page you want visitors to land on, and the pages it points to list this page in return. If the search finds nothing, check the HTML Google received using URL Inspection in Search Console before deciding the tags are missing.
How to Check Your Hreflang Is Working
Search Console used to have an International Targeting report. Google has deprecated it, says it will keep supporting and using hreflang tags, and does not name a replacement report. So you check the markup itself:
- Look at the source. Check a few pages in each language, as in the Top Tip above.
- Run the set through a testing tool. Google lists the hreflang testing tool on TechnicalSEO.com, which says it can check tags in a page’s HTML, HTTP headers or XML sitemaps. Google notes that tools like it are not maintained or checked by Google. Aleyda Solis’s generator is useful for building tags from a list of URLs.
- See what Google received. In Search Console, URL Inspection shows the HTML Google returned for an indexed URL under View crawled page, and for the current version under Test live URL, then View tested page.
- Re-check after changes. Adding, removing or changing the address of any page changes the set, so every other page in it needs to match.
On a recent multi-region B2B training site, we copied the English pages into nine country subfolders, such as /en-gb/, /en-us/ and /en-au/, so each market had its own version. After launch, we crawled the site and checked every hreflang annotation. Each page had a complete set of reciprocal tags, including a self-referencing one, so the core setup was sound. The crawl flagged one issue: the global root page was tagged “en” instead of “x-default,” a default behaviour of the CMS. That leaves Google with less guidance on which version to show users outside the target regions. We logged it as a medium-priority fix for the client’s developers. – Kezia Humphries, SEO Account Manager
FAQs
Do I need hreflang if I sell in several countries in one language?
Possibly. Google lists small regional variations of similar content, such as English for the US, Great Britain and Ireland, as a case for it. If the pages differ in ways that matter to visitors, like prices, currency, delivery or spelling, hreflang tells Google they are deliberate variants. If the pages are identical, one page for all those countries is usually simpler.
Will hreflang improve my rankings?
Google describes hreflang as a way to tell it about your language and region versions so it can show the right one, and does not describe it as a ranking boost. Its job is to get the right version in front of the right searcher, which is a user experience and conversion matter as much as an SEO one.
Do I have to use x-default?
No. Google recommends a fallback page and designed x-default for language selector pages, but does not make it a requirement. It is most useful when visitors might arrive from places none of your versions cover.
How Wildcat Handles This
Hreflang is usually one part of a wider international set-up, and our international SEO service reflects that. It includes implementing hreflang tags alongside multilingual keyword research, content localisation and technical audits for each site or subdomain, and our technical SEO experts audit your website or websites and build a bespoke international strategy.
To get started, tell us what you need help with through our contact page, and we will arrange a free consultation. If you already have hreflang in place and are not sure it is working, mention that when you get in touch.
Jon Herdman
SEO Executive
