Our content pipeline runs on an AI model with no internet access. When it needs to cite a source, it does what any student caught at the last minute would do: makes one up with breathtaking confidence. We plugged in real Google Search so it would stop hallucinating. It worked on the first try. Then two links in a freshly published article were dead by morning.
TL;DR: The Straight-Talk Summary
- Hallucinated sources: LLMs fabricate 36% of the references they cite (Nature, 2024). Without internet access, your model invents studies that do not exist.
- Grounding = real internet: you connect the model to live web search so it works from verified facts, not its own memory.
- The URL trap: the URLs the system returns are temporary redirects that expire in roughly one hour. Your validator marks them live because at publication time they still work.
- The fix: resolve every URL to its final destination at the exact moment of generation. Not afterward.
Regardless of the risk, adding a research mode so a content agent can produce higher-quality content with more reliable sources is genuinely worth it. And if the LLM you're using doesn't have this capability, adding it is practically non-negotiable.
DaniWhy Your AI Model Fabricates Sources
Language models fabricate roughly 36% of the references they generate, according to a Nature (2024) study. It's a factory setting.
An LLM doesn't "search" for information. It predicts the next most likely token given a sequence. Ask it to cite a study and it will generate something that looks entirely real: a plausible title, first-and-last-name authors, a URL formatted like a scientific journal page. All invented.
The problem isn't that it lies. It's that it doesn't know it's lying. You publish content with those sources, your reader trusts you, clicks through, and lands on a 404. Or worse: a page that has nothing to do with what you claimed.
If you're generating content with AI and not auditing your sources, assume it's happening to you. The real question is how many of your citations are smoke.
What Grounding Is, and Why Turning It On Isn't Enough
Grounding connects the model to verifiable external sources during generation: it responds from traceable facts, not probabilistic memory. The most widespread implementation is RAG (Retrieval-Augmented Generation): before the model writes anything, a prior step searches the web and passes the results as context.
Google offers this built into its Gemini API as "grounding with Google Search." 1,500 free searches per day. You enable it, the model stops hallucinating sources, and starts citing real URLs from real outlets. No more invention: it works from verified data and returns the URLs it sourced from.
Sounds like a happy ending.
It isn't.
URLs That Validate as Live, and Die Within the Hour
The URLs the search system returns are not the original outlet's URL. They're intermediate redirect links that pass through search infrastructure before landing you at the destination. And they have an expiry date.
In our experience, the validity window is roughly one hour. Past that threshold, the temporary link stops redirecting and throws an error.
What does this mean in practice? You publish an article at 10 a.m. Your automated validator checks it at 10:05. All green. At 11:15, a reader clicks your source and lands on a 404.
The worst part: your monitoring system doesn't catch it because when it validated, the link was still alive. It's an invisible failure until someone complains or a crawler flags it days later.
We caught it on two already-published articles. The links looked perfect at publication time. By the next day, dead (with the validator's green badge still attached). We fixed them by searching for each original source title and replacing the expired URL with the real study link. Minutes of work that would have been zero if we'd resolved the redirects from the start.
How to Resolve Redirects at Generation Time
The fix is simpler than it sounds. The moment you generate content, before saving it, you resolve every URL to its final destination.
Technically it's an HTTP HEAD request with redirect-following enabled. The pattern is documented for virtually any language: Python with requests, Java with HttpURLConnection. You don't download the page body, you just follow the 301/302 redirect chain until you get the canonical URL.
Here's how it works:
- The model generates the article with the URLs the search system provides.
- An intermediate step takes each URL, follows the redirects, and retrieves the canonical URL of the original outlet.
- If resolution fails (timeout, domain down), plan B: a fresh search using the source title to recover the real URL.
- Only then does it publish.
Not after publishing. Not with a scheduled task that audits links every 24 hours. At the moment of generation. Because an hour later, the door is already shut.
What This Teaches Us About AI Automation
I'd bet this problem affects more content pipelines than anyone admits. Every automation layer you add inherits the assumptions of the layer before it. Google's search system assumes you want temporary access to results. Your publishing process assumes URLs are permanent. Nobody documents that gap because both assumptions are individually reasonable.
This is the pattern that does the most damage in AI automation: not the obvious failures, you catch those fast. What bites you are the parts that work "well enough" to pass validation. The link was alive. The validator said OK. The article published. Everything correct, except it wasn't.
Watch out for the SEO angle: broken links don't directly penalize rankings, but the indirect damage is real. You waste crawl budget and lose the authority that link was passing. For Google and your readers, it signals sloppiness. If your content aims to be the reference an AI assistant cites as a source, you can't afford links that lead to a dead end.
If you're using AI to generate content, don't trust what validates as correct at the moment of publishing. Ask yourself how long that validation is going to hold. Ours lasted 60 minutes. Not one more.
