Should you really abandon hreflang tags in anchor links?

Why is there clarification on the placement of hreflang tags?

Google is reiterating a rule that has not changed since the introduction of the hreflang system in 2011. The three official implementation methods are established in the original specification: link rel="alternate" hreflang tags in the head section, X-Default HTTP headers, or declarations in a dedicated XML sitemap.

This clarification likely aims to correct a recurring confusion. Some developers attempt to add hreflang attributes directly to anchor tags, probably by analogy with other HTML attributes like lang or rel. The issue? This syntax has never been part of the standards recognized by Google, and the engine completely ignores it during crawling.

What is the difference between a link tag and a link attribute?

A <link rel="alternate" hreflang="fr"> tag in the head is a standalone HTML element that does not visually point to anything. It exists solely to inform search engines of the language variants of a page. This tag is parsed during crawling and integrated into the relationship graph between URLs.

An hreflang attribute on an anchor tag <a href="/fr/" hreflang="fr"> would theoretically be an instruction at the link level itself. But Google does not recognize this syntax, as it has never been standardized in the HTML specifications for this use case. Even if technically the attribute exists in the DOM, Google's crawler traverses it without treating it as an hreflang signal.

How does Google actually detect hreflang signals?

The crawler parses three distinct sources when processing a URL. First, it analyzes the HTML source code for link tags in the head. Then, it examines the HTTP response headers for potential Link directives. Finally, it consults the XML sitemaps declared in robots.txt or Search Console to extract grouped hreflang annotations.

Each of these methods has different technical advantages. HTTP headers are suitable for PDF files or other non-HTML resources. Sitemaps centralize management for very large multilingual sites. Tags in the head remain the most common method, as they allow granular control page by page without server dependency.

• Three exclusively official methods: link tags in head, HTTP headers, XML sitemap
• No support for hreflang attributes on anchor tags or other HTML elements
• Google's parser ignores any implementation outside the documented specification
• Reciprocity remains mandatory: every URL must declare all its variants, including itself
• One common type of error: confusing the standalone link tag with a clickable link attribute

Does this statement truly reflect field observations?

Absolutely. No documented cases show Google utilizing hreflang attributes placed on anchor tags. Empirical tests confirm that only the three official methods generate effective hreflang signals in Search Console. When a site uses invalid syntax, international coverage reports remain empty or display reciprocity errors.

What is interesting is that this confusion persists despite clear documentation for over ten years. Probably because the hreflang attribute does exist in HTML5 specifications for other contexts, particularly to indicate the language of a linked resource. But Google has never extended its interpretation beyond the three official channels.

What nuances should be added to this rule?

The main nuance concerns client-side JavaScript sites. If a SPA application dynamically injects hreflang link tags into the head after the initial render, Google may theoretically detect them during a second crawl (JavaScript rendering). However, this approach remains fragile: it's better to prioritize server-side rendering or HTTP headers to ensure detection.

Another point: the XML sitemap method suffers from a rarely mentioned flaw. Google processes sitemaps asynchronously and with delay. A change in the sitemap can take several weeks to propagate, whereas a tag in the head is detected during the next crawl of the page. For sites with high editorial velocity, this latency is problematic. [To be verified]: Google has never published a SLA on the speed of processing hreflang annotations via sitemap.

In what cases does this rule pose practical difficulties?

E-commerce sites with filters face a real conundrum. Each filter combination potentially generates a unique URL, and maintaining hreflang annotations on thousands of filtered variants becomes unmanageable. The temptation to use a dynamic anchor attribute would be understandable, but it does not work.

Headless or decoupled platforms also raise issues. When the front-end does not directly control the HTML head (generated by the back-end CMS), injecting hreflang tags requires technical coordination between teams. HTTP headers then become the fallback solution, but they require server configuration that not all shared hosting environments allow.

What should you check immediately on a multilingual site?

First action: open Search Console and check the "International Targeting" report. If no data appears while the site declares multiple language versions, this is a symptom of a defective hreflang implementation. Next, manually inspect the source code of a few key pages: the link tags must be present in the head, not elsewhere.

For sites using HTTP headers, a simple curl -I or the Chrome DevTools Network tab immediately reveals whether Link directives are being sent. If the sitemap method is chosen, download the XML file and check the syntax: each URL must list all its variants, including itself; otherwise, Google rejects the annotation as incomplete.

How to correct an incorrect implementation?

If hreflang attributes linger on anchor tags, removing them is risk-free since they have no effect. The focus should be on adding the true link tags in the head. For a WordPress site, plugins like WPML or Polylang handle this automatically. For a custom site, the template must loop through available translations and dynamically generate the tags.

Reciprocity is the most frequent trap. Each fr-FR page must point to en-GB, es-ES, de-DE, etc., but also to itself with hreflang="fr". And each en-GB page must do the same in the other direction. A single missing tag in the chain breaks the reciprocity, and Google then ignores the entire cluster. Tools like Screaming Frog or Oncrawl can detect these inconsistencies during a crawl.

What mistakes should be absolutely avoided during migration?

Never mix the three methods on the same site. Google prioritizes tags in the head, then HTTP headers, and then the sitemap. If contradictory annotations exist, the behavior becomes unpredictable. Choose one method and stick to it. Likewise, never link to non-canonical URLs: hreflang should always refer to the canonical version of each variant.

Another classic mistake: forgetting the x-default tag. It tells Google which version to serve to users whose language does not match any declared variant. Without x-default, Google makes an arbitrary choice, often based on IP geolocation, which results in an inconsistent user experience. Finally, pay attention to language codes: use fr-FR for French France, not just "fr", unless the variant covers all French speakers indiscriminately.

• Audit the source code: link tags must be in the <head>, not in the body or on anchors
• Check reciprocity: each URL must list all its variants, including itself
• Control language codes: ISO 639-1 for language, ISO 3166-1 Alpha 2 for country
• Test with Search Console: the International Targeting report should show all detected variants
• Avoid mixing head tags, HTTP headers, and sitemap on the same domain
• Implement x-default to properly manage uncovered languages