How to Set Up Hreflang: A Step-by-Step Guide for Multilingual Sites

You run a site in English, Spanish and Turkish, and a user in Madrid searches on Google only to land on your English page. Or your Turkish page shows up where your Spanish one should. Behind problems like these there is usually a missing or broken hreflang setup. This guide walks through what hreflang actually does, the decisions you need to make before touching any code, how to write the tags correctly and what to check once the site is live.

What hreflang is and what problem it solves

Hreflang is an annotation that tells search engines which language, and optionally which region, a page is written for. It connects equivalent pages across languages and tells Google: these pages cover the same thing, show each user the version that fits their language and location best.

Hreflang is not a ranking factor. It will not push a page higher. What it does is make sure that when a page already ranks, the right language version is the one people see. That means more relevant traffic, fewer users bouncing because they hit the wrong language, and clearer signals when you have regional variants of the same language, such as separate English pages for the UK and the US.

Before you start: get the URL structure right

Hreflang sits on top of your URL structure, so that structure needs to be solid. Every language version needs its own permanent, crawlable address. Switching language with a cookie or browser setting while keeping the same URL means search engines can only ever see one version.

There are three common options, and hreflang works with all of them:

• Subfolders: example.com/en/, example.com/es/, example.com/tr/ — the easiest to manage, and all authority stays on one domain.
• Subdomains: en.example.com, es.example.com — useful when each language needs a technically separate setup.
• Country domains: example.es, example.com.tr — a strong local signal, but each domain has to build its own authority.

Choose the right language and region codes

An hreflang value starts with a language code and can be followed by a hyphen and a region code. Language codes follow ISO 639-1 (en, es, tr); region codes follow ISO 3166-1 Alpha-2 (GB, US, ES, TR). A region code cannot be used on its own: “es” is valid, “ES” by itself is not a language.

Only add a region when the content is genuinely region-specific. If your Spanish page serves both Spain and Latin America, plain “es” is enough. If it quotes prices in euros and describes a service available only in Spain, “es-ES” is more accurate. The single most common mistake is “en-UK” for the United Kingdom; the correct code is “en-GB”.

Step-by-step implementation

You can implement hreflang in three ways: link elements in the HTML head, HTTP headers (useful for non-HTML files such as PDFs) or entries in your XML sitemap. Pick one method for the whole site and stick to it. The steps below assume the head method:

Here is the head of an English services page. The Spanish and Turkish pages should carry the same four hreflang lines; only the canonical tag changes so that each page points to itself.

• Build a mapping table that lists every page and its equivalents in each language; leave a cell empty if a translation does not exist.
• On every page, add link elements for all language versions, including the page itself. The self-reference is required.
• Make the links reciprocal: if the English page points to the Spanish one, the Spanish page must point back.
• Always use absolute URLs, including the protocol.
• Define an x-default for users whose language you do not serve.
• Generate the tags from your CMS or templates rather than by hand, so new pages are covered automatically.

<!-- <head> of https://www.example.com/en/services/ -->
<link rel="canonical" href="https://www.example.com/en/services/" />
<link rel="alternate" hreflang="en" href="https://www.example.com/en/services/" />
<link rel="alternate" hreflang="tr" href="https://www.example.com/tr/hizmetler/" />
<link rel="alternate" hreflang="es-ES" href="https://www.example.com/es/servicios/" />
<link rel="alternate" hreflang="x-default" href="https://www.example.com/en/services/" />

Getting x-default and canonical to work together

x-default is the page shown when a visitor’s language does not match any of the versions you offer. It is usually the English version or a language-selector landing page.

Canonical and hreflang should support each other, never contradict each other. Each language version should have a self-referencing canonical. If your Spanish page canonicalises to the English one, you are telling Google the Spanish page is not the real page, and your hreflang signal is likely to be ignored. Only include URLs in hreflang that return a 200 status, are indexable and are canonical.

Language switchers and automatic redirects

Hreflang is for search engines; people on your site rely on the language switcher. A good switcher takes visitors to the equivalent of the page they are on, not to the homepage of the other language. Label languages in their own language (English, Español, Türkçe) rather than with flags, which represent countries, not languages.

Redirecting automatically by browser language or IP is tempting, but be careful. Googlebot mostly crawls from the US, and a forced redirect can stop it from ever seeing your other versions. A safer pattern is a small suggestion banner that lets the user choose.

The hreflang mistakes we see most often

Most problems found in technical audits come down to the same handful of errors:

• Missing return links between language versions.
• Invalid codes such as en-UK, es-SP or a country code on its own.
• Hreflang pointing to redirected, 404 or noindexed URLs.
• Relative URLs such as /es/servicios/.
• Automatic IP-based redirects that stop crawlers from reaching other language versions.
• Thin, machine-translated language versions published without review.

Post-launch checklist

Hreflang is not a set-and-forget setting. New pages, new languages and URL changes all affect it. After launch, crawl the site with an SEO crawler and review its hreflang report, use URL Inspection in Google Search Console to see which canonical Google has chosen, and track performance by country.

Quick checklist:

• Does every page reference itself?
• Are all links reciprocal?
• Do the codes follow ISO standards?
• Do all target URLs return 200 and self-canonicalise?
• Is x-default defined?
• Does the language switcher take users to the same page in the other language, not to the homepage?

Wrapping up

Done properly, hreflang lets a multilingual site speak to each market in its own language. The essentials are simple: a clean URL structure, valid codes, reciprocal links and alignment with canonicals. At Norcored we build English, Spanish and Turkish sites with hreflang planned from day one, and we are happy to review an existing setup if you are unsure about yours.

FAQ

Will hreflang improve my rankings?

Not directly. It is not a ranking factor. It makes sure the correct language version of a page that already ranks is shown, which tends to bring more relevant traffic and a better user experience.

Should I put hreflang in the head or in the sitemap?

Both are valid. On small and medium sites the head method is easier to audit; on large sites the sitemap keeps page weight down. What matters is choosing one method and applying it consistently.

What if a page has no translation in one language?

List only the language versions that exist for that page. Do not point the missing language to your homepage or to an unrelated page.