Most blog migrations lose URLs the same way. Nobody decides to. The new site goes live, the old one goes off, and a week later somebody notices that the article a partner linked to in 2023 now returns an error page. By then it has been an error for a week.
Here is what actually has to move, and the order that keeps every old link working on the day you switch.
The four things that move
A WordPress blog looks like one thing and is four.
The posts themselves: titles, dates, bodies, whatever plugin markup is wrapped around them. The images, which live in a folder called wp-content/uploads on the old server and stop existing the moment that server is turned off. The listing pages, the /blog/ or /news/ addresses people bookmark. And the addresses of everything else that ranks, which on most sites includes pages nobody has thought about in years.
Each one needs its own answer, and the images are the one people forget. A post that moves with an image tag still pointing at the old server looks fine until cutover, then every picture on the site disappears at once.
The one file that tells you what to keep
Your SEO plugin has been keeping the list for you. Yoast, Rank Math and the rest publish XML sitemaps, one per content type, and the post sitemap is exactly the set of blog addresses Google has been told exist. On a client site this month it listed twenty-one posts, all under one folder. That list is the left-hand column of the redirect map, before a single post has been moved.
Then check it against reality. The same site had another seventeen pages at the site root that were really podcast episodes, each with a transcript, listed on a hand-built page and absent from the post sitemap. A sitemap tells you what the plugin knew about. A crawl of the live site tells you the rest.
Keep the address where you can
The best redirect is the one you don’t need. If the new site can serve a post at the exact address the old one used, do that. On the client site, all twenty-one posts kept their original slugs under the same folder, so a link to any of them works after the move without touching a redirect table.
Where an address has to change, it gets a one-to-one 301 redirect. The seventeen episode pages at the root moved into the same folder as the posts, one redirect each. The old listing pages, three of them, each redirect to the new library. Nothing redirects to the homepage, because a link that lands on the homepage is a link that failed politely.
Move the images, don’t point at them
Every image the posts use gets downloaded and re-hosted on the new site’s own storage, and the post bodies are rewritten to point at the new copies. That is the step that makes the migration survive the old server being switched off. It is also the step where a count matters: the site’s media library held 164 items, and the migration states how many it moved and how many it left behind on purpose.
Switch the map on at cutover, and then check it
The redirects are built during the migration and switched on the day the domain moves, not before, so the old site keeps working until the new one is live. Then the boring part, which is the part that matters: fetch every old address from the list and confirm each one answers with the page it should. Twenty-one posts, seventeen episodes, three listings. A migration that has not been checked this way has not been finished.
What this looks like from your side
You hand over access to the old site. You get back a list of every address that ranks, what each one will be after the move, and a check you can run yourself on cutover day. If an address is going to change, you know before it does. If one is going to disappear, you chose that.