SEO Migration Planning for Redesigns, Domain Moves and CMS Changes by Digital Magma

Most migrations fail quietly. The new site looks better, the launch goes well, and three weeks later enquiries are down because hundreds of old URLs now return errors.

SEO migration work stops that. It keeps a record of what ranks today, maps every old address to a new one, and checks that the content, titles and structured data survived the move.

It is cheaper before launch than after. Fixing a redirect plan on staging takes hours; rebuilding lost rankings can take months.

Missing redirects are the classic. Old URLs that ranked now return a 404, and the links pointing to them stop helping.

Content loss is the quiet one. A designer trims a long service page to three lines, and the page drops for every query the old text answered.

Then there are launch-day leftovers: a staging noindex tag left in place, a robots.txt that blocks the whole site, or canonical tags pointing at the staging domain.

JavaScript frameworks add a fourth risk. If key text appears only after scripts run, some crawlers see an almost empty page.

Google’s site-move guide recommends permanent redirects such as 301 or 308 and says to keep them for as long as possible, generally at least a year. We advise keeping them longer when the old URLs still carry links.

Google’s redirects documentation treats a permanent server-side redirect as a strong signal that the target should become the canonical URL.

Each old URL should go to the most relevant new page. Sending everything to the home page looks like a soft 404 to Google and wastes the old page’s value.

Chains slow crawling and lose users. If page A redirects to B and B to C, we point A straight at C.

Staging should be blocked from search by a password or an IP allow-list. A noindex tag on its own is easy to forget at launch.

We crawl staging with JavaScript rendering on and off. If important text appears only with rendering, we raise it with your developers before launch.

We test the redirect map against staging, row by row. Every old URL should return one 301 and land on a 200 page.

Speed is checked on real templates, not the home page alone. Core Web Vitals problems are easier to fix before the code is live.

Expect movement. Google itself says to expect temporary fluctuation during a move. What matters is whether pages settle back near the benchmark.

We report weekly in the first month and monthly after that, with each issue, its fix and the date.

The problem with the first version was rendering. Content loaded only after JavaScript ran, which left crawlers with thin pages.

Moving to Next.js let each page render on the server. Titles, headings, body text and structured data were in the HTML from the first byte.

A move like that one needs every check on this page: a URL plan, parity of content and tags, staging tests, and monitoring after launch.

Our JavaScript SEO page looks at the same project from the rendering side. The full story is in the UK healthcare case study.

Google’s guide suggests timing a move for lower traffic where possible. Launching a retailer’s new site in the week before Diwali is a risk we would flag.

Changing everything at once makes problems hard to trace. If you can, move the domain or the platform first and redesign later.

If your current site has no real search traffic, a full migration plan is more than you need. A basic redirect check will do, and we will tell you so.