How to find the pages nobody maintains any more
Every wiki older than three years is carrying documentation for systems that no longer exist. Here is how to find it in Confluence Cloud, what the built-in tools genuinely do, and how to run the audit so it does not have to be redone by hand every quarter.
Short answer. Search inside a space and set the last modified filter to a cut-off date, for example before last year. For a sharper cut, the query space = KEY AND type = page AND lastModified < now("-365d") can be run through the Confluence REST API. Both give you a snapshot; keeping that list live on a page needs a macro from an app.
Why this piles up
Nobody sets out to abandon documentation. It happens because writing a page is somebody's job and retiring one is nobody's. The service gets decommissioned, the project ends, the tool is replaced — and the page stays, indexed and searchable, looking exactly as authoritative as the page next to it that is still true.
The damage is not storage. It is that a new engineer follows instructions for a system switched off two years ago, and an auditor finds a policy page dated 2023 that contradicts the current one.
What Confluence gives you out of the box
Search filters
The advanced search screen lets you narrow by space, by contributor, by label and by last modified date, including "before" a date you choose. For a first pass this is often enough: pick a space, set the date to two years ago, and look at what comes back.
CQL through the API
Confluence's query language is more precise than the filter UI, and in Cloud it is available through the REST API. A typical audit query looks like this:
space = ENG AND type = page AND lastModified < now("-365d") ORDER BY lastModified ASC
Add AND label = "policy" to narrow it, or AND creator = "someone" to find what left with a person who has moved on. This is the right tool if somebody on the team is comfortable calling an API and turning JSON into a spreadsheet.
Labels and page reports
If your spaces use labels consistently, the built-in macros that list content by label will assemble a page of everything tagged, say, runbook. That does not tell you what is stale, but it does tell you what should have been reviewed.
Where the built-in route runs out
An audit routine that survives contact with reality
The mistake is treating this as a one-off cleanup. Do it as a standing list instead.
1. Pick one space, not the whole site. A site-wide list of eight hundred pages gets closed and never reopened. One space with forty candidates gets dealt with.
2. Set the cut-off by content type, not by feel. Runbooks go stale in six months. Policies live for years. Onboarding material is wrong the moment the tooling changes. One cut-off for everything produces noise.
3. Sort oldest first. The bottom of that list is where the obvious corpses are — the page about the office printer on floor three, the setup guide for a laptop model nobody has.
4. Decide per page: update, archive, or delete. Most pages deserve archiving. Archiving removes a page from search and navigation while keeping it recoverable, which is what people usually mean when they say "delete it".
5. Leave the list in place. This is the step everyone skips. If the list stays on a page and rebuilds itself, next quarter's audit is ten minutes instead of an afternoon, because everything handled has already dropped off it.
Careful with one thing: "not edited" is not the same as "not used". A page can be correct and heavily read for three years without a single edit. Use the date to build a shortlist, then judge each page on what it says.
What to do with what you find
Archive rather than delete. The archived page keeps its history and can be restored, and it stops competing with the current page in search results — which was the real problem.
Give the survivors an owner. A page with a named owner and a review date is a page that gets updated. A page owned by "the team" is a page owned by nobody.
Write the retirement into the process. If your definition of done for decommissioning a service does not include "archive its documentation", this list will be exactly as long next year.
When an app is worth it
Apps in this category exist for one reason: to turn the snapshot into something that stays true. The condition sits on a page, the list rebuilds itself as pages change, and a page that somebody finally updated leaves the list on its own.
Disclosure: I build one of them, Smart Search. Conditions are picked from dropdowns rather than written in CQL, the app shows in plain English what the list will contain before you save it, and CQL is still there in manual mode if you prefer it. It runs entirely on Atlassian infrastructure, so your pages are read inside your own site and nothing is sent to us. There is a demo you can click through without installing anything.
If a quarterly search filter and a spreadsheet work for your team, use those. The audit matters more than the tooling.
Frequently asked
Can I see which pages nobody reads, rather than nobody edits?
Views are a different signal from edits, and where page analytics are available on your plan they answer that question better than a date filter. The two lists rarely match: plenty of unread pages are perfectly correct, and some heavily read pages are dangerously out of date.
What is a reasonable cut-off?
180 days for operational material, one year for reference, two years before anything gets deleted rather than archived. Adjust once you have seen your first list.
Does this work across the whole site?
Technically yes, practically no. Space by space is the only version that gets finished.
We are migrating from Data Center. Does the same apply?
The idea does. Some of the tooling does not: Data Center has reporting features Cloud does not, and several audit apps never made the move — see our note on what the Connect end of life means for admins.