How to Migrate a Site Without Losing Search Rankings

A site migration is any change that alters your site's URLs, domain, structure, platform, or protocol at scale. Done right, you protect every ranking you have built. Done carelessly, you hand them to competitors.

The core problem: migrations break rankings silently. You launch the new site, traffic looks normal for a week, then it drops 40% by week three. By then, you've already moved on. The damage is months of lost leads.

Four specific steps prevent this. First: a complete inventory of every URL and what Google values about it, before you touch anything. Second: 301 redirects from every old URL to its new equivalent, no exceptions. Third: preserved metadata on every page so titles and descriptions don't reset to defaults. Fourth: 90 days of active monitoring so you catch problems before they cost you.

The most common migration killer is launching with missing or broken redirects. Google follows those redirects to pass equity from old pages to new ones. If the chain breaks, the equity evaporates and your rankings drop with it.

For a solo founder, the stakes are direct. Lost rankings mean lost traffic. Lost traffic means lost leads. This is not theoretical. The steps above are non-negotiable, and this guide covers each one in actionable detail.

The Pre-Migration Audit: Know What You Have Before You Move It

Before you change a single URL, you need a complete picture of what your site contains and what Google values within it. Skip this step and you cannot redirect pages you have not catalogued. You cannot protect equity you have not measured.

Start with a full crawl of your existing site using Screaming Frog, Sitebulb, or Ahrefs Site Audit. Export every URL with its status code, title tag, meta description, canonical tag, H1, inbound internal links, and word count. This becomes your source of truth.

Next, layer in performance data. Go to Google Search Console and pull your top-traffic pages (Performance > Pages, sorted by clicks over the past six months). Pull your most-linked pages from Ahrefs or Moz. Any page on either list is high-value and requires a verified 301 redirect in your migration.

While you are in the crawl data, identify existing problems. Duplicate content, missing canonicals, broken meta descriptions. Fix these before migration, not after. Migrating a broken site multiplies the problems on the other side.

Finally, take a baseline snapshot. Export your Search Console impressions, clicks, average position, and top-ranking queries before launch day. This gives you a clean before-and-after to spot what actually happened post-launch versus what you imagined happened.

URL Mapping and 301 Redirects: The Core of Every Safe Migration

URL mapping is the process of matching every old URL on your current site to its exact equivalent on the new site. A 301 redirect is the only type that signals a permanent move and passes link equity. A 302 tells Google the old page is still canonical and passes nothing. No redirect at all returns a 404 and the equity is gone.

Build your mapping in a spreadsheet with four columns: Old URL, New URL, Redirect Type, and Status. Every URL from your crawl export goes in here. No exceptions. No shortcuts. No "we'll handle it later."

301 vs. 302: Why This Distinction Actually Matters

A 301 redirect passes the majority of a page's link equity to the destination. A 302 does not. This is not a technicality. Using 302s by accident is one of the most common developer mistakes during migrations because many tools default to temporary redirects. Verify every redirect type in your server config, not just in your spreadsheet.

Flattening Redirect Chains

A redirect chain happens when URL A points to URL B, which points to URL C. Each hop loses equity and slows the page load. When you build your redirect map, check that no old URL passes through more than one hop to reach the final destination. If your last migration left chains behind, this is when you flatten them: point A directly to C, not through B.

What To Do With Pages That Have No Equivalent

If a page has no meaningful equivalent on the new site and carries no significant backlinks or traffic, let it 404. Do not redirect everything to your homepage. That pattern (called a "soft 404 redirect") is easily detected by Google and passes no equity. Only redirect URLs with genuine content equivalents.

If you are migrating away from WordPress, your URL structure will almost certainly change and mapping becomes even more critical. Similarly, if you are moving to a no-code platform, verify that it supports server-side 301s, not just JavaScript-based redirects. Google treats them differently.

Preserving On-Page SEO Elements Across the Move

The on-page elements that must transfer intact are: title tags, meta descriptions, H1 headings, canonical tags, structured data markup, alt text on images, and internal link anchor text. Lose any of these during a platform migration, and rankings drop independently of the redirect work.

