Why AI Assistants Cite Redirected, Deprecated, or Non-Canonical URLs

An old URL in an AI-generated answer is not automatically evidence that the assistant ignored your redirect. It may reflect when the source was discovered, how that system stores URLs, whether it followed the redirect, and how the citation was rendered. A citation can point to the URL attached to a source record rather than the final page a user would receive after clicking.

The short answer: citation systems preserve history

AI assistants do not all use the same retrieval pipeline. Some answer from a live search or browsing session. Some use a search index, a proprietary web index, a cached document, a training snapshot, or a mixture of these sources. The model may also be given a title, snippet, and URL by an upstream retrieval system and then asked to produce citations.

That creates several ways for an old URL to survive. A crawler may have found the legacy path before the redirect was deployed. A retrieval index may have stored the original URL while separately recording the destination. A citation renderer may simply print the source URL it was handed. In other cases, the old path remains discoverable in an internal link, sitemap, third-party reference, or archived document.

The practical implication is important: a redirect is one input into source selection, not a command that every AI system must obey immediately. Treat the problem as a consistency investigation. The goal is not to make a particular assistant forget a URL; it is to make the current URL the clearest, most accessible, and most consistently referenced source.

What happens when a crawler encounters a redirect

A redirect response tells a client that the requested resource is available elsewhere. For a permanent move, a server commonly returns 301 or 308 with a Location header. A client may follow that location, inspect the destination, and associate the old and new URLs. But clients differ in whether they follow redirects, how many hops they allow, and how they retain the original and final URLs.

Redirect chains are especially unhelpful. For example, /docs/old may redirect to /docs/intermediate, which then redirects to /guides/current. Some crawlers will resolve the chain; others may stop, record an intermediate URL, or reduce confidence in the destination. A direct single-hop redirect is easier to fetch, measure, and interpret.

Five reasons old URLs continue to appear

1. Stale indexes and retrieval caches

A live answer system can rely on an index that has not recrawled the old path since the move. Even if it has seen the 301, its stored document, title, or citation metadata may still be associated with the legacy URL. Recrawl frequency varies by site, page type, perceived importance, crawl budget, and the system's own update schedule.

2. Historical or training presence

Some assistants can produce a URL learned from earlier web data or from a source collected for training or evaluation. This is different from a current live citation. A page can remain present in historical data after it is deleted, redirected, or replaced. The Common Crawl and training presence guide explains why historical availability should not be treated as proof of current retrieval.

3. Sitemaps and internal links still advertise the old path

If an XML sitemap contains /docs/old while the site redirects it to /guides/current, you are publishing conflicting signals. The same applies to navigation, related-content modules, breadcrumbs, RSS feeds, API responses, PDFs, and documentation indexes. A crawler can discover the obsolete URL without ever needing a third-party link.

4. External sites and quoted documentation preserve the legacy URL

A partner, forum, repository, knowledge base, or review may continue linking to the old path. The assistant can discover that reference independently of your current site. If the old URL redirects cleanly and the destination is genuinely equivalent, the situation may be harmless. If it redirects to a broad landing page or an unrelated replacement, the citation can look misleading.

5. Citation rendering is separate from page resolution

The browser may follow a redirect and show the new page, while the answer still displays the old URL because the citation object retained the original request. Conversely, an assistant may cite a canonical URL while its underlying retrieval came through a redirected alias. The visible link is evidence about the assistant's source representation, not a complete record of its crawl process.

How to investigate a redirected citation

Start with a sample rather than assuming every old URL has the same cause. Record the exact question, assistant, date, answer wording, displayed citation, and whether the link was clickable. Repeat the query later and, where possible, in a fresh session. This separates a persistent source preference from a one-off generated reference.

