Documentation Content Audit Template (Inventory, ROT)

Content Audit: [Documentation set or site name]

Quality audit and content inventory for a documentation set: scope and objectives, method and criteria, one inventory row per page (URL, Diátaxis type, owner, last verified date, usage and feedback signals, accuracy rating, ROT verdict and action), the verdict rules, a findings summary with recomputed numbers, gaps, a remediation backlog, the redirect and archive plan, and governance for the next audit. Structure aligned with the management and quality-evaluation activities of ISO/IEC/IEEE 26511:2018 (requirements for managers of information for users) and the review concepts of ISO/IEC/IEEE 26513:2017; accessibility signals refer to WCAG 2.2 (W3C Recommendation, 12 December 2024). Replace every [bracketed] value and every row marked Example.

Document control

Approvals

Revision history

Contents

1. Scope and objectives
2. Method and criteria
3. Roles and schedule
4. Audit process
5. Content inventory
6. Verdict and action rules
7. Findings summary
8. Content gaps
9. Remediation backlog
10. Redirect and archive plan
11. Governance and next audit
12. Glossary and references

1. Scope and objectives

Example: Corvid Commerce audits its developer documentation before moving it to a docs-as-code platform. The audit decides which pages migrate, which merge and which are archived. Scope: English pages under /docs/; generated API reference and translated pages are out of scope. The example inventory in section 5 shows 10 representative pages.

Objectives:

1. Produce a complete inventory with one accountable owner per page.
2. Rate each page for accuracy, freshness and usefulness against the criteria in section 2.
3. Give each page a ROT verdict and one action from the agreed set: keep, update, merge, archive or redirect.
4. Identify content gaps from support and search evidence.
5. Produce a prioritised, owned remediation backlog with dates.

2. Method and criteria

2.1 Inventory fields

2.2 Ratings

2.3 Usage and feedback signals: privacy rules

• Use aggregate counts only: page views per page per month, positive and negative feedback counts, zero-result search terms, and support ticket tags. Never collect or store names, email addresses, IP addresses or device identifiers for an audit.
• Prefer cookieless, first-party measurement, or server log counts that are aggregated and stripped of identifiers before analysis.
• Respect consent choices and the Global Privacy Control (GPC) signal where your measurement depends on them.
• Treat low-traffic numbers with care: a reference page read by ten administrators a month can still be essential.
• Signals inform the verdict; they never decide it alone. A page with no traffic may be essential, and a page with high traffic may be harmful if inaccurate.

2.4 Accessibility signals

Record for each page whether automated checks found accessibility issues mapped to WCAG 2.2 (for example missing alt text under 1.1.1 Non-text Content, or vague link text under 2.4.4 Link Purpose (In Context)). The audit notes counts; fixes go through the Docs Review Checklist (docs/docs-review-checklist).

3. Roles and schedule

4. Audit process

Steps in practice:

1. Export every published page from the source repository and compare with the generated site map to catch orphans and pages missing from the build.
2. Join the aggregate signals for a fixed period (for example the last [3] full months) so seasonal effects do not distort single pages.
3. For each page, open the rendered version, read it, check its type, and record the owner and last verified date from metadata.
4. Ask the SME to spot check claims on pages rated Partly accurate or worse, and on every page with high usage.
5. Apply section 6 to reach one action per page. Record the reason in one sentence.

5. Content inventory

Snapshot date for the example rows: 2026-06-30 (the Q2 2026 audit that the Docs Metrics Report (docs/docs-metrics-report) example builds on). Verify interval: 12 months, so a page is stale when last verified before 2025-06-30.

Accessibility and quality signals per page (from automated checks on the snapshot date):

6. Verdict and action rules

Never delete a public URL without a redirect or an explicit "gone" response: readers, search engines and support macros link to it.

7. Findings summary

Figures for the 10 example pages in section 5:

Key findings:

1. Example: Usage is concentrated: the three Keep pages carry 70.6% of monthly views, so remediation should protect those pages first and remove the noise around them.
2. Example: Freshness is the main weakness: 7 of 10 pages have not been verified in the last 12 months, and every stale page is rated below Accurate.
3. Example: Duplication confuses readers: three Redundant pages (CA-003, CA-009, CA-010) compete with better pages, and all three have helpful ratings under 50%.
4. Example: Two pages have no owner, which explains why they decayed.
5. Example: The FAQ mixes troubleshooting, how-to and reference content; splitting it follows the Diátaxis forms.

8. Content gaps

9. Remediation backlog

The example backlog has 10 items: 7 from the inventory (every page without a Keep action) and 3 from gaps; 5 are P1, 3 are P2 and 2 are P3. Every updated or new page passes the Docs Review Checklist (docs/docs-review-checklist) before it closes.

10. Redirect and archive plan

Archive rules:

• Archived pages carry a banner that states they are not maintained and links to the current alternative.
• Archived pages are excluded from site search by default and marked so that search engines do not index them, unless a legal or contractual reason requires them to stay discoverable.
• Redirect rules follow the information architecture policy (docs/information-architecture).

11. Governance and next audit

Progress on the remediation backlog and the freshness share is reported in the Docs Metrics Report (docs/docs-metrics-report).

12. Glossary and references

12.1 Glossary

12.2 References

Standard and licence note

Structure aligned with the management and quality-evaluation activities of ISO/IEC/IEEE 26511:2018 and the review concepts of ISO/IEC/IEEE 26513:2017. Only standard names and general concepts are referenced; no ISO text, table, definition or clause wording is reproduced. Accessibility signals cite WCAG 2.2 success criteria by number and short name only. Content types follow the four forms of the Diátaxis framework by Daniele Procida (https://diataxis.fr), licensed under CC BY-SA 4.0; this template uses the type names for classification and does not adapt Diátaxis text. The ROT method is common industry practice described here in original words. All example data refers to a fictional company. This template is original text written for this collection. Check the current official versions of every cited standard before use. Template licence: MIT.