If a product page’s canonical tag points at a URL that itself redirects somewhere else, Google may not index the page you meant it to. And because AI Overviews and AI Mode pull from that same Search index rather than a separate one, the page effectively disappears from AI answers too — not because it’s low quality, but because of one mismatched <link> tag.

What the mistake looks like

A canonical tag is supposed to point at the final, live version of a page — the one that returns a normal 200 response. The mismatch happens when it instead points at a URL that 301/302-redirects elsewhere:

  • The apex domain canonicalizes to www, but the tag still says example.com instead of www.example.com (or the reverse).
  • A page migrated from http:// to https://, but old templates still emit an http:// canonical.
  • A redirect chain exists (old URL → interim URL → final URL) and the canonical points at the interim hop instead of the destination.

Each of these sends Google a canonical URL that never actually resolves with a 200 — it resolves with a redirect.

Why Google treats this as broken

Google’s own documentation is explicit that rel="canonical" is “a strong signal” the search engine considers alongside redirects, internal linking, and sitemap inclusion — not a directive it always follows (Google Search Central, “How to Specify a Canonical with rel=canonical and Other Methods”). When the declared canonical itself doesn’t return 200, that signal conflicts with the redirect Google is simultaneously following, and Google’s own troubleshooting guidance for canonicalization issues says to replace a redirecting canonical with the live, final destination URL instead (Google Search Central, “Fix Canonicalization Issues”). In Search Console’s URL Inspection tool, this is what produces a mismatch between the “user-declared canonical” and the “Google-selected canonical” — Google picks its own URL instead of trusting yours, and site owners frequently report exactly this failure mode on Google’s own Search Central help forum when redirect chains or inconsistent www/https rules are involved.

Why this reaches AI answers, not just rankings

This isn’t only a rankings issue. Google’s documentation for AI features states that AI Overviews and AI Mode are grounded in retrieval from the existing Search index and “the same fundamental crawling and indexing systems” that power regular Search results — they are not served from a separate AI-specific index or crawl. If a canonical mismatch keeps a page out of, or wrongly represented in, that index, the AI-generated answer inherits the same gap.

The same logic applies on the ChatGPT side through a different index: ChatGPT’s web search results are powered by Bing, so a canonicalization problem that confuses Bing’s crawler has the same downstream effect on what ChatGPT can surface — a mechanism we covered in more depth in why ChatGPT doesn’t know your store.

How to check it: two curl commands

You don’t need a crawler to catch this on a handful of pages. First, check what the live page actually returns:

curl -sI https://example.com/products/widget

If you get a 301/302 and a Location: header instead of a clean 200, that URL should never appear as anyone’s canonical target. Second, pull the canonical tag the page declares and re-check that URL the same way:

curl -s https://example.com/products/widget | grep -i 'rel="canonical"'
curl -sI <the URL from that tag>

If the second command also returns a redirect instead of a 200, the canonical is broken — point it at wherever that redirect chain actually ends.

The fix

Pick one canonical form per page (protocol, www/apex, trailing slash) and make every template emit it consistently, rather than relying on whichever URL a particular page happened to be generated with. Site migrations, domain moves, and CMS template changes are the most common triggers for this regressing quietly.

Fixing canonicalization gets your product pages correctly indexed, which is a precondition for AI-driven discovery — but indexing only gets an agent to the page. Whether it can then read the price, resolve the right variant, and complete a purchase there is a separate question, and that transaction layer is what AgentReady’s scan checks.

Sources