Google's Gary Illyes said that hreflang alternate URLs are "not in fact indexed in the proper sense". They are held as alternate names of a canonical URL, so the variant is mapped to the page Google did index instead of earning an index entry of its own. Search Engine Roundtable published the exchange on 10 August 2026, reporting an answer Illyes gave in a LinkedIn thread.
For anyone running an English and Thai site off one set of templates, that single sentence resolves a reporting problem that has burned hours of agency time. A Thai URL sitting in Search Console under a not-indexed label is not automatically a broken page. It can be a URL that Google has filed against its canonical and will still hand to a searcher when the query calls for it.
What Illyes said, and what prompted it
The question came from Faiez Javaid, who asked on LinkedIn: "If Google is choosing by itself one /lang/ as canonical and ignoring others showing in GSC as not indexed, then how can Google show other lang versions of the same page to the user in Search results?" That is the exact contradiction site owners keep hitting. Search Console says one thing, the search results say another.
Illyes answered in two parts. On the first he said: "when we canonicalize a URL, the other URLs in its dups cluster it was chosen from may become so called alternate names. They may be used in search results if the user query deserves one of those alternate names. The most prominent use case is the 'site:' queries. If you do a search like [site:bit.ly], we may show a bunch of urls that actually redirect; they're not indexed in the proper sense, they're just alternate names of a canonical url."
On the second he said: "hreflang alternates become such alternate URLs: they're not in fact indexed in the proper sense." Search Engine Roundtable summarised the practical consequence as the specific URL not being indexed while still being mapped to the canonical page that is indexed.
The dups cluster explained without the jargon
Google groups URLs it considers to be the same page into what Illyes called a dups cluster. Out of that group one URL is picked as the canonical, and that is the one that gets indexed in the ordinary sense of the word. The others do not vanish. They stay attached to the cluster as alternate names, which is a pointer rather than a stored copy.
The distinction that matters is between being indexed and being retrievable. An alternate name has no index entry of its own, but Google knows it exists and knows which canonical it belongs to. Illyes said those alternate names "may be used in search results if the user query deserves one of those alternate names". So retrieval is still possible through the canonical, even though the URL was never independently indexed.
Why the site: operator shows URLs that redirect
Illyes used the site: operator as his worked example, and it is the clearest way to see the mechanism from outside Google. He said that on a query like [site:bit.ly], Google "may show a bunch of urls that actually redirect", and that those URLs "are just alternate names of a canonical url".
A short link that redirects is, by definition, not the page. It has no content to index. It appears in that result set because the query is navigational and specific enough that the alternate name is the thing the searcher asked for. This is the same machinery that lets a Thai language variant surface for a Thai query even when Search Console has it under a not-indexed status. The source frames site: as the most prominent use case, not the only one.
Sourced facts and what each one changes
The table below sets the statements reported by Search Engine Roundtable on 10 August 2026 against what each one changes for a site owner reading Search Console.
| Statement in the source | What it changes for a site owner |
|---|---|
| Illyes: "hreflang alternates become such alternate URLs: they're not in fact indexed in the proper sense" | A language variant is stored against a canonical rather than indexed separately, so a not-indexed status is not proof of a fault |
| Illyes: alternate names "may be used in search results if the user query deserves one of those alternate names" | The variant can still be served, which is the direct answer to why other language versions appear in results |
| Illyes: on [site:bit.ly] Google "may show a bunch of urls that actually redirect" | The site: operator lists alternate names, so it is a poor test of what is genuinely indexed |
| Search Engine Roundtable: the specific URL may not be indexed while being mapped to the canonical page that is indexed | Reporting and retrieval are two different systems, and only one of them is visible in Search Console |
| Reported 10 August 2026, from an answer Illyes posted on LinkedIn to a question from Faiez Javaid | This is a public explanation of existing behaviour, not an announced change to how hreflang works |
Reading a not-indexed English and Thai pair without chasing a ghost
Search Console has a status called Duplicate, Google chose different canonical. On a bilingual site it shows up on the variant Google did not select, and the instinct is to treat it as an emergency. Illyes' answer gives a reason to slow down before touching anything, because a URL in that state is exactly the kind of URL that becomes an alternate name.
The honest position is that the source does not tell you how to tell a benign case from a broken one. Illyes explained the storage model. He did not publish a diagnostic. So the sensible read is that a not-indexed label on a language variant is ambiguous evidence on its own, and it needs a second signal before it justifies a template change. That second signal is whether the right variant actually reaches the right searcher, which is a search-results test rather than a Search Console test.
When hreflang really is broken
None of the above makes hreflang self-repairing. There is a set of faults that stop the mapping from being built in the first place, and those look superficially identical in a report. Worth separating out:
- Missing return links. If the English page points at the Thai page but the Thai page does not point back, the pair is not confirmed.
- Wrong language or region codes. A code that is not valid, or a region used where a language was meant, leaves the annotation unusable.
- hreflang pointing at URLs that redirect or at non-canonical URLs. The annotation then names a URL that is not the one Google would keep.
- No x-default, so there is nothing declared for searchers who match none of the declared variants.
The way to tell these apart from the benign case is that they are structural and checkable in your own markup, while the alternate-name behaviour Illyes described is internal to Google and not visible to you at all. If the annotations are reciprocal, the codes are valid and every target is a self-canonical URL that returns 200, then a not-indexed label on the variant is more likely the behaviour Illyes described than a fault you can fix. A structured SEO audit is where those four checks belong, because they are markup facts rather than judgement calls.
Testing which variant a Thai searcher actually gets
Because the source gives a storage model and not a verification method, this part is reasoning rather than reported fact, and it should be labelled that way. Search Console will not show you the mapping. What you can observe is the outcome: which URL appears for a Thai-language query on a Thai search, and which appears for the English equivalent.
The Performance report gives you a usable proxy without any guesswork about ranking. Filter it by country and by query, and look at which page is credited with impressions for Thai-language queries. If the Thai variant is picking up impressions and clicks on Thai queries, it is being served, whatever its indexing status says. If it is picking up nothing while the English page collects Thai-query impressions, that is the case worth investigating, and it is a different problem from the one Illyes was describing.
What the source did not say
Three gaps are worth stating plainly rather than filling in.
Illyes did not say how to verify that a given variant has been mapped to a canonical. There is no reported tool, report or field that exposes the alternate-name relationship. He did not say whether an alternate name can rank on its own merits for an ordinary, non-navigational keyword. His example was the site: operator, which is a navigational case, and he framed it as the most prominent use case rather than the only one. And he did not say what a site owner should do when Duplicate, Google chose different canonical appears across an entire hreflang set. The mechanism was explained; the remediation advice was not given.
What this means for Thai marketers
The statement is about how Google indexes hreflang in general. Search Engine Roundtable's report does not mention Thailand, Thai-language sites or any country scope, and nothing here should be read as a Thailand-specific rule.
That said, bilingual Thai and English sites are precisely the configuration this describes. A Thai company running /th/ alongside an English tree will have two URLs that are near-identical in structure, linked by hreflang, differing mainly in language. That is a textbook dups cluster, and the not-indexed labels that follow are the normal output of the model Illyes described rather than a sign the Thai site has been ignored.
The practical shift is where you spend attention. Time that goes into re-submitting Thai URLs for indexing, or rewriting templates in response to a status label, has a weak link to any outcome. Time that goes into checking reciprocity, code validity and canonical targets in the markup, then confirming with country-filtered query data that Thai searchers land on the Thai page, has a direct one. For teams building out bilingual coverage, that ordering is worth locking into the process before scaling pages, and it is the same discipline that underpins durable SEO in Thailand.
FAQ
Does a not-indexed status mean my Thai page is missing from Google?
Not necessarily, based on what Illyes said. He described hreflang alternates as being kept as alternate names of a canonical URL rather than indexed in their own right, and said such alternate names may still be used in search results when the query deserves them. The status describes how the URL is stored, not whether a searcher can reach it. He did not say every not-indexed variant is fine, so the markup checks still apply.
Is this a change I need to react to?
No change was announced. Illyes was explaining behaviour that already exists, in answer to a question about why other language versions appear in results when Search Console reports them as not indexed. Search Engine Roundtable reported it on 10 August 2026 as an explanation, not a launch, and no effective date or rollout was mentioned.
Does this apply in Thailand?
The source states no geographic scope at all. It is a general statement about how Google handles hreflang alternates, with no mention of Thailand or of any country-level difference. Bilingual Thai and English sites match the situation described, but that is a reading of the mechanism rather than something the source asserts.
How do I check whether the mapping is working?
The source does not describe a way to verify the mapping, and no report exposes it. What you can check is the markup, meaning reciprocal annotations, valid language and region codes, and hreflang targets that are self-canonical and do not redirect, and then the outcome, meaning which page collects impressions for Thai-language queries in a country-filtered Performance report.
Can an hreflang alternate rank on its own for a normal keyword?
The source does not say. Illyes said alternate names may be used in search results when the user query deserves one of them, and gave the site: operator as the most prominent use case. Whether that extends to ordinary informational or commercial queries was not addressed, so treating it as settled would go beyond the evidence.
The full exchange was reported by Search Engine Roundtable on 10 August 2026. If your bilingual site is throwing not-indexed labels across a language set and you would rather know which of them are real, the markup checks above are the place to start, and a proper diagnosis is a conversation worth having before anything gets rebuilt.
