Website Content Migration: How to Move Content Without Losing It During a Redesign

In most website redesigns, everyone talks about the design. Yet the real value of a site sits in the text, images and documents it has collected over the years. If you start website content migration without a plan, the new site launches with missing pages, broken tables and lost PDFs. In this guide I share the method I have used on redesign projects since 2012, from the first inventory to the final check.

What is website content migration and why is it a separate workstream?

Website content migration is the process of inventorying the text, images, documents and page data of an old site, deciding to keep, merge, rewrite or delete each item, and moving the result into the content model of the new site. Therefore, it needs its own owner, plan and timeline.

Most proposals treat it as a single line called "content entry". In practice, however, it quietly eats a large share of the redesign budget. Old sites hide forgotten campaign pages, product descriptions that each editor formatted differently, and documents nobody has opened in years. As a result, copying all of that blindly simply moves the old mess into a new design.

This article does not cover the technical SEO side in depth, such as redirect maps or Search Console monitoring. For that, read my guide on protecting SEO during a website redesign. Databases, user accounts and order records are also a separate topic. Instead, the focus here is editorial content itself.

How is content migration different from an SEO migration?

The two terms often get mixed up, so I start every project by separating them. An SEO migration makes sure search engines understand your site at its new addresses. It covers URLs, redirects, canonical tags, sitemaps and indexing. Content migration, on the other hand, answers a different question: what are we moving, in what form, and where?

For example, on a 400 page corporate site the SEO team needs a new target for every old URL. To produce those targets, you first have to make the content decisions. You cannot write a redirect target without knowing which page survives. In other words, content migration produces the input for the SEO migration. I collected the technical steps in my website migration SEO checklist.

In short, the content team decides and the SEO team secures those decisions at URL level. In practice, one person can do both jobs. Still, they should produce two separate deliverables.

Which roles should you define before the migration starts?

The most common problem I see is not technical. Specifically, it is missing ownership. Everyone assumes someone else is checking the pages, so in the end nobody does. Therefore, I recommend writing down the roles by name in the very first meeting.

• Content owner: The person who makes keep or delete decisions for a section, usually a department head.
• Migration lead: The person who runs the inventory, the mapping sheet and the timeline.
• Editor: The person who rewrites and merges content.
• Developer: The person who builds the new content model and writes the import scripts.
• Approver: The person with the final word on legal, brand or technical accuracy.

In a small business, three of these roles may sit with one person. Above all, every row should carry an owner's name. That way nobody argues later about who made a decision.

How do you build a website content migration inventory?

An inventory is a single sheet that lists every piece of content on the site. I combine three sources: the site's own XML sitemap, a crawl from a crawler tool and the content list inside the CMS. If you rely on one source, you will also miss something. The sitemap cannot see drafts, and a crawler cannot see orphan pages without internal links.

Next, add analytics and Search Console data. For example, pages that earn traffic but sit outside the menu often show up only there. My Google Search Console guide explains how to export page reports.

Count these content types separately while you build the inventory:

1. Company pages: about, team, contact, careers.
2. Service and product pages.
3. Blog posts, news and announcements.
4. Downloadable documents: PDF catalogues, data sheets, price lists.
5. Media library: images, videos, logos.
6. Page components: FAQs, testimonial blocks, reviews.
7. Legal pages: privacy policy, cookie policy, terms.

Also, the last two groups are the ones teams forget most often. In particular, never move a legal page before your legal team confirms the current version.

Which columns should your content inventory include?

The simpler the sheet, the longer it stays useful. Even so, each row must hold enough data to make a decision. My core columns are old URL, page title, content type, section, owner, last updated date, word count, organic clicks over the last twelve months, internal links pointing in, conversion contribution and decision.

You can pull word counts from a crawl export instead of counting by hand. For single pages, however, a word counter speeds things up. For conversion contribution, check page level goal reports in your analytics. Knowing which page sends form submissions often decides whether a page lives or goes.

Also add a free text column called "notes". That is where you record that a product page appears in a dealer contract, or that a PDF opens from a QR code in a printed brochure. If those dependencies stay invisible, deletion decisions come back to bite you from unexpected places.

What should you keep, merge, rewrite or delete?

Next, once the inventory is ready, every row gets a decision label. I use four labels, and the table below shows when I choose each one.

Do not decide on traffic alone. A technical page with few visits may be the page your sales team sends with every quote. It looks minor in the traffic report, yet it plays a key role in closing deals.

Also, avoid making these calls alone. Hold a short review with each content owner and discuss only the disputed rows. Then approve the clear ones straight from the list. As a result, a sheet with hundreds of rows gets settled in a few hours, and no team discovers a deleted page by surprise.

Is it always right to delete low traffic pages?

No. Content pruning became fashionable, and I have seen projects delete half a site in one go. Google's guide on creating helpful, reliable, people first content rewards original and trustworthy content. Still, that does not mean every rarely read page hurts you.

