What is a content inventory for a website migration?

It is a spreadsheet listing every piece of content on the current site, including documents and pages not in the navigation, with details such as URL, owner, traffic, language and purpose. It becomes the working document for deciding what moves to the new site and in what form.

Should we migrate all our old blog posts to the new website?

Not automatically. Keep posts that still get traffic, earn links, or support a priority service, and update them if needed. Retire posts that are outdated or thin, redirecting each to the most relevant surviving page. Moving everything just carries old clutter into a new structure.

Who should be responsible for website content migration?

One person should own the overall inventory and schedule, usually someone in marketing with the authority to make decisions. Each page then needs its own named owner, typically from the department that relies on it, who writes or approves the content and signs off before launch.

Can content be migrated automatically to a new CMS?

Large volumes of consistent content, such as articles or product records, can often be imported by script. Content that needs editorial judgment, or that has to fit a new template structure, is better moved manually by someone reading it. Most projects use a mix of both.

How to Plan a Website Content Migration Without Losing Key Pages

Content migration is an editorial project, not a copy and paste

There are two halves to moving a website. One is technical: URL mapping, redirects, metadata and protecting search visibility. That half is well covered in the website migration SEO checklist, and the search planning that should start before a redesign is in how to prepare an SEO migration before a website redesign.

The other half is editorial: deciding what content exists, what it is for, what survives, who rewrites it and how it fits the new structure. This article is about that half. It is less technical and more political, because it involves asking departments to let go of pages they are attached to, and asking busy people to write things by a deadline.

Get the editorial half wrong and the technical half cannot save you. A perfect redirect to a page that no longer answers the question is still a lost visitor.

Build an inventory that is actually complete

Start with a crawl of the current site, which gives you every page reachable by following links. Then go looking for what the crawl missed, because that is where key pages hide:

Documents: PDFs, forms, price sheets, brochures and annual reports, often uploaded years ago and linked from emails.
Orphan pages: landing pages from old campaigns, pages linked only from email signatures or printed materials, QR code destinations.
Functional content: form confirmation messages, error pages, automated emails, cookie and privacy notices, terms of service.
Embedded and third-party content: booking widgets, job listings, videos and maps that live elsewhere but appear on your pages.
The other language, if the site is bilingual. Translated versions are sometimes incomplete or structured differently, and they need their own rows.

Analytics and Search Console help here: pages that receive visits but do not appear in the crawl are pages nobody remembers making. Ask the team as well. The person who handles client onboarding knows exactly which forms and guides clients need, and they may not be linked from anywhere obvious.

For each item, record the URL, title, content type, language, owner, last updated date, recent traffic, whether it gets organic search visits, and whether other sites link to it. Then add two columns that most inventories leave out: who relies on this and what task it supports.

Find the key pages that traffic data misses

Most inventories sort by traffic and protect the top of the list. That is a good start and an incomplete one. Some of the most important pages on a site get modest traffic because the people who need them are few and specific.

Ask these questions of each department:

Which pages do you send people to? Sales teams link to particular case studies or service explanations in proposals. Client service links to how-to pages. HR links to benefits or application details.
Which pages do partners, funders or regulators link to? A government directory, an industry association or a funding body may link to a specific page, and that link may be in a printed document you cannot update.
Which pages carry legal or compliance weight? Privacy policies, terms, disclosures, accessibility statements, and in regulated sectors, specific required information.
Which pages convert disproportionately? A low-traffic page that produces a steady trickle of qualified inquiries is worth more than a busy blog post that produces none.

Mark these as key pages in the inventory regardless of traffic. They get the most careful treatment: a named owner, an explicit decision, and a check on launch day.

Decide the fate of every item

Every row in the inventory needs one editorial decision. A useful vocabulary:

Keep: accurate and useful, moves across with light formatting changes.
Revise: the topic matters but the content is outdated, thin or off-message.
Merge: several pages covering overlapping ground become one stronger page.
Split: one page trying to serve several audiences becomes separate pages, each with a clear purpose.
Retire: no longer needed. It gets a redirect to the closest relevant page, not to the home page.
Archive: not needed on the public site, but kept offline for records, legal or reference purposes.

The decision should be made against the new site’s purpose, not the old site’s structure. A page that existed because the old navigation had a slot for it is not automatically needed. If the new site was planned through a proper discovery phase, the audiences and tasks it defined are the test: does this item help a priority audience complete a priority task?

Expect resistance. Departments are attached to their pages, and “we have always had that” is a powerful argument in a meeting. A rule helps: anyone who wants to keep a page must name who will own it and review it. Pages without a willing owner are usually pages nobody needs.

An illustrative example: a hypothetical regional insurance brokerage with a decade-old site finds hundreds of items, including a separate page for every product in every town it serves and a news archive going back years. The decisions: merge the town-by-product pages into product pages with location sections, retire most of the news archive with redirects to relevant products, keep the claims process pages almost unchanged because client service relies on them, and split the single “Business Insurance” page into the three distinct audiences it was trying to serve.

Map content to the new content model

A new site usually has a new structure: content types with defined fields, such as a service page with a summary, process, related case studies and FAQs. Old content rarely fits those fields as written. A long page of prose does not map neatly to a template that expects a summary, three benefits and a process.

So the migration plan needs a mapping step. For each surviving item, record its destination (the new URL and content type) and what work is needed to fit the template. This is where many “keep” decisions quietly become “revise” decisions, and it is better to find that out in the spreadsheet than in the CMS.

Decide early whether content will be moved manually, by script, or a mix. Automated import works for large volumes of consistent content such as articles or product records. Anything that needs editorial judgment should be moved by hand, by someone who reads it on the way.

Owners, deadlines and a content freeze

The most common reason website projects launch late is not development. It is content that nobody was assigned to write. Avoid that with three simple rules.

Every item has a named owner. A person, not a department.
Every revision has a deadline that lands well before the build is finished, leaving time for review, translation and approvals. In a bilingual organization, translation needs its own slot in the schedule, not a hope that it fits.
There is a content freeze on the old site from a set date, with a simple process for urgent changes that records them so they can be applied to the new site too.

Someone also has to own the whole inventory. That person chases deadlines, resolves disputes between departments and decides when a page is good enough to ship. It is often a marketing manager, and it should be part of their job for the duration rather than an extra task on top. If your team is doing the writing, how to write website copy that sells is worth reading before the first draft.

Content QA before launch

Technical QA checks redirects and metadata. Content QA checks that the content arrived intact and makes sense. Go through the inventory row by row on the staging site and check:

Every key page exists at its planned URL and says what it should.
Formatting survived: headings, lists, tables converted properly, no stray code or broken characters.
Images, documents and videos load, with alt text and captions in place.
Internal links point to new URLs rather than relying on redirects.
Forms work end to end, including confirmation messages and notification emails.
Both language versions are complete and linked to each other, where applicable (the bilingual planning guide covers parity in detail).
Contact details, hours, names and prices are current.

Have the people who own the key pages sign off on them. They will spot an outdated detail far faster than a project manager will.

After launch, keep the inventory. It becomes the baseline for the first months of monitoring, described in what to expect after launching a new website, and the starting point for ongoing content ownership. On website projects, we treat the inventory as a deliverable the client owns, because it remains useful long after the site goes live.