Hreflang Sitemap vs HTML Tags vs HTTP Headers: Pick One

Q: Does every URL in the hreflang sitemap need its own entry?

Yes. Google's rules require a separate element for each URL, and each one must list every language version including itself. A page in three languages produces three entries, each with the same three children. Listing alternates only under the main-language URL leaves the other versions without return links.

Q: Do hreflang links count toward the 50,000 URL sitemap limit?

No. Google states that the child elements don't count toward the URL limit. Only the URLs count. The file size limit of 50MB uncompressed still applies, and hreflang annotations add a lot of bytes, so large multilingual sites often need to split their sitemaps and use a sitemap index.

Q: When should I use HTTP headers for hreflang?

Use HTTP Link: headers for non-HTML files such as PDFs, which have no for link tags. For normal web pages, headers work but are harder to audit, because the annotations aren't visible in the page source. They also tend to get lost when you change hosting, server or CDN configuration.

An hreflang sitemap is an XML sitemap where each <url> entry lists every language version of that page as <xhtml:link> children. It is one of three ways to tell Google about localized pages, alongside HTML <link> tags in the page head and HTTP Link: headers. Google says the three methods "are equivalent from Google's perspective," so the right choice is whichever your site can keep accurate.

The short recommendation: use HTML tags if your CMS or framework renders them reliably on every page, use an hreflang sitemap if you can't edit page heads or have many languages, and reserve HTTP headers for PDFs and other non-HTML files. Don't run all three at once. Google says there is no benefit in Search, and three implementations triple the chances of them disagreeing.

How do the three hreflang methods compare?

All three carry the same information; they differ in where it lives and who can maintain it.

	HTML `<link>` tags	XML sitemap	HTTP `Link:` header
Where it lives	`<head>` of every page	One or more sitemap files	Server response headers
Best for	Sites where templates control the head	Large sites, many languages, CMS with locked templates	PDFs and non-HTML files
Page weight	Adds one line per language to every page	None	None in the HTML
Visible when viewing the page	Yes, in the source	No, you must open the sitemap	Only in network tools or a header checker
Common failure	Template drops a language or the self-reference	Sitemap goes stale when URLs change	Server config forgotten during a migration
Google's verdict	Equivalent	Equivalent	Equivalent

Google's localized versions documentation describes HTML tags as useful "if you don't have a sitemap or the ability to specify HTTP response headers," and HTTP headers as "useful for non-HTML files (like PDFs)." The sitemap method has no stated preference either way. Pick on maintenance, not on ranking, and fit the choice into your wider international SEO strategy.

Hreflang sitemap example and rules

An hreflang sitemap repeats the full set of alternates inside every page's entry.

Here is a sitemap for one page published in English, German and French:

<?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">
  <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="de" href="https://example.com/de/preise"/>
    <xhtml:link rel="alternate" hreflang="fr" href="https://example.com/fr/tarifs"/>
    <xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/en/pricing"/>
  </url>
  <url>
    <loc>https://example.com/de/preise</loc>
    <xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/pricing"/>
    <xhtml:link rel="alternate" hreflang="de" href="https://example.com/de/preise"/>
    <xhtml:link rel="alternate" hreflang="fr" href="https://example.com/fr/tarifs"/>
    <xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/en/pricing"/>
  </url>
  <url>
    <loc>https://example.com/fr/tarifs</loc>
    <xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/pricing"/>
    <xhtml:link rel="alternate" hreflang="de" href="https://example.com/de/preise"/>
    <xhtml:link rel="alternate" hreflang="fr" href="https://example.com/fr/tarifs"/>
    <xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/en/pricing"/>
  </url>
</urlset>

The rules Google sets for this format:

Declare the namespace xmlns:xhtml="http://www.w3.org/1999/xhtml" on the <urlset>.
Create a separate <url> element for each URL, each with its own <loc>.
Inside each <url>, list every alternate version including itself. Three versions means three entries, each with the same three child links (plus x-default if you use it).
The order of <xhtml:link> children doesn't matter, but a consistent order makes errors easier to spot.
Use fully qualified URLs with https://.

Two size facts help with planning. Google's sitemap guidelines limit a single sitemap to 50MB uncompressed or 50,000 URLs, and the <xhtml:link> children don't count toward the URL limit. Hreflang does make files much heavier, though, so on large sites you'll hit the 50MB ceiling sooner and should split into several sitemaps under a sitemap index.

HTML link tag example

HTML tags put the same list in the <head> of every version of the page.

On each of the three pricing pages above, the head contains this identical block:

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

The tags must be inside a well-formed <head>. Google says that once it meets an invalid element in the head, such as an img or iframe, it assumes the head has ended and ignores everything after it, so hreflang lines placed below one are lost. Google also warns against combining hreflang with other attributes such as media in a single <link> tag.

