What Is the Hreflang Tag and How Do You Use It? Multilingual Website SEO Setup

What is the hreflang tag?

A hreflang tag is a link element, written as rel="alternate" hreflang="language-REGION", that tells search engines which language or regional version of a page exists at which URL. In practice, it says: "this page also exists in Turkish here and in German there." Google then shows the matching version to the right searcher.

I have run talhaaslan.com in Turkish, English and German for years, so I deal with the hreflang tag every week. For example, most guides treat it as a translation topic. However, my framing is different: hreflang is a matching job, not a translation job. In other words, you are pairing URLs, and every pair has to be complete.

Google documents three equivalent ways to declare these pairs in its localized versions guide: an HTML link element, an HTTP Link header, and xhtml:link entries inside an XML sitemap. In this guide I walk you through all three, using my own site as the live example.

What does the hreflang tag do, and how is it different from canonical?

The hreflang tag groups equivalent pages across languages so that Google can pick the best one for each searcher. Canonical, on the other hand, solves a different problem: it tells Google which URL among duplicates should represent the content. In short, canonical picks a winner, hreflang introduces siblings.

For example, my English SEO consulting page and my German SEO consulting page are not duplicates. Each one has its own canonical pointing to itself. The hreflang tag simply connects them, so a searcher in Vienna sees the German version instead of the English one.

Confusing the two, however, creates real damage. If you set the German page's canonical to the English URL, you tell Google the German page does not deserve its own place in the index. Therefore, keep canonical self-referencing and let hreflang do the cross-language work.

Which websites need hreflang, and which do not?

You need hreflang when the same content exists in more than one language, or when the same language targets more than one country with different details. For example, prices, currencies, shipping terms and legal text are typical reasons for regional versions.

• A Turkish online store with English and German storefronts needs it.
• An agency site like mine, with tr, en and de sections, needs it.
• A single-language blog that only publishes in Turkish does not need it.
• Sites where the "translation" is a machine output nobody reviews should fix the content first, then think about tags.

In my SEO consulting work, I also see the reverse mistake: a single-language site adds hreflang because a plugin offered the option. That adds maintenance for zero benefit. Otherwise healthy sites end up with broken pairs pointing to pages that never existed.

How do you write a hreflang tag correctly?

In practice, the syntax is short. You place a link element with three attributes: rel="alternate", hreflang with the language code, and href with the absolute URL of that version. The region code is optional and then comes after a hyphen.

• Language only: hreflang="tr" covers Turkish speakers everywhere.
• Language plus region: hreflang="en-GB" covers English speakers in the United Kingdom.
• Another regional variant: hreflang="de-AT" covers German speakers in Austria.

Beyond that, three details matter more than the rest. First, the href must be absolute, including the protocol and domain. Second, the URL must return a 200 status, not a redirect. Third, the language code comes first and the region code second, never the other way around. A hreflang tag with "GB-en" is invalid and Google drops it.

Because these rules are mechanical, I generate the lines with the hreflang generator on my site instead of typing them by hand. Typing is where the small mistakes creep in.

How do you choose language and region codes?

Language codes follow ISO 639-1 and region codes follow ISO 3166-1 Alpha 2. Google's documentation states plainly that it "doesn't automatically derive the language from a country code", so the language part is never optional. You can write "tr" alone, but you can never write "TR" alone.

In practice, two traps catch almost everyone. The first is "en-UK": the United Kingdom's ISO code is GB, so the correct value is "en-GB". Next comes the difference between "tr" and "tr-TR". The short form targets every Turkish speaker; the long form, however, narrows the page to Turkish speakers located in Turkey.

My rule of thumb: use language-only codes unless you genuinely have country-specific content. Regional codes look precise, but they also shrink your audience. For example, a "de-DE" page without a "de" fallback leaves Swiss and Austrian searchers with no declared match at all.

What is x-default, and which page should get it?

