Running One Site for Two Countries: A Practical Guide to Hreflang Implementation

A five-month mistake with one wrong character

I once ran a site selling the same product into the UK and Australia, with a set of Australian pages written specifically for that market. For about five months, those Australian pages didn’t rank in Australia at all. The UK pages ranked there instead. Everything looked correct from the inside. The problem turned out to be a single character in a language code, and it took me longer than I’d like to admit to find it.

This is the international SEO piece, and I want to write it as a practitioner rather than as a spec document, because the spec is short and the ways it goes wrong are many.

The architecture decision comes first

Start with the architecture question, since it comes first and it’s expensive to change later.

You can run a separate country domain for each market: something.co.uk alongside something.com.au. This sends the strongest possible geographic signal, because a country code domain is unambiguous about who it’s for. It’s also the most expensive path by a distance. You’re running multiple sites, building authority separately for each, and every link you earn benefits only one of them.

You can run subfolders on a single domain: /uk/ and /au/ on the same site. This is the default answer for almost everyone, and it’s what I’d recommend if you asked me cold. One domain, one pool of authority, and every market benefits from links earned anywhere on the site.

You can run subdomains: uk.something.com. In my experience this splits the difference in a way that gets you the worst of both. Search engines treat subdomains as somewhat separate for authority purposes, so you take that cost without getting the clean geographic signal a country domain gives you.

Pick subfolders unless you have a specific reason not to. A specific reason might be a legal requirement to run a local entity, a genuinely different business in each market, or an existing country domain with years of history you’d be throwing away.

What hreflang actually does

Hreflang is the mechanism for telling search engines that two pages are alternate versions of each other for different audiences.

Start with what it doesn’t do. Hreflang is not a ranking factor. Adding it will not lift you in any market. It also isn’t protection against a duplicate content penalty, because there is no duplicate content penalty in the sense most people mean. What hreflang does is help a search engine choose which of your versions to show a given user. That’s the entire job.

The syntax, and why symmetry matters

On each version of a page, you list every alternate version, including the page itself, with a code saying who each one is for. A single entry looks like this:

<link rel="alternate" href="[full absolute URL of that version]" hreflang="[code for who it's for]" />

One of those lines per version, and critically, the identical block goes on every version. A site with three markets carries the same three lines on all three pages. That symmetry is the thing to picture, because most broken implementations are broken precisely because the blocks drifted apart.

Language codes vs region codes

The language part is a two-letter ISO 639-1 code. The region part is a two-letter ISO 3166-1 country code. That distinction is where my five-month problem lived, because I had written en-UK. The country code for the United Kingdom is GB. en-UK isn’t a valid value, and an invalid value is ignored entirely, silently, with no warning anywhere.

The mistakes that break most implementations

Beyond the code itself, three failures show up constantly.

Non-reciprocal tagging: if your UK page points at your Australian page as an alternate, the Australian page has to point back. When the return link is missing, search engines discard the relationship. This happens often on sites where one market’s pages are generated by a different template or maintained by a different person.

Missing self-reference: each page has to list itself among the alternates. People leave this out because it feels redundant. It isn’t optional.

Canonicals fighting hreflang: if your Australian page carries a canonical tag pointing at the UK page, you’ve told search engines the Australian page shouldn’t be indexed on its own, which contradicts what the hreflang is trying to say. Each localised page should canonicalise to itself. This one breaks more sites than any other single mistake I see.

When to add a region code

A related decision is whether to use a language code on its own or a language with a region attached. Plain “es” targets Spanish speakers wherever they are. “es-MX” targets Spanish speakers in Mexico specifically. The region form is narrower, and it only makes sense when you actually have something market-specific on the page. I’ve seen sites carve their Spanish content into five regional variants that were word for word identical, which achieves nothing except five times the maintenance. Start with language only. Add regions when the content genuinely diverges.

Translation is a separate problem

Translation is worth separating from all of this, because people conflate the two and they’re different problems. Hreflang handles which version gets served. It says nothing about whether the version is any good. Running your English pages through machine translation and indexing the output is a fast way to fill a site with content nobody wants to read, and search engines have got considerably better at recognising it. If you’re entering a market properly, budget for a human to at least edit the output. If you can’t, it’s a reasonable decision to serve that market in English and say so, rather than publish translations you can’t stand behind.

There’s also x-default, which nominates a fallback for users who don’t match any of your listed audiences. Use it on your global or English-language default. It’s optional and cheap to add.

