Hreflang SEO: Selling Overseas From Australia

Every Australian business that expands overseas hits the same wall. The site is correct for one market and confusing for the search engines serving four, and nobody notices until the overseas pages stop appearing in front of the people they were built for.

I have spent 13 years working on Australian sites, and the pattern is consistent. The market decision gets made commercially, the pages get built, and the technical signal that ties the versions together is either missing or wrong in a way nobody checks.

This is written for the owner or marketer whose site now has an Australian version and at least one overseas version, and who wants to know whether the setup is right before investing further. It covers what hreflang tells a search engine, when you need it and when you do not, the three ways to implement it, and the mistakes that quietly stop a whole set from working.

What hreflang is really telling search engines

Language, region and the difference between them

Hreflang is an annotation that says which language and which region a page is aimed at, and which other pages are the same page for a different audience. It is not a ranking device and it does not lift anything on its own.

Two dimensions matter. Language is what the page is written in. Region is who it is written for. English written for a reader in the United Kingdom and English written for a reader in Australia share a language and represent two different regions, and those are two different signals.

Getting that distinction right is most of the work. Most broken setups I look at have the language part correct and the regional part vague or inconsistent.

What hreflang cannot do for you

It cannot work out your page's language for you. Per Google's guidance on telling Google about other language versions of your page, "Google doesn't use hreflang or the HTML lang attribute to detect the language of a page; instead, we use algorithms to determine the language."

It also cannot translate a page, cannot make two near identical pages genuinely different, and cannot rescue a setup where the versions are not really aimed at different audiences. It describes a relationship. If the relationship is not real, the annotation describes nothing.

Which Australian businesses actually need it

Selling into several English speaking markets

The clearest case is a business selling the same thing into several English speaking markets. Australia, New Zealand, the United Kingdom, the United States, Canada, Ireland, Singapore. Same language, different prices, different delivery promises, different spelling conventions and different legal requirements.

Without the annotation, a search engine has to choose which version to serve, and it will often choose for you. Frequently it chooses something reasonable for a general audience and wrong for the reader who needed the local terms and the local currency.

This is also where I see the most avoidable damage. A UK reader lands on the Australian page, sees prices in dollars they cannot identify, and leaves, and the business concludes that the market is not interested.

When one English site is genuinely enough

If you sell the same thing in the same way everywhere, and your prices, shipping and terms do not change by market, hreflang has nothing to connect. One English site serving everybody is a legitimate and far simpler position to hold.

The test is whether the reader would genuinely benefit from a different version. If the answer is no, the annotation adds maintenance work with no payoff, and it is one more thing to get wrong later. Some background on how I approach that judgement sits in about my background.

The three ways to implement hreflang

HTML link elements

The most common method is a set of link elements in the head of each page, one for every version in the set, including the page you are on. It is easy to read, easy to break, and the only method most content management systems support without custom work.

Two rules from Google's guidance do most of the heavy lifting. "Each language version must list itself as well as all other language versions." A set that omits itself is incomplete, and an incomplete set behaves much like a set that was never there. The other rule is about what the tags point at: "Alternate URLs must be fully-qualified, including the transport method (http/https), so: https://example.com/foo , not //example.com/foo or /foo".

HTTP headers and sitemaps

HTTP headers carry the same information for files that cannot hold markup, such as PDFs, and they are the tidiest option when you cannot edit the page itself.

Sitemap entries can carry the annotations for a whole set at once, which is easier to maintain at scale on a large site. Whichever method you choose, commit to one per page set rather than mixing them, because mixed methods are where most of the avoidable faults come from.

Reciprocity: the rule that breaks most setups

Why a one way tag is ignored

Reciprocity decides whether any of this works. Per Google's guidance, "If two pages don't both point to each other, the tags will be ignored." A page pointing at its counterpart while the counterpart points somewhere else is a one way relationship, and it is treated as though it did not exist.

This is the fault I find most often, and it always appears the same way. A new market is launched, the new page is built correctly, and nobody returns to add the matching tags on the older pages. The new page then points at pages that are not pointing back.

Self referencing tags and the full set

A complete set is every version referencing itself and every other version. Three markets means three tags on each page, not two. Four markets means four tags on every page in the set.

The arithmetic is worth stating plainly, because a set that is almost complete behaves exactly like a set that is not complete at all. There is no partial credit here.

Language and region codes done properly

Two letter codes versus region variants

Codes come at two levels. A language on its own, such as en or fr, and a language with a region, such as en-AU or en-GB. The regional form is more specific, and it is the right choice whenever you have more than one version of the same language.

Do not invent codes. Use the documented two letter language and region values rather than a country abbreviation, a made up variant or a lowercase mix. An unrecognised code is simply ignored, and it takes the whole set down with it.

Handling Australian English and the global default

