Site Migration Without Losing SEO: A 9-Step Plan

A site migration without SEO losses follows nine steps: you define what is changing, inventory every URL, prepare the new version on a test environment, build a 301 redirect map, test it, launch with a checklist, and then monitor for weeks. Many dramatic traffic drops do not come from algorithm updates; they come from migrations done without a plan.

What a site migration is and why it is risky

A migration is any change that alters what Google sees or where it sees it: a redesign, a new platform, a switch to HTTPS, a move to another domain or a restructuring of URLs. The risk is not the change itself. It is that Google has already learned the old site: it knows which addresses exist, what content they hold and which links they receive. If those vanish without explanation, it has to learn everything again.

Google's documentation is clear about expectations: when you move a site with URL changes, it can take a few weeks or more before Google gradually starts showing the new URLs instead of the old ones, and longer for large sites. Your aim is not to avoid every fluctuation but to keep it short and predictable.

If you are about to build a site from scratch to replace an old one, building an SEO-optimized website includes the migration plan from the design phase rather than after launch.

Migration types and their risk level

Not all migrations are equal. The table below helps you gauge how careful you need to be.

A practical rule: the more you change at once, the harder it is to find the cause of a problem. If you have a choice, do not change the domain, the URLs, the design and the content simultaneously.

Step 1: define what changes and how you will measure success

Before anything else, write down in a document:

1. what is changing (domain, URLs, platform, design, content);
2. what is not changing and must be preserved (titles, copy, link structure, speed);
3. the metrics to compare: indexed pages, Search Console clicks and impressions, organic traffic, rankings for main queries, conversions.

Save these numbers at least 3–4 weeks before launch. Without a baseline, you cannot tell whether you lost anything.

Step 2: inventory every URL and its value

The list of old URLs is the basis of your redirect map. Collect them from several sources, because none is complete:

• a full crawl of the site;
• the current sitemap;
• Search Console (pages with impressions or clicks, including those not in the menu);
• your analytics tool (pages that receive visits);
• server logs, if you have access;
• the backlink list, so you know which pages receive external links.

For each address, note organic traffic, rankings, backlinks and the page's role (home, category, service, article). Pages with traffic or links are the ones you cannot afford to lose. Keep a full copy of the old site until the migration has settled.

Step 3: prepare the new site on a test environment

The new version is built on staging, protected by a password and/or noindex so Google does not index it prematurely. On staging, verify:

• every important page has an equivalent: title, description, H1, text, images;
• canonicals point to the new addresses (not the old ones); the details are in the article on canonical tags and duplicate content;
• structured data and internal links use the new addresses;
• for multilingual sites, hreflang annotations are updated; see the hreflang guide;
• speed has not degraded; compare Core Web Vitals before and after.

Do not move content over in bulk without reviewing it. A migration is a good moment to fix weak titles, but do it as a separate stage if you want to be able to isolate causes.

Step 4: build the 301 redirect map

The redirect map is the heart of the migration: a table with two columns, the old address and the equivalent new address. The rules:

• Page by page, to the closest content. Do not send everything to the homepage; Google may treat redirects to irrelevant pages as soft 404s.
• Direct, no chains. Old → new, not old → intermediate → new. Every extra hop slows things down and complicates them.
• 301 (or 308) from the server, not redirects done in JavaScript.
• Pages with no equivalent: redirect to the relevant parent category, and if none exists, leave a deliberate 404 or 410.
• Include variants: with and without trailing slash, with and without www, http and https, parameters that have traffic.

An example rule on Apache (.htaccess) for a moved page:

Redirect 301 /old-services/audit https://example.ro/audit-seo

For many URLs you use pattern-based rules (RewriteRule) or a mapping file. For short lists you can generate the rules with the 301 redirect generator. The difference between 301 and 302, plus other traps, is explained in the article on redirects.

Step 5: test before launch

Testing is the difference between a calm migration and a dramatic one. On staging:

1. run a crawl on the list of old addresses with the redirects applied, and check every response: a 301 straight to a 200;
2. look for chains, loops and redirects to 404 pages;
3. check a sample of every page type (home, category, product, article);
4. confirm that robots.txt and meta robots are the production ones, prepared for launch day, not the test ones;
5. test forms, payments and tracking scripts.

How to check a redirect quickly

For a spot check you do not need an expensive tool. One simple command shows what the server answers:

curl -I https://example.ro/old-services/audit

Read the first lines of the response: the status code and the Location header.

Repeat the test on a sample of each page type, not only on the few addresses you know by heart. Mistakes usually hide in the rare cases: addresses with parameters, with capital letters, with an extra slash.

Step 6: choose the moment and prepare a rollback plan

Launch during a lower-traffic period and when the team is available to react, not on a Friday night. Prepare a rollback plan: what you do if something goes seriously wrong (restoring the old site, disabling redirects). If you are changing domains, keep access to both.

Step 7: launch and run the checklist

On launch day, in order:

1. activate the 301 redirects;
2. remove noindex and the password from the new site;
3. replace the test robots.txt with the production one (the classic error is exactly the staging file going live);
4. publish the new sitemap with the final addresses; also keep the sitemap of old addresses temporarily so Google discovers the redirects faster; the XML sitemap guide shows what to include and what not;
5. if you changed the domain or subdomain, use the Change of Address tool in Search Console; it does not apply to moving from HTTP to HTTPS or to moves inside the same domain;
6. verify in Search Console that both properties (old and new) are confirmed.

Step 8: checks in the first 48 hours

Right after launch, look for the obvious problems:

• redirects work on a sample of old addresses;
• the homepage and key pages return 200 and are indexable (test with URL Inspection);
• no waves of 404 or 5xx errors appear in Search Console;
• tracking records visits and conversions;
• speed is within expectations.

If something is not indexed, see the guide to pages not indexed.

Step 9: monitor for weeks and keep the redirects

The first 4–8 weeks are the period to watch most closely: crawl errors, the number of indexed pages, clicks and impressions, main rankings. A temporary dip may occur; the direction matters, not a single day. Compare with the numbers saved in Step 1. If you have not used the indexing reports before, start with the Google Search Console beginner's guide.

Keep redirects as long as possible, generally at least a year according to Google's documentation; for user experience, they are worth keeping even longer. Update important external links to point directly at the new addresses.

Common migration mistakes

• Noindex or Disallow: / left over from staging.
• Mass redirects to the homepage.
• Redirect chains or loops.
• Canonicals left on the old addresses.
• No inventory, so pages with traffic get forgotten.
• Changing too many things at once.
• Removing content that brought traffic, with no replacement.
• Deleting redirects after a few months.
• Launching with no prior measurements, meaning nothing to compare against.

Limits: what no plan can guarantee

Be realistic:

• You cannot eliminate every fluctuation. Google needs time to process the changes.
• If the old site had problems, the new one does not fix them automatically; a migration can even expose them.
• A small site can be moved more simply, but the steps stay the same, only the lists are shorter.
• If a page disappears for good, you will lose its traffic. A deliberate 404 is more honest than a forced redirect.
• Results depend on the niche and on the quality of the new content.

Conclusion: next steps

A successful migration is a boring one: nothing disappears, nobody notices. Start like this:

1. Save baseline numbers from Search Console and analytics.
2. Inventory all addresses and build the redirect map.
3. Test everything on staging, then launch with the checklist.
4. Monitor for at least two months and keep the redirects.

If you want the migration planned and verified by specialists, see our service for building an SEO-optimized website, with migration included. You will find more guides on the blog.

Moving a multilingual or multi-country site? Our international SEO services include migration planning with hreflang and redirects.