Hreflang Tags: When You Need Them and How to Set Them Up

# Hreflang Tags: When You Need Them and How to Set Them Up

If your site serves people in more than one country or language, you have probably heard about hreflang tags — and that they are confusing and easy to mess up. Both are true, but only because the rules are pedantic, not because the concept is hard.

Here is the plain version: hreflang tells Google which version of a page to show to which user, based on language and country. If you only sell to one country in one language, skip it. If you serve multiple languages or regions, getting it right is the difference between a French visitor landing on your French page or getting dumped on your English page and bouncing in three seconds.

This guide covers who actually needs hreflang, how to set it up without breaking anything, and the small handful of mistakes that cause most of the problems.

What hreflang tags actually do

Hreflang is an HTML attribute that tells search engines two things about a page:

1. What language it is written in
2. Optionally, what region or country it is targeted at

When Google understands these signals, it tries to serve the right version to the right user. A searcher in Mexico looking for your product should land on your Spanish-Mexico page, not your generic Spanish page or your English one.

The tag itself looks like this in the page's HTML head:

html

The hreflang value uses ISO codes: a language code (like en or es), optionally followed by a country code (like us or mx). The x-default value is a fallback for users whose language or country does not match any of your other versions.

Hreflang is not a ranking factor. It does not make you rank higher. It only helps search engines pick the right page to show to the right user.

Do you actually need hreflang?

This is the question most small business owners get wrong.

You probably need hreflang if:

• You have the same content in multiple languages (English and Spanish versions of the same product page)
• You target multiple English-speaking countries with localized content (US prices in dollars, UK prices in pounds)
• You have country-specific subdirectories, subdomains, or domains (example.com/uk/, uk.example.com, example.co.uk)

You probably do not need hreflang if:

• You only sell to one country in one language
• You have a single English site with a few translated marketing pages but no localized content
• Your "international" presence is just shipping to other countries from the same US site

Be honest about this. Adding hreflang to a site that does not need it adds complexity and a new surface area for bugs.

The three common setups

There are three legitimate ways to structure a multi-region site, and hreflang works with all of them.

Country-code top-level domains (ccTLDs): example.fr, example.de, example.co.uk. Each country gets its own domain. The clearest signal to users and search engines, but expensive and operationally heavy. Big enterprises use this.

Subdomains: fr.example.com, de.example.com. Cheaper than ccTLDs and still clearly separated. A decent middle ground for businesses growing into multiple regions.

Subdirectories: example.com/fr/, example.com/de/. Easiest to manage, all your domain authority lives in one place, and most small businesses end up here. If you are starting from scratch, this is what I would recommend.

The hreflang setup logic is identical across all three. Only the URLs in your tags change.

What goes wrong without hreflang

Imagine you run an online store selling handmade leather bags. You have an English site at yourstore.com and a Spanish version at yourstore.com/es/. Without hreflang, Google sees two pages with similar layouts, similar product images, and translated text. It may:

• Treat them as duplicate content and pick one to show
• Show your English page to Spanish-speaking customers in Spain because the English page has more backlinks
• Mix and match, showing your homepage in English but your product page in Spanish to the same user

The user lands on a page they cannot read, hits the back button, and you lose the sale. With correct hreflang, Google understands these are alternate versions of the same content for different audiences and serves the right one.

How to set it up: a practical walkthrough

Say you have a SaaS product with three versions:

• English for the US: yourapp.com/en-us/
• English for the UK: yourapp.com/en-gb/
• Spanish for Spain: yourapp.com/es-es/

On every page across all three versions, you add hreflang tags pointing to all alternate versions, including itself. This is the part most people miss.

In the HTML head of the US English homepage:

html

On the UK English homepage, the exact same set of tags. Same for the Spanish homepage. Every version references every other version, including itself. This is called "self-referencing" hreflang and it is required.

For the pricing page, repeat the pattern with the pricing URLs:

html

Every page has its own set of hreflang tags pointing to its translated equivalents.

Three ways to implement hreflang

Pick the one that fits your stack.

1. HTML head tags. The most common method. Works on any site where you can edit templates. WordPress (with a plugin), Webflow, and Shopify (with an app) all support this.

2. HTTP headers. Used when you cannot edit HTML, like for PDFs or other non-HTML files. The hreflang values are sent in the HTTP response header. Rare for small business sites.

