Changing host does not cost you rankings. Changing URLs does. Almost every guide on this subject blends the two into one checklist, which is why people building a 301 redirect map for a move where no URL changed — pure busywork with a real risk attached — is such a common sight.
And the single most expensive mistake in a WordPress migration is not a redirect at all. It is a checkbox in Settings that lives in the database, gets ticked on staging, and travels to production with everything else. Below: which of the two migrations you are actually doing, the setting that quietly deindexes sites, a step-by-step table of where the SEO risk really sits, and the case for not bothering with any of it.
There are two migrations, and only one is an SEO event
Google indexes URLs. Not servers, not hosting panels, not IP addresses. If a page keeps its exact address and keeps serving the same content, a search engine has nothing to reconsider — the request simply resolves somewhere else. That is the whole reason a pure host move is not, by itself, an SEO operation.
A move that changes the addresses themselves is the opposite: every ranking signal is attached to an old URL that no longer exists, and the entire job is transferring those signals across. Work out which row you are in before you plan anything, because the two need almost nothing in common.
| What is changing | Is it an SEO event? | What the move actually needs |
|---|---|---|
| Host only — every URL identical | No | Verify nothing blocks crawling or indexing on the new copy. No redirects to build. |
| HTTP to HTTPS | Yes, mildly — the scheme is part of the URL | 301 every http URL to its https twin, update internal links and canonicals. Google says the Change of Address tool is not needed here. |
| Permalink structure changes | Yes | A 1:1 redirect map old → new, updated internal links, a fresh sitemap submitted in Search Console. |
| Domain changes | Yes — the one that deserves the caution | Redirect map, plus a Change of Address request, plus keeping those redirects live for at least a year. |
Most people asking how to migrate WordPress without losing SEO are in row one. They are moving to a better host, keeping the domain, keeping the permalinks. For them the redirect chapter that dominates every article on the subject is not just unnecessary — it is the part most likely to break something.
The setting that actually costs people their traffic
Sites do not lose rankings by changing server. They lose rankings by shipping the staging site’s “do not index me” instruction to production. It is the one failure in this whole process that is both silent and total: nothing looks broken, the site loads perfectly, and over the following days the pages quietly drop out of the index.
The mechanism is specific to WordPress and worth knowing exactly. Under Settings → Reading there is a checkbox, Discourage search engines from indexing this site. Since WordPress 5.3, ticking it causes <meta name="robots" content="noindex,nofollow" /> to be printed into the head of every page (WordPress.org documentation, verified August 2026). The setting lives in the database. A migration copies the database. So the box someone sensibly ticked on the staging copy arrives on the live site along with the posts, the products and the orders — and nothing in the process flags it.
Google’s own guide for moving a site without changing URLs names this directly: “While building the new copy of a site, some site owners use a robots.txt file to disallow all crawling by Googlebot and other crawlers, or use noindex meta tags or HTTP headers to block indexing of content. Be sure to remove any such blocks from the new copy of the site when you’re ready to start the move.” (Google Search Central, verified August 2026.) It is the only warning in that document phrased as an instruction.
Two details make this worse than it sounds. The WordPress setting is a request, not a wall — the documentation is blunt that it does not block access and it is up to search engines to honour it, so the site stays perfectly reachable for humans while it disappears for Google. And because deindexing is gradual, the drop usually shows up a week or two after the migration, by which point nobody is looking at the move as the cause any more.
Every step, and where the SEO risk really sits
The same sequence we use on every job — copy, verify, switch, watch — with the specific thing that can cost you traffic at each stage and the countermeasure. The timings behind these steps are in how long a WordPress migration takes; this is the same process viewed through what search engines see.
| Step | What can cost you rankings | Countermeasure |
|---|---|---|
| Build the staging copy | Staging gets indexed and competes with the live site — or its indexing block later ships to production | Protect staging with HTTP authentication, not with a noindex you have to remember to remove |
| Search-replace the URLs in the database | A naive find-and-replace corrupts serialised data, or leaves half the site pointing at the staging hostname | Use a serialisation-aware search-replace, then search the database for the staging host to confirm zero matches |
| Install SSL on the new host | https fails or falls back to http after the switch, creating redirect chains and mixed content | Install and test the certificate before the DNS change; confirm http → https resolves in a single hop |
| Switch the DNS | Visitors and Googlebot split between two servers while the change propagates | Lower the TTL ahead of the switch and keep the old host serving the identical site until traffic stops reaching it |
| Go live | The noindex or the robots.txt Disallow: / from staging is now on production | Within minutes of the switch: view source on the live domain and load /robots.txt. Both, every time |
| The first week after | A crawl-rate dip is read as a penalty and triggers panicked changes that cause a real one | Google states a temporary crawl-rate drop after a move is normal and recovers — watch Search Console, change nothing |
On the DNS row, how far ahead to lower the TTL is decided by the value you already have: the old TTL has to expire before the lower one is universally in effect. Google’s move guide suggests dropping it to a few hours at least a week in advance (verified August 2026). If your current TTL is 24 hours, lowering it 48 hours before is enough.
If the URLs do change: the redirect part
Skip this section if the domain and permalinks are staying. If they are not, this is where the entire risk of the migration is concentrated, and the rules are Google’s, not folklore.
- Map every old URL to one new URL. One hop, no chains. Server-side HTTP redirects are what Google recommends: all permanent methods end up with the same effect, but server-side ones are noticed fastest.
- Keep the redirects for at least a year. Google’s wording is explicit — “generally at least 1 year” — because that is the window in which signals finish transferring to the new URLs.
- Move everything at once if the site is small or medium. Google recommends moving all URLs simultaneously rather than a section at a time; staging the move in phases is advice for large sites only.
- Update the internal links. Do not leave the site relying on its own redirects to navigate itself — change the links to point at the new URLs directly.
- Submit the new sitemap in Search Console, and file a Change of Address request if the domain changed. Not for a host move, not for HTTP to HTTPS.
- Expect movement. Google says rankings may fluctuate temporarily during a move and settle over time. That sentence exists because the instinct at day three is to start changing things, and that is what turns a dip into a decline.
What to check the day you go live
Five minutes of checks, in this order, on the live domain — not on staging, not on the temporary URL the host gave you.
- View source on the homepage and one deep page. Search the head for
robots. Ifnoindexis there, untick the box in Settings → Reading and reload. - Load /robots.txt. A blanket
Disallow: /does the same damage from a different direction. - Test the URL of your best-performing page. Not the homepage — the page that brings the traffic. It should return 200, over https, with no redirect.
- Check that http and www variants resolve in one hop to the canonical version, and that the certificate covers both.
- Use the URL Inspection tool in Search Console on that same page and confirm Google can fetch it from the new server.
- Leave the old host running until its logs show no traffic — Google’s recommendation, and your only rollback if something surfaces on day two.
When it is not worth the effort
Two cases, and both cut against selling you work.
If no URL is changing, do not build a redirect map. Redirects are not free insurance: every unnecessary rule is a chance to create a loop, a chain, or a rule that catches a URL it was never meant to catch. A same-address move needs verification, not redirection. Adding the map anyway is how a migration that carried no SEO risk acquires some.
And if the site has no organic traffic to lose, this whole protocol is theatre. A new site, or one that has never ranked for anything, does not need a staged SEO migration plan. Move it, check the head for a noindex, and get on with the work that might actually earn it some rankings.
The one thing genuinely worth avoiding is the opposite error: putting off a move you need because you are afraid of what it might do to your positions. We have taken over sites that sat on a failing host for a year for exactly that reason — accumulating downtime, which search engines do notice, to avoid a migration that would have changed nothing about their URLs. If your host is unreliable, moving is the low-risk option. Our WordPress migration service exists for the version of this where somebody else takes the checklist off your hands — but the checklist is above, in full, if you would rather do it yourself.
Frequently asked questions
Will I lose my rankings if I change hosting?
Not if the URLs stay identical. Google indexes URLs, not servers — a page at the same address, serving the same content, has nothing for search engines to re-evaluate. What costs people traffic in a host move is almost never the move itself: it is a block on crawling or indexing that came along with the copy from staging.
Do I need to set up 301 redirects when I only change host?
No. If every URL is unchanged, there is nothing to redirect — each address already resolves to the right page on the new server. Building a redirect map anyway is not neutral: it adds chains and loops that can genuinely hurt. Redirects belong to migrations where the URLs themselves change.
Should I use the Change of Address tool in Search Console?
Only if the domain changes. Google states the tool is for moving from one domain to another, and explicitly says it is not needed for an HTTP to HTTPS migration. A host change on the same domain does not involve it either.
How do I check whether a noindex came across with the migration?
Open the live site, view the page source, and search the head for a robots meta tag. If you find noindex, go to Settings → Reading in WordPress and untick "Discourage search engines from indexing this site". Then load /robots.txt on the live domain and confirm it does not contain a blanket Disallow: /.
How long does it take for Google to settle after a migration?
After a host move with identical URLs, expect a temporary dip in crawl rate that recovers on its own. After a move that changes URLs, Google says ranking fluctuation during the transition is normal and asks you to keep the redirects in place for at least a year so all signals transfer.
Can I redesign the site at the same time as the migration?
You can, but do not. If traffic drops afterwards you will have no way of knowing which change caused it — the move, the new templates, the changed URLs or the new content. Migrate first, confirm the numbers are stable, then redesign. Two weeks of patience buys you a diagnosis you cannot get any other way.
Sources (verified August 2026): Google Search Central — Site moves without URL changes; Google Search Central — Site moves with URL changes; Google Search Central — Redirects and Google Search; WordPress.org — Settings Reading screen.