x-default is a reserved hreflang value for users whose language or region matches none of your declared versions. Google recommends it for language selector pages and for home pages that automatically redirect visitors. In practice, it is your "if unsure, show this one" instruction.

On talhaaslan.com the Turkish root is the default, so x-default points to the Turkish URL of each page. A global brand might instead point x-default to an English version or to a neutral language picker. Either choice works, as long as every page in the group carries the same logic.

There is a second benefit that few people mention. Google's own Search Central blog post on how x-default can help you explains that x-default also helps Googlebot discover URLs it might otherwise never see. So the line does double duty: routing users and surfacing pages.

HTML, HTTP header or sitemap: which method should you use?

Google accepts three equivalent methods and gains nothing from seeing all three at once. Instead, pick the one your team can maintain. The table below summarises how I decide for client projects.

Because the sitemap child elements do not count towards the sitemap URL limit, that method scales best. However, for a site of my size the HTML method is simpler to inspect, so that is what I use.

How do you add hreflang tags in the HTML head?

Every page on my site carries four lines: Turkish, English, German and x-default. For example, here is the set for the home page, written out as text rather than a code block.

1. <link rel="alternate" hreflang="tr" href="https://talhaaslan.com/">
2. <link rel="alternate" hreflang="en" href="https://talhaaslan.com/en/">
3. <link rel="alternate" hreflang="de" href="https://talhaaslan.com/de/">
4. <link rel="alternate" hreflang="x-default" href="https://talhaaslan.com/">

The same four lines appear on the English and German home pages, unchanged. That repetition is also the whole point: each version lists itself and all its siblings. For a service page, only the paths change, so the English SEO page and the German SEO page share an identical block.

Put the lines in the head, before any scripts that might rewrite the document. If your template already outputs canonical and Open Graph tags, add the hreflang tag lines in the same place. Then reload the page and confirm the four lines exist in the raw source, not only in the browser's rendered DOM.

How do you deliver hreflang through an XML sitemap?

For a big catalogue, the sitemap method wins on maintenance. Each URL entry contains one xhtml:link child for every language version, including itself. Google then reads those children as if they were tags in the page head.

Consider an example calculation, not a client case: a store with 3 languages and 40 product pages has 120 URLs. Each URL needs 4 hreflang lines, so the group needs 480 declarations. Editing 480 lines across 120 templates by hand is therefore unrealistic. A generated sitemap produces them in one pass.

The workflow I recommend has three steps. First, build the URL groups from your database, so every product knows its sibling IDs. Next, generate the sitemap with the XML sitemap generator or your platform's exporter, adding the xhtml namespace at the top. Finally, submit the file in Search Console and check that the reported URL count matches your expectation.

One warning applies here. Remember that the sitemap children count against nothing, but the parent URLs still count towards the 50,000 URL limit per file. Split large catalogues into several files under one index.

Why is the return link rule so critical?

Google states the rule in one sentence in its localized versions documentation: "If two pages don't both point to each other, the tags will be ignored." In other words, the declaration only counts when both directions exist. A one-way link is worth exactly nothing.

This is the most frequent failure I find on small sites. A developer adds the English tag to the Turkish page, then forgets the Turkish tag on the English page. Both pages look tagged; however, Google treats the pair as unlinked. As a result, the wrong language appears in the results, and nobody understands why.

Run the example calculation again from the other side. If you delete one product page in a 3 language group, the two remaining siblings still point to a dead URL. That breaks their pairs too, so one deletion damages three pages. Therefore, deletion checklists need a hreflang step, not only a redirect step.

Why does every page need a self-referencing tag?

Google's requirement reads: "Each language version must list itself as well as all other language versions." The self reference confirms that the current URL belongs to the group under that exact language code. Otherwise, the group has a hole in it.

In the Ahrefs study I cite later, a missing self reference appeared on 18% of sites with hreflang. That figure surprised me at first, because it looks so basic. Then I looked at how plugins work: many only output "the other languages", because that felt logical to whoever wrote the code.

