Publish the same site in English and Croatian, English and German, or any other language pair, and you introduce a problem search engines don’t solve automatically: deciding which language version to show a given searcher. Without a clear signal, Google might show your Croatian page to someone searching in English, or index both versions as separate, competing pages instead of recognising them as equivalents. hreflang is the tag that fixes this - when it’s implemented correctly, which is where most sites go wrong.
What hreflang actually solves
hreflang tells search engines “this page has an equivalent in another language, and here’s the URL for it.” When someone searches in French, Google can then choose to surface the French URL from a cluster of equivalent pages instead of the English one, purely based on language and, optionally, region. It does not translate content, does not affect ranking directly, and does not replace good multilingual UX like a visible language switcher.
When you actually need it (and when you don’t)
Use hreflang when you maintain genuinely equivalent pages in different languages that should swap places in results depending on the searcher’s language - a bilingual marketing site, a company blog published in two languages, or region-specific pricing pages. You don’t need it for a single-language site with an on-page translate widget, since there’s no separate crawlable URL to annotate. A blog that’s only partially translated should annotate just the pairs that genuinely match - don’t force hreflang onto an English post that has no real Croatian equivalent.
How the tags actually work
Each language version of a page needs a link element (or sitemap entry) pointing to every other language version, including itself - this is the self-reference rule people forget most often. The pattern is symmetrical: if the English page links to the Croatian one, the Croatian page must link back to the English one using matching URLs. Language codes follow ISO 639-1 (en, hr, de), optionally combined with a region code (en-us, en-gb) when you need to distinguish more than just language. An x-default tag lets you specify a fallback for searchers whose language doesn’t match any of your versions, often pointing at a language switcher or your primary market’s page.
There are two valid ways to declare the tags: <link> elements inside each page’s <head>, or entries inside the XML sitemap. HTML tags are simpler to reason about on a small site, but every page carries the weight of listing every language variant, which gets noisy past three or four languages. Sitemap-based hreflang keeps the HTML clean and is usually the better choice once you’re maintaining more than a couple of language pairs, since all the relationships live in one file that’s easier to generate programmatically.
Mistakes that break hreflang silently
- Missing return tags - page A points to page B, but B doesn’t point back to A, which most search engines simply ignore as invalid.
- Using non-standard or invented language codes instead of the actual ISO values.
- Pointing hreflang at a redirected or non-canonical URL instead of the final, indexable one.
- Forgetting the self-referencing tag - each page must list itself among its own alternates.
- Skipping x-default and leaving searchers with no clear default when their language doesn’t match any variant.
Most of these mistakes are invisible in a normal browser test, since the page still renders fine - they only show up when a crawler or validator checks the raw hreflang relationships. That’s exactly why they tend to survive for months on real sites: everything looks correct to a human, and the failure only costs you the searchers who never see the version meant for them.
A real example: English and Croatian on the same domain
A common, workable structure is language-prefixed paths on one domain: yoursite.com/en/services and yoursite.com/hr/usluge. Every English page lists its Croatian counterpart in hreflang, every Croatian page lists the English one back, and both list themselves. If the site later adds German, each existing pair simply grows to a trio - every page in the cluster references every other page, plus itself. The pattern doesn’t change whether you’re pairing English with Croatian, Spanish, or Japanese; only the URL structure and language codes do.
How to verify it’s actually working
URL Inspection in Search Console will show you the canonical Google chose for a given page, which is a useful sanity check if hreflang seems to be getting ignored. Crawling the site with an SEO tool that reports hreflang errors (missing return tags, wrong codes) catches most implementation mistakes before they reach production. Manually checking search results from a VPN or incognito session set to the target language is a rough but useful spot-check for whether the right version is actually surfacing.
A short checklist before you ship hreflang
- List every language/region pair you actually maintain as genuine equivalents - don’t force partial content into the cluster.
- Add hreflang tags (via <link> elements or the sitemap) with correct ISO language and region codes.
- Make sure every page in the cluster references every other page, plus itself, symmetrically.
- Add an x-default for language-neutral entry points if your audience includes searchers outside your listed languages.
- Crawl the site after launch to confirm there are no missing return tags or broken URLs in the hreflang set.
Killer Click builds bilingual and multilingual sites with routing and hreflang planned from day one, so the technical SEO doesn’t fight the information architecture months after launch - it’s part of the same decision as the URL structure itself.