Is en-UK a valid hreflang code?

No. The ISO 3166-1 Alpha 2 code for the United Kingdom is GB, so the correct value is en-GB. Search engines ignore en-UK.

It is optional, but recommended. It tells search engines which page to show users who match none of your listed languages or regions, often a language selector or main international page.

Should localized pages canonicalize to the English page?

No. Each localized page should canonicalize to itself. Pointing canonicals to another language tells search engines to drop the localized version, which conflicts with hreflang.

Is a subfolder or a ccTLD better for international SEO?

Subfolders on one domain are usually the most efficient because authority is shared and maintenance is simpler. ccTLDs give a strong country signal but require building each domain separately.

Can I use automatic redirects by country?

It is risky. Googlebot mostly crawls from US IP addresses and may never see other versions. Serve the requested page and suggest the local version with a banner instead.

Does hreflang help rankings?

Hreflang does not boost rankings directly. It helps search engines show the right version to the right users, which improves relevance, click-through and conversions in each market.

International SEO and hreflang without mistakes

ccTLD vs subfolder vs subdomain

There are three common ways to separate markets. Each one works; the right choice depends on your resources and how independent each market is.

Structure	Example	Strengths	Trade-offs
Country code top-level domain (ccTLD)	example.de, example.co.uk	Strongest country signal, local trust	Separate domains to build authority for, more cost and admin, limited to countries not languages
Subfolder	example.com/de/, example.com/en-gb/	Shares the authority of one domain, simplest to run	Country targeting relies on hreflang and content signals
Subdomain	de.example.com	Can be hosted separately, flexible for teams	Often treated more like a separate site, authority less shared
URL parameters	example.com?lang=de	Easy to implement	Not recommended, hard for users and search engines

Our default recommendation

For most businesses, subfolders on one generic domain are the most efficient choice: one domain to build links to, one technical setup to maintain, and clear sections per market. ccTLDs make sense when local trust really matters, you have strong local teams, or legal and commercial reasons require separate entities. Whatever you choose, keep it consistent across all markets.

Geotargeting signals today

Google retired the international targeting report in Search Console, so you cannot set a target country for a subfolder there anymore. Google now relies on signals such as ccTLDs, hreflang, local content, currency, addresses and links from the region. That makes clean hreflang and real localization more important, not less.

Decide what actually differs

Before writing a single hreflang tag, decide whether you are targeting languages, regions, or both.

Language only. One Spanish version for all Spanish speakers. Use language codes such as "es".
Language plus region. Different English pages for the US and the UK because prices, spelling and legal terms differ. Use codes such as "en-US" and "en-GB".
Both together. A general "en" page as a fallback, plus specific "en-GB" and "en-AU" pages where you have them.

Only create a separate regional version when something real differs: currency, pricing, availability, shipping, legal text, or meaningful vocabulary. Ten nearly identical English pages that differ by one word create duplicate content problems and maintenance overhead without helping users.

English variants worth separating

Code	Market	Common differences
en-US	United States	USD, US spelling ("optimize", "color"), US legal terms
en-GB	United Kingdom	GBP, UK spelling ("optimise", "colour"), VAT language
en-CA	Canada	CAD, mix of spellings, bilingual expectations in some provinces
en-AU	Australia	AUD, UK-style spelling, GST, local terms

If you serve these markets, our guides for the UK, Canada and Australia cover local search specifics.

The codes

The hreflang value is a language code, optionally followed by a region code.

Language uses ISO 639-1 two-letter codes: en, de, fr, es, pl.
Region is optional and uses ISO 3166-1 Alpha 2 country codes: US, GB, DE, CA, AU.
Join them with a hyphen: en-GB, de-AT, fr-CA.
Never use a region alone. "GB" by itself is invalid.
Use the correct country code. The United Kingdom is GB, so "en-UK" is wrong and is ignored.

Codes are case-insensitive, but the convention of lowercase language and uppercase region makes them easier to read.

A complete set in the HTML head

For a page available in US English, UK English and German, every one of the three pages carries the full set:

<link rel="alternate" hreflang="en-US" href="https://example.com/en-us/pricing/" />
<link rel="alternate" hreflang="en-GB" href="https://example.com/en-gb/pricing/" />
<link rel="alternate" hreflang="de" href="https://example.com/de/preise/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/pricing/" />

Return tags and self-reference

Hreflang only works when it is confirmed in both directions. If the US page points to the UK page, the UK page must point back to the US page. Missing return tags are the most common reason hreflang is ignored. Each page must also list itself in the set, which is why the full block is identical on every version.

What x-default does

The x-default value tells search engines which page to show users whose language or region matches none of your versions. It is usually a language selector page or your main international version. It is optional but strongly recommended.