Before deleting, ask three questions. First, does another channel use this page, such as an email template or printed material? Second, do other websites link to it? Third, does the topic belong to an area you plan to grow later?

If all three answers are no, you can delete it. However, if any answer is yes, consider merging or rewriting instead. That way you cut archive bloat without throwing away value you already built. For a wider view on keeping content current, see my article on content freshness and update strategy.

How do you create a content mapping sheet for website content migration?

The mapping sheet is the inventory with decisions applied. It shows where each old item lands on the new site, which template it uses and how its content splits into fields. Put simply, the inventory answers "what do we have?" and the mapping sheet answers "what happens to it?"

I add these columns: new URL, new template, target content type, field mapping, migration method (scripted or manual), status and reviewer. Also, to keep new URLs consistent, a slug generator helps.

With merged pages, several old rows point to one new row. If the sheet does not show that link clearly, the redirect phase turns into a debate. Google's documentation on site moves with URL changes also lists preparing a mapping of old to new URLs as a core step. That said, I will not go into redirect types here.

How do you fit old content into a new content model?

Most new sites also no longer use one big text box. Instead, they rely on separate fields: title, summary, hero image, specification table, FAQ block and related products. On the old site, however, all of this often sits mixed inside a single HTML body.

For that reason, lock the content model before the migration starts. Then write a field mapping for each old content type. For example, the first paragraph of an old product page goes into the new "summary" field. The bullet list goes into "features", and the table at the bottom goes into "technical data".

Without field mapping, editors rebuild every page from scratch. As a result, two pages of the same type end up looking different, and the consistency of your design system breaks on day one. Field based content also makes structured data easier, which I cover in my article on schema markup.

Should you migrate content with scripts or by hand?

Use both. Copying hundreds of similar blog posts by hand is slow and error prone. An editor also loses focus after a few hours. On the other hand, handing your few critical pages to a script is risky. That includes the homepage, service pages and landing pages that drive leads.

My practice looks like this. A developer writes an import script for content that shares a template and carries the "keep" label. The script first runs on a small sample. Then an editor checks the output. Once the issues are fixed, the developer imports the full group. Content labelled "rewrite" or "merge" always goes in by hand.

One warning from field experience, not a guarantee: the first scripted run almost always reveals a formatting problem. So plan at least one correction round, and never treat the script as a one shot job.

How do you clean up formatting and code clutter?

Text from older CMSs comes with hidden baggage. You get inline styles, formatting pasted from Word, shortcodes from an old theme, empty paragraphs and nested tags that do nothing. On the new design these show up as odd fonts, broken spacing and failing components.

• Strip inline styles and font tags, and let the new design system handle formatting.
• List every old shortcode and define its replacement.
• Fix the heading hierarchy and turn bold paragraphs into real headings.
• Check tables and simplify wide ones that break on mobile.
• Confirm that embedded videos and maps still work.

You can build most of this cleanup into the script. Still, a human should make the final call. Automated cleanup in particular can scramble column order or merged cells in tables.

How do you move images and media files without losses?

The media library is usually the messiest part of any migration. I regularly find five sizes of the same image, uploads no page uses and photos named "IMG_4432". First, separate used files from unused ones. Then move only files that appear in at least one piece of content.

Check three things for each image: file size, file name and alt text. Shrink oversized files before they slow down the new site. For one off jobs, an image resizer does the work. Also, replace meaningless file names with descriptive ones.

For alt text I rely on two sources. The W3C images tutorial explains which images need a description and which count as decorative. Google's image SEO best practices note that descriptive file names and alt text help Google understand images. A migration is a good moment to fill in missing alt text.

How should you handle PDFs, catalogues and downloads?

Downloads rarely show up in an inventory, because they are files rather than pages. Yet in manufacturing, healthcare and legal services, PDF catalogues are often the most requested content. Their URLs live on in customer inboxes, dealer presentations and printed material for years.

So open a separate tab for documents. For each file, note the old URL, document version, owning department, whether it is still valid and the new URL. Upload the current version instead of the old one, but make sure the old address still leads to the new file.

Also consider a landing page for each key document. A bare link to a PDF gives neither users nor search engines any context. A short page with a description, the scope of the document and a download button works better. It also gives your sales team a cleaner link to share.

Why do internal and embedded links break during a migration?

Links inside body text are the quietest casualties of a migration. Hundreds of internal links still use the old URL structure. Thanks to redirects they seem to work. However, every click now passes through an extra hop, and over time redirect chains build up.

That is why I update body links to the new URLs during the import, using the mapping sheet. Adding this step to the script is usually easy, since the mapping already exists. Links to merged or deleted pages need an editor's eye, though. Sometimes removing the link is the better choice.

