Why it matters
A migration is the one project that can undo years of organic growth in a week. URLs change, redirects get missed, templates lose content, and the staging site's noindex goes live with the launch. Each of those problems is easy to prevent and slow to recover from once search engines have recrawled the site.
Migrations are also an opportunity. Moving to a new CMS or a new rendering setup is the best moment to consolidate weak pages, fix the URL structure and improve performance, because the site is being rebuilt anyway. A well-run migration often ends with a smaller, faster site that performs better than the one it replaced.
Search engines handle moves well when the signals are clear. Google's guidance for site moves comes down to a few things done thoroughly: permanent redirects from every old URL to its closest new equivalent, updated internal links and sitemaps, and patience while the new URLs are recrawled. Most migration losses come from skipping one of those steps for part of the site.
How I approach it
Inventory everything and set a baseline
I combine a full crawl, the XML sitemaps, Search Console, analytics, backlink data and server logs into one URL inventory. Traffic, rankings, indexation and Core Web Vitals are recorded per template so there is something to compare against after launch.
Decide what to keep, merge or drop
Every URL gets a decision. Pages with traffic or links move or merge into a close equivalent. Pages with neither can be retired. This is where a migration becomes a clean-up.
Map redirects one to one
Each old URL with value gets a permanent redirect to its closest new page: no chains, no loops, and no blanket redirects to the homepage. Images, feeds and old sitemaps go into the map too.
Check rendering on staging
For JavaScript sites and headless CMS builds, I check that main content, links and structured data are in the HTML the server returns. Server-side rendering or pre-rendering solves most problems here.
Run a pre-launch checklist
Robots.txt, noindex tags, canonicals, hreflang, structured data, analytics, the redirect file and the 404 page are all checked on staging, then again on production within the first hour.
Monitor closely after launch
A daily crawl of the old URL list, the Page indexing report in Search Console, 404s and server logs. Most issues show up in the first days, while they are still easy to fix.
Clean up and compare
Update internal links to point straight at new URLs, remove any chains that appeared, and compare traffic and indexation per template against the baseline.
What good looks like
There is a complete inventory of old URLs, with traffic and link data.
Every old URL with traffic or links has a permanent redirect to its closest equivalent.
No redirect chains, loops or blanket redirects to the homepage.
Staging is protected by authentication, and launch removes every noindex and disallow rule meant for staging.
Titles, headings, main content and structured data carry over to the new templates.
Main content is present in the server-rendered HTML.
Core Web Vitals on the new templates are equal to or better than the baseline.
A monitoring routine is in place for at least the first months.
Common mistakes
Launching with staging rules still in place
A leftover noindex tag or robots.txt disallow can remove a site from search within days.
Redirecting everything to the homepage
Search engines tend to treat mass redirects to an unrelated page as soft 404s, so the old pages’ value is lost.
Changing everything at once without tracking it
New URLs, design, content and platform in one release make it impossible to see what caused a drop. If they have to ship together, track each change separately.
Forgetting images, feeds and files
Image URLs rank in image search and get linked from other sites. They need redirects or need to keep their paths.
Stopping monitoring after a week
Large sites are recrawled over weeks or months. Problems with deep pages can take that long to appear.
In practice
At FLOYT Mobility I drove the migration from WordPress to Contentful across two international brands, consolidating legacy pages into a leaner, higher-quality landing page structure and improving Core Web Vitals on both. At Oi I led the technical migration of a React site to pre-rendering and server-side rendering, which solved the JavaScript rendering problems that were blocking organic indexation.
This site is going through the same process: it is moving from WordPress to a static build, keeping its existing URLs and redirecting the ones that change. For the redirect basics, see how to create 301 redirects with .htaccess. The full role history is on the About page.
Frequently asked
How long does it take for traffic to recover after a migration?
For a well-run move, many pages settle within a few weeks, while very large sites can take months to be fully recrawled. Temporary movement in rankings is normal. A steady decline after the first weeks usually points to a missed redirect or template problem.
Should I change URLs during a migration?
Only when the new structure is clearly better. Keeping URLs removes the biggest risk in a migration. When they must change, the redirect map is the most important document in the project.
Is a headless CMS good for SEO?
It can be very good, because it separates content from presentation and allows fast front ends. The risk is rendering: if pages are built in the browser, search engines and AI crawlers may not see the content. Server-side rendering or static generation removes that risk.
What about dynamic rendering?
Google describes dynamic rendering, serving pre-rendered HTML only to bots, as a workaround rather than a long-term solution. Server-side rendering, static generation or hydration are the better options for new builds.