3. XML sitemap. List hreflang relationships in your sitemap.xml. This works well for large sites where you want to manage hreflang centrally instead of editing every template. The downside: sitemap-based hreflang is easier to drift out of sync with the actual site.

For most small business sites, HTML head tags are the right choice. They are visible, easy to debug, and supported by every SEO tool that audits your site.

The four mistakes that break hreflang

Most failed hreflang setups come down to these.

1. Missing self-reference. Every page must include a hreflang tag pointing to itself. If your English page lists hreflang tags for French and Spanish but not English, Google ignores the whole set.

2. Non-matching return tags. If page A says page B is its Spanish version, page B must also say page A is its English version. Both pages have to point at each other. Otherwise the relationship is broken.

3. Wrong language or country codes. Use ISO 639-1 for languages (en, es, fr, de) and ISO 3166-1 Alpha 2 for countries (US, GB, MX, ES). Common mistakes: en-uk instead of en-gb, using en-eu (Europe is not a country code), or inventing codes that do not exist.

4. Pointing to redirects or non-canonical URLs. Your hreflang tags should point to the final, indexable URL. If a tag points at a URL that redirects, has a noindex directive, or has a canonical pointing elsewhere, Google ignores it. The same applies to 404s — clean up old tags when you remove language versions.

A pre-launch checklist

Before you push hreflang live, run through this:

• [ ] Every page has a self-referencing hreflang tag
• [ ] Every alternate has a return tag pointing back
• [ ] All language and country codes use the correct ISO format
• [ ] All URLs in hreflang tags are absolute (full URLs, not relative paths)
• [ ] All URLs return 200 OK and are indexable
• [ ] You have an x-default fallback set
• [ ] The hreflang set is identical across all versions of the same page

Testing your hreflang setup

Three quick verification steps after you ship.

Check the raw HTML. View the source of a page (Ctrl+U or Cmd+Option+U) and search for "hreflang". The tags must be in the section. If they end up in the body, they are ignored.

Use Google Search Console. Inspect individual URLs and watch for hreflang errors. This is the most authoritative source, since it tells you what Google itself sees.

Run a site crawl. Tools that crawl your full site check return tags, identify mismatches, and flag pages where hreflang is missing or broken. This is how you catch problems at scale on sites with hundreds of pages.

A small business scenario

A woodworking shop in Texas sells custom cutting boards on Shopify at woodshop.com. Most customers are in the US, but a growing share are in Mexico. The owner translates the top 30 product pages into Spanish and publishes them at woodshop.com/es-mx/.

Without hreflang, the Spanish pages get ignored by Google. Mexican customers searching in Spanish keep landing on the English homepage. Bounce rate from Mexico is 85%.

The owner adds hreflang to every page. On every English page:

html

Mirror set on every Spanish page. Within a few weeks, Spanish-speaking searchers in Mexico start landing on the right pages. Bounce rate from Mexico drops to 40%. Spanish-language pages start ranking on google.com.mx.

This is the kind of thing hreflang quietly fixes. It does not boost your rankings — it stops you from leaking visitors to the wrong language.

When to bother and when not to

Set up hreflang if at least one of these is true:

• You see traffic in your analytics from countries where you have or want localized content
• You are losing visitors to high bounce rates from non-English-speaking regions
• You sell physical products with shipping or pricing that varies by country
• You serve regulated industries where local page versions are legally required

Skip it if:

• You translated three pages as an experiment and have no clear traffic from those regions
• You serve a single market and just want to "look international"
• You cannot keep translations in sync (out-of-date translations hurt more than no translations)

Run a free audit on your hreflang

If you are not sure whether your hreflang is working, the fastest way to find out is to scan your site. A free audit flags missing tags, broken returns, invalid codes, and pages with hreflang pointing at redirects or 404s — every issue covered above. Run yours at FreeSiteAudit and get a checklist of what to fix.

Final thoughts

Hreflang sounds intimidating but is mostly mechanical once you know the rules. Pick a URL structure that fits your business. Add the tags consistently. Make sure every page references every alternate, including itself. Use correct ISO codes. Test with Search Console.

That is it. There is no magic. Avoid the four common mistakes — missing self-references, broken return tags, invalid codes, redirects — and your tags will quietly do their job, directing the right visitors to the right pages without you having to think about it again.

Sources

• Google: Tell Google about localized versions of your page
• Google: Creating helpful, reliable, people-first content