Practical guide 5 min read
A website content inventory records the pages and assets a business already publishes. It gives the team a shared view of each item’s purpose, factual owner, review evidence and next action before a redesign or routine content update. An inventory is not a list of new articles to commission, and a low traffic number is not an automatic reason to remove a useful page.
Use the template below for an existing business website. It separates the record of what exists from the judgement about what should change. The examples are fictional; they are not client work or a claim of search results.
Inventory, content audit and migration map do different jobs
- Inventory: what exists, where it lives and who is responsible for it.
- Content review or audit: whether an item is accurate, useful, distinct and appropriate for its audience, and what evidence supports a change.
- Migration URL map: what happens to an old address during a move, including its intended destination and technical checks.
The Department of Energy’s content-inventory guidance similarly separates listing content from analysing its usefulness and accuracy. Its own CMS instructions and organisational review requirements are specific to that organisation, not universal website rules.
1. Set the scope and sources
Choose the website or section being reviewed, the review date and the person responsible for the record. Include relevant service pages, articles, downloads, important images and other assets—not only items that happen to appear in the main menu.
Combine an authorised CMS export, the current sitemap, navigation and internal links with relevant search, analytics and business records. Each source has limits: a sitemap can omit old landing pages; an analytics report can miss unmeasured visits; a CMS list can include private or test items. Keep private/account material out of the public publishing list, and record any unreviewed section.
2. Use these content-inventory template fields
Start with one row per reviewed item. Keep observations separate from proposed changes so an unapproved recommendation does not become a publishing instruction.
- Identity: current URL or asset reference, page title, content type, section and language where relevant.
- Purpose: intended audience, question or task, preferred topic owner and the next useful visitor action.
- Responsibility: factual owner, reviewer, final approver and review date.
- Evidence: claim sources, asset rights or permissions, known factual gaps and references to relevant reports with their dates and scope.
- Condition: what was actually checked, observed problems and anything still unknown or not applicable.
- Decision: proposed action, reason, dependency, approval status, responsible person and next review trigger.
Copyable blank record: [URL/reference]; [title/type/section]; [audience and purpose]; [preferred topic owner]; [factual owner]; [review date]; [evidence references and periods]; [observed issue or unknown]; [proposed action and reason]; [approver/status]; [action owner]; [next review trigger]. Do not put passwords, customer details or private conversations in this shared record.
3. Review usefulness and accuracy before choosing an action
Open the actual item and ask whether it still answers the intended visitor’s question. Check service availability, prices, contact details, dates, qualifications, product information, image permissions and other claims against sources the business can approve. An attractive layout or successful page load does not establish factual accuracy.
Check for overlapping purposes, not just matching words. Two pages can mention the same topic while serving different tasks; two differently worded pages can compete to answer the same question. Choose the intended owner before deciding whether to consolidate anything.
Use relevant search and enquiry observations as context, with the period and measurement limitations recorded. A support page, policy or specialist reference can remain useful without much search traffic. Conversely, traffic does not make an obsolete offer safe to retain unchanged.
4. Turn the inventory into a review queue
This illustrative example uses relative paths for a fictional business. It demonstrates decision records, not a recommended action for your corresponding pages.
| Item | Purpose and observation | Evidence or missing input | Proposed action and gate |
|---|---|---|---|
| /services/repairs/ | Explain a current repair service; an old contact number remains. | Service owner must confirm the current number and service boundary. | Update the existing page after factual approval; retest its contact action. |
| /resources/preparation/ | Help booked customers prepare; little recorded search traffic. | Support team confirms customers still need the instructions; analytics coverage is limited. | Retain useful guidance and review accuracy; do not remove it solely for low traffic. |
| /guide-one/ and /guide-two/ | Both appear to answer the same buying question. | Reviewer compares unique material, intended audience, links and relevant search evidence. | Assess consolidation; approve the owner and retained content before preparing any redirect. |
| /old-offer/ | Describes an offer whose availability is unclear. | Business confirmation and an appropriate replacement, if any, remain unknown. | Escalate for a decision; do not silently invent availability or redirect it to an unrelated page. |
Use clear states such as not reviewed, awaiting facts, proposed, approved, implemented and retested. A completed inventory row is not evidence that the proposed website change has been made. Attach the resulting URL or change reference and retest evidence when work is completed.
5. Send each decision to the right workflow
Use the website design brief to turn approved content needs into project inputs and responsibilities. Use the SEO content brief for an individual page assignment with its own intent, approved facts and internal links. Do not paste the inventory into a writing brief without deciding what the page should own.
If an approved decision changes or retires an address, carry it into the migration URL map and testing workflow. The inventory records the editorial reason; the migration record verifies the technical outcome. A proposal to merge pages is not permission to deploy redirects or delete content.
6. Keep the record useful after the first review
Prioritise inaccurate offers, broken essential journeys and missing ownership before cosmetic differences. Agree review triggers suited to the content: a changed service, new price, expired permission, moved URL, repeated customer question or planned redesign. Preserve unresolved questions rather than replacing them with guessed facts.
For recurring publishing and technical care, use the WordPress website maintenance checklist. For a design project, share your current website, inventory scope, confirmed content responsibilities and priority customer tasks when discussing Agal Technologies’ web design service. New copy, migration and ongoing maintenance must be included explicitly in the written scope.
Related Blogs
