What Is the Rel Alternate Tag and How Does It Affect SEO?

The rel alternate tag (rel="alternate" with hreflang) is a signal Google uses to help determine which language or regional version of a page to serve a given user. Get it right and Google surfaces the correct locale to the right audience. Get it wrong and Google makes that determination on its own, using content language detection, IP-based signals, and link patterns, and it frequently surfaces the wrong version, fragmenting your international traffic. For multilingual sites, incorrect or missing hreflang implementation is one of the most common and consequential causes of underperforming international organic traffic.

One clarification matters before going further: hreflang is a signal, not a command. Google can override it when other on-page signals contradict the annotation. This distinction changes how you approach implementation from the start. The goal is not just syntactically correct tags; it is a consistent signal environment where every element reinforces the same message. At Brandleap Agency, hreflang and alternate link tag audits are a standard part of every full technical SEO review because the failure points are predictable and the fixes are concrete once you know where to look.

This article covers the exact syntax for each implementation method, how to handle mobile and AMP setups, the most common reasons Google ignores hreflang annotations, and a step-by-step validation process you can run today.

What the rel alternate tag actually does (and what it doesn’t)

The relationship between the alternate link tag and hreflang

The rel="alternate" attribute is an HTML link element that serves multiple purposes depending on context. In SEO, it is almost always paired with the hreflang attribute to signal international targeting. The combination tells Google: “this URL has an equivalent version for a different language or region, and here is that URL.” When a user in Germany searches a relevant term, Google reads the hreflang annotations across the site and attempts to surface the German-language version in German search results. Without those annotations, Google makes the language determination on its own using other signals like content language detection, IP-based signals, and link patterns, and there is no guarantee it selects the correct version.

The self-referential entry is the detail most developers miss. Every page in a hreflang cluster must include a tag pointing to itself, not just to the other language versions. If the English page lists the German and French alternates but omits its own entry, Google may read the cluster as incomplete and discard it entirely.

Why Google treats it as a signal, not a command

Google respects hreflang annotations when they are consistent, complete, and do not contradict other on-page signals. When canonical tags, robots directives, or redirect chains conflict with hreflang, Google falls back on the signals it trusts more. According to Google’s own documentation on canonicalization, canonicals typically win that conflict. Two sites with identical hreflang syntax can get completely different results: one site’s signals reinforce each other across every element, and the other’s undercut the hreflang annotations through conflicting canonicals or blocked URLs.

This is why implementation cannot be treated as a one-time tagging exercise. Consider a site where aggressive canonical consolidation for duplicate content inadvertently points several locale URLs to a single canonical, those hreflang clusters become ineffective the moment that canonical signal contradicts them. Every supporting signal on the page has to point in the same direction as the hreflang cluster.

Three ways to implement rel=”alternate” hreflang correctly

HTML head rel alternate implementation

The most common method is placing link tags directly in the section of each HTML page. The exact syntax uses absolute URLs, and every page in the cluster must carry the full set of alternates, including itself. A complete implementation for an English and German site with a fallback looks like this:

The x-default value signals to Google which URL to serve when no other hreflang value matches the user’s language or region preference. It is not a generic fallback for any unmatched traffic; it is specifically designed for scenarios like a language selector page, a global homepage, or a page that adjusts dynamically by geolocation. This method works best for small to medium HTML sites where templates are centrally controlled and the number of locale variants is manageable.

XML sitemap method for large-scale multilingual sites

For sites with hundreds or thousands of URLs across multiple locales, adding full hreflang clusters to every HTML page becomes impractical to maintain. The hreflang sitemap approach centralizes all annotations in a single file using xhtml:link elements. The correct structure requires declaring the XHTML namespace on the root element, then placing one xhtml:link entry per language version inside each block, including a self-referential entry:

  
    https://example.com/about
    
    
    
  

Per Google’s sitemaps documentation, the sitemap method is treated as equivalent to the HTML head approach, neither carries an inherent advantage over the other. The critical maintenance risk is staleness: if the sitemap contains outdated URLs, removed pages, or missing locale entries, those errors can silently break the entire cluster. A stale sitemap is often harder to catch than a broken HTML tag because the errors are concentrated in one file rather than distributed across pages where crawlers surface them individually.

HTTP headers for non-HTML assets

When the content is not HTML, there is no section available. PDFs, images, and other file types that exist in multiple language versions require hreflang delivered through HTTP response headers configured at the server or CDN level. This is the least commonly needed approach, but it is the correct one for technical documentation or downloadable resources distributed across locales. Server-level configuration makes this method harder to debug, and some CDN setups can alter or strip custom headers. Google recommends sticking to one primary implementation method per site to avoid conflicting signals across different delivery layers.

How to handle mobile, AMP, and subdomain setups

Mobile-specific domains and the canonical relationship

The m-dot setup requires a precise bidirectional relationship. The desktop page points to its corresponding mobile page using rel="alternate" with a media attribute targeting small screens. The mobile page points back to the desktop using rel="canonical". The desktop URL is always the canonical; the mobile URL is always the alternate. A common failure mode is pointing multiple desktop pages to the same mobile homepage, or having the mobile page canonical to itself rather than to the desktop version. Both break the signal because Google cannot establish a one-to-one match between desktop and mobile equivalents.