If your site serves Australia and other English speaking markets, be explicit about which page is the Australian version, and consider a generic English page as the fallback for everybody else. Being specific about the Australian page is what stops a global English page being served to Australian readers.

Read Google's own worked example in full before you settle your structure, because it shows how the generic and specific versions are expected to coexist rather than compete. Most of the confusion I see comes from a site treating them as alternatives when they are meant to sit side by side.

Common configuration faults I find in audits

Mixed protocols and redirected targets

The classic cluster of faults. Some tags pointing at http while the pages serve over https. Some pointing at a URL that redirects. Some pointing at a trailing slash variant that is not the canonical form of the page.

Each one weakens the annotation, and together they can cancel it. Every target in a hreflang set should be the live, canonical, absolute version of that page, served over the same protocol you are telling the search engine about.

None of this is exotic. It is what happens when a site migrates protocol or changes URL structure and the tags are not included in the migration checklist.

Tags that vanish once the page renders

If your hreflang tags are inserted by script, they may be missing from the initial response. That is now a fault worth checking for, because the annotation needs to be present when the page is read, rather than appearing only once it has been rendered.

The test takes a minute. Fetch the URL and look at the head of the response. If the tags are not there, part of the signal is not there either.

It is worth knowing how small a minority this whole practice is. Per the Web Almanac 2024 SEO chapter, hreflang is in use on "10% of desktop websites and 9% of mobile websites". A minority of sites declare their market structure at all, and the ones that do it badly are counted in that number.

Testing and maintaining a hreflang set

Checks worth running before launch

For each page in the set, five checks. Does it reference itself. Does it reference all the others. Is every URL absolute and fully qualified. Does every target return the canonical version without redirecting. Does the annotation survive the initial response.

The state of the wider web is worth knowing here. Per a study of hreflang across 374,756 domains, "When we ran a study on hreflang across 374,756 domains, we found that 67% of the hreflang implementations had issues." That is a study of other people's sites rather than yours, but it tells you how normal these faults are and how easily they are missed.

Where the work involves a professional services site and its markets, the shape of it is the same kind of engagement I keep examples of in work with professional services clients.

What breaks when you add a new market

Adding a market breaks a previously correct set, because every existing page now needs one more tag. The failure mode is always one directional. The new pages are built properly and the old pages are forgotten.

Treat a new market as an edit to every page in the set rather than as an addition to the site. Put the check into the launch process so it happens without anybody having to remember it, since the person who remembers is usually the person who has moved on.

What to settle before you translate anything

Structure, URLs and market decisions

Structure decisions come before any content work. Are the language versions going on subdirectories, subdomains or separate domains. Which markets are you genuinely serving, and which of them share a language but need a regional version. Who owns the content in each market. Who signs off on what the pages say.

Those four decisions determine what the hreflang set has to express. Getting them wrong means rebuilding the annotation later, or discovering that the site structure cannot support the markets you have already committed to commercially.

The translation work itself sits outside this piece. This is about the structure the translated pages will live in, and it is much cheaper to settle before anybody starts writing.

The cost of getting the setup wrong

The cost is not one mistake. It is the compounding one. A market that receives the wrong version loses local search visibility over months, and the correction usually involves changing URLs that by then have links, history and analytics attached to them.

That is why I treat hreflang as a pre expansion check rather than a project. I do SEO consulting for international growth for Australian businesses, and the first step is a review of one page set to confirm the tags point both ways and the targets are live.

Where the wider picture needs reviewing at the same time, a marketing audit before you expand is the sensible place to start, because the market decision and the technical structure should be settled together rather than a year apart.

Frequently asked questions

Do I need hreflang if I only sell in Australia?

No. If you have one version of your content for one market, hreflang has nothing to connect. It only earns its place when you have multiple versions of the same page aimed at different languages or regions.

What is the most common hreflang mistake you see?

One way tags. A page points to its counterpart and the counterpart does not point back, and the pair is then ignored. It usually happens when a new market is added and only the new page gets updated.

Should Australia be en-AU or just en?

If you also target other English speaking markets, be specific where you can and consider a generic English page as the fallback for everybody else. Being explicit about the Australian version is what prevents a global English page from being served to Australian searchers.

Does hreflang help with duplicate content between markets?

It helps search engines understand which version belongs to which audience, which is the point of it, but it is not a duplicate content cure on its own. The audience mapping has to be real, not a tag applied to pages that say the same thing to the same people.

Can I use hreflang on pages that are only partly translated?

Yes, and Google's guidance covers that case, but be honest about it. If the main content is identical across versions, the versions are effectively the same page for the same reader and the setup will not achieve much.

How do I know if my hreflang setup is working?

Check a full page set. Every version should reference itself and all the others, the URLs should be absolute, the targets should be live and canonical, and the tags should survive rendering. Then repeat the check after each new market is added.