International SEO: Hreflang Mistakes That Tank Global Rankings

Key Takeaways:

• Hreflang implementation errors are among the most damaging and most overlooked issues in international SEO audits.
• Missing return tags, incorrect language codes, and structural confusion between subdomains and subdirectories are the top offenders.
• Global rankings suffer not because search engines penalize hreflang errors directly, but because those errors cause signal dilution, cannibalization, and wrong-locale indexing.
• Multinational brands need a systematic audit approach, not a one-time fix, to maintain hreflang integrity at scale.
• Practical, implementable fixes exist for every common mistake covered in this article.

Why Hreflang Still Breaks Global SEO in 2025

Let me be direct about something the broader SEO industry tends to dance around: hreflang is not complicated in theory, but it is brutally unforgiving in execution. And for multinational brands managing dozens of locale variants across multiple domains, subdirectories, or subdomains, a single implementation error can quietly destroy months of international SEO work without a single algorithmic penalty ever appearing in your Search Console data.

That is the insidious part. Hreflang mistakes do not announce themselves loudly. They bleed rankings slowly. Users in Germany get served an English page. Users in Australia land on a US-optimized experience. Organic traffic from target international markets stagnates or declines, and the root cause gets misattributed to content quality or link equity rather than a broken tag configuration that has been sitting in your codebase since the site launched.

After nearly two decades of auditing international SEO setups for enterprise brands and high-growth startups, I can tell you with confidence: hreflang is one of the highest-leverage, lowest-attention areas in global SEO. If you get it right, you unlock serious organic performance across markets. If you get it wrong, you are essentially funding a multilingual content operation that search engines are choosing to ignore or misroute.

This article walks through the most common hreflang mistakes we encounter during international audits, with actionable guidance on how to identify and fix each one. If your brand operates in more than one country or language market, this is required reading for your SEO team.

Quick Primer: What Hreflang Actually Does

Before diving into mistakes, let us establish a shared understanding of what hreflang is supposed to do. The hreflang attribute is an HTML tag that tells search engines which version of a page to serve to users based on their language preference or geographic location. Google and Yandex support it. Bing has its own handling of international signals, but generally respects it as well.

A correctly implemented hreflang tag looks like this:

<link rel="alternate" hreflang="en-GB" href="https://www.example.com/en-gb/page/" />

The tag communicates: serve this URL to users whose browser and search settings indicate they prefer British English. When implemented correctly across all locale variants of a page, it creates a self-referencing network of signals that allows Google to index and serve each version to the right audience without confusion. When implemented incorrectly, that network collapses, and Google is left making guesses, usually bad ones.

Mistake #1: Missing Return Tags (The Single Most Common Hreflang Error)

This is the one that shows up in nearly every international audit I have ever run. Hreflang is not a one-directional attribute. It requires reciprocal confirmation. Every page referenced in a hreflang annotation must also reference back to every other page in the set.

Here is what that means in practice: if your US English page (en-US) references your French page (fr-FR), your French page must also reference your US English page AND itself. If it does not, Google treats the entire hreflang cluster as invalid and ignores it.

From Google’s own documentation: “Each language version must list itself as well as all other language versions.” That is not a suggestion. It is the condition under which the attribute functions at all.

Why this happens at scale:

• Locale pages are added to a site incrementally, and older pages are not updated to include the new locale in their hreflang set.
• CMS templates generate hreflang tags dynamically but only pull from an incomplete locale mapping table.
• Third-party translation platforms implement their own hreflang without syncing with the parent site structure.
• Regional teams manage their own subdomain or subdirectory independently and do not include cross-references to other locales.

How to fix it:

