How to Migrate a Blog Without Losing SEO (2026 Checklist)

Most blog migrations lose traffic in the first two weeks, and the ones that don't share one habit: they treat old URLs as promises to keep, not baggage to drop. A single missing redirect on your best-ranking post can wipe out months of link equity that took years to build.

TL;DR: To migrate a blog without losing SEO, map every old URL to its new one, add a 301 redirect for each, keep slugs identical when you can, fix internal links to point at the final URL, then resubmit your sitemap in Google Search Console and watch coverage for two to four weeks. The traffic dip is optional — it comes from broken redirects and dropped meta, not from the move itself.

Will migrating my blog hurt my Google rankings?

Not if you preserve URLs and redirects. Google says a well-executed migration should recover within a few weeks. Rankings drop when old URLs 404, when redirects chain three or four hops deep, or when your titles and meta descriptions get regenerated by the new CMS. The move itself is neutral. Your redirect map decides the outcome.

The risk is real but bounded. Sites that redirect every old URL 1:1 usually see a small, temporary wobble as Google recrawls. Sites that skip the redirect map or let a bulk plugin guess the mapping can lose 20 to 60 percent of organic traffic and take months to claw it back.

What actually causes the traffic drop?

Four things, almost always: dead URLs with no redirect, redirect chains, lost meta tags, and stale internal links. Each one is preventable with a checklist. None of them are caused by "moving to a new platform" in the abstract — they're caused by details slipping through during the move.

Here's how the two paths compare.

The left column keeps your rankings. The right column is what a rushed weekend migration looks like.

How do I map old URLs to new ones?

Export a full list of your live URLs first, then decide the new path for each before you touch the new CMS. Pull the list from your current sitemap.xml, your analytics, and a crawler like Screaming Frog so you catch pages that aren't in the sitemap. Sort by traffic — your top 20 percent of URLs carry most of the ranking value, so they get checked by hand.

Build a simple two-column sheet: old_url, new_url. If your new platform keeps the same slug structure, most rows map 1:1 and you're mostly done. If the structure changes (say /2024/03/my-post becomes /blog/my-post), every changed row needs a redirect. Don't guess the mapping — a wrong redirect is worse than a 404 because it sends Google and readers to the wrong content.

If you're moving off WordPress specifically, the migrate from WordPress guide walks through pulling that URL list cleanly.

Why do slugs matter so much?

Because the slug is the part of the URL Google has already indexed and other sites have already linked to. Change it and you break the match unless a redirect catches it. Keep slugs identical across the move and a huge chunk of your URLs need no redirect at all — the new URL just resolves.

This is where a CMS earns its keep. UnfoldCMS has slug history built in: when you change a post's slug, the old slug keeps working and 301s to the new one automatically, without you writing a redirect by hand. That safety net matters most during a migration, when slug edits are easy to make by accident. You still map the URLs that genuinely change, but same-name posts protect themselves.

The migration checklist (step by step)

Run these in order. Don't skip ahead — step 4 depends on the map from step 1 being complete.

1. Export every live URL. Combine your sitemap, analytics top-pages, and a full crawl. Dedupe. This is your source of truth.
2. Build the redirect map. One row per URL: old_url → new_url. Verify the top-traffic rows by hand.
3. Copy meta, don't regenerate it. Move seo_title and meta_desc for each post exactly. Don't let the new CMS title-case them — that corrupts proper nouns like "WordPress" or "CMS."
4. Set up 301 redirects for every URL whose path changed. Permanent move = 301, always. Load them before cutover, not after.
5. Keep the slugs you can. Only rewrite paths you have a real reason to change.
6. Fix internal links. Update every in-content link to point at the final new URL, so you don't rely on redirects internally.
7. Regenerate sitemap.xml and robots.txt. The new sitemap should list only live, canonical URLs — no redirected paths.
8. Cut over. Point DNS or publish. Test 20 sample old URLs immediately — each should 301 to the right page in one hop.
9. Resubmit the sitemap in Google Search Console. Then request indexing on your top 10 posts.
10. Monitor for 2 to 4 weeks. Watch Coverage, Pages, and the top-queries report for drops.

For the redirect mechanics — status codes, testing, common mistakes — the 301 redirects for SEO guide covers the setup in detail.

301 vs 302: which redirect do I use?

