SEO Migration

Types of site migration and their SEO risk

„Migration” covers very different changes, from moving to a new server to merging two sites under a new domain, and each needs a different scope of work. Risk grows with the number of URLs that change and with the number of things changed at the same time.

Google's documentation on site moves with URL changes recommends changing one thing at a time, for example the domain first and the layout later. The Change of Address help page adds that combining a move with a redesign of content or URL structure can cause traffic loss, and that several sites should not be consolidated in one step but moved one by one, waiting for traffic to settle in between. If the business needs everything changed at once, I plan longer monitoring and agree up front how we will tell which change caused a drop.

SEO migration timeline – what I do at each stage

Most of the work in a good migration happens before launch, not on switch-over day. On a typical project I start several weeks ahead, and monitoring runs for 90 days, while the redirects and their upkeep stay in place much longer.

The best time to bring me in is while the new structure is being designed, before anyone fixes the URLs. At that point you can still keep old URLs wherever there is no reason to change them, and every URL that stays the same is one less redirect to maintain.

URL inventory – where I get the full list of URLs

A redirect map is only as good as the URL list it was built from, and the list of pages in your CMS is usually just part of it. The most valuable URLs often appear in neither the menu nor the sitemap: old articles with external links, past campaigns, PDF files, parameter URLs from old ads.

Google's site move documentation lists sitemaps, server logs, analytics, the Search Console Links report and the CMS itself as sources, and reminds you to include images, videos, JavaScript and CSS files. I merge these sources into one table:

• A crawl of the current site with JavaScript rendering, including images and files.
• Every sitemap, including old ones nobody remembers and files submitted to Search Console years ago.
• Search Console: URLs with impressions and clicks over the longest period the report offers, the Links report, the Page indexing report.
• GA4: landing pages with traffic from all channels, not only search, because newsletters and ads have their own URLs too.
• A backlink tool (Ahrefs): URLs with external links, including those that already return 404.
• Server logs on large sites: URLs Googlebot still requests.
• A CMS or product database export: the full list of products, categories, posts and their IDs, which makes automatic matching easier.

After merging and de-duplicating, each URL gets its data: organic traffic, referring domains, rankings and conversions. Then I split URLs into tiers. For the tier with traffic or links I check every row of the map by hand; for the long tail, such as thousands of products, I match URLs automatically by ID or SKU and spot-check samples.

The 301 redirect map – the rules I use to assign URLs

Every old URL with value should reach the closest content equivalent through a single permanent redirect, and URLs you deliberately do not move should return 404 or 410. Google's documentation also notes that redirects do not lose PageRank, so the problem is never the redirect itself, only a bad destination.

Google advises against sending many old URLs to one unrelated page, such as the homepage. For chains it recommends as few hops as possible: ideally none, and if that cannot be avoided, about three hops and fewer than five, while Googlebot follows up to ten. Every row in my map has a „decision type” column and a short reason, so months later anyone can see why a URL ended up where it did.

Redirect types and how Google treats them

The table follows Google's redirects documentation (updated April 2026). In practice, the most common bug I find is 302 redirects set by default by a plugin or framework and never switched to permanent.

How I implement redirects and test the map

I implement redirects where they run fastest and most reliably: on the server, at the CDN or in the application router, not in client-side JavaScript. Where exactly depends on the number of rules and on who will maintain them.

• Pattern rules (for example the whole /blog/2019/... directory to /blog/...) go into server or framework config as expressions, because one rule covers thousands of URLs.
• One-to-one maps with many URLs live in a file or database and are looked up in the routing layer, instead of thousands of separate rules that slow down every request.
• In Next.js, short lists go into the redirects config, and large maps are handled in middleware with a dictionary-style lookup. More on this in the Next.js migration service.
• URL normalisation: letter case, trailing slashes, old .html and .php extensions, encoding of non-ASCII characters. I handle these variants with general rules before the detailed map.

I test the map automatically. A script requests every old URL in the map, checks the status code, number of hops, the destination and the destination's own status, and compares the result with what was expected. The test passes only when every row ends in a single 301 or 308 to a page returning 200, and removed URLs return 404 or 410. I run the same test on staging, in production on launch day and then on a schedule throughout monitoring.

Staging tests – what I compare between the old and new site

On staging I compare old and new versions template by template, because post-migration drops rarely come from redirects alone and more often from the new site quietly losing content, links or signals. I run two crawls and match them URL to URL using the map.

Pre-launch checklist

I protect staging with a password rather than only a noindex tag, because a password will not accidentally ship to production with the template. Google's documentation on hosting moves without URL changes reminds you to remove temporary robots.txt blocks and noindex tags left over from the build before switching. Forgetting this is one of the most common reasons a site disappears from results after launch. I cover rendering problems in detail in the article on JavaScript SEO.

Migration launch day – my run sheet

Launch day should be boring: everything that can be tested earlier already has been, and on the day I only check that production behaves like staging. I schedule the launch for a lower-traffic period, which Google also recommends for sites with seasonal traffic.