Still, the fix is trivial once you see it. Your English page must include an "en" line pointing to its own URL, alongside the "tr" and "de" lines. If you use my four line pattern from earlier, the self reference is already there, because the block is identical on every sibling.

How do hreflang and canonical work together?

The two tags cooperate when each language version canonicalises to itself and the hreflang tag points only at those canonical URLs. Problems start when a hreflang line targets a URL that is not the canonical, for example a version with tracking parameters or a trailing slash mismatch.

The Ahrefs research found that 8% of sites point hreflang at non canonical URLs. Google then faces a contradiction: canonical says "this URL does not represent the page", while hreflang says "this URL is the German version". In that conflict, hreflang usually loses, so fix the strings first.

My checklist for a single page runs in this order:

1. Confirm the canonical points to the page's own clean URL.
2. Copy that exact URL, including the trailing slash, into the hreflang lines of every sibling.
3. Verify each sibling's canonical matches the URL you used for it.

If you generate canonical and meta tags with the meta tag generator, reuse the same URL string for hreflang. Consistency at the string level prevents most of these conflicts.

ccTLD, subdomain or subdirectory: which URL structure fits a multilingual site?

Google compares three structures for multi regional sites in its multi regional guide. Each one also sends a different geographic signal and carries a different cost. The table below combines Google's notes with what I have seen in practice.

For most Turkish businesses going abroad, I recommend subdirectories, which is also what talhaaslan.com uses. Country domains only make sense when a single country brings most of the revenue and you can afford separate marketing. If the site is being planned from scratch, my web design process sets this structure before the first template exists.

Why is IP based automatic redirection harmful?

Google's guidance is direct: "Avoid automatically redirecting users from one language version of a site to a different language version." The main technical reason is crawling. Googlebot mostly crawls from the United States, so an IP redirect sends it to your English pages and hides the others.

Users suffer as well, because they lose control. A Turkish speaker travelling in Germany lands on the German page and cannot switch back. Someone sharing a link sends the reader to a different language than the one they saw. Consequently, the redirect that felt helpful becomes a wall.

Instead, show a small banner suggesting the likely language and let the visitor decide. Keep every version reachable by URL, keep the switcher visible on every page, and let the hreflang tag route searchers on the search engine's side. That combination respects both Googlebot and people.

How do you find and test hreflang tag errors?

You test hreflang in four passes: syntax, HTTP status, reciprocity and canonical agreement. Search Console used to help here, but the International Targeting report disappeared in 2022. Google's help page confirms it "will continue to support and use hreflang tags on your pages", so the tags still matter; only the report is gone.

My testing sequence for a page group looks like this:

1. Open the raw source of each version and confirm the full block exists.
2. Paste every href into the redirect checker and confirm each returns 200, not 301 or 404.
3. Check that each target page contains a line pointing back to the page you started from.
4. Compare each hreflang URL to the target page's canonical, character by character.

For sites above a few hundred URLs, a desktop crawler with a hreflang report replaces the manual passes. Still, the logic is the same four questions, and I run them again after every template change. Most hreflang tag breakages start with a redesign, not with the original setup.

What are the most common hreflang mistakes?

Ahrefs analysed 374,756 domains in its hreflang study and found that 67% of sites using hreflang had at least one issue. The percentages below come from that study, with a one line fix from me for each.

• Missing x-default, 56.3%: add one line per group pointing to your default version.
• Missing self reference, 18%: make every page list its own URL under its own code.
• Pointing to redirected or broken URLs, 16.9%: recheck every href after any URL change.
• Missing return links, 15.3%: generate blocks per group, never per page.
• Pointing to non canonical URLs, 8%: copy the canonical string exactly.
• Invalid language or country codes, 4.6%: validate against ISO lists, and remember en-GB, not en-UK.

