Skip to main content

Hreflang Tag Generator

Generate hreflang link tags for multilingual websites with x-default support.

Reviewed by · Last reviewed

0
Total Tags

Using the Hreflang Tag Generator

  1. Add each language-region variant as a row - pick the language code (ISO 639-1, e.g. en, es, de), optionally pick a region (ISO 3166-1 alpha-2, e.g. US, GB, MX), and paste the absolute URL that serves that variant.
  2. Include the current page in the set - hreflang requires every page in a cluster to reference every other page including itself. Omitting the self-reference is the most common implementation bug.
  3. Add an x-default row - point it at your language-selector page, your English-fallback version, or the main landing page for users whose locale matches no listed variant.
  4. Copy the generated <link> block - the output contains one <link rel="alternate" hreflang="..." href="..."> per variant, ready to paste into <head>.
  5. Deploy the same block to every listed page - the en-US page must have the same full hreflang set as the es-MX page, with only the self-reference differing in hreflang code.

How Hreflang Works for Google and Yandex

Hreflang is a directive, not a hint. It tells a search engine: "these URLs are equivalent content translated or localized for these language-region combinations; show the right one to each user." Google\'s documentation at developers.google.com/search/docs/specialty/international/localized-versions describes three implementation methods - HTML <link rel="alternate"> in <head>, HTTP Link response header, or xhtml:link entries in XML sitemaps. This generator produces the HTML link method, which is the most common and works for any page type.

The language codes themselves follow IETF BCP 47, which is the composite of RFC 5646 (tag syntax) and RFC 4647 (matching algorithm). In practice, the subset you need is ISO 639-1 two-letter language codes, optionally suffixed with a hyphen and an ISO 3166-1 alpha-2 region code. Script codes (zh-Hant, zh-Hans) are valid and necessary for Chinese variants but rare elsewhere. Google ignores hreflang values it does not recognize and logs them as "unknown hreflang" errors in Search Console.

Where Hreflang Earns Its Keep

  • E-commerce sites with country-specific stores (prices, currencies, shipping rules) - ensures Google shows the UK user your GBP site, not the USD one.
  • Multi-regional English sites (en-US, en-GB, en-AU, en-CA) where content is substantively the same but localized for tax, compliance, or idiom.
  • Translated blog posts where the source English and the target German, French, Spanish versions all target the same query intent but for different audiences.
  • Localized landing pages for ad campaigns - without hreflang, Google can index the wrong variant and users from the wrong region land on irrelevant pricing.
  • Subdomains per country (us.example.com, mx.example.com) or subdirectories (example.com/us/, example.com/mx/) - both structures need hreflang to tell Google how they relate.

Hreflang Implementation Pitfalls

  • Missing return tags - if the en-US page lists es-MX but the es-MX page does not list en-US back, Google ignores the entire relationship. This is called a "return tag error" and shows up in Search Console\'s International Targeting report.
  • Wrong region codes - en-UK is invalid; the ISO 3166 code for the United Kingdom is GB, so en-GB is correct. Similarly, Latin America is not a region code - there is no es-LA; use specific country codes.
  • Pointing to redirecting or 404 URLs - hreflang requires the referenced URL to return 200. 301s, 302s, and 404s all break the cluster for that variant.
  • Mixing xml:lang or HTML lang with different hreflang - they should match. A page with <html lang="en"> and hreflang="es-MX" self-reference is inconsistent and confuses crawlers.
  • Forgetting x-default - without it, users whose locale matches nothing get arbitrary default selection. x-default gives you explicit control over the fallback.
  • Using hreflang for variants that are not actual translations - Google has stated that if two variants are essentially identical English with trivial differences (say, prices in GBP vs USD only), hreflang between them is fine; but if the content genuinely differs in substance, it should be separate pages, not hreflang variants.

Language Tag Syntax (BCP 47 in Practice)

BCP 47 tags have a structured grammar: language[-script][-region][-variant]. Language is a 2-3 letter ISO 639 code; script is a 4-letter ISO 15924 code (Latn, Cyrl, Hant, Hans); region is a 2-letter ISO 3166-1 alpha-2 code or a 3-digit UN M.49 code. For hreflang you rarely need the full grammar - the overwhelmingly common forms are plain language (en, fr, de), language-region (en-US, es-MX, pt-BR), and the Chinese script variants (zh-Hans, zh-Hant). Avoid over-specifying: en-Latn-US is technically valid but adds no information Google can use. The x-default value is literally the string x-default; it is a reserved BCP 47 value for "default fallback."

Alternatives to HTML Hreflang Tags

