What Is a Hreflang Tag?
A hreflang tag is an HTML attribute that tells search engines which language and regional version of a page to show users based on their language and location. It maps equivalent pages to language and country codes, so a searcher in Spain sees the Spanish page and one in Mexico sees the Mexican Spanish version. Hreflang prevents wrong-language results and reduces duplicate content problems across international or multilingual sites, and it must be reciprocal to work.
- Syntax
- <link rel="alternate" hreflang="es-mx" href="..."> in the head (Google Search Central)
- Code format
- ISO 639-1 language, optionally plus ISO 3166-1 Alpha-2 region (e.g. en-us) (Google Search Central)
- Must be reciprocal
- Every page in a set must link back to all others or Google ignores the tags (Google Search Central)
- x-default value
- hreflang="x-default" sets the fallback page for unmatched users (Google Search Central)
What does a hreflang tag do? #
A hreflang tag tells search engines that several pages are language or regional variants of the same content, and it specifies which variant to serve based on a user's language and location. When a site has, say, an English page for the United States and a Spanish page for Mexico, hreflang links them and labels each with its language and optional country, so Google can show the right one to the right searcher. Without it, a Spanish speaker might land on the English page or vice versa, and Google might treat near-identical language versions as duplicate content competing against each other. Hreflang solves both problems: it improves the user experience by matching language to audience and it clarifies that these pages are alternates rather than duplicates. For US local businesses this matters most when serving bilingual communities, and building it correctly is part of the international and multilingual work handled through /services/web-design, where the tagging structure must be planned before pages are published.
When does a local business actually need hreflang? #
Most single-location US businesses serving one language do not need hreflang at all, and adding it unnecessarily only introduces risk. It becomes relevant in specific situations. A business offering its site in both English and Spanish for a bilingual market, common in states like Texas, California, and Florida, uses hreflang to serve each language version correctly. A company operating across the US and another country, such as a firm with US and Canadian or US and Mexican pages, uses it to distinguish regional variants. A franchise or multi-region brand with content tailored to different areas may use it too. The guiding rule is that hreflang is for genuine language or regional variants of the same content, not for pages that merely target different US cities in the same language, which is a job for distinct location pages and strong /services/local-seo. Misapplying hreflang to same-language city pages creates confusion without benefit, so the first question is always whether true language or country variants exist.
How do you implement hreflang tags? #
There are three supported methods, and you pick one based on your site type. The most common is HTML link tags in the head of each page, where every variant links to itself and to all its alternates. The second is HTTP headers, used for non-HTML files like PDFs that have no head. The third is XML sitemap annotations, which is often the cleanest approach for large sites because it centralizes the mapping in the sitemap rather than editing every page. Whichever method you choose, three rules are absolute. Every page in the set must reference every other page including itself, the references must be reciprocal so each page links back, and the language and region codes must use the correct ISO formats. A single missing return link or a typo in a code can cause Google to ignore the entire set. Because the syntax is unforgiving, teams handling multilingual sites through /services/wordpress-development typically manage hreflang with a dedicated plugin or automated sitemap generation rather than by hand.
<!-- Place the SAME full set in the head of every listed page -->
<link rel="alternate" hreflang="en-us"
href="https://example.com/services" />
<link rel="alternate" hreflang="es-mx"
href="https://example.com/es/servicios/" />
<link rel="alternate" hreflang="x-default"
href="https://example.com/services" />What are language and region codes in hreflang? #
The hreflang value combines a required language code with an optional region code. The language code uses the ISO 639-1 standard, two lowercase letters such as en for English, es for Spanish, or fr for French. The optional region code uses the ISO 3166-1 Alpha-2 standard, two letters, conventionally uppercase, such as US, MX, or CA, joined to the language with a hyphen. So en-us means English as used in the United States, and es-mx means Spanish as used in Mexico. You can target a language alone, like es for all Spanish speakers regardless of country, or a specific language-region pair for finer control. Common mistakes include using a country code alone without a language, which is invalid because hreflang is language-first, or inventing codes like en-uk when the correct region code for the United Kingdom is gb. Getting these codes exactly right is essential, since search engines silently ignore malformed values, and validating them is a routine step before any multilingual launch.
What is the x-default value? #
The x-default value designates a fallback page for users whose language or region does not match any of your specified variants. When someone searches and none of your explicit hreflang targets fit their setting, Google serves the page marked x-default. This is typically your primary or most general version, often an international English homepage or a language-selection page. For a US business with English and Spanish variants, the x-default is usually the English page, so anyone outside the two defined audiences lands somewhere sensible rather than on a variant that assumes a wrong locale. The x-default is optional but strongly recommended, because without it Google has no clear instruction for unmatched users and may pick a variant that is not ideal. It functions as a safety net that makes an international setup graceful for the long tail of visitors who do not fit a defined bucket. Including it is a small addition that prevents a class of poor experiences, which is why our /services/ui-ux-design process treats it as a default part of any multilingual page structure.
Why must hreflang be reciprocal? #
Reciprocity is the rule that trips up more hreflang implementations than any other. For a set of alternate pages to be recognized, every page must link to every other page in the set, and those links must point back. If page A declares that page B is its Spanish alternate, then page B must also declare that page A is its English alternate. If B fails to link back, Google treats the relationship as unconfirmed and may ignore the annotation entirely. This bidirectional requirement means you cannot tag one page in isolation; you must maintain the whole cluster consistently. On a small site with two languages this is manageable by hand, but as pages and languages multiply, the number of required links grows quickly and manual maintenance becomes error-prone. That is why larger multilingual sites centralize hreflang in XML sitemaps or automate it, ensuring reciprocity is generated rather than hand-typed. When a hreflang setup mysteriously fails to influence results, a broken return link is the first thing our audits check.
How do you test hreflang tags? #
Testing hreflang starts with validation, because malformed codes and missing return links fail silently. Dedicated hreflang testing tools crawl your pages, confirm that codes use valid ISO formats, and check that every relationship is reciprocal, flagging orphaned or one-way references. Search Console historically reported international targeting issues and remains useful for spotting broken clusters at scale. You can also inspect a page's source or headers directly to confirm the tags are present and correctly formatted, and our /tools/website-grader includes technical checks that surface obvious hreflang problems alongside other findings. Manual verification matters too: search from different locales or use a VPN to confirm the right variant surfaces for the right audience. The two failure modes to watch are invalid codes, such as a made-up region abbreviation, and non-reciprocal links where one page in a set forgets to point back. Because both are invisible to ordinary browsing, deliberate testing after every change to a multilingual set is essential to keep the whole cluster working.
Common hreflang mistakes to avoid #
The most common hreflang mistake is non-reciprocal tagging, where pages fail to link back to each other and Google ignores the set. A close second is incorrect codes, such as using a country code alone without a language, inventing values like en-uk instead of en-gb, or mixing up language and region order. Another frequent error is pointing hreflang at redirected or noindexed URLs, which breaks the relationship because the target is not a stable, indexable page. Applying hreflang to same-language pages that merely target different US cities is a conceptual mistake, since those are not language or regional variants and should be handled as ordinary location pages backed by /services/local-seo. Forgetting the x-default leaves unmatched users without a graceful fallback. Finally, mismatched or self-referencing errors, where a page omits a self-reference or references the wrong URL, quietly invalidate the cluster. Because these errors are silent, any multilingual build handled through /services/website-migrations includes a validation pass before and after launch to confirm the tags actually take effect.
FAQ
Do I need hreflang for a single-language US site?
No. Hreflang is only for sites with genuine language or regional variants of the same content. A single-language US business targeting different cities does not need it; those are ordinary location pages. Adding hreflang unnecessarily introduces risk without benefit, so most local sites serving one language and one country should skip it entirely.
What is the difference between hreflang and a canonical tag?
A canonical tag points to the single preferred version of duplicate or near-duplicate pages to consolidate indexing. Hreflang instead says several pages are equal language or regional alternates, none preferred over the others. They serve different goals, and each page in a hreflang set should generally self-canonicalize rather than canonicalize to a different-language variant.
Can I use hreflang for English and Spanish on one US site?
Yes, this is a common valid use. A US business offering English and Spanish versions of its pages for a bilingual audience uses hreflang, such as en-us and es-us or es-mx, to serve each language correctly. Ensure the tags are reciprocal and include an x-default fallback for unmatched visitors.
Why are my hreflang tags being ignored?
The usual cause is missing reciprocity, where pages in the set do not all link back to each other. Other causes include invalid language or region codes, pointing at redirected or noindexed URLs, or a missing self-reference. Because these errors fail silently, validate the full cluster with a dedicated hreflang testing tool.
Does hreflang help my rankings?
Hreflang does not directly boost rankings, but it ensures the right language or regional version shows to the right user and prevents variants from being treated as duplicate content competing against each other. This improves user experience and click-through, which supports performance indirectly rather than acting as a ranking factor on its own.
Where do I put hreflang tags?
You can place them in three locations, and you pick one method per site. As HTML link tags in each page's head, as HTTP response headers for non-HTML files like PDFs, or as annotations in an XML sitemap. Large multilingual sites often prefer the sitemap method because it centralizes the mapping and makes reciprocity easier to maintain.
Was this helpful?