What does Google mean by 'alternative names' and how does it change our understanding of indexing?

When Google canonicalizes a URL, it doesn’t just discard the other variants. These URLs become alternative names stored in the duplicate cluster. They are not 'indexed' in the traditional sense — no distinct entry in the main index — but they remain known and usable.

For hreflang URLs, the mechanism is identical. Google selects a canonical version (often the en-US version or the one that receives the most signals), and the others become alternatives. They may emerge in SERPs if the user’s language or geolocation justifies it, without GSC ever marking them as 'indexed.'

Why does GSC show some pages as 'not indexed' when they appear in results?

GSC distinguishes between two states: indexed (present in the main index with its own entry) and not indexed (known but not stored as an independent page). The alternative names fall into this second category. They can be served in response to a targeted query, but they do not exist as an autonomous entry.

The most striking case? Site: queries. You type site:mysite.com/fr/ and see URLs that redirect or are marked as 'not indexed'. Google displays them because your query specifies its domain and path, but that doesn’t mean they are indexed in the conventional way.

How does this mechanism affect the multilingual hreflang strategy?

Canonicalization can occur beyond your control if your hreflang signals are weak, inconsistent, or contradictory. Google will choose a canonical version based on its own criteria: link signals, geographic consistency of backlinks, user data, crawl patterns. If your fr-FR version becomes canonical for the whole cluster, your en-GB version remains an alternative that may serve British users, but will never appear as 'indexed' in GSC.

This changes the game for audits. A multilingual site with 80% of its pages marked as 'not indexed' isn’t necessarily failing if the canonical versions are correctly selected and the hreflang alternatives are properly declared. The real criterion: does the user in each geo receive the correct language version?

• Hreflang URLs are not indexed individually but become alternative names for the canonical chosen by Google.
• GSC shows 'not indexed' for these alternatives, but they can still appear in SERPs depending on the user context.
• Site: queries reveal non-indexed URLs because they force Google to display known but non-autonomous alternative names.
• Hreflang canonicalization depends on multiple signals (backlinks, user signals, geo consistency) and may escape your control if your declarations are weak.
• An hreflang audit should focus on cluster coherence and the relevance of served versions, not on the raw indexing rate in GSC.

Is this statement consistent with what we've observed on the ground for years?

Yes, and it finally formalizes what many of us have observed empirically. Language versions marked as 'not indexed' that continue to generate targeted organic traffic is a classic situation. Gary Illyes confirms that this is not a GSC bug; it’s the expected behavior.

However, this clarification raises a question that has never really been addressed: how does Google choose the canonical in a hreflang cluster? The official documentation remains vague. We know it does not depend solely on hreflang tags, but also on external signals. Backlinks from .fr domains to the /fr/ version? Very likely. Patterns of localized user clicks? Definitely. But Google does not publish a weighting matrix. [To be verified] on live site conditions.

What nuances should be added to this explanation from Google?

The notion of 'alternative name' is convenient but it glosses over a reality: not all alternative names are equal. Some language versions remain completely invisible even for geo-targeted users because Google has determined they are redundant or poorly implemented. If your hreflang are bidirectional, but your fr-FR content is a poor-quality machine translation, Google might ignore this alternative and serve the en-US version to your French visitors.

Another point: Gary talks about site: queries as a typical use case. But what about classic organic searches? We lack data on the true frequency at which Google serves an alternative name instead of the canonical. If a French user types a local query, does Google consistently serve /fr/ even if /en/ is canonical? Not always, and that’s where it gets tricky.

In which cases does this rule not apply or pose a problem?

First problematic case: sites with distinct content by language, not just translations. If your /fr/ version offers products or articles missing from /en/, and Google treats it as a mere alternative name, you may lose traffic on unique content. The mechanics of duplicate clusters are designed for nearly identical versions. When the content diverges, hreflang becomes an unsuitable tool.

Second case: hybrid architectures where some pages have hreflang and others do not. Google can canonicalize inconsistently across the site, creating partial clusters. Result: some language versions become alternative names, others are indexed independently, and GSC displays an inexplicable chaos. This happens more often than one might think on sites that have gradually added hreflang.

How can you verify that your hreflang URLs are working despite the 'not indexed' status in GSC?

First step: test from target geos. Use a VPN or tools like BrightLocal, SEMrush Position Tracking with geographical targeting, or simply Google Search Console filtered by country. Check that the appropriate language version appears in SERPs for representative queries.

Second check: analyze your server logs. If Googlebot regularly crawls your hreflang URLs even marked as 'not indexed', that’s a good sign. If these URLs generate organic traffic in Google Analytics segmented by language, they are working as intended. The GSC status becomes secondary.

Should you continue to declare all hreflang versions even if they won't be indexed?

Absolutely. The hreflang annotations serve specifically to structure these clusters of alternative names. Without them, Google has to guess which pages are language equivalents, and it often makes mistakes. You risk a wild canonicalization where an English version overrides all others for all geos.

Be rigorous: bidirectional hreflang, x-default tags for out-of-target users, consistency between HTML tags and XML sitemaps. If Google must choose a canonical in your cluster, it’s better that it be based on clear signals rather than algorithmic assumptions.

What errors should be avoided following this clarification from Google?

Classic mistake: panicking over a GSC report showing 70% of pages as 'not indexed' on a multilingual site. If these pages correspond to alternative hreflang versions and targeted traffic is working, that’s normal. Don’t force indexing through aggressive sitemaps or contradictory self-referencing canonical tags.

Another trap: neglecting the content of alternative versions on the grounds that they are 'just' alternative names. Google may decide to promote an alternative to canonical if its content is richer, its user signals better, or its backlinks stronger. Treat each language version as a standalone page, not as an empty shell.

• Test your hreflang URLs from target geos using VPN or geo-targeted tracking tools.
• Check in Google Analytics that each language version receives organic traffic from its target area.
• Audit your server logs to confirm that Googlebot regularly crawls all your hreflang versions.
• Ensure your hreflang annotations are bidirectional and consistent across HTML, sitemaps, and HTTP headers.
• Do not artificially deindex alternative versions: let Google handle canonicalization through hreflang signals.
• Monitor canonical changes in GSC (tab 'Pages' > 'Why pages are not indexed') to detect unexpected recanonicalizations.