Skip to content
Insight

International Technical SEO: Hreflang, Geo-Targeting, And Language Variants

International SEO gets messy fast. You start with a simple idea: show the right page to the right person in the right place. Then you launch 3 languages, add a second currency, spin up a subfolder for Europe, and suddenly Google is indexing the wrong version, users land on the wrong pricing, and your teams are arguing about whether you need hreflang, canonicals, or both.

Rick Talbot
Rick

Digital Director

This is where international technical SEO earns its keep. Not as a box-ticking exercise, but as a way to stop wasted effort and protect revenue.

In the UK, that matters because digital demand is not a side channel. In November 2025, 28.6% of retail sales in Great Britain were made online. If you get your international setup wrong, you are not just losing rankings, you are leaking money.

This guide breaks down the practical parts: hreflang, geo-targeting, and language variants, plus the decisions that stop international sites turning into a tangled web.

If you want the wider technical foundation behind this, you will find plenty of related technical SEO content in Totally Digital’s Insights section.

What international technical SEO actually means

International technical SEO is the structure and signalling that helps search engines:

  • discover each country and language version
  • understand which pages are equivalents
  • serve the correct version in search results
  • avoid duplicate content confusion across markets

It is not the same thing as translating your site. Translation is content. International SEO is making sure the content is routed and interpreted properly.

The main levers you control are:

  • URL structure (ccTLDs, subdomains, subfolders)
  • hreflang annotations (language and region alternates)
  • internal linking and sitemaps (discovery and priority)
  • localisation signals (currency, addresses, phone numbers, local content)
  • geo-targeting strategy (what you target and how)

Start with the decision that controls everything: URL structure

Before you touch hreflang, decide how you are separating markets.

You have 3 common options:

1) Country domains (ccTLDs)

Example:

  • example.co.uk
  • example.fr
  • example.de

Pros:

  • strong country signal
  • easier to ring-fence markets
  • often clearer for users

Cons:

  • expensive to maintain
  • link equity splits across domains
  • more work for analytics, tagging, and governance

2) Subdomains

Example:

  • uk.example.com
  • fr.example.com

Pros:

  • separate deployments if you need them
  • can be useful for legacy systems

Cons:

  • can behave like separate properties
  • tends to increase complexity without giving you the cleanest benefits

3) Subfolders

Example:

  • example.com/uk/
  • example.com/fr/

Pros:

  • authority consolidates under 1 domain
  • easier to manage at scale
  • usually simpler for tracking and reporting

Cons:

  • requires strong discipline to avoid cross-market duplication
  • needs clean routing and templating

Google’s own guidance recommends using different URLs for different language versions, rather than relying on cookies or browser settings.

If you are redesigning or rebuilding, lock this decision early. It is painful to change later, and it is exactly the type of thing an SEO-first build process should cover.

Hreflang: what it is and what it is not

Hreflang is the mechanism that tells search engines: these pages are the localised versions of the same core page, and here is which audience each one is for.

Two important truths that stop a lot of confusion:

  1. Hreflang does not detect language. Google uses algorithms to determine page language, and it does not rely on hreflang or the HTML lang attribute to detect it. 
  2. Hreflang is a hint, not a guarantee. You are improving the odds that the right version appears, not forcing it like a switch.

The basic hreflang pattern

For a page with UK English and US English variants, you typically want:

  • en-gb for UK English
  • en-us for US English
  • x-default for a neutral fallback (optional, but often useful)

You implement hreflang in 1 of 3 places:

  • HTML head (most common)
  • XML sitemaps (best at scale, especially for big sites)
  • HTTP headers (useful for PDFs or non-HTML resources)

The key rule that catches most teams: hreflang needs to be reciprocal. If UK points to US, US must point back to UK. If it is not a closed loop, Google may ignore parts of it.

Region targeting vs language targeting

If you have:

  • Spanish for Spain and Spanish for Mexico, you use language and region variants.
  • Spanish content that is identical worldwide, you may only need language targeting.

