The hreflang attribute is a piece of code that tells Google which language and region a specific page is meant for, so the right version shows up in the right country’s search results. If you have an English page for US shoppers and a French page for Quebec shoppers, hreflang is how you stop Google from showing the wrong one to the wrong person.
It sounds simple. In practice, hreflang is the single most miswired piece of technical SEO I see on international sites. The concept is friendly, the syntax is fussy, and the failure modes are silent. You don’t get a red error in Search Console when your hreflang is broken. You just slowly notice that French Canadians keep landing on your US English homepage, bouncing, and not coming back.
What hreflang actually does
Hreflang is a targeting signal, not a ranking signal. Think of it as a label you put on each version of a page that says, in effect, “this one is for English speakers in Canada,” “this one is for French speakers in Canada,” “this one is for English speakers in the United States.” Google reads those labels and uses them to decide which version to surface to which user in organic search.
The keyword is surface. Hreflang doesn’t redirect anyone. It doesn’t change what users see when they click a link. It influences which URL Google chooses to display in the SERP for a given query and a given user’s location and language settings.
It also doesn’t pass ranking signals between versions. Each language and region variant ranks independently in its own SERP. Your fr-ca page doesn’t inherit authority from your en-us page or vice versa.
The syntax
Hreflang values combine a language code with an optional region code. The language code uses ISO 639-1 (two letters, lowercase). The region code uses ISO 3166-1 Alpha 2 (two letters). They’re joined with a hyphen.
en, English, no specific regionen-us, English, United Statesen-ca, English, Canadaen-gb, English, United Kingdomfr, French, no specific regionfr-ca, French, Canadafr-fr, French, Francees-mx, Spanish, Mexicoes-es, Spanish, Spain
You cannot use region alone. us by itself is not a valid hreflang value. A region must always be paired with a language.
One value worth flagging: x-default. Use it on the version you want Google to show when no other hreflang value matches the user’s language or region.
Where to put it: three options
1. HTML head (link rel=”alternate”)
The most common approach. You add a <link> tag in the <head> of every page for every language and region version, including the page itself.
<link rel="alternate" hreflang="en-ca" href="https://example.com/en-ca/" /> <link rel="alternate" hreflang="fr-ca" href="https://example.com/fr-ca/" /> <link rel="alternate" hreflang="en-us" href="https://example.com/en-us/" /> <link rel="alternate" hreflang="x-default" href="https://example.com/" />
2. HTTP headers
For non-HTML resources like PDFs, you can’t put a link tag in a head section. Instead, you serve hreflang through the HTTP Link header. Most sites don’t need this.
3. XML sitemap
The cleanest option for large sites. Instead of editing every page, you declare hreflang relationships in one place: your XML sitemap. Each URL entry lists its alternates. For sites with more than a few hundred pages across multiple languages, this is what I default to.
The rule that breaks everyone: return tags
Hreflang is bidirectional. Every page that declares an alternate has to be declared as an alternate in return. If your English Canadian page says “the French Canadian version is at /fr-ca/,” then the French Canadian page must say “the English Canadian version is at /en-ca/.” Both directions. Always.
This is the most common hreflang error in the wild. If the return tag is missing, the entire annotation for that page pair gets ignored.
Self-referencing
Every page should list itself as one of its hreflang alternates. Your en-ca page should have an hreflang="en-ca" entry pointing to its own URL. This is required, not optional.
When you need hreflang
Three broad scenarios:
Multilingual sites. You have the same content translated into different languages.
Multi-regional sites. Same language, different regions. A US ecommerce store and a UK ecommerce store both in English, but with different prices, spelling, shipping policies.
Combined: multilingual and multi-regional. The most common real-world setup. A Canadian retailer might have en-ca, fr-ca, en-us, and es-mx versions.
When you don’t need hreflang
If your site is one language for one region, you don’t need hreflang. A Toronto plumber serving the GTA in English doesn’t need it. You also don’t need hreflang for trivial regional differences (“favourite” vs “favorite”).
The Canada situation
Canadian businesses serving both English and French audiences need en-ca and fr-ca, not just en and fr. If you use fr alone, you’re telling Google your French page is for all French speakers everywhere: France, Belgium, Switzerland, Quebec, Senegal, the lot.
Use fr-ca and you’re telling Google: this is specifically for French speakers in Canada. That’s almost always what you want.
Common pitfalls
| Pitfall | What’s wrong | Fix |
|---|---|---|
| Missing return tags | Page A points to page B, but page B doesn’t point back | Every page in the cluster lists every other page including itself |
| Wrong language codes | Using “uk” for the United Kingdom (uk is Ukrainian) | UK is en-gb. Check ISO 639-1 and ISO 3166-1 |
| No self-reference | Page lists alternates but doesn’t include itself | Add the hreflang entry pointing to the page’s own URL |
| Region without language | Using “us” or “ca” alone | Region codes need a language. Use “en-us” or “en-ca” |
| Hreflang to noindex/404 | Alternate URLs return 404 or have noindex tags | Alternates must be live, indexable URLs |
| Language mismatch with content | Page is declared “fr-ca” but the actual content is English | The declared language must match the page’s primary language |
| No x-default | Users outside your targeted languages see whichever version Google guesses | Add x-default pointing to your fallback page |
The “uk” vs “en-gb” mistake deserves its own callout. UK feels intuitive as a country code for the United Kingdom. It’s not. In ISO 639-1, “uk” is the Ukrainian language. The correct value for UK English is en-gb.
Tools to validate hreflang
- Screaming Frog. Crawl the site, look at the Hreflang tab. The single best tool for hreflang audits.
- Ahrefs Site Audit. Includes a hreflang report that catches the same classes of error.
- Semrush Site Audit. Similar coverage.
- Google Search Console. Surfaces hreflang issues through the Indexing reports.
- Manual spot checks. Pick a page, view source, confirm the return tag exists on each alternate.
WordPress implementation
For most WordPress sites, you should not be writing hreflang by hand. The major multilingual plugins handle it automatically:
- WPML. Generates hreflang tags automatically for every translated page.
- Polylang. Free for basic use, paid for advanced features.
- TranslatePress. Visual translation interface, also handles hreflang automatically.
- Weglot. Service-based translation that injects hreflang for you.
What you do need to check, even with a plugin: that translations are linked correctly inside the plugin’s admin, that x-default is configured, and that the actual output matches what you expect.
What hreflang is not
The HTML lang attribute
The lang attribute on the <html> tag declares the language of the page for browsers, screen readers, and accessibility tools. It’s not a Google targeting signal. Set it correctly for accessibility, and set hreflang separately for SEO.
Canonical tags
Canonical tags resolve duplicate content within the same language and region. Hreflang resolves which version to show across different languages and regions.
Each hreflang variant should canonicalize to itself, not across versions. A common mistake is canonicalizing all language versions to one master URL, which tells Google the other versions don’t matter and effectively erases them from indexing.
The user experience side
Hreflang doesn’t redirect users. If you want users redirected based on their location or browser language, you need separate logic for that. I recommend the banner approach: “Looks like you might prefer the French Canadian version. Switch?”
Auto-redirecting based on IP or browser language tends to break things, especially when users are travelling or using a VPN.
A practical rollout checklist
- Confirm you actually need hreflang.
- Pick your language and region codes. Confirm against ISO 639-1 and ISO 3166-1.
- Decide on implementation method (HTML head for small sites, XML sitemap for larger ones).
- Build the hreflang cluster for one page first. Verify return tags work.
- Roll it out site-wide using your CMS, plugin, or sitemap generator.
- Crawl with Screaming Frog. Fix every reported error.
- Submit the updated sitemap to Search Console.
- Spot check a handful of priority pages monthly.
Bottom line
Hreflang is unglamorous, fiddly, and important. The core rules are simple. Every page in a cluster references every other page including itself. Use language plus region codes from the right ISO standards. Implement consistently across every page. Don’t confuse it with HTML lang or canonical tags. Audit with Screaming Frog. Let a real plugin handle the work on WordPress.
If you’re running a Canadian business serving both official languages, get to en-ca and fr-ca specifically. Don’t settle for generic en and fr. The targeting precision is worth the small extra effort.
Done right, hreflang disappears into the background and your international traffic just works. Done wrong, you spend a year wondering where your French Canadian organic visitors went.