How to Migrate a Blog Without Losing Search Rankings

Key takeaways

Build a URL-to-URL redirect map covering 100% of indexed pages before migration day, not after traffic drops.
Use 301 (permanent) redirects, never 302s or meta-refresh — 302s tell Google the move is temporary and signals don't consolidate.
Expect a 2-4 week dip in impressions even on a clean migration; anything beyond 6-8 weeks without recovery means something broke.

What "losing rankings" during a migration actually looks like

Rankings don't usually vanish overnight — they erode in a specific pattern that's worth recognizing early, because the fix depends on which pattern you're seeing. The first is a clean, temporary dip: impressions drop 20-40% in the first two weeks as Google recrawls and reconsolidates signals to the new URLs, then recover fully by week four. That's normal and expected even with a perfect migration — Google has publicly said reprocessing a site move can take "a few weeks" for smaller sites and longer for larger ones, per Google Search Central's site move documentation.

The second pattern is permanent loss, and it has a specific signature: individual pages that ranked well disappear from search results entirely rather than just dropping a few positions. That means the redirect for that specific URL failed, points to the wrong destination, or the page's content changed enough during migration that Google treats it as a different document. We've seen founders migrate a blog post from /blog/post-name to /resources/post-name and change the H1 and intro paragraph "while they were at it" — and lose the ranking not because of the URL change, but because the content signal shifted at the same time the URL did. Never combine a URL migration with a content rewrite. Do them as two separate events, weeks apart.

Build the URL migration map before you touch anything

This is the single highest-leverage step and the one people skip because it's tedious. Export every indexed URL from Google Search Console (Coverage report, or the URL Inspection API if you're scripting it) and from your XML sitemap, then cross-reference against your server logs if you have them — logs catch URLs that still get hit by bots or old backlinks even if they're no longer in your sitemap.

For each URL, record:

The exact old URL (including trailing slashes and query parameters, which matter for matching)
The exact new URL it maps to
Whether the content is identical, substantially similar, or being merged with another page

That last point matters more than people expect. If you're consolidating three thin blog posts into one comprehensive guide — a pattern we recommend often when cleaning up keyword cannibalization before a migration — redirect all three old URLs to the single new page, not to your homepage or category page as a lazy catch-all. Redirecting everything to the homepage is the most common mistake we see on solo migrations, and it tanks rankings because Google can't map old relevance signals to anything specific on the new page.

Redirects: the part everyone gets wrong