Notice that none of these mistakes concern translation quality. They are all matching errors. That is exactly why I keep repeating that hreflang is a pairing discipline, and why a generator plus a checker beats a careful human every time.

How does the hreflang tag work on Bing and other search engines?

Bing reads hreflang, but weighs it lightly. Fabrice Canal from the Bing team said in September 2020 that "hreflang is indeed a far weaker signal than content-language at Bing". So if Bing traffic matters to you, add a content-language meta tag to every page as well.

In practice, the extra line is simple: a meta element with http-equiv="content-language" and the language code as its content. It costs nothing and also does not conflict with Google. On my German pages, for example, that line reads "de" and sits directly under the charset declaration.

Also remember that no search engine uses hreflang to detect the page's language. Google says it relies on algorithms that read the visible content, not the hreflang tag or the HTML lang attribute. In other words, a German page with English body text remains an English page, whatever the tags claim.

How do you handle the same language in different countries?

You create one URL per country version and give each its own regional code, plus a language only fallback for everyone else. A typical set for a Turkish store selling to Turkey and to Turkish speakers in Germany looks like this, as a purely technical example:

• hreflang="tr-TR" pointing to the Turkey page with lira prices.
• hreflang="tr-DE" pointing to the Germany page with euro prices and EU shipping terms.
• hreflang="tr" pointing to whichever of the two you treat as general.
• hreflang="de-DE" and hreflang="de-AT" for the German versions, if pricing differs.

However, the trap is creating regional pages that differ only in the tag. Google instead expects real differences: currency, delivery, legal notes, contact details. If nothing differs, use one page with a language only code and save yourself the maintenance. In e-commerce consulting projects, this decision usually comes down to whether the checkout genuinely changes per country.

Should partially translated pages get hreflang?

Only pair pages that are true equivalents. A page that is half translated, or a page that exists only in Turkish, such as a legal disclosure under Turkish law, should stay out of the hreflang group. Pointing an English tag at a Turkish page misleads both Google and the visitor.

On my own site, some Turkish legal pages have no English or German counterpart. Therefore, those pages carry no hreflang block at all, and the English pages simply do not mention them. Leaving a tag empty is a valid decision; forcing a false pair is not.

When a translation is in progress, publish the hreflang lines together with the finished page, not before. Otherwise, you announce a version that returns a placeholder or a 404, and you land in the 16.9% broken URL group from the Ahrefs data.

Your step by step hreflang setup checklist

Before you launch or audit a multilingual site, walk through these ten steps in order. Each step also catches one specific class of error from the sections above.

1. Decide the URL structure: subdirectory, subdomain or country domain.
2. List every page group and confirm each version is a real equivalent.
3. Choose language only or language plus region codes per group.
4. Pick x-default and apply the same choice across the whole site.
5. Select one delivery method: HTML head, HTTP header or sitemap.
6. Generate the full block per group, including the self reference.
7. Set every canonical to the page's own clean URL.
8. Test every href for a 200 status and exact canonical match.
9. Remove any IP based redirect and replace it with a language banner.
10. Recheck the whole set after every redesign, migration or page deletion.

Print this list if you must. In practice, the sites that keep hreflang healthy are the ones that treat step ten as a routine, not as a one time launch task.

Does the hreflang tag directly improve rankings?

No. The hreflang tag is not a ranking signal, and I will not pretend otherwise. What it does is make sure the version that ranks is the right one for the searcher. However, that distinction has a very real commercial effect.

Picture a German searcher who lands on your English page because the pairing is broken. The page ranks, the click happens, and the visitor leaves within seconds because the language is wrong. Your ranking looked fine in reports; however, the conversion never occurred. Fixing the pairing changes which page appears, and therefore changes how many visitors stay.

So treat hreflang as conversion protection rather than a ranking trick. If you want a second pair of eyes on a multilingual setup, or you are planning one from scratch, you can contact me directly. I review the pairs myself, without an agency in between.