CMS content migration QA checklist for website redesigns

A website redesign can fail quietly during content migration. The new design might look correct, the CMS might be editable, and the launch checklist might look complete, but traffic and conversions still suffer if titles are shortened, old PDFs disappear, product copy lands in the wrong field, or localized pages lose their matching references.

This checklist is for teams moving content during a website redesign, WordPress theme rebuild, Shopify content cleanup, headless CMS migration, multilingual launch, or technical SEO migration. Use it after the new CMS model is close to final and before the full content move is treated as production-ready.

Start with a source inventory that becomes the temporary truth for the migration. Export every live URL, title, template, status, canonical URL, language, owner, traffic level, conversion role, and last updated date. If the site has staging pages, campaign pages, PDFs, gated assets, or landing pages outside the main navigation, include them too.

The inventory should separate content that will be migrated, merged, rewritten, redirected, archived, or rebuilt as a new template. Without this decision column, teams keep rediscovering the same pages during launch week.

• Crawl the live site and compare it with CMS exports, analytics landing pages, XML sitemaps, and paid landing page lists.
• Mark revenue-critical, SEO-critical, legal, support, campaign, and legacy pages.
• Assign one content owner and one technical owner for every page type, not just every department.
• Create a frozen inventory version before bulk migration starts, then log every approved change after that point.

A CMS migration is not a copy-and-paste task. The old page might have one body field while the new template has hero copy, intro copy, comparison rows, FAQs, related services, schema inputs, and reusable call-to-action modules. QA needs a field map that explains where each old value should land.

For each page type, document required fields, optional fields, fallback behavior, allowed formats, character limits, image ratios, owner notes, and fields that should not be migrated. This prevents content from being squeezed into the closest available field just because the importer needs a value.

• Create field maps for homepage, service pages, case studies, blog posts, products, collections, landing pages, and legal pages.
• Confirm which fields are plain text, rich text, markdown, references, numbers, dates, booleans, files, or select options.
• Test long titles, empty optional fields, translated copy, special characters, and reusable modules.
• Keep a visible exception list for pages that need manual editing after import.

Metadata often gets lost because it is not visible in the design review. Treat title tags, meta descriptions, canonical URLs, robots settings, Open Graph fields, structured data inputs, image alt text, breadcrumbs, and publish dates as migration content. They need the same ownership and QA as visible body copy.

Do not let the new system auto-generate everything unless that is an intentional decision. Auto-generated metadata can be useful for low-risk pages, but key service pages, product pages, collection pages, case studies, and articles should be reviewed manually before launch.

• Compare old and new title tags for every SEO-critical page before launch.
• Check meta descriptions for truncation, duplication, missing value props, and wrong language.
• Confirm canonical URLs and noindex rules are not inherited from staging or draft content.
• Verify image alt text, Open Graph images, breadcrumbs, and schema fields after import.

URL QA should be connected to content QA. When content is merged, renamed, localized, or moved into a new CMS collection, internal links and redirects can break even if the page itself imported correctly. Review URL decisions beside the content inventory so the reason for each redirect is visible.

Use the redirect map as a working QA document, not a file that appears at the end of the project. Every removed or changed URL should have a destination, status, owner, and test result. Internal links should point directly to the new destination instead of relying on redirects wherever possible.

• Test old URL to new URL redirects for a representative set of high-traffic and long-tail pages.
• Replace internal links that still point to staging, temporary slugs, old domains, or redirected URLs.
• Check navigation, footer links, breadcrumbs, related posts, related services, XML sitemaps, and hreflang alternates.
• Confirm canonical tags use the final production URL format, including trailing slash and locale rules.

Images and files are easy to overlook because the page may still look roughly correct. QA should confirm that image crops, responsive sources, file names, alt text, captions, compression, licensing, and file destinations survive the move. Broken PDFs, oversized hero images, and missing case study assets can hurt both trust and performance.

Embedded content needs separate checks. Forms, videos, calendars, maps, calculators, comparison tables, product feeds, and third-party widgets often depend on scripts or IDs that do not migrate cleanly between CMS platforms.

• Check at least 20 high-value pages on mobile and desktop for image cropping and missing assets.
• Open migrated PDFs, downloads, gated assets, and media links from the live page, not only from the CMS.
• Confirm lazy loading, image dimensions, compression, and responsive variants after deployment.
• Test embeds with consent banners, ad blockers, strict privacy settings, and slow network conditions.

Reusable modules make a CMS easier to maintain, but they also multiply migration mistakes. A single wrong testimonial, pricing note, service card, product badge, or compliance statement can appear across dozens of pages. QA should include both the source module and every important page where it appears.

Also watch for page-level exceptions. Legacy pages often contain special disclaimers, hand-built tables, campaign copy, custom CTAs, or region-specific notes that are not obvious in a bulk export. These need manual review before the final import is approved.

• List reusable modules and confirm their owner, purpose, source content, and pages where they appear.
• Check modules in context on service pages, case studies, blog posts, product pages, and landing pages.
• Document exceptions that need manual migration, rewriting, or development support.
• Avoid creating one-off CMS fields unless the exception is business-critical and likely to recur.

Multilingual migration adds another layer of risk. The English page may be ready while the Chinese, German, or regional variant still has old screenshots, missing metadata, mismatched internal links, or a different conversion path. QA should compare page pairs, not just language folders.

For each translated page, confirm the locale, slug, title, meta description, hreflang reference, canonical URL, navigation label, form language, currency, legal copy, and owner. If a page is intentionally not translated, document the fallback behavior and redirect decision.

• Match every migrated page to its translated or regional equivalent where one exists.
• Check translated metadata, image alt text, button labels, forms, thank-you states, and downloadable assets.
• Verify hreflang and canonical rules after the content is published, not only in the CMS preview.
• Keep a list of pages that will launch in one language first so stakeholders do not mistake them for migration bugs.

Do not wait for the full migration to discover that the CMS model is missing a field. Move a sample set first: one homepage or hub page, two service pages, two case studies, five blog posts, five product or collection pages where relevant, one legal page, one low-traffic archive page, and at least one translated page.

Review that sample in the CMS, on staging, in search previews, and in a crawl. The sample should expose field mapping problems, page speed issues, missing media, broken internal links, editor confusion, and manual work that needs to be budgeted before the real migration starts.

• Sample at least 20 to 30 pages or 10% of the site, whichever gives better coverage.
• Include easy pages, high-value pages, long pages, legacy pages, and pages with unusual modules.
• Have content, SEO, design, development, and operations reviewers sign off on the same sample set.
• Update the field map and migration process before importing the remaining content.