Title tags and meta descriptions are often stripped or auto-generated during platform imports. Check every imported page, not just a sample. Run a post-import crawl with Screaming Frog and compare title tags against your pre-migration export, field by field.

Internal links deserve specific attention. Relying on redirects to handle internal links is lazy and costly. If your new site's internal links still point to old URLs, every internal page load adds a redirect hop, slowing the site and diluting equity. Update every internal link to point directly to new URLs. Navigation menus, in-body links, footer links, all of it.

Your XML sitemap must reflect the new URL structure from day one. Submit it to Search Console on launch day, not a week later. Do not submit a sitemap containing old URLs, redirected URLs, or pages returning non-200 status codes. Google will index the old URLs and create duplicate content conflicts.

The staging trap is real: many platforms serve staging without a Disallow: / in robots.txt for Googlebot. If Google crawls your staging before launch, it indexes duplicate content that conflicts with your live site. Always confirm that Disallow: / blocks your staging from search engines, and that your live robots.txt is permissive on day one.

Migration Phase Checklist: Who Owns What and When

Migrations fail when tasks fall between people. When nobody owns a phase end to end. Five clear phases cover the process, and each needs an owner and a success metric before you start.

Staging discipline is non-negotiable. Test every redirect in staging before launch, not after. A broken redirect found in staging costs an hour to fix. One found after launch costs rankings and leads.

On launch day: deploy during low-traffic hours (early morning, mid-week) to reduce the window of disruption if something breaks. Avoid Fridays. If something goes wrong on Friday, you have nobody to call until Monday.

For solo founders, every row in this table has the same owner: you. The only way to prevent the audit from bleeding into the build, which bleeds into launch day, which means nothing gets verified, is to plan this work in advance with a clear calendar and deadlines.

Telling Google About the Move

Google needs two signals after a migration: the new sitemap showing where your content lives, and (for domain changes only) the Change of Address notification confirming the move is intentional.

Recrawling a migrated site typically takes four to eight weeks for healthy, well-linked sites. Larger or less frequently crawled sites can take longer. Treat these as typical ranges, not guarantees.

The Change of Address tool in Search Console applies only to domain-level changes (example.com moving to newdomain.com). It does not apply to URL restructuring on the same domain. If you are only changing URL paths without changing the domain, skip Change of Address and focus entirely on redirects and sitemap resubmission.

On launch day, go to Google Search Console, remove any old sitemap entries, and submit your new sitemap. Then use the URL Inspection tool to manually request indexing for your ten highest-value pages. This prompts Google to crawl those pages faster than waiting for the regular crawl schedule.

Keep your old Search Console property active and monitored for at least six months after migration. Coverage errors, redirect issues, and traffic anomalies often surface first in the old property because Google is still resolving which URLs are canonical. Delete or ignore it and you miss that signal.

Post-Migration Monitoring: The 90 Days That Decide Everything

The 90 days after launch decide whether a migration succeeds or quietly fails. Monitoring must be active and structured: daily for the first two weeks, weekly from weeks three through eight, and monthly from weeks nine through twelve.

Days 1-14 (daily): Check Google Search Console for crawl errors and coverage issues. Run a fresh site crawl with Screaming Frog to catch any redirects that broke during deployment. Monitor the Coverage report for any spike in 404s or redirect errors.

Weeks 3-8 (weekly): Review the Performance report in Search Console. Track total clicks, total impressions, and average position against your pre-migration baseline. Check which pages dropped most sharply. Verify those pages' redirects are resolving correctly and that their metadata transferred intact.

Weeks 9-12 (monthly): Assess the overall traffic trend. If clicks are within 10-15% of your pre-migration baseline by week eight, the migration is tracking normally. If you see a decline that persists past week three, investigate immediately.

The alarm threshold: a 30% or greater drop in clicks or impressions persisting past week three is not normal settling. It signals missing redirects, a crawlability problem, or metadata loss. Treat it as an incident, not a trend to wait out.

An undetected broken redirect does not just lose a ranking. It loses every lead that page would have generated until someone catches it. This is why monitoring is not optional. This is why you check the data.