1. Content freeze in the old CMS during the switch, so no URLs appear that are not in the map.
2. Deploy the new version and the redirects; remove the password, noindex and robots.txt blocks.
3. Run the automated test of the whole redirect map in production and check the most important URLs by hand with URL Inspection.
4. Submit the new sitemap in Search Console. I keep the old sitemap with the previous URLs for monitoring, as Google suggests, and redirect warnings in it are expected at that point.
5. For a domain change: the Change of Address tool for the old domain and every verified variant.
6. Set crawl rate to let Googlebot decide on both properties, and make sure the new server can handle the heavier crawling Google warns about after a move.
7. Full crawl of the new version and comparison with the staging crawl.
8. Update URLs in ad campaigns, business profiles, newsletters and with partners who link to your most-used pages.

For a hosting change with no URL changes, Google advises lowering DNS TTL to a few hours at least a week before the move and keeping the old server running until its logs show no more traffic. I treat that case as a migration too, because a new server's firewall blocking Googlebot can do as much damage as missing redirects.

Post-migration monitoring – what I measure and when I act

After launch, what matters most is catching an error within days, not a month later in a traffic report. Google warns that rankings may fluctuate temporarily during a move, and that a medium-sized site takes a few weeks to move and a large one longer. So I separate normal fluctuation from signs that something is broken.

Google says a move is complete only when Googlebot has visited every old and new URL at least once, and that there is no fixed frequency for those visits. That is why rarely crawled long-tail URLs can take weeks to move. During the 90-day monitoring period I track rankings for the 50 most important queries and report weekly on indexing health, and every new 404 with value goes into the map immediately.

Domain change and rebranding – what the Change of Address tool requires

The Change of Address tool in Search Console only works when moving a domain or subdomain to another domain, and it has conditions you must meet before launch. It is not for switching to HTTPS, moving between www and non-www, or changing paths within the same domain.

• You must own both the old and new properties in Search Console, under the same Google account.
• The old domain's homepage must 301-redirect to the new homepage.
• The request covers every variant of the old domain (www and non-www, subdomains), each of which must be verified even if unused.
• According to Search Console Help, the move notice and signal forwarding last 180 days, and redirects must stay at least that long, longer if Google still sends traffic to them. Google advises keeping the old domain registered for at least a year.
• Moves cannot be chained: after moving A to B, you cannot immediately move B to C.

A rebrand adds a layer few people think about: brand data off the site. I update Organization structured data with a reference to the former name, business profiles, the Google Business Profile, industry directories and social profiles, and ask the biggest linking publishers to update their links, starting with the links that send the most traffic, as Google suggests. I also do this so that AI models connect the old and new names to the same company. How to check whether that works is covered under the AI visibility audit, and entity consistency in structured data under Schema.org implementation.

Online store migrations and moving to Next.js – what is specific

With stores and technology changes, the biggest risk is not page URLs but everything generated automatically: filters, variants, pagination, structured data and rendering. I check these separately from the redirect map.

Changing the store platform

• URL structure imposed by the platform. Some platforms force fixed prefixes in product and collection URLs, so redirects are unavoidable and must be planned for the whole catalogue.
• Product variants: whether colour and size get their own URLs or parameters, and which URL is canonical.
• Filters and sorting: a new platform often generates different filter URLs; I decide which combinations should be indexed and which not, so as not to waste crawl budget.
• Out-of-stock and deleted products: the rules must work from day one, not after the first error report.
• Reviews and Product data: carrying ratings, prices and availability into the new template's structured data.
• Image URLs: changing product image paths means losing image search traffic unless they are redirected.

Moving from WordPress or another CMS to Next.js

When migrating to Next.js I check that metadata, canonicals and hreflang are generated on the server, that the trailing-slash policy is preserved, that non-existent URLs return real 404s and that content has not ended up in components loaded only in the browser. The move is also a chance to improve Core Web Vitals, but only if the new version is measured before launch, not after.

Traffic drop after a migration – how I find the cause and recover rankings

If the migration has already happened and traffic fell, the cause almost always belongs to one of a few groups, and the order of checks matters because the first ones are the most common and the quickest to fix. I rebuild the missing data on old URLs and compare it with what happens today.

1. Rebuild the list of old URLs from archived sitemaps, Search Console (data from the whole available period), backlink tools and copies in web archives.
2. Today's status codes for those URLs: missing redirects, 302s, chains, redirects to the homepage.
3. Indexing blocks: noindex, robots.txt, canonicals pointing to staging or the old domain, X-Robots-Tag headers.
4. Content parity: whether new pages have the same content, headings and titles, and whether the template shortened category and product descriptions.
5. Internal linking: whether the menu and content still route through redirects or to removed URLs.
6. Rendering and performance: whether content is in the server HTML and whether Core Web Vitals got worse after the technology change.

Redirects added late still work, although signals return more slowly than in a migration prepared before launch. If more than a year has passed and traffic has settled at a lower level, instead of rescuing the migration I run a full technical SEO audit, because the causes may now lie elsewhere. Drops caused by lost external links to removed URLs I also make up for through link building.

What drives the scope and cost of an SEO migration

The cost of a migration depends on how many URLs need a manual decision, how much the structure changes and whether I implement the redirects myself. SEO migrations start from €1,200 and include 90 days of monitoring.

A broader walkthrough with examples is in the article SEO migration without losing rankings, and the general SEO principles a migration does not exempt you from are on the technical SEO page. For multilingual sites, see the article on hreflang and international SEO.