On where to put the tags, you have three placements: in the head of the HTML, in the HTTP response header, or in your XML sitemap. Head tags are the easiest to reason about on a small site. Sitemap entries are the maintainable option once you have hundreds of pages, because everything lives in one file you can generate rather than scattered across templates. Header placement exists mainly for non-HTML files like PDFs.

The most damaging mistake has nothing to do with tags

Automatic redirection based on IP address does more damage than any tagging error. Someone visits from Australia, the server bounces them to the Australian version. It feels helpful, and it’s genuinely destructive. Googlebot crawls predominantly from US addresses. If your site force-redirects by IP, Googlebot sees the US version of everything and may never index the others at all.

The correct pattern is a suggestion rather than a redirect: detect the visitor’s likely market, show a banner offering to switch, and let them choose. Remember the choice in a cookie. Every large multinational site does it this way, and it’s not an accident.

Same language, different market

The same-language case confuses people, so let’s be direct about it. en-GB and en-AU pages that differ only in currency, spelling and a shipping paragraph are perfectly legitimate. That’s exactly what hreflang exists for. You don’t need to artificially differentiate the content to justify separate pages. You do need the pricing, shipping terms and contact details to genuinely reflect the market, because otherwise there’s no reason for the page to exist.

When the pages are near-identical and hreflang is absent or broken, a search engine picks one version and shows it everywhere. That’s the failure mode I opened with. It isn’t a penalty. It’s a search engine doing its best with insufficient information.

Pricing is usually the reason any of this exists, so handle it deliberately. Showing a visitor their local currency is fine, and you don’t need a redirect to do it. Detect the market, set the currency on the page, and leave the URL alone. What you want to avoid is a setup where the price a crawler sees differs from the price a customer sees at the same URL, because that’s how you end up with the wrong currency showing in search results and a bounce rate to match.

Consolidating two domains into one

There’s a migration case worth covering too, since it comes up whenever someone inherits a mess. If you’ve got two country domains and want to consolidate onto one site with subfolders, that’s a full site migration for both properties, with everything that implies. Map every URL to its destination, redirect one to one rather than to a category page, keep the redirects up permanently, and expect a dip. The upside is real, because you stop splitting authority across two domains. The cost is real too, and it’s front-loaded. I’d only do it if the smaller domain is genuinely underperforming rather than merely inconvenient.

Measuring whether it’s working

Search Console shows hreflang errors under its international targeting reporting where that’s still available, and more usefully, the performance report lets you filter by country. That filter is how you actually check this. Look at your Australian pages, filter to Australia, and see whether they’re the version being served. If the wrong version is showing, you have a real problem rather than a theoretical one.

If you’re running subfolders, set up a separate Search Console property for each folder. It takes two minutes and turns a single noisy dataset into per-market numbers you can act on.

A ten-minute audit for an inherited site

If you’ve inherited a site that already has hreflang and want to know whether it works, here’s the short version. Pick one page. View source, find the alternate block, and note it down. Now take each URL that block lists, open it, and compare its block against the one you noted. If all the blocks are identical across all the versions, reciprocity and self-reference are fine. Next, check that each page’s canonical points at itself. Last, check the codes against the actual ISO lists rather than against what looks reasonable, because en-UK looks entirely reasonable and is wrong. Four checks on a single page tell you whether the template is right, and if the template is right, the rest of the site usually is too, since nobody hand writes these.

Give it time. Hreflang changes take weeks to settle, not days, and they settle gradually as pages get recrawled. I wouldn’t draw conclusions inside a month. On a large site with slow crawl coverage it can run closer to two months before the picture is stable, so put a reminder in the calendar rather than reloading the report every Monday morning.

Hreflang is a hint, not a command

The honest caveat, and it’s a real one: hreflang is a hint. Search engines are explicit that they treat it as a signal rather than an instruction, and there are documented cases of correctly implemented markup being overridden. You’re improving the odds of the right page showing. You’re not commanding it.

Do you need any of this

Which leads to the question worth asking before any of it. Do you need it? If you sell one product, in one language, at one price, to anyone who’ll buy it, you probably don’t need multiple country versions at all. A single well-built site that mentions the markets you serve will do fine. The machinery in this article is for people with genuinely different pricing, stock, or legal terms per market. Adding it without that need buys you maintenance work and nothing else.

For more practical breakdowns like this one, drop by The SEO Desk.