Where teams go wrong is over-segmenting. If you create en-gb, en-ie, en-au, en-nz but the pages are basically identical, you are creating complexity for very little gain. Sometimes you are better off with 1 English version plus strong localisation elements where they matter (currency, shipping, contact details).

Geo-targeting: what still works in 2026

A lot of SEOs still talk about “setting geo-targeting in Search Console”. That used to be a thing.

It is not anymore.

Google deprecated the International Targeting report and removed country targeting in Search Console, saying it had little value for the ecosystem. Google still supports hreflang, but the old country targeting toggle is gone. 

So what does geo-targeting look like now?

Strong geo-targeting signals you can control

  • ccTLDs (a direct country signal if you use them)
  • clear localisation on-page: addresses, phone formats, local policies, shipping, VAT handling
  • local currency and pricing
  • localised content beyond simple translation (terminology, units, cultural context)
  • internal linking that keeps users and bots within the right market
  • local backlinks and PR in each target country

In other words: you geo-target by building a version of the site that actually belongs in that market.

Language variants: the sneaky international problem

Not every international setup is UK vs France vs Germany. Sometimes it is:

  • UK English vs US English
  • French vs Canadian French
  • Portuguese vs Brazilian Portuguese

These “same language family” variants cause specific issues:

1) Thin localisation that looks like duplication

If your UK and US pages are 95% the same, Google may treat them like near-duplicates unless you clearly differentiate intent and context.

What helps:

  • currency and pricing aligned to the market (GBP for the UK)
  • shipping and returns content that is genuinely different
  • local case studies and proof points
  • spelling and terminology done properly (trainers vs sneakers matters more than you think)
  • different structured data where appropriate (for example, localBusiness details)

2) Wrong version ranking in the wrong place

This is the classic: your US page ranks in the UK because it is stronger, has more links, or has cleaner internal linking.

Hreflang helps, but it is not enough on its own. You need:

  • internal linking that favours the correct market
  • market-specific authority signals
  • clean canonicals (more on that next)
  • sitemaps segmented by market

3) Automatic redirects based on IP or browser

This is one of the quickest ways to break international SEO.

Google recommends different URLs per language rather than relying on automatic adjustments via cookies or settings.

If you force-redirect users and bots, you create problems like:

  • Googlebot cannot reach the alternate versions reliably
  • users cannot choose their preferred version
  • shared links break (someone in London clicks a US link and gets bounced)

A better pattern:

  • show a gentle market selector banner
  • remember the user’s choice
  • do not block access to any version

Canonicals and hreflang: how they should work together

This is where lots of international setups fall apart.

The rule of thumb:

  • canonical tags handle duplicates
  • hreflang handles equivalents

If you have UK and US versions, they are equivalents, not duplicates, so each page should normally canonical to itself.

What you do not want:

  • UK page canonical to US page
  • US page canonical to UK page

If you do that, you are effectively telling Google there is only 1 real version, while hreflang is telling Google there are many. Mixed signals usually lead to unpredictable results.

There are edge cases (like truly identical pages you do not want both indexed), but in most commercial international builds, you want each market page to stand on its own.

Hreflang implementation options that actually scale

Option 1: HTML head tags

Good for:

  • small sites
  • a handful of languages

Bad for:

  • large ecommerce sites
  • thousands of URLs
  • frequent releases

Every page needs a full set of alternates. That becomes maintenance debt quickly.

Option 2: XML sitemap hreflang

This is usually the cleanest choice at scale, because:

  • it is centralised
  • it is easier to validate
  • dev teams can generate it from a mapping table

You can also split sitemaps by market, which makes debugging and monitoring far easier.

Option 3: HTTP header hreflang

Useful for:

  • PDFs
  • non-HTML files
  • assets you still want localised in search

Common hreflang mistakes that waste months

Here are the ones that show up in international audits again and again:

Wrong codes

