- Published
- Updated
- Reading time
- 8 minutes
- Filed under
- sources · research
KnitKnot field note
AI is citing pages that don't exist
We probed every URL that ChatGPT, Claude, Perplexity, and Gemini cited across nearly 10,000 buyer-question answers. One citation in eighteen points at a URL that was unavailable when checked, and nearly a third of answers lean on at least one.

Max Wiesner
Co-founder, KnitKnot
Evidence plate / sourcesObserved · sourced · reviewedWe clicked the receipts
When an AI answers a buyer’s comparison question, it shows its work: a list of citations under the answer, about a dozen per response. Those citations are the answer’s receipts. They’re why the recommendation feels trustworthy.
So we clicked all of them.
Across our benchmarks we’ve collected just over 115,000 citations from nearly 10,000 AI answers to buyer evaluation questions, spanning ChatGPT, Claude, Perplexity, and Gemini. We fetch every cited page, because our scoring works claim-by-claim and a claim’s supporting source is part of the measurement. Fetching them means we also learn something nobody asks about: whether the page is still there.
In the collection reported here, one citation in eighteen pointed at a URL that returned HTTP 404, HTTP 410, or a DNS failure. Nearly one answer in three included at least one such citation. These are historical fetch results, not a measure of how many buyers encountered the answers.
The subset of answers generated in July 2026 had a similar rate to the full collection, which also included earlier answers. Recently generated answers also included URLs that failed when checked.
Not all engines rot equally
The rate varies by engine, and the spread is wide:
Perplexity had the highest failed-citation rate in this collection. The rates do not establish why the engines differed. Retrieval behavior and the types of pages cited are possible explanations to investigate, not causes isolated by this count.
The collection separated transient failures and bot walls from URLs returning 404, 410, or DNS failures. A retry can confirm a repeated failure. It cannot prove that the page is permanently gone or determine what the AI saw when it generated the answer.
What a dead citation looks like
The failure modes are more varied than “somebody deleted a blog post.”
The page moved and nobody redirected. More than a thousand distinct cited pages return plain HTTP 404. Docs restructures, blog re-platforms, marketing-site redesigns. The content usually still exists somewhere. The URL the AI knows doesn’t.
The domain itself is gone. The starkest case in our data is an open-source project’s retired domain, sktime.net. DNS doesn’t resolve. There is no server left to return an error. Three engines independently cited pages on it nearly 600 times and presented a nonexistent website as evidence.
The page was deliberately withdrawn. HTTP 410 indicates that a resource is no longer available and the server considers the absence likely permanent. We recorded over a hundred citations returning this status in ChatGPT answers alone. The status does not establish why a publisher removed the page. Publishers pulled the content, but it still does work in live answers.
And it’s not just third parties. The pattern shows up on vendors’ own sites. We’ve watched documentation pages moved during a site restructure keep collecting citations at dead URLs because nobody added redirects. The AI is recommending those vendors from pages their own team deleted.
How can an answer cite an unavailable page?
A failed fetch shows that the URL was unavailable when checked. It does not establish whether the page existed earlier, whether the answer used a stored version, or whether the URL was generated incorrectly. Those explanations require evidence beyond the status code.
HTTP 404 also does not distinguish temporary absence from permanent removal. HTTP 410 indicates that the server considers the absence likely to be permanent. DNS failures require their own diagnosis. The historical figures above describe the failed URLs in that collection; they do not prove that every resource is permanently gone. HTTP status definitions
For a disputed company claim, preserve the failure and check whether an archived or moved page can be identified. Treat it as a candidate until you can establish a reliable connection to the original citation. The source-tracing guide covers that evidence boundary.
We’re not the only ones seeing this
We wanted to know whether our corpus was an outlier, so we went looking for independent evidence. It’s not an outlier. It’s a well-documented pattern arriving from two directions at once.
The first direction: the web itself rots. Pew Research Center’s When Online Content Disappears found that 38% of webpages that existed in 2013 were no longer accessible a decade later, and roughly a quarter of news pages contain at least one broken link. Any system trained on snapshots of a decaying web inherits that decay.
The second direction: AI engines handle that decay badly. The Tow Center for Digital Journalism tested eight AI search engines on news citations and found them collectively wrong on more than 60% of queries. Gemini and Grok 3 cited more fabricated or broken URLs than working ones, and Grok 3 pointed at error pages in 154 of 200 tests. At a much larger scale, Ahrefs studied 16 million URLs cited or recommended by AI assistants and found they send users to 404 pages nearly three times as often as Google Search does.
These studies use different query sets, collection dates, and definitions of a failed citation. They provide related evidence about broken links. Their rates are not directly comparable with the B2B buyer-question collection reported here.
What should you do when a cited page is gone?
If the URL belongs to your company and the content moved, redirect it to the closest useful replacement. Check that the destination still answers the original question. A redirect to an unrelated homepage does not restore the missing evidence.
If another publisher owns the URL, look for its replacement before writing a new page. A missing source can reveal a buyer question that current content handles poorly. Publishing a useful, supported answer gives readers a live reference, but it does not guarantee that an AI system will replace the dead citation with yours.
Keep the citation and failed fetch in the record. A page that cannot be inspected leaves the claim unresolved until another reliable source settles it.
What we built to fix it
None of this is visible if you treat citations as a list of strings. It only shows up if you resolve every cited URL and keep resolving them. Pages that are alive today die later, so the record has to move with the web. That’s the design principle behind KnitKnot’s Content & Source Intelligence, and it turns dead citations from a curiosity into a workflow:
Every cited page is a first-class record. Each URL an engine cites in your benchmarks gets fetched, classified by page type and owner, and tracked as its own row, with every answer that leaned on it attached. When a cited page is unreachable, you get the receipt: the specific failure and when we last confirmed it. Because dead pages sometimes come back, we re-probe them weekly so the record stays current in either direction.
Attach the source to the work. A playbook can connect an unavailable source with the captured answer and a proposed response. That response might be a redirect on your domain or a useful replacement page. The record gives the team a specific task and evidence to compare later.
Check later answers. After the work ships, repeat the same buyer questions and inspect their citations. Record whether the dead source still appears and whether the new page is cited. That comparison shows what changed in the collected answers; it does not isolate the effect of the edit.
Check the pages behind your own captured answers. Our benchmark examples show how the answer and source evidence fit together.
For the steps to check a disputed citation, read how to find the sources behind AI answers. The guide separates a listed URL from evidence that supports a specific claim.