Hreflang that every version agrees on.

What hreflang does

Hreflang annotations tell Google which URLs are language or regional versions of the same page, so Google Search can point each user to the most appropriate one. The aim is that a searcher in Manchester sees your en-GB page with prices in pounds, one in Texas sees your en-US page, and a Turkish speaker sees your Turkish page.

What hreflang doesn’t do is tell Google which language a page is in. Google works that out from the visible content and uses neither hreflang nor the HTML lang attribute for it. Translating only the menus and footer isn’t enough either: Google treats language versions as duplicates when their main content is in the same language.

Codes that work, and codes that don’t

Each value is an ISO 639-1 language code, optionally followed by an ISO 15924 script code and an ISO 3166-1 alpha-2 region code: en, en-GB, zh-Hant. The language always comes first and is never optional, because Google doesn’t derive a language from a country code. Case doesn’t matter, so en-gb and en-GB are the same.

In audits, these are the code errors we see most:

• en-UK. Google says UK, like EU and UN, has no effect; the United Kingdom’s code is GB, so use en-GB.
• uk on its own, which means Ukrainian, not British English.
• gb or us with no language in front: a region on its own is invalid.
• es-419 for Latin American Spanish, which Google doesn’t support.

Return links, URLs and canonicals

Each version must list itself and every other version. Annotations work in pairs: if your en-GB page points to your tr-TR page but the Turkish page doesn’t point back, Google ignores that pair, while pairs that do point to each other still count. URLs must be fully qualified, including https://, and HTML link tags must sit inside a well-formed head section.

List the URL you want indexed in each market: the final address, not one that redirects or carries noindex. Keep canonicals in step. Google’s guidance is to give a localised page a canonical in the same language, so never point your Turkish page’s canonical at the English one; on most sites each version is simply its own canonical.

If your UK and US pages are essentially the same English content, Google may treat them as duplicates and pick one. It recommends using hreflang alongside canonicals to help it show the right regional URL, but the stronger fix is to localise the pages properly, with their own prices, spelling and delivery terms.

Annotations can go in the HTML head, in HTTP Link headers, which suit PDFs, or in an XML sitemap using the xhtml namespace. Google treats the three as equivalent, so choose the one you can keep accurate. In a sitemap, each url entry lists every version, itself included.

Setting up the UK, US and Türkiye

Use regional codes only where versions differ. If one English page serves everyone, en is enough. If you run separate UK and US pages with their own prices, spelling and delivery terms, label them en-GB and en-US, and consider an en page as the catch-all for English speakers elsewhere, as Google’s own example does.

The same logic applies to Turkish. tr describes a page for Turkish speakers anywhere and tr-TR one for users in Türkiye. With a single Turkish version, tr is usually the simpler and more accurate label; a region code earns its place when you have two Turkish versions to tell apart.

Google recommends x-default for the fallback: the page people see when no version matches their language or region. Point it at your international English page or a language selector, and use the same URL across the whole cluster.

Don’t redirect visitors automatically by IP address or browser language. Google advises against it, because such redirects can stop users and search engines seeing all your versions, and Googlebot usually crawls from the US. Link to the other versions instead and let people choose.

Keeping clusters in sync

Hreflang fails quietly: nothing looks broken, but the wrong version appears in the wrong market. In audits it has usually gone wrong when the site changed, with a new market added to some templates but not others, a page retired in one language only, or a migration that changed URLs while the annotations kept the old ones.

Treat each cluster as one unit. When you add a version, update every page in the cluster in the same release; when you remove one, take it out of every annotation and redirect or retire the URL. Generate annotations from the same data as your canonicals and sitemaps, not from a hand-kept list.

When you work through the validator above, fix missing return links first, since Google ignores those pairs, then invalid codes, then URLs that redirect or aren’t canonical. Search Console’s International Targeting report has been deprecated, so check the Google-selected canonical in URL Inspection for key pages, and validate again after any release that touches templates or URLs.