All posts
7 min read

Hallucinated URLs: Capturing the Traffic AI Invents

LLMs send users to plausible URLs that don't exist on your site. Find them in your 404 logs, 301 the recurring ones, and read them as a map of how AI sees your site.

A flow diagram on Deep Navy showing an AI chat inventing the URL /pricing-plans, the request hitting a 404 wall, and a gold 301 redirect arrow rerouting the visitor to the real /pricing page.

AI assistants sometimes send real visitors to URLs that have never existed on your site. A model asked "where can I see AcmeApp's pricing?" may answer with acmeapp.com/pricing-plans because that path is plausible - thousands of sites use it - even though your actual page lives at /pricing. The visitor clicks, lands on your 404 page, and leaves. You paid the full cost of earning that recommendation and lost the conversion at the last hop.

This is fixable in an afternoon, and the fix is one of the highest-leverage, lowest-effort moves in AI search right now: mine your 404 logs for AI-referred requests, 301 the recurring invented paths to the real pages, and - this is the part most people skip - read the hallucinated URLs as free market research about how language models conceptualize your site.

Why models invent URLs at all

An LLM generating a URL is not looking it up in a live index; it is completing a pattern. When the model has strong memory of your actual URL - because the page is heavily cited, crawled, and linked - it reproduces it correctly. When it has weak memory but strong priors about how sites like yours are structured, it interpolates: /pricing-plans, /docs/api, /integrations/slack, /free-trial. These are statistically likely paths, not retrieved ones.

Retrieval-augmented engines like Perplexity mostly link what they fetched, so their citation links resolve. The invented-URL problem concentrates in chat contexts where the model answers from parametric memory - ChatGPT without browsing, Claude reciting from training data, or any assistant paraphrasing "you can find it at..." in prose rather than quoting a fetched source. It also shows up secondhand: AI-generated articles, newsletters, and forum answers repeat invented links, which then get clicked, scraped, and repeated again. Once a plausible-but-wrong URL enters circulation it tends to persist, because nothing in the loop ever checks it against your server.

Two properties follow from this mechanism, and both work in your favor. Invented URLs are not random - they cluster tightly around a handful of conventional patterns. And they are recurring - the same wrong path shows up again and again, because different models share the same priors about site structure.

Finding them in your logs

Your 404s are already being recorded; the work is separating AI-driven misses from ordinary noise (old backlinks, typos, vulnerability scanners probing /wp-admin.php). Three filters get you there.

Filter 1 - referrer. Grep your access logs for 404 responses where the referrer is an assistant domain: chatgpt.com, chat.openai.com, perplexity.ai, claude.ai, gemini.google.com, copilot.microsoft.com. This is your highest-confidence set: a human clicked a link an AI showed them, and your server said "no such page."


grep ' 404 ' access.log | grep -E 'chatgpt\.com|openai\.com|perplexity\.ai|claude\.ai|gemini\.google\.com|copilot\.microsoft\.com'

Filter 2 - plausibility patterns. Many AI-originated visits arrive with no referrer (apps and privacy-stripping browsers drop it), so also scan referrer-less 404s for paths that look designed rather than mistyped: clean lowercase slugs, hyphenated, no file extensions, matching common site conventions - /pricing-plans when you have /pricing, /blog/getting-started when you never wrote it, /support when you use /help. A typo'd backlink looks broken; a hallucinated URL looks like it should exist. That is the tell.

Filter 3 - recurrence. Count hits per missing path over 30 days and sort. One-off 404s are noise. The same invented path arriving weekly from multiple IPs is a model's stable belief about your site, and stable beliefs are worth responding to. If you are already doing AI crawler log analysis for user agents like GPTBot and ClaudeBot, this is the same pipeline pointed at status codes instead of crawl frequency - and crawler hits on nonexistent paths are themselves a hint that a URL is circulating somewhere.

If you do not have server log access, your analytics 404 page view report with referrer breakdown gets you most of the way, though referrer-less traffic will be underrepresented.

The fix: redirect or build

For each recurring hallucinated path, you have two good options and one bad one.

