Duplicate Content After a CMS Migration: A Recovery Plan

Duplicate content after a CMS migration is almost inevitable. The old CMS structured URLs one way, the new CMS structures them differently, and the redirects between them rarely consolidate cleanly. The result is a transition period — sometimes weeks, sometimes months — where Google sees two versions of every page and rankings suffer. This article is the focused plan for catching and fixing those issues during that window.

The shape of post-migration duplicates

Three common patterns emerge after most migrations. First, the same content existing at two URLs because the redirect logic produced a hop rather than a 301 (status 200 at both URLs). Second, content that was consolidated during migration now appearing as duplicates because the canonical tags from the old site survived. Third, parameter variations that were previously canonical-handled now indexable because the new CMS does not produce canonical tags consistently.

Crawl the old URL list

Pull the URL list from the old site — preferably from the old sitemap if you still have it, otherwise from Search Console's historical data. Crawl every old URL and check the response. A 301 to a single destination is correct. A 200 means the old URL is still live on the new platform, which is a duplicate. A 404 is fine if intentional, a problem if accidental.

Verify canonical tags on every template

Pick five pages from each template type on the new site and verify each has a canonical tag pointing to itself (or to its intended canonical destination). Templates that produce no canonical tags or that produce canonicals pointing to wrong destinations need fixing at the template level, not per page.

Reconcile sitemap against indexed pages

Pull the current sitemap and compare to the indexed-page count in Search Console. If the sitemap has 1000 URLs and Search Console shows 1500 indexed pages, the extra 500 are likely duplicates or unintended URLs that should be excluded. Identify what those URLs are and either canonicalise them away or block them from indexing.

Pagination and faceted navigation

Pagination URLs (?page=2, ?page=3) and faceted navigation URLs (?color=red&size=large) are duplicate-content magnets after migrations. The old site likely had canonical-handling rules for these; the new site might not have inherited them. Specifically check pagination canonicals and decide your faceted navigation policy (canonicalise all variants to the unfiltered URL, or noindex filter URLs).

Variant pages on ecommerce

Migrations from one ecommerce platform to another often change how product variants are represented. The same product available in three colours might now have three URLs instead of one. Audit a sample of product types and confirm variant URLs are canonicalising to the master product.

Cross-domain duplicates

If your migration moved content from one domain to another (subdomain consolidation, separate language sites merging, etc.), check that the old domain is properly redirecting. Same content on two different domains is the most aggressive form of duplicate content and can take longer to resolve.

Schema markup duplicates

Sometimes the same article has schema markup on multiple URLs after migration. Google handles this oddly — the rich result might appear for the wrong URL or stop appearing entirely. Audit the schema URL targets across duplicate-suspect pages and consolidate.

The recovery timeline

Most post-migration duplicate issues resolve within 4-8 weeks of fixing the underlying cause. Google needs to recrawl, reprocess canonicals, and update indexing. Speeding this up means submitting affected URLs for reindexing in Search Console and ensuring the canonical tags are clear and consistent.

How to monitor the recovery

Weekly checks during recovery: indexed page count trend (should converge toward intended value), duplicate-content warnings in Search Console (should decrease), branded search performance (should recover to pre-migration baseline). A flat or worsening trend after week four suggests the fix is incomplete and warrants another investigation pass.

Tooling for migration duplicate detection

A comprehensive site audit that runs continuously catches duplicates as they appear rather than waiting for the next manual audit. During a migration window, the catch-time matters — issues fixed in week one are resolved by week eight; issues caught in week six take until week twelve.

UtilitySEO and similar tools have migration-specific audit modes that surface duplicate-content patterns common to migrations. For high-stakes migrations, running the audit continuously through the recovery window is worth the additional spend — the cost is small relative to the downside of unresolved duplicates dragging on rankings for months.

The recovery plan is mostly about discipline, not novelty. Run the same audit on a weekly cadence, fix what surfaces, and let the index settle. Most migrations recover cleanly with this discipline. Migrations that do not recover usually skipped one of these steps.