The Mistakes That Cost Rankings Most Often

Most migration ranking drops trace back to a small set of repeated errors. These are the patterns from failed migrations, with specific consequences and fixes for each.

1. Missing redirects on high-traffic pages. Consequence: immediate 404s, lost equity, pages drop out of rankings. Fix: a verified crawl post-launch that confirms every URL from your pre-migration inventory resolves to a 200 or a valid 301.

2. Launching with a crawl-blocking robots.txt. This happens when a developer copies the staging robots.txt to production by accident. Consequence: Google cannot crawl the site, impressions drop to near zero, the problem takes days to notice. Fix: a manual robots.txt check the moment you go live.

3. Metadata stripped during platform import. Title tags, meta descriptions, and H1s reset to platform defaults on many CMS migrations. Consequence: rankings drift on affected pages over weeks. Fix: a post-import crawl comparing title tags field by field against your pre-migration export.

4. Using 302 redirects instead of 301s. Consequence: equity is not passed, Google continues treating the old URL as canonical. Fix: verify every redirect type in your server configuration, not just in your spreadsheet.

5. Redirect hops through internal links. This is less obvious but consistent in cost. When your new site's internal links still point to old URLs that redirect, every page carrying those links passes equity through an extra hop. Fix: update all internal links to their final destinations directly.

Frequently Asked Questions

How long does it take to recover rankings after a site migration?

For healthy sites with proper 301 redirects and no crawlability issues, rankings typically stabilize within four to eight weeks of launch. Some pages recover faster, particularly those with strong backlink profiles. Pages with redirect chains, missing metadata, or incomplete internal link updates can take significantly longer.

Do I need to do anything in Google Search Console for a URL structure change on the same domain?

Yes, though the Change of Address tool does not apply to same-domain changes. Submit an updated XML sitemap immediately on launch day, use the URL Inspection tool to request indexing for your highest-priority pages, and monitor the Coverage report daily for the first two weeks to catch new 404s or redirect errors.

What is the difference between a 301 and a 302 redirect for SEO?

A 301 signals a permanent move and passes the majority of link equity to the destination. A 302 signals a temporary move and does not reliably pass equity, leaving the old URL as canonical. For migrations, always use 301s unless you have a specific reason to use a temporary redirect.

Should I migrate and launch new content at the same time?

Avoid it. Launching new content during a migration makes it much harder to isolate which changes caused any ranking fluctuations. Complete the migration, verify that traffic is stable, and then resume normal publishing. Mixing the two signals creates diagnostic noise that delays identifying and fixing problems.

How do I migrate a site with thousands of pages?

Prioritize your URL map. Sort all pages by organic traffic and referring domains, and address high-value pages first with verified redirects. For lower-value pages with no traffic or backlinks, a clean 404 is often right instead of a forced redirect. Process the highest-traffic segments first and test them in staging before launching anything.

What happens if I discover a broken redirect after launch?

Fix it immediately. A broken redirect discovered on day five has already cost you five days of lost leads. Update the redirect, verify it resolves to a 200 status, and request a recrawl in Search Console. Monitor that page's rankings over the following two weeks to confirm recovery.

The Takeaway: Migrations Are Manageable. Your Rankings After Should Be Too.

Site migration without losing rankings is not about luck or platform choice. It is about completing three things correctly: a thorough pre-launch audit with full URL mapping, server-side 301 redirects on every URL that carries traffic or equity, and 90 days of structured post-launch monitoring.

Each step is achievable. The time cost is real, particularly for solo founders who are also responsible for running the business.

The harder truth is that migration is not the end of the SEO work. After the redirects are verified and Search Console is clean, the content work needs to keep going. Posts need to get published. Internal links need updating as new pages go live. Rankings need ongoing attention.

If that ongoing work is what keeps stalling, automation is worth exploring. Building a system that handles research, writing, and publishing so you can focus on the actual business is how founders reclaim their time.

That is exactly what Agent Solo's early access is built for: autonomous AI systems that own your content and web presence end-to-end, so migrations stay safe, content keeps compounding, and you get back to selling.