Blog · Diagnosis

Outdated pages are poisoning your answers

Published 8 October 2026 · 8 min read

Outdated pages are poisoning your answers
Photograph: Jason Leung / unsplash

The short answer: Old pages you forgot about are still being fetched, chunked and quoted, so an engine can describe a product you retired or a price you changed two years ago. Retrieval has no sense of your roadmap. It picks the passage that matches the question best, and a tidy 2023 page often matches better than a messy 2026 one. The fix is removal and consolidation, not another new post.

Most teams treat an old page as harmless. It gets no traffic, nobody links to it, so it sits there. That reasoning came from a world where a page with no clicks had no effect.

Retrieval does not rank your archive, it matches it

Think about what the system is actually doing when someone asks about your pricing. It turns the question into a query, pulls candidate documents, cuts them into passages, and keeps the few that look closest to the question. That is the published shape of retrieval-augmented generation rather than a secret: the selection step scores passages against the question, and nothing in the public descriptions of it takes an account of which document a site owner would prefer. The rankers themselves are not published, so treat the detail of a given engine's scoring as unknown.

Now consider the shape of a retired page. It was written when the product had one plan and one number, so it says that plan and that number plainly, in one place, with a heading that repeats the question almost word for word. Your current pricing page carries four tiers, a toggle, an enterprise call-to-action and a feature matrix rendered by JavaScript. Which one is the cleaner passage? Usually the old one. That is the mechanism we think explains the cases we keep running into, where a retired page gets quoted in preference to the current one. We cannot see inside an engine's ranker, so read it as a hypothesis that fits the symptom, not as documented engine behaviour.

The same logic applies to a changelog entry announcing a feature you removed, a 2024 blog post describing an integration that broke, a careers page for an office you closed, and a comparison page written against a competitor who has since rebuilt their product. Each one is a well-formed passage making a confident claim. Each one is wrong now.

The four shapes stale content takes

Not all old pages fail the same way, and the remedy differs.

Contradiction. Two of your own pages give different answers to the same question. The engine has no tie-breaker it can explain, so in the answers we have read it picks one, hedges, or quotes both. We record this often on older sites. We have not counted it across audits, so take that as an impression from the work rather than a rate.

Orphaned truth. The page is still accurate but nothing links to it any more, so it drops out of the crawl cadence and gets replaced in the index by a weaker page that is linked. Accuracy does not protect a page from obscurity.

Zombie detail. A specific number, SKU, integration name or certification that was true once. These do the most damage in our experience, because a specific wrong detail is more quotable than a vague right one.

Phantom entity. A product line, brand name or sub-brand you sunset. An engine can keep describing it because the web still describes it, and your own site never explicitly said it ended. Silence is not a retraction.

That last one connects to a broader problem we wrote about in Why AI never mentions your brand: where an engine cannot resolve which of several versions of you is current, we have watched it hedge rather than commit to one.

Why a date stamp is not the fix

The reflex is to update the dateline and move on. Teams bulk-edit dateModified, push a new sitemap, and wait.

It rarely works, for two reasons. The first is that a claimed date is only a claim. Google's Article structured data documentation (checked October 2026) asks for ISO 8601 dates and recommends supplying timezone information, saying that otherwise it will default to the timezone used by Googlebot, which tells you the field is parsed input rather than a fact the engine takes on sight. That is Google's documented handling; other engines publish less about how they read the field, and we cannot tell you what they do with it. The second reason is simpler and does not depend on engine behaviour at all: changing a date does not change the sentence. If the passage still says the old number, the passage is still wrong, and it is the passage that gets quoted.

Tell the engines the page changed, properly

There are real levers here and they are unglamorous.

For removal, Google's documentation on removing information from Google (checked October 2026) says a page hosted on your site can be taken out of Google's search results within a day through the Removals tool, and that such requests last for about six months. That is a stopgap, not a fix, and it governs Google's results only. The same page says removing or updating the content is the most secure option, lists password protection and a noindex tag as the other durable routes, and tells you not to use robots.txt to block a page. Other engines run their own removal processes, which we have not tested.

