Rebuilding your site without losing rankings: the method behind an SEO migration

Migrations that crash traffic rarely fail for mysterious reasons. They fail because of missing redirects, content lost along the way, a noindex left over from staging or canonicals still pointing to the old addresses. These are predictable mistakes, and therefore avoidable with a method. This is mine, split into the phases where I apply it.

Phase 1: inventory

The list of existing URLs is the foundation, and it does not come from a single source.

• Full crawl of the current site, with status, canonical, title, description, H1, internal links.
• Existing XML sitemaps.
• Search Console: pages with impressions and clicks over the last 12-16 months, including those the crawl no longer finds.
• Server or CDN logs: URLs requested by Googlebot and users.
• Backlinks: URLs receiving external links, including misspelt ones.

Combining them gives the list of URLs that matter, sorted by traffic, conversions and links. Baseline metrics are saved too: clicks, average positions by page group, Core Web Vitals.

Phase 2: decisions and the redirect map

Each URL gets an explicit decision: keep, move, merge, remove. Then the redirect map, one to one:

• every URL that changes leads with a 301 to the equivalent content;
• no mass redirects to the home page: Google treats them as soft 404s;
• no chains: an old URL reaches its destination in a single hop, even if there were earlier redirects in between;
• rules for patterns (parameters, capitals, trailing slashes, old pagination structures) as well as individual URLs;
• URLs removed with no equivalent: 404 or 410, not 200.

The map is written in a format that can be tested automatically: a file with source and expected destination.

Phase 3: parity in the new site

The new site must keep the signals that made the old one rank, at least for important pages:

• equivalent content, not summaries trimmed to fit the design;
• titles, descriptions, H1 and H2 structure;
• internal links to key pages, with similar or better click depth;
• structured data;
• consistent hreflang if the site is multilingual;
• important images at the same URLs or redirected.

One principle: if a page brings traffic, the design adapts to the content, not the other way round.

Phase 4: staging and testing

• A password-protected staging environment, not just noindex: it is safer and leaves nothing to remove.
• A crawl of staging compared with the current site: missing pages, empty titles, wrong canonicals, broken links.
• Automated testing of the redirect map: every source must return a 301 to the expected destination in one hop.
• Lab performance and Core Web Vitals on the main templates.

Phase 5: launch

On launch day, in order:

1. DNS switch or deploy at a low-traffic time;
2. check robots.txt and that no noindex was inherited from staging;
3. test the redirect map against production;
4. canonicals and sitemaps updated with the new URLs, sitemap submitted in Search Console;
5. spot checks of the most important pages.

Phase 6: monitoring

In the following weeks: index coverage and soft 404s in Search Console, logs for 404s on URLs with traffic or links, clicks and positions by page group compared with the baseline, real-user Core Web Vitals. Fixes are made straight away: a missing redirect discovered two months later has already done its damage.

The most expensive mistakes

• noindex or robots.txt blocks inherited from staging: the new site vanishes from the index within days.
• Mass redirects to the home page: Google treats them as soft 404s and the value of the old pages is lost.
• Redirect chains: every extra hop dilutes signals and slows crawling.
• Content cut to fit the design: pages that brought traffic lose exactly what they ranked for.
• Canonicals still pointing to old URLs or, worse, to the staging domain.
• Domain change and rebuild together, without the change of address tool.
• No monitoring after launch: errors are discovered when the drop is already established.

Almost all of them are caught with a crawl of staging compared against the current site and an automated test of the redirect map. These checks take hours, against damage measured in months.

My take

The migration is the part of a rebuild that matters more than the design, and I treat it as code: the redirect map lives in the repository with the site, is tested automatically and is part of the deploy. With Nuxt and Netlify this is particularly convenient: redirect rules live in the project configuration and every preview lets you check them before publishing. On this very site, when the articles section was renamed and some content was merged, every old address was mapped to the closest content.

If you are considering moving from WordPress to a static architecture, the SEO migration is the part to design first: I cover it in From WordPress to Nuxt, GitHub and Netlify.

And I always advise against launching during a peak period for the business: a migration deserves a few quiet weeks of observation.

Why work with me

I have been programming since 1999, delivered more than 300 projects and work as an external developer with about 30 agencies, from Rome and remotely. I run migrations with a multi-source inventory, automatically tested redirects and post-launch monitoring.

If you are about to rebuild your site, get in touch before touching the URLs: in a call of about 20 minutes we work out what needs protecting. The service is in Speed and SEO.