Canonical and hreflang in an AI-answer world

A canonical tag tells engines which URL is the primary version of duplicate or near-duplicate content, and hreflang tells them which language or region version belongs to which audience. Both still matter when the destination is an AI answer instead of a ranked list, but they reach the model through a different path than they did in classic search, and AI engines honor them less reliably. If you manage duplicates and localization the way you did for Google in 2020, you can watch an assistant cite the wrong URL, the wrong language, or an outdated variant with your correct signals sitting right there in the head of the page.

Here is what actually happens to these signals once an answer engine is in the loop.

#Canonical was always a signal, not a command

Even for Google, rel="canonical" has never been a directive. Google's own documentation calls it "a strong signal that the specified URL should become canonical," and is explicit that the tag expresses a preference the algorithm can override: "if you don't specify a canonical URL, Google will identify which version of the URL is objectively the best version to show" (Google Search Central, "Consolidate duplicate URLs"). Google groups duplicate and near-duplicate pages into a cluster and picks one representative for the whole set.

That was already the model in traditional search. AI answer engines add a second layer of indirection on top of it. ChatGPT's search does not maintain its own web index; it retrieves through Bing. When Seer Interactive compared SearchGPT citations against search results, it found that "87%+ of SearchGPT's citations matched Bing's top organic results when the same exact question was used as a query, with most of those results appearing in the top 10 positions," versus 56% for Google, across a directional sample of about 100 queries (Seer Interactive). The practical meaning: for ChatGPT, the URL that gets cited is largely the URL Bing decided to rank, which is the URL Bing treated as canonical. Your canonical tag still counts, but it counts by influencing Bing first, not by talking to the model directly.

So the failure mode is specific. If Bing has indexed and ranked a parameterized, tracking-tagged, or otherwise non-preferred variant of your page, that variant is what ChatGPT can quote, regardless of what your canonical points to. The tag did not fail; it just was not the last word.

#hreflang gets honored unevenly, and often not at all

Hreflang has the same "signal, not guarantee" character, and AI engines currently handle it worse than duplicate-content consolidation. Glenn Gabe ran a first-party test of translated, hreflang-tagged pages across five assistants, querying in French, Italian, and Spanish with matching language preferences set. ChatGPT "returned a link but it was the US English version" for both French and Italian queries. Claude also returned the US English version for French and Italian. Perplexity was mixed: it returned the correct Italian URL once (which Gabe described as "rare during my testing") but gave US English for French and Spanish. Only Copilot, which runs on Bing's infrastructure, "returned the correct url (the French version)" consistently (G-Squared Interactive, "AI Search, hreflang, and translated content").

The pattern is worth sitting with. The assistants that lean hardest on a mature search index (Copilot on Bing) respected the localization signal. The ones synthesizing more freely defaulted to the most authoritative version they could find, which is usually US English. If a meaningful share of your audience asks these tools in another language, hreflang alone will not route them to your localized page today. The tag is correct and largely ignored.

#Duplicate content: the risk is a wrong representative, not a penalty

The old fear about duplicate content was a ranking penalty. That was mostly a myth even for Google, and it is the wrong thing to worry about with AI. The real risk is representative selection. When several URLs carry the same or near-identical content, the engine clusters them and elects one to stand for the group, exactly as Google describes for its own index (Google Search Central). If the elected representative is a stale cache, a print view, a syndicated copy on someone else's domain, or a URL with old pricing, that is the version an assistant may quote and attribute.

You are not being punished for having duplicates. You are losing control over which copy speaks for you. In an AI answer, there is usually only one cited source per claim, so "which copy" is the entire game.

#What to do about it

The through-line is that these tags are inputs to a selection process you do not own, so the job is to make the correct version the obvious winner at every layer, not just to declare it once.

• Keep canonical, sitemap, and internal links pointing at the same clean URL. When all three agree, you remove the ambiguity that lets an engine pick a variant. Mixed signals are where the wrong URL sneaks in.
• Check what Bing has indexed, not just Google. Because ChatGPT retrieves through Bing, Bing's chosen canonical is effectively ChatGPT's. If Bing ranks a parameter-laden variant, fix that at the Bing index level.
• Do not rely on hreflang alone for AI localization. Until assistants honor it consistently, make each localized page strong enough to stand on its own: clear language signals in the visible content, a self-referencing canonical per locale, and distinct, genuinely translated text rather than thin machine output.
• Collapse accidental duplicates at the source. Trailing slashes, uppercase paths, session parameters, and HTTP-versus-HTTPS variants all create copies an engine can elect. Redirect them to one form so there is only one candidate to represent you.
• Watch which URL actually gets cited. The only way to know whether your canonical and hreflang decisions survived the trip through an answer engine is to look at the URLs assistants return for your key queries and compare them to the versions you intended.

Canonical and hreflang did not stop mattering. They became upstream signals feeding a system that makes its own final call, and that reads localization signals poorly. Treat them as the first move in getting the right URL cited, then verify the last move landed where you meant it to.