The useful outcomeA spreadsheet of URLs is an inventory. A website content audit becomes valuable when each row ends in a defensible decision and a named next action.
A website content audit starts with the journeys that matter
Begin with the decisions visitors arrive to make. A software company may need prospects to understand the product, compare plans, trust the team and request a demo. Those journeys matter more than whether the current site has 80 pages or 800.
Build an inventory from the CMS, sitemap and analytics, but group each URL by audience, need and next action. A pricing page and an old campaign page may use different templates yet answer the same buying question. Seeing them together makes overlap visible before a designer reproduces both.
GOV.UK's content transition guidance recommends auditing existing material, identifying high-use and high-impact content, finding duplicates and deciding what does not need to move. The practical lesson is simple: migration is a selection exercise, not a moving van.
Combine usage data with human evidence
Traffic shows what people reach, not whether the page helps them. Combine analytics and search data with support questions, sales objections, stakeholder knowledge and direct user research. A low-traffic legal or implementation page can still remove a critical buying risk.
Imagine a hypothetical B2B platform whose integration page gets modest traffic. Sales calls repeatedly stall on one unsupported system, while support tickets reveal confusion about setup. Deleting the page because it is not popular would erase the evidence the redesign needs most.
GOV.UK guidance on learning user needs recommends using research, analytics, search logs and contact data rather than treating internal opinions as facts. Record the source beside each finding so a later meeting cannot turn a loud preference into user evidence.
Give every page one explicit decision
Every material page should end with one primary action: keep, merge, rewrite or remove. The decision needs a reason and a release condition. "Rewrite" is not actionable if nobody knows which claim is weak, which question is unanswered or who approves the replacement.
For example, three service pages may repeat the same promise with different labels. Merge them only if they serve the same audience and buying decision. If one page supports a regulated procurement process, similarity in wording is not enough reason to collapse it.
| Page state | Decision | Evidence to record | Release condition |
|---|---|---|---|
| Useful and current | Keep | Clear need, trusted facts, active owner | Fit the new journey and template |
| Overlapping | Merge | Same audience, intent and next action | Choose one destination and redirect the rest |
| Needed but weak | Rewrite | Known gap, stale proof or unclear answer | Approve a brief, evidence and owner |
| No longer justified | Remove | No valid need, duplicate or expired purpose | Map links, redirects and dependent journeys |
Score trust and ownership, not just prose
A polished paragraph can still be unsafe to publish. Check whether claims are supported, dates are current, terminology matches the product and a named person can approve future changes. Content with no owner starts ageing the moment the redesigned site launches.
Consider a hypothetical security page that says data is encrypted but does not identify what is encrypted, when or according to which current policy. The audit should not beautify the sentence. It should flag the missing evidence, assign an approver and block publication until the claim is precise.
Google's people-first content guidance asks whether material provides original value, clear sourcing, descriptive headings and trustworthy presentation. Those checks are useful beyond search because they expose what a buyer can verify and what the organisation can maintain.
Write briefs before you write pages
A rewrite brief should name the reader, the question to answer, the evidence available, the action to support and the approver. It can also list required examples, objections and terms that need explanation. This gives writers and designers a shared contract before layouts harden around placeholder copy.
A product comparison page, for example, may need a feature table, a limit that prevents a bad purchase and a route to technical documentation. Its brief is not "make this more compelling." It specifies what a serious evaluator must understand and what proof the team can honestly provide.
Descriptive structure also helps people navigate long pages. The W3C notes that headings communicate organisation and support navigation. Decide that hierarchy in the brief, then let visual design give it rhythm rather than inventing the information model afterward.
Connect content decisions to the migration contract
The audit is not finished until old URLs have destinations. Record the future URL, redirect, title, description, internal links, structured data and owner where each item applies. That map connects editorial intent to engineering work and gives quality assurance something concrete to verify.
Suppose two old guides become one new guide. The map should identify the preferred destination, redirects from both old URLs and every important internal link that must change. Google's site move guidance explicitly recommends preparing old-to-new URL mapping and using redirects when URLs change.
This is where a content audit meets, but does not replace, a technical SEO audit. The content work decides what deserves to exist. The technical work checks whether search engines and browsers can reliably find, understand and serve it.
AI can classify the inventory, but it cannot own the decision
AI can group similar pages, extract headings and suggest likely duplication. It can also draft summaries for a reviewer. It cannot know whether a low-traffic compliance page prevents a costly sales objection, whether a claim is approved or which team accepts the risk of removal.
In a hypothetical audit of 500 URLs, automation might flag 40 pairs with similar text. A content lead still needs to compare audiences, backlinks, current product truth and contractual obligations. Treat the model as a sorting assistant, not as the publisher or accountable owner.
The serious objection is time: teams want design to begin immediately. A short evidence pass on the highest-value journeys is often enough to start. What does not work is pretending the decision can wait while components, navigation and templates are already being approved.
Buy a decision system, not a spreadsheet export
A useful proposal should describe the inventory method, evidence sources, review roles, decision criteria, rewrite briefs, URL map and approval points. It should also state what is excluded. A team may audit priority journeys first, but the boundary must be visible so ignored content does not silently enter the build.
Bring the current sitemap, CMS export, analytics access, top user journeys, sales questions and known legal approvals. The website design brief helps organise those inputs, while the redesign strategy guide places the audit inside the wider programme.
- Priority audiences and journeys are named.
- Every important URL has a user need and business role.
- Analytics, search, support and research evidence are linked.
- Keep, merge, rewrite or remove is justified per page.
- Weak claims have evidence needs and approvers.
- Rewrite briefs and old-to-new URL mapping are deliverables.
- Launch checks and post-launch ownership are assigned.
Website content audit checklist before a redesign
If your team can provide the URL inventory and the three journeys that matter most, the work can be scoped without inventing certainty. Send those inputs to Seuil Digital and ask for an audit that ends in decisions your writers, designers and developers can ship.