For change notification, the IndexNow protocol lets you push URLs to the search engines that participate in it the moment content is added, updated or deleted, in batches of up to 10,000 URLs per post, per its documentation (checked October 2026). It is one HTTP call and a key file at your domain root. Participation is a published list, so check that the engines you care about are on it before you count on it.

For the assistant surfaces, propagation is not instant. OpenAI's bots documentation (checked October 2026) notes that for search results it can take around 24 hours from a robots.txt update for its systems to adjust. That is OpenAI's figure for its own search surface, not a number for the category, and we have no equivalent published figure for the others. Still, it is a useful calibration: if you block or unblock something today, do not judge the result tomorrow morning.

And if the page is slow, none of this matters, because it may never finish being read. Slow pages get dropped before they get read covers the timeout side of the same loss.

A check you can run this week

Pick your twenty most load-bearing facts. Price, plan names, turnaround, integrations, certifications, office locations, headcount band, the exact product names. For each one, run a site-scoped search for the old value and the new value. Count the pages carrying each.

Then ask five engines a question whose correct answer is the new value, three times each, and record the number they quote. Three runs is a sample, not a census, and the same prompt can answer differently on a different day, so treat a single old value as a lead rather than a measurement. If an engine returns the old value even once, find the page it cited and read it. More often than not, in the audits we have run, the culprit is a page nobody on the current team has opened in a year.

Three actions follow, in this order. Delete pages whose only content is a wrong claim. Merge near-duplicates into one canonical page and redirect the rest to it, in a single hop. Date-anchor what remains, so a passage carries its own context: a sentence that reads "as of October 2026, the Starter plan is X" still carries its date when it is lifted out of the page, while a bare "the Starter plan is X" does not. Whether an engine then uses that date is not something we can observe.

Comparison content needs its own pass, because it ages against someone else's roadmap as well as your own. Comparison pages that get cited goes into how to write those so they stay defensible.

The longer version of this exercise, with the rest of the checks in order, is in A self-audit checklist for AI visibility. If you would rather see what the findings look like when they are written up with the evidence attached, the sample audit report walks through the format section by section.

Honest limits

This post does not establish that engines prefer stale passages. It describes a mechanism that is consistent with answers we have read, and the ranking step that would prove it is not published by anyone. The frequency language here, how often contradictions turn up on older sites and how often the cited page is one nobody has opened, comes from audit work we have not counted, so none of it is a rate you can cite back at us.

The three documented figures, Google's one-day removal and six-month expiry, IndexNow's 10,000 URLs per post, and OpenAI's roughly 24 hours for a robots.txt change to reach its search surface, are each one vendor's statement about its own system, checked in October 2026, and none of them describes the others. We cannot tell you how long a wrong claim persists after you fix the page, because that depends on caches, on third-party copies of the claim, and on how often the engine re-crawls you, and we have not seen a pattern stable enough to quote as a number.

We also cannot separate a stale page from a stale third party. If a directory, a review site or a syndication partner still carries the old number, cleaning your own site will reduce the problem without ending it. That part is slower and partly outside your control.

FAQ

Should I delete old blog posts or just update them? Delete when the page exists only to assert something now false and has no inbound links worth keeping. Update when the topic still matters. Merge when two pages cover the same ground, and redirect the loser to the winner with one hop, not a chain.

Does a noindex tag stop an assistant quoting the page? Not reliably, and not the same way across engines. A noindex directive governs search indexing; separate crawler directives govern the AI user agents, and a user-initiated fetch may follow different rules again. Check each engine's published crawler documentation rather than assuming one tag covers all of them.

How old is too old? Age is the wrong axis. A 2019 page stating something still true is fine. A page from last quarter stating a number you changed on Monday is a problem today. Audit by claim, not by publication date.

Will removing pages hurt my search traffic? It can, if you remove pages that still earn clicks. That is why the order matters: find the wrong claims first, check their traffic and links, then choose between delete, merge and rewrite per page rather than running a cull.

Sources

All four were opened and confirmed to support the sentences citing them in October 2026.

Related reading

Why AI never mentions your brandA self-audit checklist for AI visibilitySlow pages get dropped before they get readComparison pages that get citedRedirect chains, and the sources they loseMigrating a site without losing citations