Option 1 - 301 to the real page. When the invented URL has an obvious real counterpart, ship a 301 Moved Permanently from /pricing-plans to /pricing. The visitor lands where they meant to go, the recommendation you earned actually converts, and crawlers that re-fetch the circulating link consolidate signals onto the canonical page instead of logging a dead end. Keep it honest: redirect only where intent clearly matches. Funneling every 404 to your homepage creates soft-404 behavior that Google's documentation explicitly warns against, and it reads as a bait-and-switch to the user who wanted docs and got a hero banner.

Option 2 - build the page the AI expects. Sometimes the hallucination is demand data. If models keep inventing /integrations/slack, that is evidence users keep asking assistants whether you integrate with Slack, and the model keeps assuming a page should answer it. If the underlying thing is real - you do have a Slack integration, buried in a docs subsection - promote it to the URL the world already believes in. You are not chasing the model; the model is showing you a gap between what people ask and what you have made addressable. The same logic drives redirect hygiene for citation retention: URLs are the addresses AI systems store for your content, and meeting a stored address with a 200 beats hoping the store gets corrected.

The bad option - ignore it. Every recurring hallucinated URL is a visitor stream with demonstrated intent terminating at your least persuasive page. And an assistant ecosystem that keeps hearing "404" when it checks a link it recommended has one more reason to route the next recommendation elsewhere.

One guardrail: never mass-create thin pages for every 404 in the log. Redirects for clear matches, real pages for real demand, nothing for the noise. The filter is whether you have something genuine to put at the address.

What hallucinated URLs tell you about your site's entity

Here is the strategic layer. A model inventing /pricing-plans on your domain is telling you it believes you are a commercial product with tiered pricing. Inventing /docs/api means it believes you have a developer surface. Inventing /case-studies means it files you as a B2B vendor whose buyers expect proof.

Collect a quarter of hallucinated paths and you get a crude but honest rendering of your site's shape in the model's head - which conventional pages it expects a company like yours to have. Divergences run both directions. Expected-but-missing pages (/customers, /security, /changelog) show where you deviate from category convention, which is friction every time an assistant tries to answer a question about you. Never-hallucinated pages that you consider core are worse news: if no model ever invents a path for your flagship capability, that capability may not be part of your machine-readable identity at all - the same entity-level problem we unpack in anatomy of a lost citation. Your 404 log is the cheapest entity audit you will ever run.

Frequently asked questions

Why do AI models make up URLs instead of saying they don't know?

Because URL generation is pattern completion, not lookup. When a model's memory of your exact path is weak, the statistically likely continuation is a conventional path like /pricing or /docs, and the model has no built-in step that verifies the string against your server before presenting it. Browsing-enabled and retrieval-based modes check; parametric answers often do not.

Should I 301 every 404 that comes from an AI referrer?

No. Redirect the recurring paths with a clear intent match to their real counterpart, build pages where the hallucination reveals genuine demand, and leave the noise alone. Blanket-redirecting all 404s to the homepage produces soft-404 signals and frustrates the visitor you were trying to save.

How do I know a 404 came from an AI system if there's no referrer?

You can't be certain per-hit, but you can classify by shape: clean, hyphenated, extension-free slugs that match common site conventions, recurring across weeks and IPs, are characteristic of generated URLs rather than typos or link rot. Recurrence is the strongest single signal - priors are shared across models, so invented paths repeat.

Can I stop models from hallucinating URLs on my domain?

Not directly - you cannot patch a model's weights. You reduce the rate by making your real URLs the strong memory: stable paths, consistent internal linking, clean sitemaps, and citable pages that get fetched and referenced often. And you make the remaining hallucinations harmless with 301s, which is the part fully under your control.

Turn invented addresses into arrivals

The whole play is one log query, a handful of redirect rules, and a quarterly read of what the misses are telling you. If you want the crawler-side half checked too, Citevera's free AI crawler access checker shows which AI agents can reach any URL and which robots.txt rule decides it, and a full Citevera audit scores how reliably your real pages - the ones the redirects should land on - answer the questions that sent the visitor in the first place. The traffic AI invents is still traffic. Catch it.