hreflang breaks down on mixed-language pages because the entire annotation system is built on an assumption that each URL represents one language, fully and unambiguously. A bilingual product page (English and Spanish descriptions stacked in the same template, for instance) violates that assumption at the source. Google still has to determine what language a URL is “in” before it can decide whether an hreflang annotation pointing to that URL as a language alternate is even accurate, and mixed content makes that determination ambiguous. The unpredictable results you see (wrong-language versions ranking in the wrong markets, hreflang clusters getting partially ignored, inconsistent selection of which URL serves which locale) are downstream symptoms of that ambiguity, not a configuration bug you can patch with better markup.
The single-language assumption hreflang depends on
Google’s documentation on implementing hreflang describes the annotation as telling Google “about the different variations of this page” for different languages or regions, with each variant living at its own distinct URL. The implicit and necessary premise is that Google’s language-detection process, which runs independently of your hreflang tags, will look at a given URL’s rendered content and assign it a primary language. hreflang doesn’t declare a page’s language; it declares a relationship between URLs that are each already, independently, in a specific language. Google cross-checks the two: it uses its own content-based language classification as a sanity check against your hreflang claims, and if a URL’s actual content doesn’t match what the hreflang cluster claims it is, Google can discount or ignore the annotation for that URL.
A bilingual page defeats this cross-check by construction. If a product page displays both English and Spanish description text in the same HTML document, Google’s language classifier has no clean single answer to give that URL. Depending on the ratio of each language’s text, template structure, which language appears first in the DOM, and other pages’ linking patterns, Google might classify the page as English, as Spanish, as an inconsistent mix that shifts between crawls, or, in some cases, decline to associate it confidently with either. Whatever the classifier lands on, if it doesn’t match the language your hreflang tag claims for that URL (say, you’ve annotated it as the “es” alternate but Google’s classifier leans English because of navigation chrome, footer content, or the higher volume of English text), the mismatch undermines the credibility of the entire annotation for that URL.
This produces the unpredictable pattern practitioners report: it’s not that hreflang “doesn’t work” uniformly, it’s that Google’s confidence in the annotation varies page by page depending on how the language mix happens to tip the classifier on any given crawl, and that confidence can shift between crawls as content, ads, or dynamically injected text change the ratio. Two nearly identical bilingual templates on the same site can behave differently in search results simply because one has slightly more Spanish text pushing the classifier one way and the other has slightly more English text pushing it the other way.
There’s a second-order effect too: hreflang relies on return tags, where each URL in a cluster must reciprocally reference the others. If Google’s classifier is uncertain about URL A’s language, it can become uncertain about the validity of the whole reciprocal relationship, since the cluster’s coherence depends on each node having a confidently identifiable language to begin with. That can cause Google to discard signals for the entire cluster rather than partially honor it for the URLs that are unambiguous.
What to do about it
There is no supported hreflang pattern for annotating a single URL that mixes multiple full languages of content. The documented, reliable fix is structural: separate the languages onto distinct URLs, each containing content in one primary language, and hreflang-annotate those distinct URLs against each other. For the bilingual product page example, that means an English-primary URL (which may still contain incidental foreign-language terms, like a brand name or an untranslated technical spec, without breaking anything) and a separate Spanish-primary URL, each hreflang-tagged back to the other and to any other regional variants.
If the business requirement is genuinely to show both languages to every visitor regardless of locale (a deliberate bilingual-display product, not a site serving different locales differently), that’s a legitimate design choice, but it isn’t an hreflang use case at all. hreflang exists to tell Google which URL to serve to which language/region audience; if every visitor gets the same bilingual page regardless of locale, there’s no alternate version to annotate, and hreflang should likely be omitted entirely for that content rather than forced into a pattern it wasn’t built to support.
When auditing an existing implementation showing this problem, check Search Console’s International Targeting report, which surfaces hreflang errors including return-tag mismatches, and independently spot-check what language Google’s cache or rendered snapshot associates with the flagged URLs. If the perceived language doesn’t match the intended hreflang value, mixed content is very likely the root cause, and the fix is separation into distinct, single-language URLs rather than any adjustment to the hreflang tags themselves.
