Hreflang Tag Generator
Build correct hreflang tags for every language and region pairing — in HTML link, HTTP header, or XML sitemap format. With x-default handling and reciprocal-link checking baked in.
<link rel="alternate" hreflang="en-US" href="https://example.com/" />
<link rel="alternate" hreflang="fr-FR" href="https://example.com/fr/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/" />Reciprocal-link rule: drop the same set of hreflang tags into every page in this cluster — including each page's self-reference. If even one page is missing the cluster, Google will silently ignore the entire group.
What hreflang does (and why your international SEO is probably broken)
Hreflang is a small annotation that tells Google one specific thing: this page has equivalent versions in other languages or regions, and here is the URL for each one. When a user in Munich types your brand name into google.de, hreflang is what tells Google to serve the German page instead of the default English one. Without it, Google has to guess — and it guesses wrong more often than international SEO teams want to admit.
The mechanic is simple. Each page in a multilingual cluster declares every other page in the cluster (including itself) using a <link rel="alternate" hreflang="…"> tag. The hreflang value is an ISO 639-1 language code (like fr) optionally combined with an ISO 3166-1 region code (like fr-CA for French Canadian). Google reads the cluster, builds an internal map of which page serves which audience, and uses that map at query time.
The problem is that hreflang is one of the most consistently broken parts of technical SEO. Auditing client sites, we routinely find that somewhere between 60% and 70% of multilingual sites have at least one hreflang error — duplicate locales, broken reciprocal links, mismatched canonicals, invalid language codes, or hreflang pointing at noindex pages. Each of these failure modes causes Google to silently throw out the entire cluster and revert to guessing. Which means you spent six months translating content for a market that Google never serves correctly.
Real example. A SaaS company we worked with had a perfectly translated French Canadian site at /ca-fr/. They were ranking on page 5 in google.ca for their core terms. The English page was outranking the French one for French Canadian queries. The cause: the hreflang on the French page used fr_CA with an underscore instead of fr-CA with a hyphen. One character of typo, six months of lost organic traffic. That is why this generator exists — it removes the entire class of syntax errors that break international SEO.
The three places you can put hreflang
Same data, different delivery mechanism. Pick the one that matches your stack and scale.
Inside <head>
The default and most common option. Each page declares its locale siblings via <link rel="alternate" hreflang="…" href="…" /> tags inside the <head>. Easy to inspect via view-source, easy to debug, works on every CMS. The right choice for sites with up to ~30 locale variants per page.
Most websites under 50 locales
Link: response headers
Hreflang declared as HTTP Link headers on the server response. The only valid option for non-HTML files like PDFs, where you cannot embed a <link> tag. Configure via .htaccess, NGINX config, or your CDN. Often used by enterprise sites that serve downloadable assets in multiple languages.
PDFs, downloads, non-HTML files
xhtml:link in sitemap.xml
Hreflang declared inside your XML sitemap using xhtml:link entries. Centralises all hreflang data in one place, which is a sanity-saver for large sites with hundreds of locale variants per page. Avoids bloating your HTML. The format Google recommends for enterprise-scale international sites.
Sites with 100+ locales per page
Reciprocal links: the rule everyone breaks
Hreflang is a contract between pages. Every page in a language cluster must reference every other page in that cluster — including itself. Skip one reference and Google interprets the cluster as malformed and ignores the lot. There is no partial credit. No warnings in Search Console until traffic has already dropped. Just silent failure.
Walk through a three-locale example. You have an English page at example.com/, a French page at example.com/fr/, and a Spanish page at example.com/es/. The English page's <head> needs three hreflang tags: one pointing at itself (en), one at the French page (fr), and one at the Spanish page (es). The French page needs the same three tags. The Spanish page needs the same three tags.
On every page in the cluster:
<link rel="alternate" hreflang="en" href="https://example.com/" /> <link rel="alternate" hreflang="fr" href="https://example.com/fr/" /> <link rel="alternate" hreflang="es" href="https://example.com/es/" /> <link rel="alternate" hreflang="x-default" href="https://example.com/" />
Notice the self-reference. The English page declares hreflang for English pointing at itself. This is the line developers most often skip because it feels redundant. It is not. Without the self-reference, Google does not know which page in the cluster is the English version — it only sees that two other pages claim to know about an English version that does not declare itself. The cluster fails validation.
This is also why centralising hreflang in an XML sitemap or a shared component template is a good idea once you go beyond two locales. Hand-editing reciprocal hreflang on every page in a fifteen-locale cluster is how you end up with the cluster silently breaking the next time a developer ships a new market without updating the other fourteen pages.
Five hreflang mistakes that silently break your localization
Hreflang is unforgiving. A small typo or a structural mismatch causes Google to discard the entire cluster — and you only find out months later when the wrong locale keeps ranking. These are the issues we see on almost every client audit.
Wrong language code
The classic. Using uk for United Kingdom (that is the code for Ukrainian — you want en-GB), jp for Japan (it is ja-JP), or cn for Chinese (it is zh-CN). Hreflang uses ISO 639-1 for language and ISO 3166-1 alpha-2 for region — they are not always intuitive. One invalid value invalidates that one declaration; multiple invalid values can invalidate the cluster.
Region without language
Hreflang values like US or DE on their own are invalid. Region is always optional, language is always required. If you want to target US English specifically, the value is en-US, not just US. This generator blocks the invalid combination so you cannot ship it by accident.
Inconsistent canonical URLs across the cluster
Every URL in your hreflang tags must be the canonical URL of that page. If your French page canonicalises to example.com/fr/ but your hreflang on the English page points to example.com/fr/index.html, Google detects the contradiction and ignores the entry. Common on WordPress, Shopify, and any CMS that adds or strips trailing slashes inconsistently.
Self-reference missing on one of the pages
Every page must declare a hreflang tag pointing at itself. The English page needs hreflang="en" pointing at the English URL. This feels redundant — "why would a page declare itself?" — but without it the cluster fails validation. The self-reference is non-negotiable.
Hreflang on a noindex page
If one of the pages in your cluster has noindex, Google will not honour any hreflang pointing at it. Worse, if the noindex page is part of the cluster, Google may discard the whole cluster as inconsistent. This often happens when staging environments accidentally ship noindex to production, or when an old locale gets noindexed but its hreflang references stay in place. Audit periodically.
After you ship hreflang, validate it
Generation is the easy part. Verification is what saves the rollout.
Once your tags are live, run them through Google Search Console's International Targeting report — it will surface any cluster where Google is rejecting your hreflang and tell you why. Then spot-check three or four pages with a crawler like Screaming Frog or Sitebulb, both of which validate hreflang reciprocity automatically. Do not skip this step. The whole point of hreflang is correctness, and correctness can only be confirmed after the fact.
If you are operating across many markets and want a faster way to monitor international visibility — including which locales are actually being served by Google in each country — RankNow.ai's Rank Tracker supports per-country tracking out of the box. Pair it with hreflang done right and you can finally see whether Google is doing what you told it to.
Hreflang FAQ
Everything we get asked about hreflang, x-default, and international SEO targeting.
Contact SupportNo. Hreflang exists to disambiguate between multiple language or regional versions of the same content. If your site only ships in one language and you have no regional variants, hreflang adds noise and zero value. The lang attribute on your <html> tag is enough to declare the language. Hreflang only starts paying off the moment you have a second locale — even something as small as en-US plus en-GB.
They solve different problems. The lang attribute (e.g. <html lang="en-GB">) tells the browser, screen readers, and search engines what language the current page is written in — it describes the page itself. Hreflang tells search engines about other versions of the same page in different languages or regions. lang is page-level metadata; hreflang is a relationship between pages. You should use both: lang on every page, hreflang on pages with localised siblings.
Use plain en when you have one English version that serves every English-speaking market. Use en-US, en-GB, en-AU, etc. when you have separate pages per market — different pricing, different shipping, different spelling, different products. The wrong move is mixing the two: if you have an en page and an en-US page, Google has to guess which one wins for US searchers, and it usually picks the wrong one. Pick one strategy per language and stay consistent.
Yes — and you must, if the page targets multiple locales. A single English page that serves the US, Canada, and Australia should declare hreflang="en-US", hreflang="en-CA", and hreflang="en-AU" all pointing to itself, plus hreflang entries for every non-English locale variant. There is no upper limit. Large sites routinely ship pages with 30+ hreflang declarations covering every market they serve.
x-default tells search engines which page to show when none of the declared language or region versions matches the user. A French-Canadian visitor with no fr-CA version available will be served whatever you set as x-default. Most sites point x-default at their main English page or a language selector. It is technically optional, but Google strongly recommends it — without it, users in unsupported locales get unpredictable routing.
In our experience, the four most common reasons are: (1) the language code is invalid (e.g. uk for United Kingdom — that is the code for Ukrainian, you want en-GB), (2) the URLs in your hreflang tags 404, redirect, or return noindex, (3) the reciprocal links are missing — every page in the cluster must reference every other page including itself, and (4) you are mixing absolute and relative URLs. Use Google Search Console's International Targeting report to see which specific errors Google is throwing.
Yes — exactly. The URL in each hreflang declaration must be the canonical URL of that locale's page. If your fr-FR page canonicalises to https://example.com/fr/ but your hreflang points to https://example.com/fr/index.php, Google sees a contradiction and ignores the hreflang. Worse, if a page canonicalises to a different locale entirely (a common WordPress mistake), the entire cluster collapses. Audit canonicals and hreflang together — they have to agree.
Bing supports hreflang but historically relied more heavily on the meta language tag and the country in your Bing Webmaster Tools geotargeting settings. In practice, valid hreflang tags do not hurt Bing rankings and they help with Google, ChatGPT, and Perplexity (which all parse the same signals). Add them once and they work everywhere worth optimising for. Just do not skip Bing's geotargeting settings on top.
Neither is "better" — they serve different content types. HTML link tags are the standard for HTML pages and are easiest to debug because they show in view-source. HTTP Link headers are necessary for non-HTML files (PDFs, images, downloads) since you cannot put a <link> tag inside a PDF. XML sitemaps are best for very large sites with hundreds of locale variants where adding 50+ link tags to every page bloats your HTML. Pick the format that matches your file type and scale.
Other free tools you might like
See all 10 free toolsSchema Markup Generator
Generate valid JSON-LD structured data for Article, Product, FAQ, LocalBusiness, Recipe, Event, and Organization in seconds.
UTM Link Builder
Build clean, consistent UTM-tagged URLs one at a time or in bulk via CSV. Perfect for paid campaigns, email blasts, and referral attribution.
SERP Snippet Simulator
Preview exactly how your title tag and meta description appear in Google desktop and mobile SERPs — pixel-accurate truncation included.
Hreflang is sorted. Now find out where you actually rank in every country.
RankNow.ai's Rank Tracker monitors your keyword positions daily across countries, languages, and devices — so you know whether Google is serving the locale you told it to.
Try Rank Tracker Free