Is Your Hreflang Actually Working — or Just Sitting There?
Most multilingual website teams reach a point where hreflang is added to the technical checklist, configured once, and never reviewed again. The assumption is that if it was set up correctly at launch, it will continue working. That assumption is responsible for a lot of lost traffic.
More than 60% of sites using hreflang have at least one implementation error, according to Screaming Frog analysis data, with missing return tags being the single most common problem. Google treats hreflang as a hint, not a directive — which means a broken implementation simply gets ignored. No Search Console alert, no crawl error, no warning. Just quietly ineffective.
The practical consequences are real: users land on the wrong language version of your site, Google indexes unnecessary duplicate content across locales, and the ranking authority that should be shared across your language cluster gets fragmented instead. All of these problems are preventable with a technically sound implementation.
This guide covers the three available implementation methods, the ten most frequent errors with explanations of why they happen and how to fix them, and a verification process you can run immediately against your current setup.
What Hreflang Does (and What It Cannot Do)
Hreflang is the rel="alternate" link attribute that signals to search engines which pages are alternative versions of each other for different languages or regions. The basic syntax looks like this:
<link rel="alternate" hreflang="lang_code" href="https://absolute-url.com/page/" />When Google crawls a page containing these annotations, it builds a “cluster” of related pages and understands that they are all equivalent versions of the same content in different languages. From that point on, Google attempts to show each user the most appropriate version based on their language settings and geographic location.
The critical distinction — and the one most often misunderstood — is that hreflang is a hint, not a directive. Google Search Central states it plainly: “Hreflang annotations are a hint to Google, not a directive. Google may ignore improper implementations and determine independently which content to display.” A broken implementation does not trigger an error. It simply fails silently.
Gary Illyes of Google, one of the search engine’s primary technical voices, has explained the ranking dimension on hreflang.org: “Hreflang tags don’t function as direct ranking signals algorithmically, yet they provide substantial value within content clusters — in a cluster, a group of similar content pages in different languages share the same ranking authority.” The practical implication is that a correctly implemented hreflang cluster allows pages in lower-authority languages to benefit from the ranking equity of stronger ones.
When to use hreflang
Hreflang is appropriate when you have content in multiple languages or regional variants of the same language. Common scenarios:
- A site in English and Spanish targeting the same topic for different language audiences
- An English-language site with regional variants (en-US, en-GB, en-AU)
- A site with Latin American and European Spanish variants (es-MX, es-ES)
- A trilingual site like Ighenatt, serving content in Spanish, English, and Catalan (es, en, ca)
Hreflang is not appropriate if your pages in different languages cover significantly different content, if only a portion of your site is translated, or if the pages do not represent genuine content equivalents.
The Three Implementation Methods
There are three technically valid ways to implement hreflang. Each has distinct advantages depending on site size and technical architecture.
| Method | Where It Lives | Best For | Key Constraint |
|---|---|---|---|
| HTML head tags | <head> of each page | Small to medium sites (< 1000 URLs per locale) | Requires modifying every page; adds to HTML size |
| XML Sitemap | sitemap.xml file | Large sites (> 1000 URLs); any CMS with sitemap generation | Requires correctly indexed sitemap |
| HTTP headers | Server response headers | PDFs and non-HTML documents | Only applicable to non-HTML resources |
Method 1: HTML Head Tags
The most direct approach. Inside the <head> element of every page in the cluster, you include a <link> tag for each alternative version, including the current page itself:
<head>
<!-- Self-referencing tag (required) -->
<link rel="alternate" hreflang="en"
href="https://ighenatt.es/en/recursos/seo-tecnico/hreflang-implementacion/" />
<!-- Spanish version -->
<link rel="alternate" hreflang="es"
href="https://ighenatt.es/recursos/seo-tecnico/hreflang-implementacion/" />
<!-- Catalan version -->
<link rel="alternate" hreflang="ca"
href="https://ighenatt.es/ca/recursos/seo-tecnico/hreflang-implementacion/" />
<!-- Fallback for uncovered languages/regions -->
<link rel="alternate" hreflang="x-default"
href="https://ighenatt.es/en/recursos/seo-tecnico/hreflang-implementacion/" />
</head>This exact block must appear on every page in the cluster — the English, Spanish, and Catalan versions. Google builds the cluster from whichever page it crawls first. If one page has an incomplete set of tags, bidirectionality breaks and the entire cluster annotation becomes unreliable.
Method 2: XML Sitemap
For sites with thousands of localized URLs, editing the HTML of every individual page is impractical and can create crawl budget issues. The scalable alternative is to declare hreflang relationships in the XML sitemap.
First, add the xhtml namespace to the urlset element:
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
xmlns:xhtml="http://www.w3.org/1999/xhtml">Then, inside each <url> block, include <xhtml:link> tags for all versions in the cluster:
<url>
<loc>https://ighenatt.es/en/recursos/seo-tecnico/hreflang-implementacion/</loc>
<xhtml:link rel="alternate" hreflang="en"
href="https://ighenatt.es/en/recursos/seo-tecnico/hreflang-implementacion/"/>
<xhtml:link rel="alternate" hreflang="es"
href="https://ighenatt.es/recursos/seo-tecnico/hreflang-implementacion/"/>
<xhtml:link rel="alternate" hreflang="ca"
href="https://ighenatt.es/ca/recursos/seo-tecnico/hreflang-implementacion/"/>
<xhtml:link rel="alternate" hreflang="x-default"
href="https://ighenatt.es/en/recursos/seo-tecnico/hreflang-implementacion/"/>
</url>The bidirectionality rule applies here too. If the English URL block declares a relationship with the Spanish URL, the Spanish URL block must also declare a relationship back to the English URL. In practice, this means each URL in the cluster appears as a <url> entry in the sitemap, and each entry includes the full set of <xhtml:link> tags for all cluster versions.
Method 3: HTTP Response Headers
This method applies exclusively to non-HTML resources such as PDFs and downloadable documents, where modifying a <head> element is not possible. It is configured at the server or CDN level using the Link response header:
Link: <https://ighenatt.es/en/seo-technical-guide.pdf>; rel="alternate"; hreflang="en",
<https://ighenatt.es/recursos/guia-seo-tecnico.pdf>; rel="alternate"; hreflang="es"For standard web pages, this method is unnecessary. It becomes relevant in documentation-heavy projects or sites distributing multilingual PDF content to different language audiences.
The 10 Most Common Hreflang Errors
Screaming Frog analysis reveals that implementation errors cluster around the same technical points across different sites. Knowing them in advance is the most efficient way to avoid them.
1. Missing Return Tags (Broken Bidirectionality)
The most frequent error by a wide margin. It occurs when page A includes a hreflang tag pointing to page B, but page B has no reciprocal tag pointing back to A. Google Search Central is explicit: “If page X links to page Y, page Y must link back to page X. Missing return links cause annotations to be ignored or not interpreted correctly.”
The consequence: both tags stop working, even if one page has a perfectly valid annotation.
Fix: Ensure the hreflang block is identical across all pages in the cluster, with every page referencing all other versions.
2. Missing Self-Referencing Tag
Every page must include a hreflang tag pointing to itself, in addition to the tags pointing to other versions. An English page that only includes tags for the Spanish and Catalan versions has this error.
Fix: Always include the tag with the language code of the current page and its canonical URL as the href value.
3. Missing or Misconfigured x-default
x-default is strongly recommended for a complete implementation. It defines which version to show users whose language is not covered by any specific tag. Without it, Google decides unilaterally.
Fix: Add hreflang="x-default" pointing to the most universal version of your content — typically the English version or a language selector page.
4. Invalid Language Codes
The correct format is BCP 47: lowercase language code, hyphen, uppercase region code. Common mistakes: en_US (underscore instead of hyphen), UK standalone (not a language code; must be en-GB), or ENG instead of en.
Fix: Verify against the official BCP 47 code list. For language only: es, en, ca. For language + region: es-ES, es-MX, en-GB, en-US.
5. Tags Pointing to Redirected URLs
If a URL in a hreflang tag responds with a 301 or 302, Google does not follow that redirect for hreflang purposes. The tag must point directly to the final canonical URL.
Fix: Crawl all URLs referenced in your hreflang tags with Screaming Frog and correct any that return 3xx status codes.
6. Tags Pointing to Non-200 Pages
Tags referencing URLs that return 404, 410, or any non-200 status are ignored. This frequently occurs during migrations when pages are removed without updating the hreflang tags on remaining versions.
Fix: Run periodic audits of all URLs in your hreflang tags to detect non-200 responses.
7. Canonical vs. Hreflang Conflict
If a page has a canonical tag pointing to a different URL (not itself), and simultaneously has hreflang tags, Google will likely prioritize the canonical signal. Google documentation notes that 30-40% of canonical tags with conflicting signals are ignored, but the same logic applies in reverse — hreflang gets deprioritized when canonical sends a contradictory message.
Fix: Canonical tags on hreflang pages should be self-referencing. Check that no cross-locale canonical redirects exist between language variants.
8. Inconsistent Implementation Across Methods
Some sites have hreflang in HTML head tags and in the sitemap, with different data in each location. This creates conflicting signals. If you use both methods, the data must be identical; ideally, use a single consistent method across the entire site.
Fix: Choose one method and apply it consistently. If you maintain both, ensure they are kept in sync.
9. Inconsistent Trailing Slash
https://example.com/page/ and https://example.com/page are different URLs to Google. If hreflang tags use one format and canonical URLs use another, Google may treat the pairs as unrelated pages.
Fix: Define a consistent trailing slash policy for the entire site and apply it without exceptions to all URLs in hreflang tags.
10. Relative URLs Instead of Absolute
Hreflang requires fully-qualified URLs — with protocol and domain included. A relative URL like /resources/seo-tecnico/hreflang-implementacion/ is not valid.
Fix: Always use the complete URL: https://ighenatt.es/en/recursos/seo-tecnico/hreflang-implementacion/.
Verification Checklist
An hreflang implementation is complete only when it has been verified. This process covers all critical points:
Step 1 — Bidirectionality audit with Screaming Frog
Crawl the full site and go to the Hreflang tab. Filter by “Non-Reciprocal”. Any URL appearing in that filter has a missing return tag error. Export the list and fix it.
Step 2 — Manual validation and hreflang tools
Validate your hreflang implementation by manually inspecting rel="alternate" and x-default tags in the HTML source or via a full-site crawl with Screaming Frog or DeepCrawl. Confirm that all referenced URLs return HTTP 200 and appear in your XML sitemaps. For per-URL validation, use hreflang.org. For indirect crawl-based verification, use Google Search Console’s URL Inspection tool or Coverage reports to surface indexing errors. Consult Google’s official multilingual/multiregional documentation for authoritative guidance.
Step 3 — URL-specific test with hreflang.org checker
The tool at hreflang.org validates a specific URL and shows all detected pairs, including alerts for bidirectionality and language code issues. Use it to validate new pages before publishing.
Step 4 — HTTP status verification of all referenced URLs
Extract all URLs mentioned in your hreflang tags and verify they all respond with 200. Screaming Frog can do this in List Mode.
Step 5 — Canonical and hreflang consistency check
For each page with hreflang, confirm that the canonical tag points to the same URL as the self-referencing hreflang tag. Discrepancies here indicate a conflict that will cause Google to deprioritize your hreflang signals.
Hreflang in Modern Frameworks and Static Site Generators
In frameworks like Astro — which powers the Ighenatt website — hreflang tags are generated programmatically in the base layout component. The correct approach is to build the localizedSlugs object using centralized URL helpers and pass it to the layout, which then renders the tags in the <head>. This makes bidirectionality automatic: when the layout includes tags for ES, EN, and CA, every page in the cluster receives the complete block with references to all three versions.
For sites with thousands of localized pages — the recommended threshold for switching to sitemap-based hreflang is 1000 URLs per locale — the XML sitemap approach is more maintainable. The sitemap with the xhtml namespace declares all hreflang relationships in a single file that Google crawls periodically, without adding to the HTML size of individual pages.
The key principle in any technical approach is to treat hreflang as data, not markup: generate it from a single authoritative source of truth, apply it consistently across all pages in every cluster, and verify it periodically against the actual state of your URLs.
For a broader view of how hreflang fits into a complete technical SEO strategy, see our resources on technical SEO and Google indexing issues.