After launch, test sample pages with a redirect checker to catch chains. If you want to rethink the whole link architecture, my guide to internal linking strategy is a good place to start.

Should you migrate meta titles, descriptions and structured data?

Yes, but with checks. Meta titles and descriptions that editors wrote by hand over the years often earn clicks. Do not let the new CMS overwrite them with an automatic template. Instead, add "meta title" and "meta description" columns to the mapping sheet.

That said, copying every field blindly is also a mistake. Merged pages need a new title. Rewritten pages need a description that matches the new copy. A Google SERP preview tool helps you check length and appearance.

The same logic applies to structured data. If the old site had hand coded FAQ or product markup, confirm that the new templates generate it. Otherwise you can lose rich results without anyone noticing.

How do you plan a website content migration timeline?

Build the timeline from dependencies, not dates. You cannot decide before the inventory ends. The mapping sheet stays incomplete until the decisions are made. Likewise, scripts cannot run until the content model is final. Making this chain visible shows the team which task blocks which.

1. Inventory and data collection.
2. Decision labels and owner sign off.
3. Content model and field mapping.
4. Rewriting and merging.
5. Test import and correction round.
6. Content freeze and final import.
7. Quality checks and launch.

Run the rewriting step in parallel with design. Then the designer works with real copy, and the editor sees early how much text each template can hold. For instance, a summary that does not fit a service card surfaces during design rather than a week before launch.

How do you manage a content freeze?

A content freeze is the period when you stop publishing new content or editing existing pages on the old site. Without a freeze, the inventory goes stale, and some updates vanish on launch day.

On the other hand, a long freeze leaves the marketing team silent for weeks. So keep it as short as you can and write an exception rule. Urgent announcements and legal updates, for example, can still go live. The team then applies the same change on the new site that day and notes it in the inventory.

In practice, I run the freeze in two stages. During stage one, only new pages stop and small fixes stay allowed. In stage two, right before the final import, all changes stop. As a result, the final import matches the old site exactly.

How do you handle multilingual sites during content migration?

On a multilingual site, the inventory is not one sheet. It is one sheet per language. Does the English page have a German version? Is the French copy current? Which pages were never translated? If you start deciding before answering these questions, a page deleted in one language leaves its twin stranded in another.

Add a "language group" column and link all versions of the same content with one ID. Decide at group level, then track status per language. Also tie the translation team's schedule to the main timeline. Otherwise you will find empty templates in some languages on launch day.

How you signal language versions to search engines is a separate technical topic. I cover it in my multilingual website SEO guide.

How do you check the quality of migrated content?

Quality control goes far beyond "does the page load?" I check in three layers: count matching, sample review and critical page review.

For count matching, compare the number of "keep" and "rewrite" rows in the mapping sheet with the number of published items on the new site. If the numbers differ, hold the launch until you find what is missing. For sample review, open random pages from each content type. Then check titles, images, tables, links and meta fields.

Critical page review means checking every top traffic and top conversion page by hand. You pull that list from the traffic and conversion columns of the inventory. Log every issue in the status column of the mapping sheet. Then everyone sees in one place which issues are still open.

What should you monitor in the first weeks after launch?

Launch is not the end of the migration. Rather, it is the start of the validation phase. In the first weeks I watch three signals: not found errors, changes in search visibility and form conversions.

Not found errors reveal content that slipped through the mapping sheet. Visibility changes show whether merged and rewritten pages had the effect you expected. Form conversions measure how content decisions affected business results. For the full technical monitoring list, go back to the migration checklist.

Keep a backup of the old site and the mapping sheet after launch too. Months later, a customer may ask for an old catalogue. Someone may also ask why a page disappeared. You will find the answer in those two sources.

What are the most common content migration mistakes?

Over the years I have seen the same mistakes repeat on projects of every size. All of them are preventable during planning.

• Building the inventory from the sitemap alone and missing orphan pages.
• Changing the content model after the import has started.
• Leaving everything to a script and never checking key pages by hand.
• Skipping a separate inventory for PDFs and media.
• Leaving old internal links in body text.
• Requesting rewritten copy a few days before launch.
• Running no content freeze at all, or dragging it out for weeks.

Most of these items call for discipline rather than technical skill. That is why I treat content migration as a sub project with its own owner and timeline, not as a side task.

Should an agency handle website content migration or your own team?

The answer depends on content volume and on who holds the knowledge. Your team knows the products and services best, so handing off every keep or delete decision is a mistake. However, inventory work, scripted imports and quality control are repeatable tasks that reward experience.

The model I recommend is simple: you make the decisions, and an experienced team runs the process and the technical import. If you want to plan content migration alongside a new design, see my web design service. For protecting search visibility, see SEO consulting.

Whichever model you choose, do not skip the inventory, decision labels, mapping sheet and quality checks. Together, these four outputs are the lasting answer to "where did that content go?"