How to Migrate a WordPress Site Without Losing Rankings
The things that break during a move involving this platform are predictable, which is the entire value of knowing the platform. Address structure, content fidelity, added components and redirect handling account for nearly all of it. Every one of those is a decision somebody can make deliberately rather than discover afterwards.
What Usually Moves And What Usually Breaks
Content generally transfers. What sits around the content frequently does not. That single distinction explains most of what goes wrong. It is why a transfer can look successful while quietly losing things.
What normally survives. The words and the pictures.
Text, images and the basic structure of a page usually arrive intact. Somebody checking a sample of pages sees them looking correct, which is a reasonable check that happens to miss the problem entirely, because the problem is not visible on a page.
What frequently does not. Everything attached.
Address structures, the descriptions written for search results, machine-readable markup, anything produced by an added component and the accumulated redirects from earlier moves.
Why the distinction exists. Different storage.
The content is the thing being exported. The surrounding material is held in various other places, some of it inside components that are not part of the export at all. An export can therefore be complete and correct while leaving most of the search-relevant material behind.
Why the platform makes this more likely. It is extensible by design.
A system that can be extended by anybody accumulates behaviour from many sources over years. That flexibility is the reason people choose it. It is also why a move involving it has more moving parts than a closed system would.
Address Structures Change By Default
How addresses are constructed is configurable. Whatever the new build is set to becomes the new structure. If nobody sets it deliberately, it takes whatever the installation defaults to.
Why this is the biggest single risk. It changes every address at once.
Not one page. Every page on the site, simultaneously, because the pattern applies to all of them. A single unconsidered setting is the difference between a migration with no address changes and one with thousands.
How it happens without anybody deciding. Nobody was asked.
The setting is chosen when the site is created, usually by whoever is doing the technical setup, at a point where nobody has raised search. It is not a decision anybody remembers making, which is why it never appears in a project record or a handover.
What to establish first. Whether the old pattern can be kept.
Frequently it can. A move that keeps every address identical is the cheapest possible migration, because no mapping is needed and no value has to travel anywhere. That question is worth asking before anybody starts building rather than after.
When changing it is legitimate. When the old one was genuinely poor.
That is a real reason and it is a decision with a cost, which means it belongs in the plan with a mapping attached, per URL mapping for a site migration.
Content Import Is Not Content Preservation
An import moves content into a new system. Whether everything attached to that content survived is a separate question. It is one nobody asks, because the import reports success.
What tends to be lost. The attachments.
The descriptions written for search results, alternative text on images, custom fields holding information the theme displayed, plus formatting produced by a page builder that the new system does not understand.
Why the page builder case is the worst. The content is inside it.
Where pages were assembled with a visual builder, much of the content exists in that builder's own format. Move to a system without it and the words may arrive as unreadable fragments, else not at all. This is the one case where a content transfer can fail visibly rather than quietly.
Why nobody catches it. The check is visual.
Somebody opens a few pages and they look right. Missing alternative text and absent descriptions are invisible in that check. Shorter pages read as fine unless compared against the original.
What catches it. The pre-migration crawl.
Comparing what pages contained before against what they contain now. That comparison exists only if somebody took the record beforehand.
Plugins Generate Things You Did Not Know You Had
Added components produce a great deal of what a site does for search. Much of it is invisible until it stops. Removing or replacing one removes whatever it was quietly producing.
What they commonly generate. Four things.
Machine-readable descriptions of pages. The address lists published for crawlers. The instructions about which version of a page is authoritative. And in many cases the redirect table itself.
Why that is a migration problem. Components are chosen fresh.
A rebuild rarely reproduces the exact set that existed before. Somebody selects what the new site needs, reasonably. Anything the old set was producing that nobody knew about simply stops.
The redirect case specifically. The sharpest one.
Where redirects lived inside a component, replacing it can remove every redirect the site had, including those from a previous migration years earlier. Nothing announces this and every one of those old addresses stops working.
What to do about it. Inventory before rebuilding.
Establish what the current set produces, so that the new build reproduces it deliberately rather than by luck. That inventory is a short exercise and it has to happen while the old site is still assembled. The markup half of this is covered in structured data during migration.
Where Redirects Live On This Platform
Redirects can be held in three places on a site like this. The choice affects speed, who can maintain them and how likely they are to survive the next rebuild.
At server level. Fastest, least accessible.
Handled before the site itself is involved. Efficient, though changes require access that the person who needs to make them frequently does not have.
Inside an added component. Most accessible, most fragile.
Easy for anybody to manage through the site's own interface, which is genuinely valuable on a site nobody technical looks after. The trade is that the redirects exist only while that component does, which is the block four problem in its sharpest form.
Built into the site itself. The middle option.
Handled by the build rather than by something added, so it survives component changes. It needs whoever built the site to have made it that way deliberately, which means asking for it rather than expecting it.
What to decide, plus when. Before the mapping.
Whichever is chosen has to hold the volume the map will contain. Somebody has to be able to maintain it in three years. The mechanism is in how to implement 301 redirects.
The Staging Problem
Builds on this platform are frequently created as a copy of another environment. Copies carry their settings with them, including the ones added to keep the copy private.
Why copying is standard practice. It is the sensible approach.
Duplicating a working environment is faster and safer than assembling a new one. It guarantees the new site starts from something known to work. Nothing about this is bad practice.
What comes along with it. Everything, including the settings.
A copy is a copy. Whatever was configured in the original arrives in the duplicate. That includes any instruction added to keep an unfinished site out of results.
Why it survives to launch. Nothing surfaces it.
The setting produces no visible effect on the site. It cannot be seen on any page, so a full round of testing passes with it still in place and everybody involved signs the launch off in good faith.
What this means practically. It is on the launch list.
Not because anybody is careless. A copied environment carries invisible state, so the only defence is a check. That check is the first thing on our crawling and indexing guide.
What A Good Build Does
Five things, none of which is difficult and all of which have to be somebody's responsibility. A build doing all five produces a migration with very little left to go wrong.
Settles the address structure first. As a decision.
Agreed deliberately at the start rather than inherited from a default, with a mapping produced if it changes at all.
Reproduces what the old components produced. Deliberately.
Having established what those were, rather than discovering the gaps afterwards.
Verifies content rather than assuming it. Against the record.
Comparing what arrived with what existed, particularly where a visual builder was involved, since that is where content loss is largest.
Puts redirects somewhere durable. A conscious choice.
Somewhere that survives the next component change and that somebody can still maintain later.
Removes the staging protections. On a list, not from memory.
Because it is invisible, with a consequence out of all proportion to the effort of checking.
What To Check After
The general launch checks apply here as anywhere. Four additional things are worth verifying specifically because of how this platform works.
That the address pattern is what was agreed. Not what defaulted.
The single highest value check on this page, because it affects every address at once and because a default can quietly override an agreement.
That machine-readable descriptions are still produced. They may not be.
If a component was producing them and the new set does not, they have gone without any error appearing.
That the redirect table survived. Including the old ones.
Particularly redirects inherited from a previous migration, which live in whatever was handling them and may not have been carried across by anybody who knew they existed.
That nothing is still telling crawlers to stay away. The copied setting.
Per block six, within the hour. The full series is on the website migration guide.
The content
moved. What
surrounded it?
The address pattern agreed as a decision rather than inherited from a default, what the old components were quietly producing established before anything is replaced, redirects put somewhere that survives the next rebuild, content compared against the record rather than glanced at, with the copied settings removed from a list rather than from memory.
What a migration engagement covers:
A migration is a one-off project rather than a monthly service, so it is scoped and quoted against the size of the site and how much is changing at once.
Every guide.
One practice.
What a migration is, the types, when to do it, planning, the checklist, auditing, mapping, redirects, internal links, tags, downtime, crawling, structured data, performance, notifying, monitoring, recovery and the mistakes.
