You migrate a website without losing SEO by running five steps in order: inventory the live site before anything is designed, preserve URLs wherever you can, map every changed address to a single permanent redirect pointing at a relevant page, carry content and metadata across complete rather than approximately, and verify all of it by request on launch day. WPBuildAI runs every migration in exactly that sequence, for three reasons: each step produces an artifact that can be tested rather than trusted, the order matters because later steps depend on earlier ones, and every migration that loses rankings turns out to have skipped one of the five. Here is each step, what it produces, and how it fails when it is rushed.
Why does the inventory come before the design?
Because the record of what the current site contains is what everything else gets graded against, and it cannot be reconstructed once the old site is gone. The first deliverable of a migration is not a design.
Crawl the live site and capture, per URL: the address and its status code, the title, the meta description, the canonical tag, the heading structure, the body content, every image with its alt text, the internal and outbound links, and any structured data. Then add the sources a crawl cannot reach: Search Console’s page and performance exports over the longest period available, analytics for every page that received a visit in two years, and server logs if you can get them.
That combined record is the contract for the whole project. The new site is built to satisfy it, the redirect map is generated from it, and launch is graded against it. Without it, the new site gets built from the pages someone remembered, and the pages nobody remembered disappear silently. The method is set out in what is a crawl-first migration.
The number that surprises people: a site with 200 pages in its navigation typically has 600 to 1,000 addresses that have served content. The gap is where the losses live.
Which URLs should you preserve?
Every one you reasonably can, because changing an address is never free and most URL changes buy nothing measurable.
A preserved URL needs no redirect, no recrawl, and carries no risk. Google distinguishes moves with URL changes from moves without them precisely because the second kind is close to invisible to search engines: the same address returns the same content, and nothing has to be relearned.
Three changes are worth making during a move: http to https, removing platform artifacts such as index files or query strings from paths, and consolidating duplicate addresses so that www and non www, and trailing slash variants, resolve to one canonical form. Everything else, especially restructuring hierarchy for tidiness, should be resisted or postponed. The reasoning is in should you keep your old URLs after a migration.
What does each step actually produce?
Five artifacts, one per step, and each one can be tested rather than trusted. That is the whole reason to work in this order.
| Step | Artifact it produces | How it fails | How you test it | Verdict | | Artifact it produces | How it fails | How you test it | Verdict | | --- | --- | --- | --- | --- | | Inventory | A per URL record of the whole live site | Built from the sitemap instead of a crawl | Row count against analytics and Search Console | WPBuildAI starts here on every project | | Preserve URLs | A list of addresses that do not change | Tidying URLs for looks | Diff old and new URL lists | Fewer changes means fewer risks | | Redirect map | One row per old URL, destination, status | Blanks, chains, homepage dumping | Request every row, expect one hop to a 200 | The load-bearing file | | Carry content | New pages matching the inventory | Pages arrive thinner than the originals | Word count and heading diff per page | Thin pages lose rankings, not URLs | | Verify | A pass or fail per URL on launch day | Spot checks instead of full runs | Automated request of every mapped URL | Mechanical, no judgment needed |
The map is a spreadsheet with one row per old URL, its exact destination, and its status code. Every row resolves in a single hop to a page that returns 200. Google’s redirect guidance treats a permanent redirect as the instruction that an address has moved for good, and chains, while they work in a browser, cost crawl efficiency and clarity.
Two rules make the difference between a map that preserves value and one that looks complete. Redirect to the nearest surviving page by topic, not to the homepage, because unrelated homepage redirects are commonly treated as soft errors. And never leave a blank cell, because a blank becomes a 404 on launch day. The full method is in what is a redirect map and how do you build one.
Why do rebuilt pages lose rankings even with perfect redirects?
Because the page arrived thinner than the one that was ranking, and that failure looks like an improvement rather than a defect.
A redesign usually shortens pages. Sections get merged, an FAQ block gets dropped as clutter, a long explanation becomes three bullet points, and the page looks cleaner while containing less of what it used to rank for. Rankings follow, and the cause is misdiagnosed as the migration when it was the edit.
So check content parity mechanically against the inventory: per page word count, heading structure, image count and alt text, and the presence of any structured data the old page emitted. Where a page is deliberately shorter, that is a decision, and it should be a recorded one rather than a surprise found in week six.
Metadata is the other half. Titles, meta descriptions, canonical tags, and open graph images are assets your SEO plugin was storing, not machinery you are discarding with it. Export them before the plugin is touched. And every new page should declare itself canonical, which is the point of Google’s canonicalization guidance and the migration specific case in do canonical tags matter after a website migration.
How do you verify a migration on launch day?
By requesting every row of the map rather than reviewing it. Reading a redirect map by eye proves nothing; requesting every row proves everything.
On launch day, run every old URL through an automated check that follows redirects and records the chain and final status. The pass condition is exact: at most one hop, ending in a 200, at a page whose subject matches the original. A 404 is an immediate permanent loss. A chain is a slow leak. A loop is an outage for that address.
Test the variants too, because real inbound links use all of them: with and without www, http and https, with and without a trailing slash. A page can look perfect while the exact string in someone’s five year old link returns nothing.
Then confirm the site is crawlable, a staging robots rule or a leftover noindex tag is the single most damaging launch error, submit the new sitemap following Google’s sitemap guidance, and check that forms and analytics work. The full sequence is in what to do in the first week after a migration goes live.
What does a normal recovery look like?
A shallow dip for two to three weeks, then recovery to baseline within four to eight. Knowing that shape is how you tell patience from neglect.
Impressions fall 10 to 30 percent in weeks one and two, recovery becomes visible in week three, and most small sites are back to baseline within four to eight weeks. A migration that preserved URLs entirely often shows no meaningful dip at all. Larger sites take longer because recrawling takes longer, not because anything is wrong.
The leading indicator is coverage, not rankings. New URLs indexed and old URLs reporting as redirects within days means the move was communicated properly and the rest is waiting. Unindexed new pages or a growing not found list means a fault that will not resolve on its own. The full curve and its decision points are in how long does ranking recovery take after a migration.
What if the old site is already gone?
The sequence still works with one substitution: replace the crawl with an archive reconstruction. This applies when the host has closed the account, or the CMS is locked and nobody has credentials.
Search Console still holds your URL and query history even when the site is gone, and it is the highest value source in this situation. Analytics holds the pages that received visits. Public web archives hold copies of many pages, including their titles and body text. A backlink tool holds the addresses other sites point at, which is the set that matters most.
Combine those into the same inventory you would have crawled, accepting that it will be incomplete. Then rebuild the pages that earned something, map the rest to their nearest surviving equivalent, and accept 410 for the ones you genuinely cannot reconstruct.
The result is worse than a proper crawl and far better than starting from a blank site with new URLs, which is what happens by default when nobody looks. A site rebuilt from an archive with correct redirects usually recovers most of its previous traffic; a site rebuilt with fresh URLs and no map starts at zero regardless of how good it looks. The recovery path for locked out and abandoned sites is covered in what to do if your WordPress developer disappears.
What should you check before you sign anything?
Six questions, and the specificity of the answers tells you more than any portfolio does.
| Question to ask | A good answer names | A weak answer says |
|---|---|---|
| What happens to my current URLs | A crawl, a written policy, a map | The new information architecture |
| Who builds the redirect map | A file, one row per old URL | Redirects will be set up |
| How is the map tested | An automated run on launch day | We check the main pages |
| How is content parity checked | A page by page diff against the crawl | Content will be migrated |
| What happens in weeks two to six | Coverage monitoring and a defect window | The project ends at launch |
| Whose accounts hold the domain and code | Yours, with them invited | Ours, for convenience |
What are the four ways this actually goes wrong?
Scoping from the visible site, adding redirects at the end, smuggling a redesign inside the migration, and never verifying. Nearly every damaged migration is one of those four, and all four are preventable at the planning stage.
Scoping from the visible site. The navigation gets rebuilt, the archive does not. Old posts, tag pages, and paginated archives are dropped because nobody listed them, and the loss surfaces in week five as a 404 report.
Redirects added at the end. Treated as a launch task rather than a design input, so the URL structure gets invented first and the map is written to fit it. That is backwards: the map should constrain the structure.
A redesign smuggled inside a migration. Two changes at once, so when traffic moves you cannot tell which caused it. If both are genuinely needed, sequence them and let the platform move settle first.
No verification. The map exists, nobody ran it. This is the most common failure of all, and it is the cheapest to fix: a script over a thousand rows takes two minutes.
The condensed pre launch version of all of this is in WordPress migration SEO checklist, which is the checklist to hand to whoever is doing the work.
When is preserving everything the wrong goal?
When the old site was not worth preserving. A site with thirty visitors a month, no backlinks, and an archive of thin pages nobody reads is not carrying equity, and treating the move as a preservation exercise spends real money protecting nothing.
In that situation the honest advice is to launch clean, keep only the handful of URLs that actually receive traffic, and return gone for the rest. The map shrinks from 900 rows to about 20, the project gets cheaper, and nothing of value is lost.
It is also the wrong goal when preservation is being used to avoid a decision. Sites accumulate pages that should have been retired years ago, duplicate service pages, abandoned campaign landing pages, tag archives with one post each. Redirecting all of them preserves clutter rather than equity, and it carries that clutter into the new site as permanent redirect rules somebody will inherit.
The test is per URL rather than site wide: did this address earn anything in the last two years, in traffic, links, or conversions. If yes, preserve it. If no, retire it deliberately and write the reason in the row. A migration is one of the few moments when pruning is cheap, and refusing to prune is how sites get heavier with every move.
Key takeaways: keeping rankings through a platform move
Inventory first. The record of the live site is the contract everything else is graded against, and it must come from a crawl plus Search Console, analytics, and logs, never from the sitemap or from memory.
Preserve URLs by default. Changing an address costs a redirect, a recrawl, and a permanent maintenance obligation, and buys almost nothing unless it fixes a real defect.
Map every changed address to one permanent redirect at a relevant page. No blanks, no chains, no dumping unrelated pages on the homepage.
Carry the content whole and verify by request on the day. Pages that arrive thinner lose rankings for content reasons, and a redirect map nobody tested is an intention rather than a safeguard.
Quick answers
How do you migrate a website without losing SEO? Inventory the live site first, preserve URLs wherever you can, map every changed address to a single permanent redirect, carry content and metadata across complete rather than approximately, then verify by requesting every old URL on launch day. WPBuildAI runs migrations in exactly that order, because each step produces something testable, and a skipped step is what every migration horror story turns out to have in common.
What is the biggest cause of SEO loss during a migration? Missing redirects for URLs nobody knew existed. Not the pages in the navigation, which everyone remembers, but paginated archives, tag pages, attachment URLs, and old posts that only external links still point at. Those are invisible unless you crawl and export before the move rather than after it, and their loss is permanent rather than a delay you can wait out.
How much traffic should I expect to lose in a migration? A clean migration dips 10 to 30 percent in impressions for two to three weeks and returns to baseline within four to eight weeks. A migration preserving every URL often shows no meaningful dip at all, because nothing has to be relearned. Losses persisting past week four are faults rather than recovery time, and they need diagnosing rather than waiting out.
Do I need an SEO agency to migrate a website safely? You need the work done rather than a particular kind of supplier. The five steps are mechanical, and a competent developer with a crawler can execute all of them. What an SEO specialist adds is judgment on the ambiguous calls, which old pages deserve redirects and which should be retired honestly, plus a second pair of eyes on launch day when it counts.
Is it not safer to keep the old site running alongside the new one? No, and it is a common expensive mistake. Two live copies of the same content on different addresses compete with each other and split every signal between them. Cut over completely, redirect the old addresses, and keep the old site only as an offline backup you can consult if something turns out to be missing.
