Canonical Tags and AI Search: Which URL Gets Cited

By Muntazir · Published 18 October 2026

In February 2025, researchers at Columbia’s Tow Center ran the same test through eight AI search tools: ask about a specific news article, see which source gets the credit. One test case involved USA Today, a publisher whose robots.txt blocks ChatGPT’s own crawler. ChatGPT answered anyway — not by refusing, but by citing a copy of the same article republished on Yahoo News. The chatbot had never been let near USA Today’s servers. It had simply found the story somewhere else, and the citation didn’t flag that “somewhere else” wasn’t the source.

The same study found Perplexity Pro doing something close to it with the Texas Tribune, despite a declared partnership between the two: across ten test queries, it cited syndicated versions of Tribune articles three times, once pointing to an unofficial republished copy nobody at the Tribune had sanctioned. A licensing deal didn’t settle which URL got the credit. Something else decided that.

What is a canonical tag supposed to settle?

Google’s own documentation calls this problem canonicalization: picking the one URL that represents a set of duplicate or near-duplicate pages. A rel="canonical" tag is how a site owner states a preference — this page, not that one, is the version worth indexing and showing. Google lists the usual causes of duplicates: regional variants, sorting and filtering parameters, a staging copy left open, a site reachable on both http and https.

The same documentation is blunt about one limit: a canonical tag is a hint, not a directive. Google weighs it alongside redirects, sitemap entries and the http/https split, and can still pick a different URL if those signals disagree. The tag states an intention. It doesn’t enforce one.

What happens when the tag itself is wrong?

A technical crawl review that reads a site’s markup across its most-visited pages — not just the homepage — tends to catch the same handful of mistakes in disguise. A canonical pointing at an entirely different domain, often left over from a migration or a staging environment nobody retired. One written as a relative path, which resolves differently depending on which URL requested it in the first place. One pointing at an insecure http:// address on a site that moved to https:// years ago and never updated the tag to match. And a page that declares itself canonical while a separate noindex directive tells search engines not to index any version of it — two instructions on one page, each contradicting the other.

None of these are exotic. They’re the kind of thing a template change or a half-finished migration leaves behind, quietly, on pages nobody thought to check again — the same layer of housekeeping that a GEO audit and a check of structured data tend to turn up alongside it.

Does an AI crawler actually read that tag?

Here the honest answer is: not confirmed. OpenAI’s crawler documentation is detailed about access control — GPTBot and OAI-SearchBot can be allowed or blocked independently through robots.txt, changes propagate within roughly a day, and a shared crawl can serve both purposes when a site allows both bots. It says nothing about whether a canonical tag changes which URL either bot treats as authoritative once it’s inside the gate. Neither OpenAI’s nor any other AI company’s public documentation addresses this directly, and the Tow Center study above didn’t isolate canonical tags as a variable either. This is a real gap in what’s publicly known, not a detail being glossed over here.

So what is actually worth fixing?

Getting the signal right still matters for the layer underneath an AI answer, even without proof that a model’s retrieval step reads it directly. Several AI answer features — Google’s AI Overviews among them — draw on the same underlying index that rel="canonical" was built to inform. A wrong canonical tag can confuse that index regardless of whether any chatbot ever looks at the tag itself, and a confused index is one more way the wrong URL ends up being the one anything downstream finds.

Checking it doesn’t take much: open a page’s source and look for link rel="canonical" in the head. Confirm it’s an absolute URL, on the same domain, over https, and that the page isn’t also carrying a noindex tag. Repeat across a handful of the most important pages — product pages, pillar content, anything that gets syndicated or exists on more than one URL path. It’s a small, mechanical piece of a fuller technical review, and most sites that have been through a migration, a domain change or a CMS switch carry at least one of these left over somewhere.

A canonical tag won’t make an AI tool cite the right URL. It removes one honest reason it might not.