Hreflang for Australia, the US and multi-market sites (2026)

Hreflang tells Google which language or regional version of a page to show. For Australian and US English versions, use en-AU and en-US, respectively, so Google can distinguish the audience for each regional page. Each version lists itself and its equivalents, with return tags connecting them. Add x-default for unmatched visitors. Keep canonical decisions separate.

An Australian software buyer should reach Australian product information, rather than discover halfway through an enquiry that the offer belongs to another market.

I'm Brenden House, founder of Searchmaxxed. This guide applies Google's documentation to an Australia and US launch, including the awkward cases a tag generator cannot decide for you.

Google documentation checked 28 October 2026 (AEST). Code and company scenarios below are worked examples, not client results.

In summary

• Hreflang connects equivalent pages. It doesn't translate content or create a regional offer.
• en-AU and en-US distinguish English-speaking markets; en covers English without a country restriction.
• HTML tags, HTTP headers and XML sitemaps are equivalent for Google. Choose the method your team can maintain.
• Return tags matter. A working Australian tag doesn't repair a missing US return tag.
• Audit whole page groups, including canonicals and redirects, before calling a regional launch finished.

What is hreflang, and when does a company need it?

Hreflang identifies alternate versions of the same content for different languages or regions. Use it when those versions have separate URLs.

A language version is a translation. A regional version can remain in English while changing the product information, commercial terms or contact route for a particular country.

Google explicitly includes small regional variations in its guidance on localised versions. Different languages aren't required.

Start with the offer. If the Australian and US versions differ, document what changes before engineering adds the tags to a shared page template across the site.

Our international SEO checklist covers that wider launch decision. Here, we're getting into the implementation.

Which hreflang codes should Australia and the US use?

Use en-AU for English targeting Australia and en-US for English targeting the United States. The language comes first.

Google supports language codes from ISO 639-1 and region codes from ISO 3166-1 Alpha 2. A country code alone isn't enough.

Use a hyphen, not an underscore. Google's current documentation accepts uppercase and lowercase values; uppercase region codes follow the standard convention.

The URL path doesn't decide the code. /au/product/, an Australian subdomain and a separate country domain can all participate in the same group of alternate pages.

The destination decides the meaning. A tag labelled en-AU must point to the Australian version, wherever that page lives within the website or across its separate country domains.

These rules come from Google's supported language and region codes.

How do you add hreflang tags for Australia and the US?

Put the complete alternate set in the HTML <head> of every equivalent page. Each page includes itself.

Consider a hypothetical B2B SaaS product. It has an Australian page, a US page and a general English page suitable for visitors outside those markets.

The general page serves both fallback roles. That is deliberate.

Place this identical alternate set on all the pages listed above:

<link rel="alternate" hreflang="en-AU"
      href="https://example.com/au/platform/" />
<link rel="alternate" hreflang="en-US"
      href="https://example.com/us/platform/" />
<link rel="alternate" hreflang="en"
      href="https://example.com/platform/" />
<link rel="alternate" hreflang="x-default"
      href="https://example.com/platform/" />

Use absolute URLs, including https://. Google specifies fully qualified destinations, rather than paths such as /au/platform/.

Keep the tags inside a valid <head>. They belong to this product's alternate set, not to every page sharing the same country folder or the same regional navigation menu.

That's the template trap. Repeating the homepage's alternate set across a catalogue does not connect the regional versions of each product.

What are return tags and self-referencing tags?

A return tag points back from an alternate page to the page that named it. A self-referencing hreflang tag names the current page.

Both matter here. The Australian platform page lists the US version, and the US page returns that relationship by listing the Australian platform page in its alternate set.

Google says it ignores relationships without return links. It can still process other reciprocal relationships, so one broken pair does not necessarily invalidate every connection across the site.

This is why a single-page check isn't enough. Fetch the destination too.

What does x-default do, and is it the same as en?

x-default specifies a fallback for unmatched language or regional settings. en specifies English without a country restriction. They aren't interchangeable.

Google recommends a general language URL when several regional versions share that language. Consider the unmatched visitor too.

Your general English page can serve both roles, as in the example above. A selector is another option.

Choose for the visitor. If someone reaches a manufacturing product page, a fallback that retains their product choice is more useful than sending them back through the catalogue.

That's a design recommendation, not an extra Google requirement. Google allows any page as x-default, although it says the value works best with language selectors.

The attribute doesn't redirect anyone. Your website's redirect behaviour is a separate decision, explained in Google's multi-regional site guidance.

Google advises against automatic language redirects and IP-based content adaptation. Let visitors choose their region.

Should hreflang go in the HTML head or an XML sitemap?

Google treats HTML tags, HTTP headers and XML sitemaps as equivalent methods. Maintaining several implementations brings no additional Search benefit.

Choose by ownership and maintenance. The method matters less than whether it keeps matching the pages your team actually publishes, changes and removes from the live website over time.

For Searchmaxxed technical work, this sits alongside sitemap engineering and rendering checks. We check the published output.

What does an hreflang XML sitemap look like?

An hreflang sitemap gives each page its own <url> entry. List every equivalent, including itself.

This smaller example has only Australian and US pages. It deliberately omits the general English page and optional fallback used in the earlier HTML example.

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
        xmlns:xhtml="http://www.w3.org/1999/xhtml">
  <url>
    <loc>https://example.com/au/platform/</loc>
    <xhtml:link rel="alternate" hreflang="en-AU"
                href="https://example.com/au/platform/" />
    <xhtml:link rel="alternate" hreflang="en-US"
                href="https://example.com/us/platform/" />
  </url>
  <url>
    <loc>https://example.com/us/platform/</loc>
    <xhtml:link rel="alternate" hreflang="en-AU"
                href="https://example.com/au/platform/" />
    <xhtml:link rel="alternate" hreflang="en-US"
                href="https://example.com/us/platform/" />
  </url>
