CMS migrations are where good rankings go to die, and the reason is almost never the new platform. It is that migrations are run as engineering projects with an SEO checklist bolted on near the end, when the decisions that matter were made in week one.
If you are moving from a hand-built site to WordPress, from WordPress to a headless setup, from Magento to Shopify, or from anything to anything, the order below is roughly the order in which things break.
1. The URL inventory, before anything else
Export every URL that currently exists and gets traffic or links. Not the sitemap — the sitemap is what you think exists. Use three sources and merge them: Search Console's page export for the last sixteen months, a full crawl of the live site, and your server access logs for the last ninety days.
The logs catch what the other two miss: old URLs with no internal links that still receive Googlebot visits and still carry backlinks. Those are exactly the URLs that get forgotten and 404 after launch.
2. The redirect map, written before the new site is built
One row per old URL, one target per row, 301 status. Not a catch-all rule to the homepage — a catch-all is functionally the same as deleting the page, because the redirect is treated as a soft 404 when the destination has no relationship to the source.
Where a page genuinely has no equivalent, redirect it to the closest category page, and accept that you will lose some of its value. Where several old pages consolidate into one new page, that is fine, but check you are not quietly merging two pages that ranked for different terms — you will keep one ranking and lose the other.
Test the map on staging. Every row. A spreadsheet of three hundred redirects typically contains ten to fifteen typos, and each typo is a dead page on launch day.
3. Template-level on-page elements
New CMS, new templates, new defaults. The usual casualties:
- Title tags regenerated from a template pattern, overwriting hand-written ones
- Meta descriptions dropped entirely, because the new theme does not output them
- H1 duplicated or moved into the site logo
- Canonical tags pointing at the parameterised version, or self-referencing the staging domain
- Schema blocks lost, because they lived in the old theme's footer
Audit these on a sample of ten pages per template on staging, then re-audit on production within an hour of launch. Production almost always differs from staging in at least one of them.
4. The staging-site leak, in both directions
Two failure modes, opposite causes, same root. Either staging was indexable and Google has now indexed a duplicate of your whole site, or the noindex and Disallow: / that protected staging shipped to production and your live site is now blocked.
The second one is more common and far more expensive. Check robots.txt and the X-Robots-Tag header on production, by hand, on launch day. This takes two minutes and is the single highest-value check in the entire migration. It belongs on the same ten-minute monthly audit you should be running anyway.
5. Internal linking, which never survives intact
Navigation changes, footer changes, and every in-content link written as an absolute URL now points to a 301 at best. Crawl the new site and look specifically for internal links that redirect. They work for users and they waste crawl equity, and in a large site there will be thousands of them.
6. Images, which are quietly half your traffic in some verticals
New media library, new paths, new filenames. If image URLs change without redirects, image search rankings reset from zero. Keep the filenames if at all possible, and redirect them if not.
7. Analytics and Search Console, before you need the data
Confirm the tracking code fires on the new templates, confirm the Search Console property still verifies after any DNS or header change, and submit the new sitemap on day one. You will want clean before-and-after data when somebody asks whether the migration hurt, and the only way to have it is to have it already.
What to expect afterwards
Even a well-run migration dips. Google needs to recrawl, re-evaluate and re-consolidate, and on a site of a few thousand URLs that takes two to six weeks. A dip of ten to twenty percent for a fortnight is normal. A dip of sixty percent is a broken redirect map or a shipped noindex, and you should go looking for it rather than waiting for recovery.
Set a calendar reminder for day 30 and day 60 to compare Search Console's indexed-page count and impression volume against the pre-launch baseline. Most migration damage is recoverable if you catch it inside a month, and much harder after a quarter.
If a migration is already booked and nobody has produced the URL inventory or the redirect map yet, that is the point at which an SEO consultant in India is worth a few days of budget — the work is cheap before launch and expensive after it.