This is the method most CMS plugins and frameworks use, and it is the easiest for anyone to inspect: view source and the annotations are right there. The hreflang tags guide goes deeper on language codes and return links.

HTTP header example

The HTTP method sends the list in a Link: response header, which is why it works for files that have no <head>.

For a whitepaper published as a PDF in English and German, each file's response would include:

Link: <https://example.com/en/whitepaper.pdf>; rel="alternate"; hreflang="en",
      <https://example.com/de/whitepaper.pdf>; rel="alternate"; hreflang="de"

Every version returns the identical header, including the entry for itself. URLs go inside angle brackets, and entries are separated by commas. Use this only where HTML tags are impossible. For ordinary pages it is harder to audit, because nothing is visible in the page source, and server rules are easy to lose when you change hosting or move to a CDN.

Which hreflang method should you choose?

Choose the method that has a single owner and updates automatically when URLs change.

Small site, normal CMS or framework, under a few hundred translated pages: HTML tags. They are visible, easy to debug, and most multilingual plugins generate them.
Shopify, hosted builders or locked themes where you can't touch the head: an hreflang sitemap generated by the platform or an app, if it supports one. Check that it regenerates when you add a page.
Many languages or regional variants per page: the sitemap. Ten language versions mean ten extra lines in every page head; in a sitemap they cost no page weight.
PDFs, documents and other files you translate: HTTP headers, configured at the server or CDN.

Whatever you pick, generate it from data, not by hand. A translations table that knows every page and its language siblings can render HTML tags or write the sitemap, and the self-references and return links stay correct automatically. Hand-edited hreflang falls apart the first time a URL changes, which is why it belongs on your pre-migration checklist.

Common hreflang sitemap mistakes

Sitemap implementations fail quietly because nobody looks at the file after launch.

Listing alternates only on the "main" language entry. Every <url> needs the full set, including itself. Otherwise the return links are missing.
Forgetting the xhtml namespace. Without xmlns:xhtml, the <xhtml:link> elements are invalid XML.
Non-canonical, redirecting or noindexed URLs. List the final, canonical, indexable URL for each language.
A stale sitemap. A page is renamed, the old URL now 301s, and the sitemap still lists it as an alternate.
Mixing methods that disagree. HTML tags say the German page is /de/preise, the sitemap says /de/pricing. Remove one method entirely rather than keeping both.
Invalid codes. en-UK is wrong (the region code is GB), and Google says reserved codes such as EU or UN have no effect.

After launch, submit the sitemap in Search Console's Sitemaps report and check that it is processed without errors. Submit it in Bing Webmaster Tools as well, so both engines discover every language version.

Frequently Asked Questions

Is an hreflang sitemap better than HTML tags?

No. Google says the HTML, HTTP header and sitemap methods are equivalent from its perspective, though the sitemap is better for maintenance on sites with many languages or locked page templates, because it adds no page weight and lives in one file. HTML tags are easier to inspect. Pick the one you can keep accurate.

Can I use both an hreflang sitemap and HTML tags?

You can, but Google says there is no benefit in Search, and it makes the setup harder to manage. The real risk is that the two drift apart, with one listing a URL the other doesn't. If you already have both, choose the one that updates automatically and remove the other.

Does every URL in the hreflang sitemap need its own entry?

Yes. Google's rules require a separate <url> element for each URL, and each one must list every language version including itself. A page in three languages produces three <url> entries, each with the same three <xhtml:link> children. Listing alternates only under the main-language URL leaves the other versions without return links.

Do hreflang links count toward the 50,000 URL sitemap limit?

No. Google states that the child <xhtml:link> elements don't count toward the URL limit. Only the <loc> URLs count. The file size limit of 50MB uncompressed still applies, and hreflang annotations add a lot of bytes, so large multilingual sites often need to split their sitemaps and use a sitemap index.

When should I use HTTP headers for hreflang?

Use HTTP Link: headers for non-HTML files such as PDFs, which have no <head> for link tags. For normal web pages, headers work but are harder to audit, because the annotations aren't visible in the page source. They also tend to get lost when you change hosting, server or CDN configuration.

The practical pick

For most small multilingual sites, HTML tags generated by the CMS are the right default, an hreflang sitemap is the right answer when you can't control page heads or have many languages, and HTTP headers are only for files. Use one method, generate it from data, and confirm it in Search Console after every URL change.

Agent Solo's Growth plan publishes articles in two languages with hreflang and canonicals output for you, and the Scale plan handles up to five languages, so there is no annotation file to keep in sync by hand. Get early access if your second-market pages aren't being indexed.