How to Build a Useful Website Content Inventory

A useful website content inventory is a controlled record of the pages a business has published, why each page exists, and what decision should be made about it. It is not merely a download containing hundreds of URLs. For a small UK agency, the inventory should connect the technical address of a page with its editorial responsibility, customer purpose, evidence and next review action. That combination helps prevent unnecessary new articles, missing service pages and careless deletions. This guide explains how to build a proportionate inventory, distinguish known facts from uncertain observations and turn the result into an editorial work queue without creating an administrative project that outlives its usefulness.

Set the inventory's boundaries before collecting URLs

Define which website properties, content types and languages belong in the exercise. A single public site might include service pages, articles, product details, campaign landing pages, documentation, media files and utility routes. Not every category needs the same review, and some routes may be intentionally excluded from search. Record the authorised production domain and any legitimate subdomains separately. A development host should not silently enter the count merely because a crawler discovered it.

Agree the purpose of the inventory. Is the business preparing a redesign, planning an editorial programme, diagnosing overlapping articles or reviewing outdated service information? That decision determines which fields matter. A migration inventory needs exact old URLs and intended successors; an editorial review needs reader purpose, factual currency and content owner. Do not promise that one spreadsheet will resolve every SEO question. Define the date of collection and keep the original export, because the site may change while the review proceeds.

Include a scope note for exclusions. For example, private account routes may require security review rather than content optimisation, while internally generated search-result pages may not be intended as independent articles. The denominator should be defensible: the number of URLs discovered is not necessarily the number of distinct editorial resources. A clear scope prevents unnecessary arguments about a site supposedly having thousands of pages when many are technical variants.

Collect addresses from complementary sources

Start with a suitable site crawl, CMS records, XML sitemaps and available authorised Search Console observations. These are complementary views, not identical lists. A crawler normally discovers reachable links; it may miss orphaned pages. A CMS may contain unpublished records or URLs that the public frontend does not serve. A sitemap can retain obsolete addresses if its generator has not been corrected. Search Console may show URLs Google knows about but omit resources outside its reporting scope.

Bring these sources together in a staging sheet and preserve the origin of each address. The Google Search Central site-move guide recommends using more than one resource when collecting URLs for migration, including CMS records, logs and relevant linked-page evidence. That guidance supports comprehensive discovery, not an assumption that every discovered address should be indexed.

Resolve duplicates cautiously. HTTP and HTTPS forms, trailing slashes, query parameters and redirects might identify alternate access paths rather than independent content. Record the requested URL, final destination, response status and reported canonical separately. Do not delete variants from the raw data before understanding why they exist. An incorrect redirect rule can make two previously distinct service pages appear to be one resource, which is a potential defect rather than successful deduplication.

Describe the real purpose of every important page

An inventory becomes editorially useful when each priority page has a concise, testable purpose statement. The title and H1 are useful clues, but they might be vague or stale. Read the page itself and record what its intended visitor should learn or accomplish. A service page might establish eligibility and enable an appropriate enquiry. A technical guide might explain a procedure and its limitations. A contact page might direct several kinds of requests to the correct team.

Use this purpose field to identify overlap. Two articles may share the word 'canonical' while one explains the concept to beginners and the other shows a developer how to test templates. That is not automatically duplication. Conversely, two posts could repeat the same examples, evidence and call to action under different headings. The inventory should flag that for editorial review rather than unilaterally assigning a canonical or ordering a deletion.

Record the audience and next action where those clarify the distinction. Avoid invented customer personas or unsupported claims about how users behave. The field should describe the published page's actual job, not the keyword a previous agency hoped it would rank for. An honest purpose statement often reveals gaps in service explanation before any new keyword research is needed.

Add technical conditions without confusing them with quality

For important URLs, collect public response status, redirect destination, intended canonical, indexing directive and whether the page is connected through useful navigation. These fields help identify technical problems that no amount of copy editing will repair. A key service page returning a 404 or accidentally carrying noindex requires investigation. An intentionally retired utility route may be behaving exactly as designed.

Keep observed and intended states separate. 'Public page returns 301 to another service' is an observation; 'should redirect to the successor guide' is an expectation that requires approval. A tool can identify a broken link but cannot decide which replacement is factually appropriate. Record the source of every material claim and the date the live response was checked. Avoid treating a CMS field as proof that the frontend currently emits that value.

Look for shared-template patterns before creating hundreds of individual tickets. Repeated missing metadata could result from one renderer rule, and an entire service group might be excluded by a deployed robots configuration. Grouping faults by cause gives a small team a manageable work queue. It also protects the client from paying for repetitive manual edits when one authorised component repair would address the source.

Use performance information as context, not a verdict

Search Console can provide impressions, clicks and page-query observations for a verified property under Google's reporting definitions. Those measures are useful when reviewing which pages attract relevant search demand. They are not the same as the business value of a page, and an average position is not a fixed rank observed by every searcher. A specialised answer can serve an essential customer question whilst receiving few impressions.

Record the property, date range, relevant filters and data limitations when adding performance fields. Google's Performance report documentation explains how those measures are presented. Compare suitable periods without assuming that every change was caused by a content edit. Seasonal demand, new results features or changed query groups can influence the figures.

Avoid automatic rules such as deleting every article below a chosen click threshold. Review factual accuracy, customer value, service relevance and internal use first. A legally important policy explanation, though it may not be a search acquisition page, should not be removed merely to tidy a dashboard. Equally, high historic traffic does not justify keeping misleading descriptions of a discontinued service. The decision needs editorial and operational judgement.

Turn uncertainty flags into specific review decisions

An inventory should allow reviewers to mark what is unknown. Useful states might include 'purpose needs clarification', 'source date needs checking', 'technical redirect unresolved', 'overlap to review' and 'service owner approval required'. These are better than a single colour-labelled SEO health score because they identify the missing evidence or responsible person. Keep a separate final action field for retain, update, consolidate, redirect, retire or investigate.

Do not equate a flag with approval to mutate production. A proposed consolidation may affect inbound links, customer bookmarks and the completeness of the surviving guide. A proposed deletion might remove a resource needed by support. Write down what evidence would permit the decision, who should approve it and how the public result would be tested. This separates discovery work from change control.

Prioritise by consequence and scope. A duplicated category caused by a shared template might affect many visitor journeys; a minor stale screenshot in an otherwise accurate archive may need a scheduled review rather than emergency work. Include dependencies such as a planned migration or a service policy update. A credible inventory is a decision queue, not a list of every theoretical improvement.

Keep the record usable after the initial audit

Choose a small set of durable fields: canonical or requested URL, content type, reader purpose, responsible owner, review date, material issue, evidence location and next action. Add migration or performance fields only where they serve a real decision. Use controlled status values and explain what each means, so colleagues do not confuse 'reviewed' with 'published and publicly verified'. A single shared register should have a clear update owner.

Integrate changes into the normal publishing process. When a new service page launches, record its purpose and owner. When guides merge, update the surviving destination and redirect map. When a source changes, mark affected articles for factual review. This turns the inventory into a maintained editorial map rather than a static export produced once and abandoned.

After an update, check the actual public page as a separate acceptance activity where the task requires it. Confirm that headings, comparisons, images and links work, and that private editorial notes remain private. A successful production database write followed by native read-back confirms the record was saved; it does not by itself verify browser presentation. The most useful inventory closes the gap between what the website claims to contain, what customers can reach and what the team is prepared to maintain. Start with a few meaningful fields and improve the decisions they support before adding another spreadsheet column.