• Run a full hreflang crawl using Screaming Frog (use the hreflang tab) or Sitebulb to extract every annotated URL and map the reciprocal relationships.
• Cross-reference your sitemap-based hreflang declarations (if you are using XML sitemaps for hreflang) against your on-page tags. Inconsistencies between the two cause further signal degradation.
• Build a master locale mapping document that lists every canonical URL per locale. Every time a new locale or page is added, this document should be the source of truth for generating correct hreflang sets.
• If using a CMS like WordPress with plugins such as WPML or Polylang, verify that the plugin generates complete reciprocal tags. Do not assume it does. Crawl and verify manually.

Mistake #2: Wrong Language and Region Codes

Hreflang uses ISO 639-1 for language codes and ISO 3166-1 Alpha-2 for region codes. The combination looks like this: language-REGION (for example, en-AU for Australian English, pt-BR for Brazilian Portuguese). The language code is always lowercase. The region code is always uppercase. And they must be valid ISO values.

The mistakes I see here are both technical and strategic.

Technical errors include:

• Using en-UK instead of en-GB. UK is not a valid ISO 3166-1 Alpha-2 code. GB is. This is one of the most frequent errors I see from US-based development teams building for the British market.
• Using zh without a region qualifier when the site has separate content for Simplified Chinese (zh-Hans or zh-CN) and Traditional Chinese (zh-Hant or zh-TW or zh-HK). These are meaningfully different audiences and markets.
• Using sp instead of es for Spanish. There is no ISO 639-1 code called “sp.” Spanish is “es.”
• Using language codes that do not actually correspond to a real ISO language, often the result of a developer copying from an outdated internal spec.

Strategic errors include:

• Assigning hreflang language-only tags (e.g., hreflang="fr") when the business actually serves distinct French-speaking markets with different products, pricing, or content (France, Canada, Belgium, Switzerland). This causes Google to consolidate signals incorrectly.
• Using hreflang="x-default" pointing to a locale-specific page rather than a genuinely neutral fallback or language selector page. x-default should be your default fallback for users who do not match any specified locale, not your US English homepage arbitrarily.

How to fix it:

• Validate every language and region code in your hreflang implementation against the official ISO 639-1 and ISO 3166-1 Alpha-2 lists before deployment.
• Use Google’s Search Console International Targeting report and the Hreflang Tags Testing Tool (available at technicalseo.com/tools/hreflang/) to validate annotations at scale.
• Establish a governance document that maps every market the business operates in to the correct hreflang code. Get this signed off by SEO and development leads before any new market goes live.

Mistake #3: Subdomain vs. Subdirectory Confusion

This is less a hreflang implementation error in the strictest sense and more an architectural decision that creates downstream hreflang problems, but it belongs in this article because I see it mishandled constantly.

Multinational brands typically have three options for structuring international content:

• Country code top-level domains (ccTLDs): example.de, example.fr, example.co.uk
• Subdomains: de.example.com, fr.example.com
• Subdirectories: example.com/de/, example.com/fr/

All three can work with hreflang. The problem arises when brands mix structures inconsistently, or when they change structures mid-implementation without updating hreflang annotations to match.

Common scenarios that cause hreflang failures:

• A brand launches its French market on a subdirectory (example.com/fr/) but the hreflang tags on the main site still reference an old subdomain (fr.example.com) from a previous implementation. Both URLs return a 200 status, both are indexed, and Google is receiving contradictory signals about which is canonical.
• A brand migrates from subdomains to subdirectories for some markets but not others, resulting in a hybrid structure where hreflang annotations point to a mix of subdomain and subdirectory URLs with no consistent canonical hierarchy.
• Regional teams manage their own subdomains and implement hreflang independently, pointing to their subdomain URLs, while the main domain’s sitemap references subdirectory versions of the same pages.

How to fix it:

• Audit your entire international URL structure before touching hreflang. Document every live URL pattern across all markets. Use a spreadsheet: market, URL structure type, canonical URL, hreflang code, and current hreflang annotation.
• Pick one structure per market and commit to it. If you are migrating from subdomains to subdirectories, implement 301 redirects from the old subdomain URLs to the new subdirectory URLs and update every hreflang annotation across every locale simultaneously, not in phases.
• If you are using XML sitemaps for hreflang (which is the recommended approach for large sites), ensure the sitemap hosted on the main domain includes the authoritative hreflang set for every market and that regional sitemaps do not conflict with the master sitemap.

