serpInventory before moving anything
A blog migration begins with a URL map, not a new theme. Export the existing public article addresses, their intended destinations, and whether each resource is retained, merged, or removed. Include useful pages that are no longer prominent in navigation. Check analytics and webmaster reports for old URLs that still matter to readers. Give every retained article a clear destination rather than relying on a broad redirect to the new homepage. The migration plan should explain what happens to a person following an old bookmark, because that concrete experience also reveals many technical mistakes.
Make the destination independently correct
Before switching traffic, verify the new pages' content, metadata, canonical addresses, and internal links. A migration should not accidentally publish preview noindex settings or canonical links pointing back to a temporary host. Test articles with images, tables, code samples, and unusual characters in their slugs. If you change both platform and content structure at once, record those changes separately so later diagnosis is possible. The destination should be a complete public resource. A redirect that reaches an empty template is not a successful migration simply because the HTTP chain ends without an error.
Update the discovery system together
Bing's guidance recommends permanent redirects for permanent moves. Apply the mapping deliberately, update internal references to the final addresses, and generate the new sitemap from the current content manifest. Keep the old host operational enough to serve its intended redirects. Where IndexNow is implemented, notify relevant changed URLs after the new behavior is live. Avoid treating one notification as a replacement for the migration itself. A coherent move has agreement across the old response, new page, navigation, canonical information, and discovery file. Each piece has a different job in explaining the change.
A hypothetical subdomain move
Imagine a fictional company moves blog.example.com/setup to example.com/blog/setup. The article remains the same resource. The team verifies the new page, sets the old URL to redirect directly to it, updates links in related guides, and lists only the intended current address in the new sitemap. It also checks that image paths no longer depend on an abandoned deployment. This hypothetical illustrates a migration checklist, not a promise about ranking retention. Search visibility may change while systems process the move, and the team should preserve evidence rather than assume a fixed recovery schedule.
Monitor mappings rather than only totals
After release, sample important old URLs and confirm their final destinations. Watch for loops, extra hops, broken assets, and redirects landing on unrelated content. Compare page groups in performance reports while keeping the migration date visible. A fall in an old URL's activity can be expected if the new address takes its place; examine the mapping before declaring a loss. Preserve the migration inventory as an operational document. Future editors may otherwise delete redirects without understanding why they exist. The most useful success criteria combine correct visitor behavior, accurate discovery signals, and observed search transitions over time.
Preserve a one-to-one migration map and verify the old-to-new visitor journey before interpreting traffic changes.
Sources & further reading
Official documentation informs this guide. Examples are illustrative, and product interfaces or limits can change.
From search signals to a useful first draft.
SERP.so is in development. Join the waitlist for a workspace that connects research, content review, and publishing.
Join early access ↗