Give Deprecated Features Their Own Help Center Section

The Problem Nobody Notices Until It's Loud

You sunset a feature. You pull the help article. Six months later your support queue fills with tickets from customers who found a cached version on Google, a community post quoting your old docs, or — most frustratingly — an AI answer that confidently described a workflow that stopped existing in Q2.

Deleting documentation doesn't erase it from the internet. It just means your authoritative version is gone, so every other version wins by default.

What Actually Happens When You Pull Old Docs

Three things break at once.

First, organic search still surfaces the Google cache or a third-party screenshot for weeks or months after removal. Customers arrive expecting the feature to exist, find nothing in your help center to confirm or deny it, and open a ticket.

Second, if you run an AI support agent — ours included — the model's training or your knowledge-base sync may have ingested the old article before you deleted it. Without a clear deprecation signal in the content itself, the agent has no way to know the feature is gone. It either repeats the old instructions confidently or gives a hedged non-answer that frustrates the customer either way.

Third, your own team loses institutional memory. A new support hire who joined after the deprecation has no reference point when a customer insists the old workflow existed. The ticket escalates unnecessarily.

What a Graveyard Section Actually Looks Like

A deprecated section is not a dumping ground. It is a deliberately maintained archive with exactly three elements per article:

• A standard deprecation banner at the top — the date the feature was removed and, where applicable, the replacement feature or migration path.
• The original content, preserved — because customers often need to understand what they used to have in order to understand why the new approach works differently.
• A clear canonical link — pointing to the current feature or, if there is no replacement, to a plain statement that the functionality was discontinued.

The section lives in your help center under a clearly named category — "Deprecated & Discontinued" works — with a robots meta tag or sitemap exclusion if you want to suppress new indexing, but without a 404 or redirect that wipes the content entirely.

Why This Matters More When You Run an AI Agent

Chattering indexes your help center to answer customer questions. So does every comparable AI support tool. When we sync your content, article context matters enormously. An article titled "How to use the Legacy CSV Importer" that opens with "This feature was removed on [date]. Use the new Data Import flow instead — see this article" gives the AI agent everything it needs to respond accurately: the feature is gone, here is the date, here is the redirect.

An article that simply 404s — or worse, an article that still says "follow these five steps" with no deprecation signal — gives the agent nothing useful, or gives it actively wrong instructions.

The deprecation banner is not just for humans. It is a structured fact that your AI agent can cite when a customer asks about the old workflow.

The Ticket-Reduction Math Is Straightforward

Say a deprecated feature generated 40 help articles over its lifetime. If even a fraction of your monthly ticket volume involves customers confused about what happened to it, a graveyard section eliminates the ambiguity in a single pass. The customer finds the article, reads the banner, clicks the migration link, and never opens a ticket. Your agent, when asked, surfaces the deprecation context and the redirect rather than stalling or guessing.

You do this once per deprecated feature. The payoff compounds as your product ages and your feature history grows.

How to Migrate Existing Docs

Start with your last two major version changes. Pull the articles that now describe dead workflows, add the standard banner, move them to the deprecated category, and update any internal links in your current docs to point to the archived version with an explanatory note. The whole pass for two version cycles usually takes a support lead an afternoon.

For new deprecations, make the graveyard move part of your feature-removal checklist. Engineering announces the sunset → support lead moves the articles and adds the banner → knowledge base sync picks up the new context → AI agent answers accurately from day one of the removal.

The Broader Principle

Help centers degrade in exactly the same way codebases do: not through dramatic failures but through quiet accumulation of things that used to be true. A graveyard section is the documentation equivalent of clear deprecation warnings in code — it doesn't pretend the past didn't happen, it just makes clear what era you're reading from.

Customers who hit that section don't feel lost. They feel informed. And an AI agent with access to well-labeled deprecated content doesn't hallucinate. It tells the customer exactly what happened and where to go next.