Use a 301 for a blog migration. Full stop. A 301 says "moved permanently" and passes ranking signals to the new URL. A 302 says "temporary" and Google keeps the old URL indexed, so link equity stays stuck on a page that no longer exists.

The only time a 302 fits during a migration is a short maintenance window — and even then, most people don't need it. When you set up redirects in UnfoldCMS's Redirects module (/admin/seo/redirects), you pick 301 or 302 per rule and can bulk-import the whole map from a CSV, which is how you load a hundred redirects in one shot instead of typing them in.

What are redirect chains and why avoid them?

A redirect chain is when URL A sends to B, which sends to C, which finally sends to D. Each hop bleeds a little ranking signal and adds load time, and Google may stop following after a few hops. Flatten every chain so old URLs 301 straight to the final destination in a single hop.

Chains usually sneak in when you've migrated more than once, or when an old redirect plugin's rules survive the move. Before cutover, run your redirect map through a crawler and check that no old_url points at another old_url. Every rule should end at a live 200-status page.

What to do about it before you cut over

Before you flip the switch, run this pre-flight pass — it catches the mistakes that cause 90 percent of migration traffic loss.

• Test your top 20 URLs by hand. Paste each old URL in a browser. Confirm one 301 hop to the right new page.
• Diff your meta. Spot-check ten posts: does the new seo_title match the old one character for character?
• Crawl for 404s. Run the new site through a crawler and fix anything returning 404 or 500.
• Check the sitemap. Open the new sitemap.xml. Every URL should return 200 — no redirected or dead entries.
• Confirm robots.txt isn't blocking you. A leftover Disallow: / from a staging site will deindex everything.
• Keep the old server reachable if you can, so redirects have something to fire from during DNS propagation.

Do this on a staging URL first if your platform allows it. The CMS migration guide for developers has a fuller pre-launch runbook if you want the deep version.

How do I monitor rankings after the cutover?

Watch Google Search Console daily for the first two weeks, then weekly. The signals that matter are indexed-page count, impressions, average position, and crawl errors. A short dip is normal as Google recrawls; a dip that keeps deepening past week two means a redirect or meta problem you missed.

Concrete things to check in GSC after cutover:

• Pages report — is the indexed count holding near your pre-move number, or dropping?
• Coverage / errors — any spike in "not found (404)" or "redirect error"?
• URL Inspection — inspect your top 5 posts; confirm Google sees the new URL as canonical.
• Performance — compare the 28 days after cutover to the 28 before. Isolate any query that lost position.

If a specific post tanks, inspect its old URL. Nine times out of ten the redirect is missing or chained.

FAQ

How long does it take to recover rankings after a blog migration? Usually two to four weeks for Google to fully recrawl and settle, assuming redirects are clean. Large sites can take a couple of months. If you're not back near baseline by week six, you have a technical problem — not a patience problem.

Do I need to redirect old URLs if the slugs stay the same? If the full URL is identical (same domain, same path), no redirect is needed — the URL just resolves. You only redirect when the path changes. On a domain change, every URL needs a redirect even if slugs match, because the host is different.

Will I lose backlinks when I migrate? Not if you 301 the linked URLs. A 301 passes the link's ranking signal to the new page, so external backlinks keep counting. You lose backlink value only when the linked URL 404s with no redirect.

Should I resubmit my sitemap or wait for Google to find changes? Resubmit it. Submitting the fresh sitemap in Search Console tells Google to recrawl faster, which shortens the dip. Waiting works eventually, but there's no reason to leave it to chance during a migration.

Can I migrate one section at a time to reduce risk? Yes, and it's smart for large sites. Move a low-traffic category first, confirm redirects and indexing behave, then roll the rest. Just keep one master redirect map so nothing falls through the cracks between phases.

Where to go next

If you're picking the platform you'll move to, look at how it handles redirects and slugs before anything else — that's what makes or breaks the migration. See the UnfoldCMS features page for how the Redirects module, slug history, and auto-generated sitemap fit together, then read the WordPress-to-modern-CMS migration story for a real move start to finish.

Methodology: this checklist is based on Google Search Central's guidance on site moves with URL changes, common patterns from post-migration Search Console data, and the redirect and slug-history behavior in UnfoldCMS. Recovery timelines are typical ranges, not guarantees — your mileage depends on site size, crawl budget, and how clean your redirect map is.