Three methods

Method	Best for	Watch out for
HTML link tags in the head	Most sites with HTML pages	Adds weight to every page on sites with many languages; must be in the head, not the body
HTTP headers	Non-HTML files such as PDFs	Harder to maintain and audit
XML sitemap	Large sites, many locales, templated platforms	Each URL entry must list all alternates, including itself

Pick one method per set of pages and stick to it. Mixing methods is allowed but makes conflicts likely and audits harder.

Sitemap example structure

In a sitemap, each URL element lists every alternate with an xhtml:link element, including itself. The same block repeats for every URL in the set. Large multilingual sites often find this easier to generate and keep correct than head tags.

Run free audit

Canonical must point to itself per locale

Each localized page should have a self-referencing canonical. The en-GB page canonicalizes to the en-GB URL, the de page to the de URL. Hreflang then connects them as alternates.

The classic mistake is canonicalizing every language version to the main English page. That tells search engines the other versions are duplicates that should not be indexed, which directly contradicts the hreflang annotations. In that conflict, the localized pages usually drop out of the index.

Only indexable, canonical URLs in hreflang

Every URL in a hreflang set should return a 200 status code, be indexable and be its own canonical. Redirecting URLs, noindex pages, or URLs that canonicalize elsewhere break the set.

The list we check first

Wrong codes. en-UK instead of en-GB, or region codes used without a language.
Missing return tags. Page A references B, but B does not reference A.
No self-reference. The page lists alternates but not itself.
Canonicals to another language. Localized pages canonicalized to the English version.
Hreflang to non-200 URLs. Alternates that redirect, 404 or are noindex.
Relative URLs. Hreflang should use absolute URLs including the protocol.
Mismatched pages. Pointing a product page to the other locale's home page instead of the equivalent product page.
Tags in the body. Link tags that end up outside the head due to template errors.
Untranslated templates. Navigation, footer and buttons left in the original language.
Duplicate regional pages with no differences. Many English versions with identical content and prices.

Automatic IP redirects are risky

Automatically redirecting users to a version based on IP address causes real problems. Googlebot crawls mostly from US IP addresses, so aggressive IP redirects can stop it from ever seeing your other versions. Travelers, VPN users and people who prefer another language get forced onto the wrong page. A safer approach is to serve the requested URL, then offer a clear, dismissible banner suggesting the local version, and remember the user's choice.

What localization adds

Translation converts words. Localization adapts the page for the market.

Currency and pricing. Show local currency and prices that make sense in that market, including tax conventions.
Spelling and vocabulary. US and UK English differ in spelling and in terms people actually type into search.
Keyword research per market. The phrase people search in Germany is not always the literal translation of your English keyword.
Legal and trust elements. Local terms, payment methods, shipping information and support hours.
Examples and references. Local units, date formats and familiar examples.
Metadata. Titles, descriptions and alt text localized too, not only body copy.

Machine translation is a draft, not a page

Raw machine translation published at scale tends to read poorly and miss local search terms. Use it to speed up drafts if you like, but have each market reviewed by a fluent editor who knows the subject and local search behavior.

What to check after launch

Crawl the site with an SEO crawler that reports hreflang errors: missing return tags, invalid codes, non-200 targets and canonical conflicts.
In Search Console, inspect localized URLs to confirm they are indexed and that Google selected your canonical, not another language version.
Check the Pages report for localized URLs marked as duplicates or alternates with a different canonical.
Review the Performance report filtered by country to confirm the right version gets impressions in each market.
Search from each market, or with a location setting, for your brand and key terms, and check which version appears.
Repeat the crawl after every significant template or URL change.

A practical sequence

Decide whether the market needs a language version, a regional version, or both.
Choose and document the URL structure.
Run keyword research in the local language for that market.
Localize priority pages first: home, top categories or services, pricing, and key guides.
Add self-referencing canonicals and full hreflang sets, including x-default.
Add the new URLs to your XML sitemaps.
Replace IP redirects with a suggestion banner.
Crawl, fix errors, and validate in Search Console.
Build local signals: relevant links and mentions from the market, local business details where relevant.
Monitor country-level performance monthly and expand content once the core pages perform.

Markets are built into every plan

As an international seo agency, AgencySEO scales by market: Small covers 1 market, Growth 2, Scale 5 and Enterprise 10, each as a monthly retainer bought online with no sales calls and no setup fee. Work includes structure decisions, hreflang and canonical audits, local keyword research, localized content and editorial links from each market, reported in your panel. Plans are month-to-month and you keep ownership of all content and accounts.

If your current hreflang setup is uncertain, a free SEO audit shows where the sets break and which versions Google actually indexes.