Use 301 redirects, full stop. A 301 tells search engines the move is permanent and that link equity, ranking signals, and indexing history should transfer to the new URL. A 302 signals "temporary," and Google deliberately holds back on fully consolidating signals for 302s because it assumes you'll move the content back — this is documented behavior, not speculation, and it's rooted in how the HTTP standard itself defines status codes (see the IETF's RFC 9110 on HTTP semantics for the formal distinction between 301, 302, and 308).

Platform migrations introduce a specific failure mode: redirect chains. You migrate from WordPress to a new CMS, and your old WordPress install already had a redirect from /old-post to /new-post set up by a plugin a year ago. Now your new site redirects /new-post to /migrated-post. A crawler hitting /old-post has to follow two hops to land on the final page. Google will follow a reasonable number of redirect hops, but each additional hop dilutes signal transfer and slows crawl efficiency, especially on large sites where crawl budget is finite. Flatten every chain to a single hop: /old-post → /migrated-post directly.

A few other specifics that trip people up:

Redirect the non-www to www version (or vice versa) and HTTP to HTTPS separately from your content migration, so you can isolate which change caused which effect if something breaks.
Preserve URL parameters that matter for tracking or pagination, but strip ones that don't — don't blindly wildcard-redirect /blog/* to /articles/* without checking that paginated or filtered URLs resolve correctly.
If you run a multilingual blog, redirect each language version to its equivalent translated page, not to the default-language homepage — this is the single most common thing that breaks hreflang setups during a migration, something we cover in more depth in our guide to structuring multilingual blog content.

What to do on migration day

Sequence matters more than most checklists admit. Here's the order that minimizes downtime and crawl confusion:

Stage the new site and test redirects in a pre-production environment using a crawler tool against your full URL list — don't test redirects by clicking a handful of links manually, test all of them programmatically.
Flip DNS and deploy during low-traffic hours for your primary audience's timezone.
Immediately verify a sample of 20-30 high-traffic redirects are live and returning 301 status codes, not 200s (serving the new page directly without a redirect) or 404s.
Submit the new XML sitemap in Google Search Console the same hour, and use the URL Inspection tool to request indexing on your 10-20 highest-value pages manually rather than waiting for organic recrawl.
Leave the old domain's redirects live indefinitely if you're changing domains — don't let the old domain expire or go dark for at least 12 months. Expired domains stop resolving, which breaks every external backlink pointing at your old URLs permanently.
Update internal links to point directly at new URLs rather than relying on redirects to catch them — redirect chains from your own internal linking slow crawl efficiency on your own site.

If your migration includes a new site structure, this is also the moment to double check your category pages are structured correctly for the new information architecture, since category-level redirects are frequently an afterthought and category pages often carry disproportionate link equity from older domains.

Monitoring after launch: what to watch and when

Don't wait for organic traffic in your analytics tool to tell you something's wrong — by the time traffic drops are visible there, you've usually lost a week or two of recoverable signal. Watch these in order:

Day 1-3: Google Search Console's Coverage report for a spike in 404s or "Crawled — currently not indexed" on your new URLs. A spike here almost always means your redirect map has gaps.
Day 3-14: Crawl stats report for a drop in pages crawled per day — if Googlebot's hitting your new site less than it hit your old one, something's slowing crawl (often a robots.txt accidentally carried over from staging that blocks crawling).
Week 2-6: Position tracking for your top 20-30 keywords. Expect fluctuation, not disappearance. If a page that ranked #3 is now simply absent from the index, pull its URL and check the redirect chain manually.
Ongoing: Set up a saved segment in Google Analytics 4 for organic landing pages so you can compare pre- and post-migration organic sessions per page, not just site-wide totals — site-wide averages hide individual page failures.

Common failure modes we see with founders doing this solo

Most SEO-related migration disasters trace back to one of a small number of root causes, and recognizing the pattern ahead of time is cheaper than debugging it after.

Changing URLs and platforms at the same time as a content overhaul. We mentioned this above, but it deserves repeating because it's the most common thing founders do deliberately, thinking they're being efficient. A migration is already a large signal change for search engines to process; layering a content rewrite, new meta descriptions, and new title tags on top makes it impossible to isolate what caused a ranking change if one happens.

Trusting the CMS's built-in "redirect import" tool blindly. Several popular platform migration tools generate redirects automatically based on slug matching, and they frequently get it wrong for any URL that doesn't follow a simple pattern — pagination, tag archives, and old AMP URLs are common casualties. Always export and manually spot-check at least 10% of auto-generated redirects.

Forgetting schema markup doesn't migrate automatically. If your old blog had structured data for articles, FAQs, or breadcrumbs, your new platform may not generate equivalent markup out of the box, and losing schema can cost you rich results in search even if rankings hold steady. Check this explicitly rather than assuming it carried over — our guide on adding schema markup without coding is a reasonable starting checklist for what to verify.

Underestimating how long full signal consolidation takes for larger sites. A 20-post blog might fully recover in three weeks. A 2,000-post blog on an older domain can take two to three months for Google to fully reprocess, because it's recrawling and reindexing at a rate governed by your site's crawl budget, not on demand. Set expectations with stakeholders accordingly before migration day, not after someone panics in week three.

Frequently Asked Questions

Q: How long does it take for search rankings to recover after a blog migration?

A clean migration with complete redirects typically shows a 2-4 week dip before rankings stabilize, based on Google's documented timeline for reprocessing a site move. Larger sites with thousands of URLs can take two to three months for full signal consolidation.

Q: Do I need to redirect every single old blog URL?

Yes, for any URL that has ever been indexed, received backlinks, or driven traffic — even old tag pages or paginated archives. Leaving any indexed URL without a redirect turns it into a 404, which loses whatever ranking signal and backlink equity it had accumulated.

Q: Should I use 301 or 302 redirects for a permanent blog migration?

Use 301 redirects exclusively for a permanent migration. A 302 signals to search engines that the move is temporary, so they hold back on fully transferring ranking signals to the new URL.

Q: Can I change my blog's URL structure and migrate platforms at the same time?

You can, but keep the actual content — titles, headings, body copy — unchanged during the move itself. Changing URL structure, platform, and content simultaneously makes it impossible to diagnose which change caused a ranking drop if one occurs.

Q: What's the biggest mistake people make when migrating a blog?

Redirecting everything to the homepage or a generic category page instead of mapping each old URL to its specific new equivalent. Search engines can't transfer page-level relevance signals to a destination that isn't actually about the same topic.