How to handle old website content before a redesign launch depends on whether it still has a place in the new site. A reliable approach is to first export old content into a list, evaluate each item as keep, merge, rewrite, or retire, and then decide which information goes into the new site. Below we explain this in three stages: inventory, triage criteria, and pre-launch checks.
First, take stock of what content the old website actually has
Don't decide based on impressions. Before the redesign, export a content list from the old site that includes at least: page title, page URL, section, content type, last updated date, and whether the page contains forms, contact details, downloadable files, or product specifications. You can export via the CMS section list or content list, or use a sitemap or crawling tool, but the exported results should be manually reviewed to avoid missing pages that aren't in the navigation.
During the inventory, group content into categories: product and service descriptions, company information (profile, qualifications, contact details), news or articles, case studies or project showcases, help and FAQs, careers, and special topic or event pages. After categorizing, evaluate each category separately—it's easier to spot duplicates and gaps than looking at everything together.
What information is suitable for the new site
You can base your judgment on three questions: Is this content still accurate? Does the new site structure have a corresponding place for it? Will users actively look for it on the new site? If all three are true, prioritize keeping and migrating it.
Common types worth keeping:
- Product and service descriptions that are still offered—specifications, scope of application, and service processes need to be re-verified.
- Basic company information, including profile, contact details, address, and qualifications. When migrating, confirm each item to avoid bringing outdated phone numbers or addresses into the new site.
- Long-term help content, such as FAQs, usage instructions, and after-sales processes. These are not time-sensitive, have low migration cost, and help complete the new site's sections.
- Case studies or project introductions with ongoing reference value. For those involving client names, image permissions, or collaboration details, confirm whether they can still be made public before migrating.
Types that need careful handling: event pages with specific years, expired promotion pages, outdated price quotes, temporary notices, and pages with very little content that occupy a section slot. If these are moved directly into the new site, they can make it look like the site hasn't been maintained for a long time.
How to decide between keep, merge, rewrite, and retire
After the inventory, give each old content item a clear disposition—don't leave anything ambiguous.
| Action | When it applies | What to watch for during migration |
|---|---|---|
| Keep | Content is still accurate and the new site has a corresponding section | Verify contact details, pricing statements, images, and attachments in the body |
| Merge | Multiple pieces cover the same topic from different angles or times | Combine into one complete piece to avoid multiple similar pages on the new site |
| Rewrite | The topic is still needed, but the wording is outdated or the structure is messy | Keep valid information, reorganize according to the new site's sections, and don't copy the old layout directly |
| Retire | Expired, duplicate, no corresponding place, or too little content | Record the old URL and set up redirects or return notices as needed after launch |
The most common problem with merging and retiring is not recording old URLs. We recommend adding a separate column for "old URL" in the list, clearly writing down every page address that is merged or retired, and then checking what happens when those addresses are opened after launch.
How to connect old links and old sections
Once the new site's section structure is finalized, map each old URL to a new URL. For one-to-one matches, set up redirects; for content without a match, redirect to the closest section page or homepage; for services that are truly no longer offered, you can return an explanation page. Organize the redirect mapping into a table before launch, and verify each one after launch—don't just check the homepage and navigation.
Also check at the section level: Does the old site's section still have a similar section on the new site? If an old section is split into two new sections, which one should the old section page redirect to? If an old section is merged, have all its content items been assigned? Making these decisions in advance reduces the chance of receiving feedback like "the link goes to a blank page" after launch.
Run through the pre-launch checklist in order
After content migration is complete, check in the following order—it's easier to spot problems than randomly clicking pages:
- Open the new site navigation and confirm every section has content and no section is empty.
- Spot-check kept and rewritten content, verifying contact details, product specifications, service scope, and images are complete.
- Open each old URL one by one to confirm the redirect target is correct and doesn't lead to an unrelated page.
- Check that forms, downloads, and online consultation entries work and that submissions are received.
- Check pages for leftover old site names, old phone numbers, old addresses, or test text.
- Go through the pages marked as retired in the list separately to confirm they don't appear in navigation or site search.
If your team is short-handed, prioritize checking navigation sections, product/service pages, contact pages, and form pages—these directly affect whether users can find information and get in touch.
Keep a mapping table after launch
A redesign launch is not the end of content handling. Keep the old-to-new URL mapping table, content disposition conclusions, responsible persons, and check dates—they'll be useful for future content maintenance, handling indexing changes, or troubleshooting broken links. The mapping table can be stored in a shared team document; it doesn't need to be public on the website.
In short, the old website content suitable for the new site is content that is still accurate, has a place in the new structure, and that users will look for. Everything else should be merged, rewritten, or retired with URLs recorded. Running through this list before launch is much easier than fixing things afterward.