1. Fetch the cited URL with a normal browser and an HTTP client. Record status code, Location headers, redirect count, final URL, response time, and whether the destination returns a successful HTML response.
2. Test common variants: HTTP and HTTPS, trailing slash and no trailing slash, uppercase and lowercase paths, query parameters, and alternate hostnames. A variant that behaves differently can create duplicate source records.
3. Inspect the final page's title, meta description, headings, visible answer, structured data, and canonical link. Confirm that the destination actually satisfies the intent of the old page rather than merely being the nearest surviving page.
4. Search the site for the old path in XML sitemaps, robots-related files, HTML, JavaScript-rendered navigation, feeds, source repositories, PDFs, and documentation manifests.
5. Review server logs or crawler reports for requests to the legacy URL. A request from a known crawler does not prove that the page was cited, but repeated access can show that the path remains discoverable.
6. Compare the assistant's citation with live search results, third-party links, and archived or training-presence evidence. Keep current retrieval, historical presence, and citation output as separate findings.

For crawler access, also inspect robots.txt guidance for AI crawlers. A blocked old URL can still appear in historical results, while a permitted redirect may lead to a destination whose HTML is difficult to process. Access and citation are related, but neither one alone explains the whole path.

The remediation order that usually works

Fix the source of inconsistency before trying to influence an assistant's output. The following order reduces avoidable ambiguity:

1. Choose one canonical destination for the topic. Do not split the same documentation across several near-identical replacement pages unless each has a distinct purpose.
2. Make the old URL resolve directly to that destination with one permanent redirect when the move is genuine. Remove redirect chains, loops, client-side-only redirects, and redirects to generic home or category pages.
3. Update every first-party reference: navigation, contextual links, breadcrumbs, XML sitemaps, RSS or Atom feeds, structured data URLs, documentation indexes, and downloadable files where practical.
4. Make the destination self-identifying. Use a stable title, descriptive heading, clear URL, relevant canonical element, and content that answers the intent associated with the legacy page. See the JSON-LD and AI discovery guide for structured data boundaries and appropriate use.
5. Publish the destination in crawlable HTML rather than hiding essential documentation behind an application shell. The crawlable HTML versus SPA guide covers common failure modes.
6. Keep the redirect long enough for important crawlers and external users to encounter it. Monitor errors and referral traffic before removing a legacy route entirely.

A 404 or 410 can be correct when there is no relevant replacement. It is not a better choice merely because it removes an old citation faster. A useful replacement with a clean 301 is generally preferable to a dead end when the topic and intent have genuinely moved.

How to measure whether the fix changed visibility

Do not use one citation as the success metric. Build a small before-and-after set of buyer, comparison, support, and category questions. For each run, record whether the brand is mentioned, recommended, or cited; which URL appears; whether the URL is canonical; and whether the destination is accessible and relevant.

A repeatable AI visibility measurement process should preserve the prompt, model or assistant, date, locale, and output. Results are probabilistic and can vary between runs. The value of the measurement is the pattern across a defined question set, not a single favorable answer.

A BatSignal Visibility Scan is optional if you want a repeatable check of crawler access, metadata, JSON-LD, sitemaps, llms.txt, and selected AI visibility signals. It should complement—not replace—server logs, redirect tests, and manual citation review. You can also review the methodology before deciding whether the checks fit your process.

What not to conclude from an old citation

An old URL does not necessarily mean the assistant cannot crawl your current page. It does not prove that your canonical tag is broken, that a competitor has displaced you, or that adding llms.txt will rewrite a proprietary index. Likewise, blocking the old URL in robots.txt is usually not a removal mechanism: a crawler may be unable to see the redirect or its replacement, while the URL remains in historical records.

Avoid changing several variables at once. If you alter redirects, sitemap entries, page copy, robots rules, and structured data simultaneously, you will not know which change affected the result. Correct the URL architecture first, then monitor recrawling and answer citations over a defined period.

For a broader foundation, compare this issue with AI visibility fundamentals, GEO versus SEO, and the AEO checklist. These practices cannot force a citation, but they can reduce the gap between the page you intend systems to use and the source they actually retain.

The practical standard: one clear path to the current answer

The most defensible fix is not to chase a particular assistant's URL formatting. Make the current page easy to discover, fetch, understand, and cite. Use a direct permanent redirect for a real move, remove obsolete first-party references, maintain a relevant destination, and monitor old and new paths separately.

Then distinguish three questions in your reporting: Can a crawler access the current page? Does a system have current or historical knowledge of it? Does an assistant cite it for the questions that matter? Those are different states. Keeping them separate turns a confusing old citation into a testable technical issue rather than a GEO folklore problem.

FAQ