Mistake #4: Hreflang Pointing to Non-Canonical URLs

This one causes a disproportionate amount of international SEO damage relative to how often it gets overlooked. Hreflang annotations must point to the canonical version of each page. If your hreflang tag points to a URL that itself has a canonical tag pointing somewhere else, Google will ignore the hreflang annotation entirely.

This situation typically arises when:

• Hreflang tags are implemented pointing to paginated URLs (e.g., /page/2/) rather than the canonical root page.
• URLs with tracking parameters (UTM codes, session IDs) are used in hreflang annotations instead of clean canonical URLs.
• A site has multiple URL variants due to HTTPS migration or www vs. non-www inconsistencies, and hreflang tags reference the non-canonical variant.
• Redirected URLs are referenced in hreflang sets instead of the final destination URL.

How to fix it:

• Every URL in your hreflang set should exactly match the URL declared in that page’s canonical tag. Run a crawl and cross-reference these two data points for every locale page.
• Use Screaming Frog’s “Follow Internal Redirects” setting and export hreflang data to identify any annotations that point to redirected URLs.
• Strip all parameters from hreflang annotations unless those parameters are part of the canonical URL structure.

Mistake #5: Incomplete Locale Coverage in the Hreflang Set

This is a scaling problem. When a site launches in two or three markets, maintaining complete hreflang sets is manageable. When it scales to fifteen or twenty markets, the operational discipline required to maintain a fully reciprocal, complete hreflang cluster for every page is significant and often not built into the content workflow.

What happens in practice: a new locale is added to the site, content is published, but the hreflang sets on all existing locale pages are not updated to include the new locale. Or a locale is retired, the pages are removed, but hreflang tags on surviving pages still reference the deleted URLs, resulting in broken annotations.

How to fix it:

• Treat hreflang set maintenance as a content operations process, not a one-time technical task. Every time a new locale page is published or deprecated, there must be a workflow step that triggers an update to all related hreflang annotations.
• Automate hreflang generation at the CMS or sitemap level using a locale mapping table as the source of truth. Manual hreflang management at scale is an operational liability.
• Schedule quarterly hreflang crawls as a standing item in your international SEO audit calendar. Use tools like Screaming Frog, JetOctopus, or ContentKing for ongoing monitoring.

Mistake #6: Using Hreflang for Pages That Should Not Have Locale Variants

Not every page on a multinational site needs a locale-specific variant. Applying hreflang annotations to pages that are identical across locales, or to pages that serve a purely functional purpose (legal disclaimers, error pages, login pages), creates unnecessary complexity and can dilute the clarity of signals Google receives about your actual locale strategy.

More critically, I have seen brands apply hreflang to thin, auto-translated pages that offer no meaningful differentiation from the original. Google’s quality assessments are sophisticated enough to recognize when localized content is substantively different versus when it is machine-translated boilerplate. Hreflang does not protect low-quality locale pages from being devalued. It just tells Google which market they are intended for, which means it surfaces your thin content to exactly the audience you are targeting and that rarely ends well.

How to fix it:

• Before implementing hreflang on any locale variant, ask whether that page provides genuinely different value to that locale’s audience. If the answer is no, the hreflang annotation is not the problem. The content strategy is.
• For functional or utility pages that do not vary by locale, use a single canonical URL with no hreflang annotation rather than creating locale-specific duplicates.

A Practical Hreflang Audit Checklist for International SEO Teams

Use this as a starting point for your next international SEO audit. This is not exhaustive but covers the highest-impact validation steps:

