Google’s Search Central documentation confirms all three hreflang implementation methods, HTML tags, XML sitemap entries, and HTTP headers, are treated as functionally equivalent by its crawler, with no ranking preference given to any single method. The choice between them comes down to site size, content type, and how the site’s content management system handles head-tag versus sitemap editing, not any inherent superiority of one method.
This guide walks through all three methods with working syntax, explains which sites each method suits best, and covers the reciprocity requirement that trips up most implementations regardless of which method is chosen.
Method 1: HTML Link Tags
The most common implementation places a link tag inside the head section of every page, once for each language or region variant, plus a self-referencing tag for the current page itself. Each tag uses rel equals alternate, combined with hreflang specifying the target language and optional region code, and href pointing to the full URL of that variant.
This method suits small to mid-size sites where editing page templates directly is straightforward, and where a CMS can inject the correct tags dynamically based on which language versions of a given page actually exist. The main drawback is scale: a site with ten languages needs ten tags per page, repeated across every page, which becomes unwieldy to audit manually as a site grows.
Method 2: XML Sitemap Entries
Rather than placing tags in every page’s head, hreflang relationships can be declared centrally within an XML sitemap using xhtml colon link elements nested inside each URL entry. This consolidates all reciprocal relationships into one file rather than spreading them across every page template, which many practitioners find easier to audit and maintain at scale. WritoryBuzz’s XML sitemap generator supports adding hreflang entries directly during sitemap creation, producing both files from the same underlying page and language list.
This method suits larger sites, particularly those where editing individual page templates for every language is impractical, since the entire hreflang relationship map lives in one centrally maintained file instead.
Method 3: HTTP Headers
For non-HTML content that has no head section to place a link tag in, such as PDFs, hreflang relationships are declared through the HTTP response header instead, using a Link header with the same rel, hreflang, and href attributes as the HTML method, sent by the server alongside the file itself.
This method is narrower in application than the other two, relevant specifically to document-heavy sites publishing translated PDFs, reports, or other non-HTML files where the content itself needs the same language-variant signalling as a webpage would receive.
The Reciprocity Rule That Applies to All Three Methods
Regardless of implementation method, every hreflang relationship must be reciprocal and self-referencing: if page A declares page B as its French alternate, page B must declare page A back as its English alternate, and both pages should also include a self-referencing hreflang tag pointing to themselves. Search engines treat a one-directional hreflang declaration as unconfirmed and may disregard it entirely rather than acting on a signal it cannot verify from both sides.
This requirement is the single largest source of implementation errors across all three methods, since a reciprocal set grows combinatorially with each added language. A site with six language variants needs each page to correctly reference the other five, a task manageable for a handful of pages but error-prone at scale without automation. WritoryBuzz’s free hreflang generator builds the complete reciprocal set automatically from a language and URL list, regardless of which of the three output formats is needed.
Combining Hreflang With Meta Tags Correctly
Hreflang implementation often happens alongside broader meta tag work on the same pages, and confirming the language and canonical signals do not conflict is worth checking in the same pass. WritoryBuzz’s meta tag generator covers canonical tag output specifically, which matters since an incorrectly configured canonical tag can undermine an otherwise correct hreflang setup.
That specific interaction between the two tag types is covered in Hreflang vs Canonical Tags: When to Use Which.
Choosing the Right Method for Your Site
| Site Type | Recommended Method | Why |
| Small site, under 50 pages | HTML link tags | Simple to implement per template, easy to audit manually |
| Large site, 50+ pages, many languages | XML sitemap entries | Centralised maintenance, avoids editing every page template |
| Document-heavy site with PDFs | HTTP headers (for PDFs) plus HTML or sitemap for webpages | Only method that supports non-HTML content |
From Method to Working Templates
Choosing a method is the first decision. Seeing exactly how the syntax looks for common site structures, from a simple two-language blog to a twelve-region e-commerce store, is covered in Hreflang Examples: Copy-Paste Templates for 10 Common Setups.
For the background on why any of this matters before committing engineering time to implementation, see What Are Hreflang Tags and Why Multilingual Sites Break Without Them.
Explore the rest of WritoryBuzz’s free technical SEO toolkit to check the surrounding signals alongside hreflang.
