Hreflang Guide: Setting Up an English and Turkish Website

Hreflang is an annotation that tells Google about the different language or regional versions of the same page. Set up correctly on a site with English and Turkish versions, it means someone searching in Turkish sees the Turkish page and someone searching in English sees the English one. This guide covers the codes, the return link rule, the x-default value and the most common mistakes, with examples.

What hreflang solves and what it does not

For UK businesses serving both English and Turkish-speaking customers, a bilingual site is a common need. Without annotations, Google cannot always tell that two pages are translations of each other. It may show the wrong language or treat the two pages as duplicates.

What the tag does not do: it does not lift rankings by itself, it does not make a page visible in another country and it does not fix duplicate content on its own. Its job is simply to match the right version to the right user.

Google collects all the rules in its documentation on localized versions. Reading that page before you start prevents most of the mistakes below.

Write language and region codes correctly

The value is a language code followed by an optional region code. The language code comes from ISO 639-1 and the region code from ISO 3166-1 Alpha 2. Examples for a site like ours:

Value	Meaning	When to use it
tr	Turkish, all regions	You have one Turkish version
en	English, all regions	You have one English version
en-GB	British English	You also have a separate US version
x-default	Page shown when nothing matches	A language picker or main version

A frequent mistake is writing "en-UK". The correct code for the United Kingdom is GB. Another is using a region code alone; "gb" on its own is not a valid value.

The return link rule

This is the most important rule: every page must list all of its language versions, including itself. If the Turkish page points to the English page, the English page must point back. If the link only goes one way, Google may ignore the annotations.

Here is what a setup looks like. The head of the Turkish blog post contains these three lines:

<link rel="alternate" hreflang="tr" href="https://example.co.uk/tr/blog/yazi" />
<link rel="alternate" hreflang="en" href="https://example.co.uk/en/blog/post" />
<link rel="alternate" hreflang="x-default" href="https://example.co.uk/en/blog/post" />

The head of the English post carries the same three lines. Addresses must be full and absolute; do not use relative URLs.

Choose where to add the annotations

You can supply hreflang in three places. It does not matter which you choose, but use one method consistently:

1. HTML head: the most common method and the easiest to audit.
2. HTTP header: for non-HTML files such as PDFs.
3. XML sitemap: easier to manage on large sites with many pages and languages.

Most systems, including Next.js, WordPress and Shopify, can generate these tags through a setting or plugin. Even so, check the output by viewing the page source.

The risk with plugins is silent errors. A translation plugin may generate alternates for pages that have no translation, and those addresses return 404. Or it may list the language homepage as the alternate on every page. These errors are invisible on the page and only show in the source.

After setup, check the source of at least one blog post, one service page and the homepage. If it works on three different page types, it is very likely working across the rest of the system.

Using hreflang with canonical tags

Hreflang and canonical tags complement each other, but combined wrongly they cause problems. Each language version's canonical must point to itself. If the Turkish page's canonical points to the English page, Google treats the Turkish page as a duplicate and may drop it from the index.

For a broader check of canonicals and redirects, see our technical SEO audit guide. It walks through status codes and duplicate content checks in order.

Sending visitors to the right language

The tags handle matching in search results, but the experience on the site matters too. In its guide to managing multilingual sites, Google recommends keeping each language at its own URL. Swapping content at a single address based on browser language makes it harder for Google to see the versions.

Put a visible language switcher on every page. It should lead to the same content in the other language, not to the homepage. If a post has no translation, hide the switcher on that page or link to the language homepage.

Localise, do not just translate

The most overlooked part of a bilingual site is the content itself. Even with flawless tags, an English page that is a word-for-word rendering of Turkish text reads oddly to UK visitors. Search phrases do not map one to one between languages either.

A Turkish speaker might search "SEO ajansı Londra" while an English speaker searches "SEO agency near me" or uses a borough name. Prices, currency, date formats and phone number formats should suit each audience. On the Turkish page, stating clearly whether a sterling price includes VAT avoids confusing visitors from Türkiye.

Do keyword research separately for each language. Pages covering the same topic in two languages do not need headings that translate each other exactly. What matters is that both answer the same question and correspond to each other.

Common mistakes

These are the language annotation problems we see most often in audits:

• A page not listing itself; every page must include its own language code.
• Redirected or 404 addresses left in the annotations.
• Every language version pointing to the homepage instead of its own counterpart.
• Annotations present on one version and missing from the other.
• Sitemap and HTML methods used together with conflicting information.

Most of these appear when pages are added or addresses change. Changing a post's slug in one language only, for instance, leaves the other version pointing at the old address. Make the check a habit after every publish rather than a one-off task.

How to test the setup

Once the setup is live, run these checks in order:

• Confirm every language version's source lists all alternates.
• Check each listed address returns a 200 code and does not redirect.
• Confirm canonical tags point to themselves on every version.
• Track performance for each language folder separately in Search Console.

Within a few weeks, the performance report should show Turkish pages appearing for Turkish searches and English pages for English ones. To see your site's tags quickly, use our free SEO checker. To track each language folder separately, use the filtering steps in our Google Search Console guide.