How to set up hreflang for multilingual SEO

Hreflang tells search engines which URL is the right localized version for a language or region. You add reciprocal link rel="alternate" hreflang="…" annotations (or the HTTP or sitemap equivalent) so Google can show the French pricing page to searchers in France and the English page elsewhere, without treating those URLs as duplicates. If you only have one language on one domain, skip hreflang and fix canonicals first.

This guide walks through when hreflang earns its maintenance cost, the three supported implementation paths, how x-default fits, the failures that silently break clusters, and how to verify a set before you add more markets. For canonicals and JSON-LD in the same layer of your stack, see SEO for developers.

When hreflang is worth the maintenance

Hreflang is not a default checkbox. It is a contract between every localized URL on your site. Google’s localized versions documentation assumes you already have separate URLs that serve different languages or regions on purpose.

You need hreflang when all of the following are true:

• Real localized URLs exist. Examples include /en/pricing, /fr/tarifs, and /de/preise, or country subdomains such as example.fr and example.de.
• Each URL should be indexed. The pages are translations or regional variants, not accidental duplicates of the same copy.
• Search should route users to the matching locale. You care which version appears in France versus Canada versus a generic English query.

You do not need hreflang when a single URL serves everyone, when only the currency changes on one page, or when you should collapse duplicates with a rel="canonical" instead. If crawl basics are still broken, start with why your site is not showing on Google and Orchory free SEO tools for a quick technical pass before you internationalize.

Practical rule: If two URLs would never both belong in the XML sitemap as separate indexable pages, hreflang is the wrong tool. Use a canonical.

Pick one implementation and keep it consistent

Google accepts hreflang in three places. Choose one primary method per cluster and mirror the same alternate list everywhere that cluster appears.

Language codes use ISO 639-1 (for example en, fr). Regional variants append ISO 3166-1 alpha-2 with a hyphen: en-GB, en-US, pt-BR. Invalid codes are a common reason entire clusters are ignored.

HTML link tags in the document head

The pattern Google documents is a complete alternate set on every member page, including a self-reference. For a three-locale pricing cluster:

<link rel="alternate" hreflang="en" href="https://example.com/en/pricing" />
<link rel="alternate" hreflang="fr-FR" href="https://example.com/fr/tarifs" />
<link rel="alternate" hreflang="de-DE" href="https://example.com/de/preise" />
<link rel="alternate" hreflang="x-default" href="https://example.com/en/pricing" />

On the French URL, repeat the same four lines with the same href values. The only difference is that the French page is the document you are viewing; it still lists itself with hreflang="fr-FR". Missing self-reference is one of the most frequent audit findings.

Keep hreflang URLs absolute, use HTTPS consistently, and point only to indexable 200 responses. If an alternate redirects or canonicalizes elsewhere, Google may drop the whole group.

Wire it once in the layout

In a Laravel, Next.js, or Astro layout, generate tags from a locale map rather than hand-editing each view. The map should list locale code, path, and whether the row is x-default. That matches how teams already centralize canonical tags, as described in the hreflang section of SEO for developers.

HTTP Link headers for non-HTML resources

When the localized asset is not HTML, send alternates as a Link header (RFC 8288). Example for a PDF brochure:

Link: <https://example.com/files/guide-en.pdf>; rel="alternate"; hreflang="en",
      <https://example.com/files/guide-fr.pdf>; rel="alternate"; hreflang="fr-FR"

Headers must still form a reciprocal cluster: each PDF response should list the same alternates. This path is rare for marketing sites but matters for developer docs shipped as PDFs or for API-driven downloads.

Hreflang in an XML sitemap

Sitemaps can carry hreflang with the XHTML namespace. Each URL entry lists itself and its alternates:

<url>
  <loc>https://example.com/en/pricing</loc>
  <xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/pricing"/>
  <xhtml:link rel="alternate" hreflang="fr-FR" href="https://example.com/fr/tarifs"/>
  <xhtml:link rel="alternate" hreflang="de-DE" href="https://example.com/de/preise"/>
  <xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/en/pricing"/>
</url>

Repeat parallel blocks for /fr/tarifs and /de/preise with identical alternate lists. Sitemap hreflang does not replace in-page tags unless you rely on it exclusively; if you also emit HTML tags, they must agree.

Generate sitemap rows from the same locale map as your templates so marketing and engineering cannot drift. That discipline is the same one you use when trimming a sitemap to canonical URLs only.

x-default and the fallback URL

hreflang="x-default" marks the URL Google should use when the user’s language or region does not match any other entry in the set. Typical choices:

• A global English page when localized homepages exist for major markets.
• A language-picker landing page that lets the user choose a locale.
• The primary market you optimize first, when other locales are secondary.

x-default is not a replacement for listing real locales. It is the safety net. Google’s guidance treats it as optional but recommended when you have a sensible fallback.

Common hreflang mistakes that break clusters

Most production hreflang bugs are boring and repeatable. Catch these before you translate another ten pages.

• Missing return tags. Page A lists B, but B omits A. Every URL in the cluster must reference every other URL, including itself.
• Broken alternates. An href returns 404, 500, or redirects through a chain to a different canonical. Fix the target before tagging it.
• Hreflang pointing at a non-canonical URL. The alternate target has a canonical pointing elsewhere, so Google treats it as the wrong page.
• Conflicting lang attributes. The HTML lang attribute on <html> should match the primary language of the content, and it should not contradict hreflang without a reason.
• Two URLs claiming the same hreflang value. Only one URL should own fr-FR for a given piece of content.
• Parameterized or session URLs in alternates. Use clean, canonical localized paths, not tracking IDs.
• Mixing implementation methods inside one cluster. HTML on some pages and sitemap-only on others invites mismatched lists.

Keyword cannibalization between locales is a separate problem: if two languages target unrelated intents, hreflang will not fix weak content. Read what keyword cannibalization is before you expand a cluster.

Verify hreflang before you scale locales

Treat verification like a small release checklist:

1. Crawl each URL in the cluster with curl or your crawler and confirm the full alternate set is present (HTML, header, or sitemap row).
2. HTTP 200 on every alternate, with no unintended noindex and a canonical that matches the hreflang URL.
3. Validate language codes against ISO lists; typos like en-UK instead of en-GB invalidate the tag.
4. Search Console URL Inspection on a sample from each locale after deploy; watch the “Google-selected canonical” and indexing state.
5. Internal links between localized versions help users and crawlers discover the cluster; see internal linking in HTML for crawlable anchors.

Re-run the checklist whenever you add a locale or change URL slugs. Hreflang debt compounds quickly when translations live in a CMS export nobody owns.

Cite-ready localized pages at scale

International SEO is not only tags. Each locale needs a page that answers the same buyer question in native phrasing, with claims you can support, stable URLs, and technical access for crawlers. Answer engines and AI Overviews pull from clear, well-structured pages the same way traditional search does, so a thin translation of English copy rarely earns citations in local markets.

Orchory maps page opportunities per site and hands your team structured prompts to ship cite-ready pages for each market you prioritize, with human review before anything goes live. If you want automation that still respects developer workflow, compare approaches in the auto SEO tool overview and request access from the homepage form when you are ready to scale beyond manual locale launches.

FAQs