Website Redesign Content Inventory Guide

A redesign can remove valuable information before anyone notices it was important. Teams often begin with the navigation they want, then migrate only the pages that fit. Old specifications, support downloads, campaign destinations and useful articles disappear because they were never included in the design discussion.

A content inventory makes those decisions visible. It records what exists, who uses it, what should happen to it and who approves the change. Bring this evidence into Website Redesign before layouts and migration estimates are finalized.

Define the Inventory's Boundaries

Decide which domains, subdomains, languages and systems the redesign covers. Include documents and media that customers access directly, not only HTML pages. A product manual or downloadable application form can be a critical destination even when it is absent from the main menu.

Identify areas that remain on another system, such as a booking portal or help center. Their URLs may stay unchanged, but navigation and authentication handoffs still need review. Record these dependencies instead of assuming they sit outside the customer experience.

Name a decision owner for each business area. Marketing can assess campaign pages, while support may understand why an obscure instructions page must remain available. A redesign team should not make those judgments from traffic alone.

Collect URLs From More Than One Source

Combine a crawl of the current site with CMS exports, sitemaps, analytics, search reports and known campaign links. Each source reveals different pages. A crawler may miss orphaned content, while analytics may omit pages with broken tracking or low recent activity.

Google's site-move documentation recommends preparing old-to-new URL mappings and considering assets such as images and downloads. Use that guidance to broaden the inventory beyond the pages visible in a new sitemap sketch.

Record the original URL exactly before normalizing it for comparison. Query parameters, trailing slashes and case differences may have operational meaning. The developer needs to distinguish true duplicates from distinct customer destinations.

Create Fields That Support Decisions

Useful columns include URL, page type, title, owner, audience, purpose, current status, traffic context, known external links, proposed action, destination and review notes. Add content dependencies where a page relies on a form, file or external system.

Keep source dates alongside metrics. A year's search activity and one month's analytics are not directly comparable. Record whether a campaign was active during the selected period and whether tracking changed.

Do not turn the sheet into a warehouse of every available metric. If a column will not influence a decision or validation step, it may be unnecessary. The inventory needs to remain usable by people who understand the content but do not work in analytics.

Read the Pages Before Classifying Them

Open each page and identify its actual task. A title can be misleading, and a page labeled news may contain the only current instructions for a product. Note whether the content is accurate, complete, duplicated or dependent on obsolete offers.

Separate factual quality from visual quality. An unattractive page may contain essential information worth preserving. A polished page may make unsupported claims or send customers to an abandoned form.

For example, imagine a fictional equipment supplier whose old support page receives few visits but links to installation diagrams used by existing customers. Removing it because it ranks poorly would damage service. The inventory should preserve the task and its downloads, even if the presentation changes.

Use a Clear Set of Content Actions

Keep means the page remains substantially useful and can retain its URL. Update means the task is valid but the explanation, evidence or product references need work. Merge means several pages genuinely serve the same task and their useful material can be combined.

Retire means the content no longer needs a public destination. Move means the task remains but its location changes. Distinguish these actions so the team does not use redirect as a substitute for deciding whether the content is still needed.

Add a reason and approver to every significant action. A row marked delete without context is difficult to challenge later, especially when the person who made the decision is unavailable.

Evaluate Business Value Beyond Sessions

Look for inquiry support, customer education, sales enablement, legal or operational requirements, and links used in printed materials or email. A low-traffic page can still serve a valuable specialist audience.

Review conversion evidence cautiously. A page may assist a later purchase without receiving final-click credit. Conversely, a popular article may attract an audience unrelated to the current offer. Use the page's purpose when interpreting its performance.

Ask sales and support staff which links they send repeatedly. Those destinations deserve explicit migration checks even if automated reports do not highlight them. Include bookmarked internal tools only when they are within the authorized redesign scope.

Map Destinations According to Customer Intent

When a URL changes, identify the closest relevant new destination. Do not send every removed page to the homepage. A customer following an old product manual link expects instructions, not a broad company introduction.

Where several pages merge, verify that the destination retains the useful answer from each source. A redirect cannot preserve information that was omitted from the new page. Treat content consolidation and routing as connected tasks.

For genuinely removed content with no suitable replacement, discuss the appropriate unavailable response with the technical team. The technical SEO audit guide helps connect those decisions with status codes, canonical URLs and crawl checks.

Account for Forms, Files and Embedded Content

Inspect forms for their destination, required fields, notifications and stored records. A redesigned page can look complete while sending inquiries to an old employee or disconnected integration.

Check downloadable files for version, ownership and links from outside the site. If a filename changes, update references and decide how old links will behave. Preserve accessible alternatives and useful document metadata where relevant.

Review embedded videos, maps and third-party widgets. Record licensing, account access and any consent dependencies. The inventory should show which content can be migrated directly and which requires another provider's configuration.

Turn the Inventory Into a Migration Worklist

Assign each approved action to an editor or developer with acceptance criteria. A page marked update needs a brief describing what must change. A page marked move needs its destination and routing requirements.

Track readiness separately from approval. Approved content may still lack images, technical implementation or final review. Use statuses that reveal the remaining dependency instead of a single ambiguous completed column.

The e-commerce migration checklist provides practical examples of validating customer journeys before and after a platform move. Adapt the scenarios to the redesign's actual page types.

Verify the Inventory Against the New Site

Check each important source URL and its intended result. Confirm destination content, links, forms, files, metadata and canonical behavior. Test high-risk page types deeply and automate repetitive URL checks where appropriate.

Keep the original inventory as a baseline and record late changes. Redesign projects often add or remove pages near launch; those decisions need the same review as the initial plan.

After release, investigate unexpected missing pages and customer complaints against the inventory. This is easier than trying to remember whether a particular document was intentionally removed.

Frequently Asked Questions

Can we start with the new sitemap instead?

Use it as a proposal, then compare it with the existing inventory. Starting only from the desired structure can hide valuable content and dependencies that do not fit the first design concept.

Should old articles be deleted because they look dated?

Read them and assess their accuracy and purpose. Some need a substantive update, others remain useful, and some can be retired. Appearance and age alone are weak deletion criteria.

Who signs off the final inventory?

The relevant business owners approve content decisions, while the technical and search teams confirm implementation requirements. Keep those approvals visible so migration choices remain accountable.