Most WordPress migrations do not lose rankings because Google punishes moving. They lose rankings because URLs quietly change, images point at paths that no longer exist, and nobody compares the new site against a record of the old one.
This is the checklist I actually work through when I move a site: what to record before touching anything, how to handle redirects properly, and the post-launch checks that catch breakage before Google does.
Principaux enseignements
- Most migration ranking drops come from unmapped URLs and broken paths, not from the move itself
- Record a full URL inventory and crawl before touching anything; you cannot redirect URLs you never listed
- 301 redirects go old URL to exact new URL in one hop; blanket redirects to the homepage waste the equity you built
- Images break most often in WordPress moves because of hardcoded paths and serialized URLs left in the database
- A temporary wobble for a few weeks is normal; a drop that persists usually means a step on this checklist was skipped
Why WordPress migrations lose rankings
Google’s own site move documentation is clear that a properly executed move should not cause lasting ranking loss, and my experience matches that. The lasting damage I see in audits comes from mechanical failures: an old URL that now returns a 404 instead of a 301, a category page whose slug changed without anyone noticing, or a media library serving images from a path that died with the old server.
Each broken URL is a small leak. One is survivable, but migrations rarely break one thing; they break a class of things, like every image on 300 posts, or every URL under a renamed category. The damage scales with whatever pattern you missed, which is why the checks below are about classes of URLs, not individual pages.
There is also a timing reality worth accepting up front. Even a clean move gets a few weeks of fluctuation while Google recrawls and reassigns signals. Do not panic-revert in week two; judge the migration at week six against the baseline you are about to record.
Before the migration: record what you have
You cannot verify a move against a site that no longer exists, so the baseline is the most valuable thing on this list. I record four things before touching anything.
- A full URL inventory. Crawl the live site (Screaming Frog or any crawler) and export every URL: pages, posts, categories, tags, images, PDFs. This list is what your redirect map and your post-launch comparison are built from.
- A rankings and traffic snapshot. Export Search Console performance (queries and pages, last 3 months) and note your top pages. This is the baseline you judge the migration against, so keep the export, not just a memory of it.
- A complete backup, files and database. Not the host’s automatic one; your own, downloaded and tested. If the move goes wrong, this is the difference between an hour of downtime and a lost weekend.
- The current sitemap and robots.txt. Save copies. You will compare the new site’s versions against them after launch, and differences jump out fast when you have the originals side by side.
The WordPress migration steps, in order
The sequence matters more than any individual trick. Build and test on a copy, map the URLs, then switch; sites get hurt when those steps run in the wrong order or under time pressure on the live server.
A WordPress migration in five controlled phases
- Snapshot and back up everything (URLs, rankings, files, database)
- Build and test the new site on staging, blocked from indexing
- Map every old URL to its exact new home
- Go live: switch DNS, enable the 301 redirects, unblock indexing
- Crawl, verify, and monitor for 4 to 6 weeks
On staging, two settings do most of the protective work. Keep the staging copy out of the index (Settings, Reading, “Discourage search engines”, plus HTTP auth if the host offers it), because an indexed staging site becomes a duplicate of your real one. And when you migrate the database, use a tool that handles serialized data (WP Migrate, Duplicator, or WP-CLI’s search-replace); a plain find-and-replace on a database dump corrupts settings that store URLs inside serialized arrays, and page builders do this constantly.
If the move includes a hosting change, test performance on the new server before DNS switches, not after. Time to first byte and Core Web Vitals are part of what you are migrating, and a slower host silently downgrades what you spent months building; the same logic from my Core Web Vitals guide applies here. Managed WordPress plans on hosts like Hostinger ou Cloudways make the staging-then-switch flow simpler because staging and cloning are built in.
Redirect mapping: the step that decides the outcome
If URLs change in any way (new domain, removed subfolder, new permalink structure, renamed categories), every old URL needs a 301 to its exact new equivalent, one hop, no chain. I covered when each redirect type is right in my redirects breakdown; for a permanent move, 301 is the answer.
Build the map in a spreadsheet from your URL inventory: old URL in one column, new URL in the next. The rule that separates a clean migration from a lazy one is specificity. Redirecting everything to the new homepage looks done, but Google treats those as soft 404s and the page-level equity you built evaporates.
Where you implement matters less than people think: server-level rules (.htaccess or Nginx) are fastest, and a redirect plugin or Rang Math’s redirection module is fine for most sites. What matters is that patterns cover classes of URLs and the exceptions are handled individually.
One trap to design around: if the site is also moving from http to https or dropping www at the same time, stack the rules so any old variant reaches the final URL in a single hop. Chains like http, then https, then the new domain slow crawling and leak signals at every extra step.
After launch: verify the move before Google does
The hours after DNS switches are where the checklist earns its keep. Crawl the OLD URL list (not the new site; the old list) and confirm every URL returns a single 301 to the right destination. Then crawl the new site and compare it against your pre-move inventory; anything that disappeared without a redirect is a leak you can still plug.
For spot checks, a chain tester shows you what a crawler sees. Here is our own domain in httpstatus.io: the bare http URL takes two 301s to reach the final https www version, which is acceptable for a protocol hop but exactly what you do NOT want stacked on top of a domain change.
In Search Console, add the new property (if the domain changed) and use the Change of Address tool under Settings; skip it for a same-domain host move or an http to https switch, where it does not apply. Resubmit the sitemap either way, and watch the Pages report over the following weeks: the old property’s indexed count should fall as the new one rises. If instead you see the new site’s count stall, my guide to reading indexing drops covers how to tell a recount from a real problem.
What usually breaks in a WordPress migration, and the check that catches it
| What breaks | Where it comes from | The check that catches it |
|---|---|---|
| Broken images | Hardcoded old-domain paths and serialized URLs in the database | Crawl the new site for 404 images; open your top 10 posts in a browser |
| Lost URLs | Slug or permalink changes nobody recorded | Compare the new crawl against the pre-move URL inventory |
| Redirect chains | Protocol, www, and domain rules stacking on each other | Run top old URLs through a chain tester; flag anything over one hop |
| Wrong canonicals | Staging or old-domain canonicals left in the head | View source on key pages; every canonical should point at the live new URL |
| Stale sitemap | Cached sitemap or plugin still referencing old URLs | Fetch /sitemap.xml directly and resubmit it in Search Console |
Two of these deserve special attention in WordPress specifically. Images break so often after a move that I wrote a separate fix-it guide for images not loading after migration; the short version is that the database is usually still pointing at the old path, and the fix is a proper serialized-data search-replace, not re-uploading files.
Canonicals are the quieter one. A staging URL left in a canonical tag tells Google the real page lives somewhere else, and the symptom shows up later as indexing weirdness. If Search Console starts reporting canonical confusion after a move, my canonical troubleshooting guide walks through it.
So, how risky is a WordPress site migration really?
Honestly, far less risky than its reputation, on one condition: the boring bookkeeping gets done. Every migration horror story I have been called in on traces back to a skipped step from the list above, usually the URL inventory or the redirect map, and almost never to Google mishandling a clean move.
So treat the move as a data problem, not a leap of faith. Record everything, map everything, verify against the record, and give Google a few weeks to settle. Yes, a temporary wobble is part of the deal; a permanent loss is not, and the difference is this checklist.
Migrating a Site and Want a Second Pair of Eyes?
N'hésitez pas à nous contacter ou m'envoyer un courriel before you flip DNS; a 30-minute review of your redirect map is a lot cheaper than rebuilding lost rankings. Remember, a migration is only as safe as the checklist behind it.
Want our posts to show up more often on Google?
One step & Google will surface this site in your Top Stories.