Every desktop-mobile pair must be a direct match using absolute URLs. Partial mappings, where some pages link correctly and others do not, create inconsistencies that Google may interpret as errors across the entire mobile alternate setup. For example, if ten product pages correctly reference their mobile equivalents but two product pages point to the mobile homepage instead, those two pages effectively have no valid mobile alternate signal.

AMP pages and the reverse alternate direction

AMP implementation reverses the direction relative to mobile-site setup. The canonical non-AMP page points to its AMP version using rel="amphtml" in the HTML head. The AMP page points back to the non-AMP version via rel="canonical". On a multilingual site that also uses AMP, both relationships must be maintained simultaneously. That means hreflang annotations across language versions and amphtml/canonical links between AMP and non-AMP versions of each page. Skipping either set creates indexing ambiguity that prevents Google from determining which version of a page to serve or which to consolidate signals toward. Subdomains follow the same pairing rules as m-dot setups: the alternate link tag does not require both URLs to share a domain, but the reciprocal canonical-alternate relationship must be consistent and fully crawlable.

The most common reasons Google ignores your hreflang tags

Missing reciprocal links and canonical conflicts

The single most disruptive hreflang failure is non-bidirectional implementation. If page A lists page B as an alternate, page B must list page A in return. Without that return link, Google may discard the entire cluster rather than guess at the relationship. This is the most frequently cited cause of hreflang being silently ignored, and it is easy to miss during implementation because the syntax looks correct on each individual page.

Canonical conflicts are the second major failure point. When a page’s canonical tag points to a different URL than what the hreflang cluster implies, Google prioritizes the canonical signal. Sites that use aggressive canonical tags for duplicate content management are especially vulnerable: the canonical strategy can inadvertently contradict the hreflang annotations across entire locale sections without anyone noticing until traffic to localized pages drops.

Invalid language codes, blocked URLs, and crawl timing

Google requires valid ISO 639-1 two-letter language codes, optionally combined with ISO 3166-1 Alpha-2 two-letter country codes. Common invalid formats include reversed codes like gb-en instead of en-gb, country-only tags like uk, and unsupported regional codes like EU. Google silently ignores these rather than flagging them, which means an invalid code can go undetected for an extended period while sending no signal at all.

Hreflang targets must also return a 200 status. Pages that return a 404, redirect, or are blocked by robots.txt are treated as if the annotation does not exist. Crawl timing adds another layer of complexity: if hreflang tags were recently added or updated, Google needs to recrawl all pages in the cluster before it can process the full signal set. Many practitioners report a window of roughly two to four weeks for a complete site, though exact timing depends on crawl frequency and site size. During that period, the setup can appear broken when it is actually waiting on crawl coverage to complete.

How to validate your hreflang setup step by step

Dedicated hreflang validators and page-level spot checks

Start with a dedicated hreflang validator that accepts a single URL or a sitemap and flags the most common errors: missing return links, invalid language codes, duplicate annotations, and absent self-references. After running the validator, open the page source directly and verify the tags manually. Check for a self-referential entry for the page’s own language, all expected alternate versions listed with absolute URLs, and no partial sets where some alternates are missing.

For sitemap-based implementations, inspect the XML file directly and confirm that every URL block contains a complete xhtml:link cluster for all language versions. A partial set, where some URL blocks have all alternates listed and others have only a few, is one of the harder errors to catch through automated tools, because the sitemap parses without errors even when the content is incomplete.

Validating rel alternate tags in sitemaps via bulk crawl and Search Console

For sites with many pages, a site crawler like Screaming Frog or an audit tool like Ahrefs Site Audit can surface hreflang inconsistencies across the full domain: invalid tags, mismatched URLs, incomplete clusters, and missing self-references at scale. These tools surface issues that a URL-by-URL validator would take hours to find manually. Note that Google Search Console no longer provides a dedicated hreflang validation report, refer to Google’s Search Console documentation for the current feature set. Use it primarily to check for indexing errors or international targeting anomalies, then rely on external validators for hreflang troubleshooting and hreflang-specific diagnosis.

The practical workflow runs in sequence: validate one representative URL manually first, crawl the site for bulk issues, fix errors in batches organized by error type, and re-run the validator to confirm corrections before waiting on Google to recrawl. Do not skip the post-fix validation step. A batch fix that corrects one error type while introducing another is common enough that re-testing before waiting on Google saves significant time.

Getting hreflang right is worth the effort

The rel alternate tag is a deceptively simple element that causes disproportionate technical SEO problems when implemented carelessly. Correct implementation means consistent, bidirectional annotations that do not conflict with canonical tags, valid ISO language codes, crawlable target URLs, and a validation step before you consider the work done. The mobile and AMP use cases add complexity that many implementation guides skip over entirely, and the crawl timing issue means that a correctly implemented setup can look broken for weeks before Google fully processes it.

For most development teams, the biggest risk is assuming the tags are working without testing the full cluster. If your site operates across multiple languages or regions and you have not audited the hreflang setup end to end, that audit belongs at the top of your technical SEO backlog. The tools covered here, from dedicated hreflang validators to bulk site crawlers, give you everything you need to find and fix the most common failure points without outside help.

Whether you work through it independently or bring in a technical partner, the goal is the same: a consistent, fully validated signal set that gives Google no reason to override what you have built. For teams managing complex multilingual architectures across dozens of locale variants and thousands of URLs, Brandleap Agency’s full technical SEO audit service covers this kind of implementation review end to end, from validating hreflang clusters and resolving canonical conflicts to auditing sitemap structure and crawl coverage across every locale.