• Crawl all locale pages and extract hreflang annotations. Verify every annotation has a corresponding return tag on the referenced page.
• Validate every language and region code against ISO 639-1 and ISO 3166-1 Alpha-2 standards.
• Confirm all hreflang annotations point to canonical URLs, not redirected, parameterized, or non-canonical variants.
• Check that hreflang annotations are consistent between on-page tags and XML sitemap declarations.
• Verify the x-default tag points to a genuine neutral fallback, not a locale-specific page.
• Audit for orphaned hreflang references pointing to deleted or retired locale pages.
• Review your international URL structure for consistency. Identify any hybrid subdomain/subdirectory situations and resolve them with a clear canonical hierarchy.
• Cross-reference Search Console’s International Targeting report for flagged hreflang errors and prioritize fixing any issues reported there first.

The Bottom Line on International SEO and Hreflang

Hreflang is not glamorous. It does not generate case study headlines the way a viral content campaign or a major link acquisition does. But for multinational brands serious about international SEO performance, it is foundational infrastructure. Getting it wrong means your global content investment is being systematically misrouted by search engines. Getting it right means each market gets the signal clarity it needs to compete and rank.

The brands that dominate international organic search are not necessarily the ones with the best content or the biggest budgets. They are the ones whose technical SEO infrastructure is disciplined, maintained, and audited consistently. Hreflang is a significant part of that infrastructure. Treat it accordingly.

If your international audit has not included a dedicated hreflang validation pass in the last six months, that gap is almost certainly costing you rankings in at least one of your target markets. The fixes are not complex. The commitment to doing them systematically is what most teams lack.

Glossary of Terms

• Hreflang: An HTML attribute used to specify the language and geographic targeting of a webpage, telling search engines which version of a page to serve to users in different locales.
• Return Tag: The reciprocal hreflang annotation required on every page referenced in a hreflang set. Each page in the set must reference all other pages in the set, including itself.
• ISO 639-1: The international standard for two-letter language codes used in hreflang attributes (e.g., “en” for English, “fr” for French, “es” for Spanish).
• ISO 3166-1 Alpha-2: The international standard for two-letter country codes used in hreflang region qualifiers (e.g., “GB” for United Kingdom, “AU” for Australia, “BR” for Brazil).
• x-default: A special hreflang value used to designate the fallback page shown to users who do not match any other specified locale. Typically used for a language selector page or a neutral homepage.
• Canonical URL: The preferred version of a URL that search engines should index and use as the authoritative reference for a piece of content.
• ccTLD (Country Code Top-Level Domain): A domain extension specific to a country, such as .de for Germany or .fr for France, used as one approach to structuring international sites.
• Subdomain: A prefix added to the main domain to create a separate site section, often used for international markets (e.g., fr.example.com).
• Subdirectory: A folder structure within the main domain used to organize locale-specific content (e.g., example.com/fr/).
• XML Sitemap: A file that lists URLs on a site and can be used to declare hreflang annotations for all locale pages, as an alternative or supplement to on-page hreflang tags.
• Signal Dilution: The reduction in SEO effectiveness that occurs when conflicting or incomplete signals are sent to search engines, preventing them from accurately understanding a page’s purpose, audience, or authority.
• Locale: A combination of language and regional settings that defines the target audience for a specific version of a webpage (e.g., French-speaking users in Canada would be the fr-CA locale).
• International Targeting Report: A report available in Google Search Console that shows how Google is interpreting a site’s international signals, including hreflang errors and geotargeting settings.
• Crawl: The process by which a search engine bot or SEO tool systematically visits and reads the pages of a website to gather data about its content and structure.
• Cannibalization: In the context of international SEO, when multiple locale versions of the same page compete for the same search query in the same market, splitting ranking signals and reducing overall performance.

Further Reading

• Google Search Central: Tell Google about localized versions of your page
• Moz: Hreflang: The Easy Guide for Beginners
• Search Engine Journal: The Complete Guide to Hreflang for International SEO
• Neil Patel: International SEO: The Definitive Guide
• Search Engine Journal: International SEO: A Comprehensive Guide to Global Search