Preserving Search Rankings Through a WordPress Migration

The migration went well by every operational measure. The site was faster, the admin worked, the checkout passed its test order, and the old host was cancelled after a month. Six weeks later organic traffic was down forty percent. The cause was not the host. It was a decision made during the move to "clean up" the blog URLs, from /2023/05/post-name/ to /blog/post-name/, without a redirect map. Every ranking those posts had earned pointed at a URL that now returned a 404.

Search traffic is attached to URLs. A server can change, an IP can change, a database can move, and the rankings can survive intact as long as the URL that the search engine knows still resolves to the same content. The migration that damages rankings is the one that changes the URL, or changes what the URL returns, without telling anyone.

So the SEO work of a migration is mostly bookkeeping. Inventory the URLs, decide what happens to each, redirect the ones that move, and make the canonical, sitemap and robots signals agree with the decision. It is unglamorous and it is the difference between a move and a reset.

Disclosure: some links on this page are affiliate links, and WPSifero may earn a commission if you buy through them. The process below works with free tools; the host link at the end is for staging, which is where the redirect map should be tested.

Rankings follow URLs, and a host change should move none of them

Separate the two migrations that people call one. A host change keeps the domain and the paths: example.com/guide/ stays example.com/guide/, served from a different machine. A domain change moves old.com/guide/ to new.com/guide/. A path change keeps the domain and rewrites the structure. Each has a different risk profile, and mixing them in one weekend makes the result impossible to diagnose.

If the domain and the paths stay the same, the search engines see the same URLs with the same content, perhaps faster. There is little to preserve because little moved. The work is operational: do not block crawlers, do not leave a staging noindex in place, do not lose the sitemap, and do not let the new host return a different status code for the same path.

If the domain or the paths change, the migration is a site move in the search-engine sense, and it needs the full treatment: a map for every URL, redirects at the old address, a change of address declaration where the domain changed, and a period of monitoring. Treating it as a hosting change is how a forty percent traffic loss happens.

Inventory the URLs you have before you move

The map starts with a list. Four sources, combined, are usually enough: the current sitemap, the web server access log for the last ninety days, a crawl of the site, and the pages report in Search Console. Each sees URLs the others miss. The sitemap knows what you published. The log knows what people and crawlers actually requested. The crawl finds orphaned pages. Search Console knows what earned impressions.

Put the list in a spreadsheet with six columns: old URL, new URL, status code, content match, priority, owner. The priority column is for the pages that carry traffic and links, because those get checked by hand. The owner column is for the person who confirms that the new page is the same content rather than a category page with a similar title.

Count the rows. A site with two hundred posts and thirty pages should produce a list in the low hundreds. A list of twelve is a sign that the crawl missed the paginated archives, the tag pages, the author archives and the attachment pages, which are exactly the URLs that generate 404 spikes after a move.

Decide the URL structure before the move, and then do not change it during the move. Restructuring content and migrating at the same time is two experiments with one measurement, and when traffic drops there is no way to tell which one caused it.

One old URL to one new URL, with a 301

The rule is one-to-one. Every old URL that has a new equivalent gets a single 301 to that equivalent. Every old URL without an equivalent gets a 410, or a 301 to the nearest category if a visitor would be better served by a landing page. What does not work is a blanket redirect of everything to the homepage, which search engines treat as a soft 404 and visitors treat as a broken link.

Three details break maps that look correct. Redirect chains: A to B to C wastes crawl budget and dilutes the signal, so point every old URL directly at the final destination. Trailing slashes and case: /Guide/ and /guide are different URLs to a server even when they look the same to a person, and both need a rule. Query strings: a redirect that preserves an old parameter can create an infinite variation of URLs, so strip what does not change the content.

Test the map with status codes, not with a browser. A browser follows the chain and shows a 200, which hides exactly the problem worth finding:

curl -sI https://example.com/2024/03/backup-guide/ | head -5
curl -sI https://example.com/old-guide | head -5
curl -sI https://example.com/test-page/ | head -5

The output should show a single 301 with a Location that is the final URL, and the final URL should return 200. If the first response is 200, the redirect is not firing. If it is 302, change it to 301 unless the move is genuinely temporary.

Canonicals, sitemaps and robots have to agree

Redirects handle the old URLs. The new site has to describe itself consistently. Every page's canonical points at its own new URL, the sitemap lists only new URLs, and robots.txt allows the paths that should be crawled. A migration is the one time these three files are read closely by both crawlers and humans, and disagreement between them produces confusing reports for weeks.

The classic failure is the staging inheritance. The new environment was built from a staging copy, so the canonical tag points at staging.example.com, the sitemap lists staging URLs, and the noindex header is still on. Each one alone is enough to keep the site out of the index. Together they can take a week to diagnose because the live pages look perfectly normal in a browser.

wp option get blog_public
curl -s https://example.com/ | grep -i canonical
curl -s https://example.com/sitemap.xml | head -20
curl -s https://example.com/robots.txt

If the domain changed, the old domain should keep its redirects for as long as possible, ideally a year or more. Do not cancel the old domain at the end of the project. The redirect is the only thing transferring the accumulated signal, and a lapsed domain takes it with it. Keep the registration and the redirect until the traffic has fully moved, then keep it for another year because old links live in newsletters and PDFs for a long time.

Internal links and content parity carry the rest

A redirect passes the signal, but the site's own links should not need it. Update the internal links to the new URLs, in posts, menus, widgets, footers and calls to action. Internal links are how crawlers discover the new structure, and a site whose navigation still points at redirected URLs is a site that keeps asking the old address for directions.

Then check parity. For every old page that mattered, the new page should carry the same primary content, the same title intent and the same internal links out. A migration that turns a detailed guide into a short category description loses the reason the page ranked. If the content is being rewritten as part of the move, do it after the redirects have settled, as a separate change with its own measurement.

Images and structured data belong in the parity check too. A media file that moved to a new path can break the image search results and the social previews. Article schema that lost its author or its dates can change how the page is displayed. Neither shows up in a visual pass, which is why the check compares the old and new page side by side rather than looking at the new one alone.

Measure for ninety days, and know what you cannot keep

After the move, watch four reports: impressions and clicks, page indexing, the 404 report and crawl stats. The pattern to expect is a dip in the first two weeks while the new URLs are crawled, followed by recovery. A dip that keeps going past a month usually means a redirect or canonical problem, not a mysterious algorithm change.

For a domain change, use the change of address tool in Search Console. It is a domain-level declaration, and it works alongside the redirects rather than instead of them. Submit the new sitemap, keep the old sitemap available on the old domain for a while, and verify both properties so the reports can be compared side by side.

Some things do not survive a move. Backlinks point at the old URL, and while a 301 transfers most of the value, it is not a perfect copy, and some of the link equity is lost at each hop. Brand queries may temporarily return the old domain. Rankings for pages that were consolidated or removed will not come back, because the page is gone. Knowing which losses are expected is how you avoid chasing them with changes that make things worse.

The free tooling covers the work: a crawler for the inventory, the curl checks above, Search Console for the measurement, and a redirect plugin or WP-CLI for the map. SiteGround includes staging and a migration plugin, which is where the map should be tested before the DNS change; a staging copy with the redirects in place is the only way to walk the old URLs and see the new pages arrive.

Where the extra tooling is not worth it: a host change with unchanged URLs on a site with fifty pages and no organic traffic to speak of. There, the correct move is to change nothing else, confirm the sitemap and canonical, and spend the budget on content. The decision rule is a single question: after the move, will every URL that has ever earned a link return the same content, either directly or through one 301? If yes, the rankings have their best chance. If no, fix the map before the DNS change, not after the traffic report.