Every large website collects content nobody meant to keep. A service page that describes a process you replaced two years ago. Three versions of the same FAQ, owned by three different teams. A landing page for a campaign that ended before half your current team was hired.
That’s content ROT: content that is redundant, outdated, or trivial. (You’ll also see the O expanded as “obsolete.” Same idea.)
No single ROT page breaks anything, which is why it rarely feels urgent. But together those pages make your site harder to use, harder to maintain, and more likely to give people the wrong answer. Here’s how to find it, decide what to do with each page, and stop it building up again.
(Full disclosure: I’m working through exactly this on our own blog right now. This page was one of the ROT candidates.)
What is content ROT?
Content ROT is published content that no longer earns its place on your site. Each letter names a different failure:
- Redundant content says what another page already says. It usually appears when several teams publish on the same topic without knowing about each other, or when someone posts the same information in a few places to get it noticed.
- Outdated content was accurate once and isn’t now. Think old prices, retired services, superseded policies, past deadlines, and anything still described as “new” or “upcoming.”
- Trivial content doesn’t help anyone do anything. Thin listing pages, placeholder pages, and announcements with no lasting value belong here.
In records management, ROT usually refers to files sitting on shared drives and in collaboration systems. The principle is the same, but this article is about the published side: the pages and documents your audiences can actually see.
Content ROT also isn’t the same as content decay. A decaying page is still accurate but is losing traffic or rankings. A ROT page shouldn’t be on your site in its current form at all.
The difference matters because the fixes are different.
Why content ROT is a bigger problem than it looks
The obvious cost is user experience. When two pages give different answers to the same question, your visitors can’t tell which one to trust.
So they call, they email, or they leave.
On a government, healthcare, or financial services site, a wrong answer can carry legal or regulatory consequences, not just a support ticket.
The less obvious costs land on your team.
We tend to think of a published page as finished. It isn’t.
Every page you keep is a page somebody has to maintain. Its links need checking, its accessibility needs testing, and its facts need reviewing every time a policy or product changes. ROT multiplies that work without adding any value. On a decentralized site with hundreds of publishers, it compounds quietly until a redesign or migration forces someone to count it.
Search adds another layer. Redundant pages compete with each other for the same queries, so neither ranks as well as one consolidated page would.
And outdated pages don’t stop being found just because they’re wrong.
That last point matters more now that answer engines summarize content for people. An AI-generated answer draws on whatever it can retrieve. If your outdated page is still published and indexed, it’s still a candidate source, and an answer built on it will repeat the old information with your name attached.
If answer engines are a priority for you, start by auditing content for answer engine discoverability.
How to identify content ROT
You can’t find ROT on a large site by reading it. You need data to narrow thousands of pages down to a list worth reviewing, then human judgment to make the call on each one.
Start with the signals. Most of them come from a site crawl, your analytics, and your CMS.
| ROT type | Signals to look for | Where to find them |
|---|---|---|
| Redundant | Duplicate or near-duplicate page titles, several pages answering the same question, the same PDF uploaded in more than one place | Site crawl, internal search results, Search Console queries where two of your URLs appear |
| Outdated | Past dates and deadlines, “new,” “upcoming,” or “this year” language, last-reviewed dates past your policy, broken links to sources that have moved, staff or products that are gone | Site crawl for text patterns and broken links, CMS review dates |
| Trivial | Near-zero visits over 12 months, pages with no internal links pointing to them, thin pages that only link elsewhere | Analytics, crawl link data |
Evergreen content deserves its own check. A guide written to last can go stale in a single sentence, like “the new rule takes effect next year.” Searching your site for date-bound phrases is one of the fastest ways to find outdated content hiding in pages that otherwise look fine.
How to use analytics to identify outdated content
Analytics won’t tell you a page is wrong. It tells you where to look first. Here’s the order I work in.
Pull at least 12 months of page-level data, so seasonal pages get a fair hearing. A page that only gets traffic during enrollment season isn’t trivial.
Sort by visits and start at the bottom of the list. Pages with no visits or close to none are your first review queue. They’re trivial, orphaned, or covering something nobody needs anymore.
Then compare visits against search impressions. A page that shows up in search but rarely gets clicked has a different problem: people see it and decide it isn’t what they want. An outdated title or a past date in the search snippet is a common cause.
Finally, check what people search for on your site. Repeated searches for something you already cover, or searches that return nothing, point to content that’s buried, mislabeled, or missing.
One caution. Low traffic on its own isn’t a reason to remove a page. Some of your most important content, like a regulatory disclosure or an accessibility statement, will always get few visits.
Traffic tells you where to look. The decision comes later.
Evaluate each page manually
Data gives you a shortlist. Someone who knows the subject still has to read each page. For every page on that list, ask:
- Is this page necessary, and for whom?
- Does the same information exist elsewhere on the site?
- Is it still accurate and current?
- Does it refer to a specific date or timeframe? Could it be written so it doesn’t?
- Does it name a specific person? Are they still in that role?
- Could it link to existing content instead of repeating it?
User feedback belongs in this review too. Comments, complaints, and support tickets that mention a page are often the first sign that it’s wrong.
The person answering these questions should be the page’s owner, or someone with the authority to decide its fate. Reviews stall when the people doing them can flag a problem but can’t act on it.
Decide: keep, update, consolidate, redirect, or remove
Every page on your review list gets one decision. Here are the five options and when each one applies.
| Decision | When it applies | Watch for |
|---|---|---|
| Keep | Accurate, needed, and not duplicated elsewhere | Add a review date so it doesn’t drift back onto the list |
| Update | The page is needed but some details are wrong | Fix the facts and the date-bound language, not just the date stamp |
| Consolidate | Two or more pages answer the same question | Merge into the strongest page, then redirect the others to it |
| Redirect | The page isn’t needed, but a current page covers its topic and the old URL has links or traffic worth keeping | Send it to a page that answers the same question, not to your homepage |
| Remove | Nothing current covers it and nobody needs it | Check records and retention obligations before you delete anything |
That last row is where regulated organizations get caught. Taking content off your website isn’t the same as deleting it from the record. If a page or document falls under a retention schedule, archive it under that schedule instead of deleting it outright.
I get the appeal of a blanket rule like “delete anything nobody has opened in six months.” It’s fast.
It’s also how required content disappears.
Once you know what you have, here’s how to decide whether to refresh, consolidate or retire the content that stays in play.
Government websites and content ROT
For US federal agencies, cleaning up legacy content is a legal requirement, not just good practice.
The 21st Century Integrated Digital Experience Act (21st Century IDEA) requires an executive agency that creates or redesigns a public website to make sure, to the greatest extent practicable, that it doesn’t overlap with or duplicate any legacy websites. It also requires that legacy websites are regularly reviewed, eliminated, and consolidated. OMB memo M-23-22, Delivering a Digital-First Public Experience, gives agencies further guidance on implementing the act.
In practice, that turns redundant content into a compliance issue. An agency that launches a redesigned site while the old pages are still live and indexed has two sites saying different things.
State and local governments, and public sector bodies outside the US, work under their own rules. But the underlying problem is the same everywhere: public information has to be current, and people have to be able to find the right version. If you’re working on a government site, here’s what’s involved in modernizing a government website.
How to prevent content ROT from coming back
A cleanup without governance is a one-off project. Within a year or two the ROT is back, because nothing changed about how content gets published.
Prevention comes down to ownership, metadata, and routine:
- Assign an owner to every page. Not a team, but a named person or role responsible for keeping it accurate.
- Store ownership and review dates in your CMS. An owner field and a last-reviewed field turn “someone should check this” into a report you can run. Showing a last-reviewed date on the page also helps your visitors judge how current it is.
- Set review cadences by content type. Regulatory and compliance pages need a review whenever the underlying rule changes. Service and product pages need one whenever the service or product changes. Evergreen guides need a scheduled review at least once a year. News and events should get an expiry date when they’re published.
- Add an approval step for new content. Someone should check whether a new page duplicates an existing one before it goes live, not after.
- Keep governance and style guidelines where publishers can find them. Most redundant content comes from people who didn’t know the original existed.
- Look for the workflow patterns behind your ROT. If the same team keeps producing duplicates, the fix is in their process, not in the next cleanup.
ROT review works best as one stage of content lifecycle management: plan, create, publish, review, retire.
If your publishing process has no retire stage, ROT is the predictable result.
How far you can take this depends on where your team sits on the path to content operations maturity.
A cleanup removes the ROT you have. Governance is what stops you building it again.
Frequently asked questions
What does ROT stand for?
ROT stands for redundant, outdated (or obsolete), and trivial. The term is common in records and information management, where it describes files that should be cleaned up. In web content, it describes pages and documents that no longer belong on your site in their current form.
What’s the difference between content rot and content decay?
Content decay is a performance problem: an accurate page loses traffic or rankings over time. Content rot is a quality problem: the page is duplicated, wrong, or pointless. A decaying page needs updating. A rotting page needs a decision, and sometimes that decision is to remove it.
How often should you audit for content ROT?
Run a full audit before any redesign or migration, because moving ROT to a new platform only makes it more expensive to deal with later. Between audits, owner reviews at the cadence you’ve set for each content type should catch most of it.
If owners review on schedule, every full audit gets smaller than the last.
