Hreflang and International SEO: Common Mistakes and How to Fix Them

Every year, businesses spend thousands of dollars on translation, local content teams, and regional marketing-only to watch Google serve the wrong language version to the wrong audience. The culprit is almost always hreflang implementation.

Google's John Mueller has called hreflang "one of the most complex aspects of SEO (if not the most complex one)." That complexity breeds errors at an alarming rate. Research from LinkGraph found that over 65% of international websites have significant hreflang implementation errors. And these aren't just theoretical problems: seoClarity has documented anywhere from a 20% to 300% lift in impressions and organic traffic in regions where hreflang was implemented correctly.

The gap between broken hreflang and working hreflang is, in many cases, the gap between an international site that grows and one that stalls. This guide breaks down the most common mistakes practitioners encounter, explains why each one damages your international visibility, and provides specific steps to fix them.

What Hreflang Actually Does (and What It Doesn't)

Before fixing mistakes, you need a precise understanding of what hreflang is-and what it isn't. The hreflang tag is an HTML attribute that indicates to search engines what language and geographical targeting your webpages are intended for, useful for websites that have multiple versions of a page for different languages or regions.

Think of it as a relational map. Hreflang isn't a language switcher. It's a relational map that tells search engines how different versions of the same content connect across languages and regions. When someone in France searches on Google.fr, hreflang tells Google which URL in your set of alternates to present. Here's the critical nuance most guides bury at the bottom: hreflang is a hint, not a directive. Google's John Mueller explains that hreflang tags act as suggestions, not directives.

This means Google may not always display the exact regional page you intend, even if hreflang tags are implemented correctly. Other signals-canonical tags, content relevance, page authority-can override your hreflang annotations. That's why getting the implementation technically clean is non-negotiable; sloppy hreflang gives Google easy justification to ignore your preferences entirely.

Hreflang vs. Geo-Targeting: They Solve Different Problems

Hreflang addresses language and regional content variants. It does not replace geo-IP redirects, and it's not a substitute for properly setting up your domain structure (ccTLDs, subdomains, or subdirectories). One website owner thought hreflang would indicate to Google that his site was targeting Germany, but his site used a country-specific domain (www.example.de), and this alone indicates a targeting preference-the hreflang markup was meaningless because his site didn't have translated or localized content.

If you only serve content in one language and don't have regional variants, you probably don't need hreflang at all. Mueller has explained that "different language version is a lot easier than the same language – different countries," noting that for purely multilingual sites, Google is often able to match language versions without hreflang.

Mistake #1: Missing or Broken Return Tags

This is the single most common hreflang error, and it invalidates your entire setup for the affected pages.

Hreflang tags should be self-referencing (each page must include a reference to itself) and bi-directional (each page that has an hreflang tag should also be included in the hreflang tags of the pages it references). When Page A references Page B as its French alternate, Page B must reference Page A right back. Skip this, and Google discards both annotations.

Google's own documentation states explicitly: "If page X links to page Y, page Y must link back to page X. If this is not the case, those annotations may be ignored or not interpreted correctly."

The problem scales brutally. One broken return link doesn't just affect two pages-it can destabilize whole clusters of alternates. Mixed signals from some versions being properly linked and others not can lead search engines to distrust or drop hreflang signals entirely for a given set of pages.

How This Mistake Happens in Practice

This mistake often occurs when teams add new language versions. The new Spanish pages include hreflang tags pointing to English pages, but nobody updates English pages to reference the new Spanish versions. The one-way relationship fails validation.

CMS updates compound the issue. Content management systems attempt to simplify hreflang implementation through plugins and automation, but automated solutions introduce new error possibilities when incorrectly configured-common CMS errors include generating wrong language codes, creating annotations for non-existent pages, or failing to update tags when pages get deleted or moved.

The Fix

Establish a system where every hreflang annotation is generated from a single source of truth. Maintaining reciprocity across large sites requires systematic approaches. Documentation should list all language versions, and implementation checklists should verify bidirectional links before deployment. Automated validation catches missing returns before they reach production.

Run Screaming Frog's hreflang crawl: its "Missing Return Links" report shows the page missing a return link and which page is not confirming the relationship. Export the report, cross-reference, and fix before resubmitting affected pages.

Mistake #2: Wrong Language and Region Codes

This mistake is embarrassingly common and entirely preventable. Country codes must follow ISO 3166-1 Alpha-2 format and language codes use ISO 639-1 format. A misspelling like "en-uk" instead of the correct "en-gb" to indicate English speakers in the United Kingdom will cause failures.

According to a 2023 study, about 8.9% of websites in hreflang clusters contain invalid language codes. These aren't obscure edge cases-they're fundamental formatting errors.

The Most Common Code Mistakes

• Using "UK" instead of "GB." The ISO standard for the United Kingdom is GB, not UK.

It's important to get the region code right as it can sometimes be counterintuitive.

• Capitalization errors.

Writing "EN-us" instead of "en-US" breaks the annotation completely. Search engines require exact formatting-language in lowercase, country in uppercase, with a hyphen separator.

• Using underscores instead of hyphens.

An invalid hreflang like "en_US" fails because the correct way to write a language code is with dashes, not underscores-the correct value is "en-US."

• Three-letter codes or full names.

Some developers use three-letter language codes or full country names instead of proper ISO standards. Phrases like hreflang='english-usa' accomplish nothing.

• Specifying a region without a language.

Hreflang tags must include proper ISO language and region codes-don't specify a country code by itself. Google doesn't automatically derive the language from the country code.

The Fix

Establish a code standard. Document your language-region combinations clearly and ensure all team members follow identical formatting conventions across every implementation. Bookmark the ISO 639-1 language code list and ISO 3166-1 Alpha-2 country code list. Validate every new hreflang annotation against these references before deployment.

Mistake #3: Canonical Tag Conflicts

The relationship between hreflang and canonical tags is where even experienced SEOs stumble. The relationship between hreflang and canonical tags is one of the most misunderstood aspects of international SEO. Hreflang URLs must be canonical URLs.

The most common mistake involves pointing canonical tags across language versions. Each language version should canonicalize to itself, not to a single "master" version. When your Spanish page canonicalizes to your English page, you tell Google the Spanish page is duplicate content-directly contradicting your hreflang annotation claiming it serves Spanish users.

This contradiction doesn't just cause confusion. It tells Google your own signals disagree, which gives the search engine permission to make its own choice. And Google's choice frequently isn't yours.

When Same-Language Regional Pages Get Canonicalized

A subtler version of this problem surfaces with same-language regional pages. When two pages are nearly identical in content, such as fr-fr and fr-be, Google may select one as the canonical version.

If two pages share the same language, Google's systems may group them. Even if hreflang presents the correct variant to users, metrics often consolidate into the canonical version.

The solution isn't just technical-it's editorial. Add unique elements to each regional page. The more distinct the content, the less likely Google is to group it under one canonical URL. Localized pricing, shipping information, regional regulations, and local case studies all create genuine differentiation.

The Fix

Audit every page in your hreflang cluster. Confirm that each page's canonical tag points to itself. If your canonical tags point to the wrong version (e.g., the global homepage instead of the local one), Google gets mixed signals. Make sure the canonical and hreflang tags align-each page should have a self-referencing canonical.

Mistake #4: Forgetting the X-Default Tag

Forgetting the x-default value is a common error. This tag specifies a default page for users whose language doesn't match any of your provided options. The fix: assign your most generic page (e.g., the English/international version) as x-default.

Although x-default hreflang attributes are optional, Google recommends them as a way to "control the page when no languages match." SEO best practice is to use x-default tags for all hreflang annotations.

Without x-default, a user whose language-region combination doesn't match any of your specified alternates gets whatever Google decides to show them. That might be a page in a language they don't read.

X-Default Implementation Pitfalls

Only one x-default tag should exist on any given page-having multiple x-default declarations will cause search engines to ignore all of them, potentially disrupting your entire international SEO strategy. This single-tag rule is absolute and non-negotiable, yet it remains one of the most common implementation errors found in technical audits.

It is possible and valid to define a page for a specific locale/language AND also as the x-default hreflang. Despite this often being intentional, sometimes x-default has been included by accident, and the page is not a suitable fallback for the rest of the world. An x-default pointing to a page in Welsh, for example, serves almost nobody as a reasonable fallback.

The Fix

Designate one page as x-default-typically your English-language or international homepage. If you set x-default to a language-selection page or a global homepage, users can choose their preferred language. Include this x-default annotation identically across every page in your hreflang cluster.

Mistake #5: Pointing Hreflang at Non-Indexable or Broken URLs

Every URL in your hreflang annotations must be live, crawlable, and indexable. Broken or redirecting URLs referenced in hreflang annotations can severely undermine international SEO. When a hreflang link points to a 404 or a page that redirects, search engines waste crawl budget trying to validate the relationship, and hreflang signals from those pairs may be ignored.

Implementing hreflang on non-crawlable pages is another trap-if a page is blocked by robots.txt or has a 'noindex' tag, it cannot be part of a valid hreflang set. The fix: ensure all alternate pages are indexable and crawlable.

This error tends to accumulate silently over time. Pages get deleted, URLs change during site migrations, and redirects proliferate. Redirects or protocol changes break hreflang silently.

What About 301 Redirects?

Mueller's response on hreflang linking to 301s was: "If they 301 it's probably ok, but…" The "but" matters. When your hreflang tags point to redirecting URLs, you increase the chance of Google getting confused about which page belongs to which language or region. Clean hreflang should always point to the final, canonical, 200-status URL.

The Fix

Hreflang should always use absolute URLs, including protocol and domain. Run regular crawls to verify every URL in your hreflang set returns a 200 status. Screaming Frog's "Non-200 Hreflang URLs" report shows any URLs in hreflang annotations which are not a 200 response. Schedule this check monthly at minimum-quarterly is too infrequent for sites that update regularly.

Mistake #6: Mixing Implementation Methods

There are three ways to implement hreflang: HTML <link> tags in the <head>, HTTP headers, and XML sitemaps. It is considered best practice to only specify hreflang using a single method on any given URL, because using multiple methods makes the configuration more open to human error.

Imagine you implement hreflang on a page using both a tag in the <head> and in the HTTP header. Some time passes, and you move to a new domain. You change the hreflang in the <head> but completely forget about the HTTP header, and so do not change it. This sort of inconsistency would lead to search engines ignoring the hreflang instruction.

Choosing the Right Method

Google's John Mueller has said that they treat hreflang found in XML Sitemaps and HTML code markup equally. There's no ranking advantage to one method over another. The practical differences are about scale and maintenance. To use HTML meta tags, Google must visit all pages to validate the cross-references. With XML sitemaps, Google can get the alternate verifications by ingesting the sitemaps without visiting every page, which is why hreflang issues can be resolved in 48 hours via XML versus weeks for the other two methods.

For enterprise sites with hundreds of thousands of pages, XML sitemaps are the pragmatic choice. For sites targeting a large number of geos, XML sitemaps are probably the best option as they are easier to generate, maintain and, importantly, QA. Smaller sites with fewer than a hundred pages across all language versions can use HTML <link> tags without much overhead. Use HTTP headers for PDFs, images, or other non-HTML resources.

Whatever you choose, commit to it. Don't mix methods for the same pages.

Building a Sustainable Hreflang Audit Process

Getting hreflang right the first time is only half the battle. Regular audits are essential. Redirects, the addition of new pages, and changes in content on a constantly evolving website can lead to errors even on sites with perfectly written hreflang tags. That's really the biggest challenge of hreflang-it isn't just about writing correct code.

Your Audit Toolkit

The best audit workflow combines automated crawling with manual spot-checks:

• Screaming Frog SEO Spider:

While hreflang is a very simple concept, it's incredibly difficult to get right at scale. The SEO Spider crawls rel="alternate" hreflang annotations in HTML, via HTTP Header, or in XML Sitemaps and reports on their setup and common errors. Its dedicated hreflang tab surfaces missing return links, incorrect language codes, and non-200 URLs in a single view. - Ahrefs Site Audit: Schedule a daily, weekly, or monthly crawl in Ahrefs' Site Audit tool. New issues will show in the Localization report for the associated project after each scheduled crawl. This is ideal for ongoing monitoring between deep audits. - Hreflang.org Testing Tool: A free option useful for spot-checking individual pages and validating that return tags are in place. - Google Search Console: The International Targeting report has been deprecated, but Google will continue to support and use hreflang tags on your pages. You can still use the URL Inspection tool to verify how Google sees hreflang on specific pages.

The Audit Checklist

Run this checklist after every site migration, CMS update, or new language version launch: 1. Reciprocity check: Does every page in every hreflang cluster reference every other page, including itself? 2. Code validation: Do all language and region codes match ISO 639-1 and ISO 3166-1 Alpha-2? 3. Canonical alignment: Does each page's canonical tag point to itself, and does that URL match what appears in the hreflang annotation? 4. Status code check: Do all hreflang URLs return a 200 status? No redirects, no 404s, no noindex tags. 5. X-default presence: Is x-default declared once per hreflang cluster, pointing to an appropriate fallback page? 6. Method consistency: Are you using one implementation method per URL-not mixing HTML tags with sitemap annotations?

Check your hreflang setup every 3–6 months, or after any domain, URL, or CMS change. For enterprise sites with frequent content updates, monthly auditing is safer.

When Hreflang Alone Isn't Enough

Even flawless hreflang won't save a weak international SEO strategy. Consider Content Delivery Networks for serving content quickly worldwide. And never automatically redirect users based on their IP address or browser settings-this prevents search engines from crawling all your international versions and confuses users who may be traveling or using VPNs.

Content differentiation matters more than most teams realize. Similar content across regions won't be penalized if you implement hreflang correctly, but you should still consider making meaningful differences between regional versions, avoiding simply copying content without localization, and ensuring each version adds unique value for its target audience.

Hreflang tells Google which page to serve. Your content determines whether users stay. Don't be disappointed if you don't see an increase in traffic after implementing hreflang tags. The goal is to serve the right language version to the right users, and this might not necessarily translate to more website visitors. Looking for improvements to engagement and bounce rates may be a better way to measure whether your hreflang tags are making a difference.

--- Hreflang errors are among the most silently destructive problems in technical SEO. They don't trigger dramatic ranking crashes that send teams scrambling. Instead, they quietly ensure that months of localization work never reaches the audience it was built for. Companies spend heavily on translations, regional content, and local teams, yet undermine all that work if search engines can't match users with the right pages.

The fixes outlined here aren't complex in isolation. Return tags, ISO codes, canonical alignment, x-default declarations-each is a straightforward technical step. The difficulty is maintaining them across hundreds or thousands of pages as your site evolves, team members change, and CMS updates introduce subtle breakage. Build the system, not just the tags. Document your language-region combinations. Automate validation. Schedule recurring audits. Treat hreflang not as a one-time implementation task but as an ongoing discipline-because the businesses that get international SEO right are the ones that make it impossible to get wrong.