Audits expose duplicate, stale, and orphaned content

What it is

After the inventory records what exists, the audit decides keep, merge, update, or retire for each item. It is built to expose three kinds of object that damage architecture: duplicates (the same fact written differently in several places), stale pages (still reachable, no longer true), and orphans (no entrance, no reference, no owner). These are the part of ROT (redundant, outdated, trivial/orphaned) that should be handled first. An audit is not a taste check. It clears the ground for a new structure: skip these three, and the new categories will classify the junk beautifully.

Inventory answers existence; audit answers stay-or-go. An audit without an inventory is sampled complaining.

Why it happens

Duplicates inflate result lists and category counts; people have to bet which near-copy is true. Stale pages send a correct path to a false fact—the better the architecture finds them, the worse the harm. Orphans stay out of navigation and still get hit by search and inbound links, becoming ghost pages nobody can explain; if the new structure gives them no place, they keep living at the old URL after launch. All three make “how many items in this class” an untrustworthy number, which then poisons breadth/depth choices, facet counts, and relatedness.

The audit must map objects to actions, not to scores. A score cannot merge two duplicate policies. An action can.

Studying it

Take known duplicate sets, stale pages, and orphan URLs as gold, and see how much of them the audit process catches—and what leaks.

• Paradigms: mark ROT actions on the inventory, assisted by near-duplicate detection, date-versus-policy-version checks, and inbound-link plus nav-reference analysis. Compare “new nav only” with “ROT then nav” on findability and trust.
• Independent variables: audit coverage, inclusion of file-type content, operational definition of stale (older than N days, superseded by a new policy, legally void).
• Dependent variables: duplicate groups caught, tasks that hit a stale fact, post-launch hits on ghost URLs.
• Methodological note: zero traffic is not orphanhood; a rare compliance page can be critical. Staleness is not last-modified: an old policy touched once a year still has a fresh timestamp. Duplicates are the same fact, not the same title.

Where it stops holding

Archives and historical records exist to keep stale objects; the audit’s action becomes “mark as history and drop from the default lookup set,” not delete. Content still inside a legal retention window cannot be retired even if orphaned. Automatic near-duplicate detection will treat language versions and accessible alternative formats as duplicates; those need a type “equivalent and required to coexist.” Personal user content (drafts, messages) is not site-level ROT.

Applying it

• Put one action on every inventory row: keep / merge into / update / retire / archive. No scoring-only audits.
• Name one canonical page per duplicate group and redirect the rest. Do not hang several near-synonym entrances in the new nav.
• Either update stale pages or remove them from default search and navigation, and mark their historical status, so “still opens” is not read as “still in force.”
• Verify by sampling ten pages that searchers open and immediately leave: the audit should already have marked them stale or duplicate. Sample ten URLs with no inbound links: they should be marked orphan and given an action. Mismatch means the audit is still an opinion.

Related

• Within the group: G1.07.1 Architecture work starts with an inventory of what already exists · G1.07.3 Uninventoried content will break a new architecture
• Adjacent: G1.11 Architectural scalability and evolution · T3.03 Content freshness and maintenance · G3.15 Result grouping and deduplication
• Search terms: content audit · ROT · duplicate content