Use correct language and region codes. Small formatting mistakes can cause Google to ignore the annotations.

Missing return tags

If the relationship is not reciprocal, the cluster breaks.

Pointing to redirected URLs

If hreflang points to a URL that 301 redirects, you are adding friction and increasing the risk of Google ignoring it.

Non-indexable targets

If you point to pages blocked by robots.txt or set to noindex, you are not building a reliable alternate set.

Inconsistent canonical strategy

As above, self-referencing canonicals are usually the right move for equivalents.

Geo-targeting in practice: a UK-first example

Let’s say you are UK-based, selling into:

  • the UK in GBP
  • Europe in EUR
  • the US in USD

A clean setup might be:

  • example.com/uk/ (en-gb, GBP)
  • example.com/eu/ (language variants inside, EUR)
  • example.com/us/ (en-us, USD)

Then your international technical plan is:

  1. Build a clear mapping between equivalents (product, category, service pages)
  2. Generate sitemap hreflang from that mapping
  3. Ensure each version is genuinely localised (currency, shipping, contact, terminology)
  4. Keep internal linking mostly within the market, with a clear global selector
  5. Monitor indexing and performance per market, not blended

This is exactly the sort of joined-up measurement Totally Digital leans into with analytics and fix-first SEO work.

How you validate an international setup without losing your mind

You are aiming to validate 4 things:

1) Discovery

Can Google find all versions?

  • Market sitemaps submitted
  • Internal links exist from hubs and navigation
  • No accidental blocking

2) Indexation

Are the right pages indexed?

  • Each market version indexable
  • Canonicals self-referencing
  • No accidental duplication or parameter bloat

3) Correct targeting

Are the correct versions appearing in the correct countries?

  • spot-check branded and non-branded queries
  • check Search Console performance by country and page
  • look for patterns where the wrong market wins

4) Experience alignment

Does the page match the promise?

  • correct currency
  • correct shipping and returns
  • correct legal and contact details
  • correct language variant

International SEO fails when the technical setup says one thing and the user experience says another.

International SEO is also a content and authority job

Even with perfect hreflang, you still need to earn the right to rank in each market.

That means:

  • local keyword research (intent differs by country)
  • local content depth (not just translation)
  • local links and brand mentions
  • market-specific proof (case studies, testimonials, partner logos)

If you are mapping content and intent across markets, this type of content audit thinking helps.

And if you are running ecommerce internationally, keep a close eye on faceted navigation and duplication, because it gets worse when you copy the same problems into 5 markets:

A simple international technical SEO checklist you can use

Use this as your baseline:

  • Decide URL structure (ccTLD, subdomain, subfolder) and document it
  • Make each market version accessible at a unique URL (no forced redirects)
  • Build a page mapping table of equivalents across markets
  • Implement hreflang (preferably via XML sitemap at scale)
  • Include x-default where a neutral fallback makes sense
  • Keep canonicals self-referencing for equivalent market pages
  • Ensure sitemaps only contain 200 status, indexable URLs
  • Localise beyond translation (currency, contact, shipping, terminology)
  • Track performance by country and directory
  • Re-audit after every major release or market expansion

Next steps

International technical SEO is not glamorous, but it is one of the fastest ways to stop self-inflicted losses when you expand.

Get the URL structure right, implement hreflang in a way you can maintain, stop relying on old Search Console geo-targeting, and make sure each market experience genuinely matches the user’s expectations.

If you want this done properly, with a technical auditthat turns into a fix-first backlog your dev team can actually ship, start here.

Or if you are planning a rebuild or migration across multiple markets, bring SEO into the build early.

If you’re tired of traffic that doesn’t convert, Totally Digital is here to help. Start with technical seo and a detailed seo audit to fix performance issues, indexing problems, and lost visibility. Next, scale sustainably with organic marketing and accelerate results with targeted paid ads. Get in touch today and we’ll show you where the quickest wins are.

Rick Talbot
Rick

Digital Director