The XML sitemap method scales better for large sites - defining hreflang per URL via <xhtml:link> elements means no template surgery. The HTTP header method is the only option for non-HTML resources where you cannot add a <link> tag. For small sites, the HTML method is simplest; for enterprise multi-locale sites with thousands of URLs, sitemap is pragmatic. Search Console\'s International Targeting report is authoritative for verifying that your implementation parses correctly.

Frequently Asked Questions

What is the difference between hreflang and the HTML <code>lang</code> attribute?

They target different audiences. <code>&lt;html lang="en-US"&gt;</code> declares the language of the current page for browsers, screen readers, and translation tools - it is a page-level property. <code>&lt;link rel="alternate" hreflang="es-MX" href="..."&gt;</code> declares that a different URL serves the Spanish (Mexico) version of this page - it is a cluster-level signal to search engines. You need both: <code>lang</code> for the page itself, hreflang to tell Google about other variants.

Do I need hreflang for a single-language site?

No. Hreflang only matters when you have equivalent content in multiple languages or regional variants. A single English site does not need hreflang, even if visitors come from 50 countries. Adding hreflang with only one variant is a no-op (and will log a Search Console warning).

What is <code>x-default</code> and when should I use it?

<code>x-default</code> is the reserved BCP 47 value for "fallback when no other variant matches." Use it when users arrive from locales you do not specifically serve - typically your language-selector page, your English-fallback, or your main global landing page. Google explicitly recommends including <code>x-default</code> in any hreflang cluster; without it, fallback behaviour is undefined and Google picks arbitrarily.

Should I use country codes or just language codes?

Depends on what actually differs. If all English speakers see the same page, use plain <code>en</code>. If prices, shipping, or tax terms differ between the UK and the US, use <code>en-GB</code> and <code>en-US</code> separately. Mixing plain language with region-specific variants is valid: you can have <code>en</code>, <code>en-US</code>, and <code>en-GB</code> all in the same cluster, with region-specific variants preferred when the user's region matches.

Why do return-tag errors matter?

Because Google uses hreflang as a bidirectional graph, not a one-way hint. If page A lists page B as its Spanish variant, page B must list page A as its English variant. Without the return tag, Google considers the relationship ambiguous and often drops hreflang processing for the entire cluster - not just the broken edge. Search Console's International Targeting report lists every return-tag error; fix them systematically, not one-off.

Can I use hreflang with subdomains vs subdirectories?

Yes, with either. Google supports all three international URL structures: country code TLDs (<code>example.de</code>), subdomains (<code>de.example.com</code>), and subdirectories (<code>example.com/de/</code>). Hreflang works identically across all three. The structure choice is about signal strength for other purposes (ccTLDs carry stronger country signals) rather than hreflang compatibility.

Do I need hreflang if I already use <code>geo-targeting</code> in Search Console?

Yes, they complement each other. Search Console's geo-targeting setting tells Google a specific property is aimed at one country, which is a weak global signal. Hreflang is a per-page, per-variant signal that links specific URLs to specific locales. Geo-targeting without hreflang risks Google confusing your <code>en-US</code> and <code>en-GB</code> variants; hreflang without geo-targeting works fine but misses a chance to reinforce the signal.

Does hreflang pass PageRank between variants?

No. Hreflang is purely a relevance-to-locale signal; it does not consolidate link equity the way <code>canonical</code> does. Each variant is ranked independently on its own links and signals. For consolidation within a cluster (say, if one English variant has all the backlinks and you want the regional variants to benefit), you need a different approach entirely - typically a canonical pointing at the master, which cancels the hreflang's indexing of the variants.

How do I test hreflang is working?

Three checks: Search Console's International Targeting report lists parse errors and return-tag issues; manually search from a VPN in the target country with a logged-out profile; use Merkle's hreflang tester or Sitebulb's international report to verify cluster symmetry. No one-shot check is definitive.

Does the generator upload my URLs?

No. The tool builds the <code>&lt;link&gt;</code> tags from your inputs using a pure JavaScript template function and renders the output string in a textarea. There is no <code>fetch</code>, no analytics on your URL content, and no server involvement. You can deploy the output and the tool has no further knowledge of your site.

Can I use hreflang alongside <code>canonical</code>?

Yes, carefully. Best practice: on each variant, <code>canonical</code> points to itself (self-canonical) and hreflang enumerates the cluster. Do NOT canonical all variants to a single master - that tells Google to drop the variants from the index entirely, defeating the hreflang. Canonical consolidates duplicates, hreflang distinguishes equivalents.

More SEO & Web Tools