</urlset>

Keep the XHTML namespace. Adding alternate links beneath only the Australian entry does not complete the US entry.

Google's hreflang sitemap instructions also apply its general sitemap rules. Google excludes alternate child elements when counting URLs towards the sitemap limit, so adding those relationships doesn't increase the counted total for the file.

How do HTTP headers work for PDFs?

Use the response's Link header to declare alternate PDF versions. Return the same alternate set from each document.

Link: <https://example.com/au/specification.pdf>; rel="alternate"; hreflang="en-AU", <https://example.com/us/specification.pdf>; rel="alternate"; hreflang="en-US"

Check the files themselves. A manufacturing specification's filename may look regional while its contents still describe the wrong product standard.

How should canonical tags work with hreflang?

A canonical identifies your preferred representative of duplicate or very similar content. Hreflang identifies language and regional alternatives. Use separate tags.

For distinct regional pages you intend to maintain separately, self-referencing canonicals are a sensible starting point. That is the assumption in our SaaS example.

The Australian page contains:

<link rel="canonical"
      href="https://example.com/au/platform/" />

The US page contains:

<link rel="canonical"
      href="https://example.com/us/platform/" />

The alternate set stays identical. The canonical changes with the page.

Don't combine hreflang with rel="canonical" in one link element. Google's canonical documentation says those combined annotations aren't used for canonicalisation.

Must every regional page always be self-canonical?

No. Google's multi-regional guidance permits a preferred canonical alongside hreflang for similar or duplicate same-language pages.

That distinction matters for Australia and the US. Both pages are English.

Don't flatten these into a universal rule. Google chooses its own canonical, and an annotation expresses your preference rather than forcing that selection.

Our canonical tags guide covers the wider duplicate-content decision. For hreflang, document the intended canonical beside each regional URL before engineering changes the template.

Which hreflang errors should you fix first?

Fix inaccessible destinations and incorrect page mappings before cosmetic formatting warnings. Then check return links, codes and canonical intent.

Google names missing return links and incorrect language or region codes among its common hreflang mistakes. Check the surrounding publishing controls too.

Searchmaxxed's technical SEO service covers crawl, canonical, sitemap and rendering fixes together. That matters when the apparent hreflang fault starts somewhere else.

An example: a new US page goes live, but its template still declares the Australian homepage as canonical. Adding more alternate tags won't fix that template.

How do you audit hreflang at scale without drowning in warnings?

Audit equivalent-page groups, then assign fixes to the templates or content records that generated them. A URL count alone hides the cause.

A hreflang cluster is the group of pages declared as regional or language equivalents. Build the audit around that group.

Here's a release map for an engineering team, for a hypothetical SaaS expansion. These are example decisions, not a Searchmaxxed client case study.

The security row matters most. A missing US security page is a content decision, not a reason to substitute the US homepage merely to fill a spreadsheet cell.

Leave it absent. When the equivalent page is ready, publish it and update the related annotations together, rather than introducing a relationship that points nowhere useful.

What should the audit export contain?

Keep a row for each declared relationship. Record the source URL, locale, target URL, response, return tag, canonical intent and responsible template.

Then group the findings. For the SaaS example, the engineering handoff might look like this:

That's actionable. The team knows what changes, where it changes and how to check whether the published version now matches the agreed regional page map.

What should you check before and after release?

Before release, compare the expected regional map with the generated annotations. Afterwards, fetch the live pages and repeat the checks.

1. Export published pages and their stable content IDs.
2. Join each content ID to its genuine language and regional equivalents.
3. Check every target's response, crawl access and indexing controls.
4. Compare each page's alternate set with the expected mapping.
5. Verify return links and self-references across the group.
6. Compare declared canonicals with the documented consolidation decision.
7. Check rendered HTML when JavaScript controls page metadata.
8. Recheck affected groups after a rename, deletion, redirect or regional launch.

Keep the mapping central. Generating tags, regional switcher links and sitemap entries from unrelated records creates extra places for a release to drift out of sync.

This fits Searchmaxxed's implementation scope: technical fixes ship alongside page work, with live verification. The tags aren't a separate product.

How do you know whether Google has understood the changes?

Use URL Inspection to examine Google's indexed view, including its selected canonical and last crawl. A clean live test isn't the same evidence.

Google explains the difference in its URL Inspection documentation, which separates information about the indexed page from what the live test can establish. The live test cannot predict Google's eventual canonical selection.

Separate the checks:

Do not treat a crawler's green status as Google's acceptance. It proves only what that crawler checked.

For regional duplicates, a different Google-selected canonical needs interpretation against the consolidation plan. It is not automatic proof that hreflang has failed.

Keep the commercial check too. The Australian page can have perfect tags while its enquiry form still routes a buyer towards the wrong market's product or sales contact.

Is Searchmaxxed right for your multi-market site?

Searchmaxxed fits companies that want technical SEO implemented, checked live and maintained alongside their commercial pages. We don't stop at the error export.

We build and fix the website. You own the site, repository, content and data, and speak directly with the people doing the work rather than through an account-manager relay.

Growth System and Agentic Search Engineering include technical work alongside page releases. Custom & Enterprise can cover multiple markets, dedicated engineering and custom reporting.

Choose the scope around the website. A regional expansion needs decisions about content and canonicals, plus someone able to make the changes in the system that actually publishes those pages.

Frequently asked questions

What should you do next?

Bring a regional URL map that distinguishes published equivalents from pages you still need to create for the markets you want to enter. Bring the pages, their intended audiences and any canonical decisions already made, so we can scope the technical SEO work against the actual site.

Let's talk pricing.