Rankings Dropped After Changing Hosts? Here's What Actually Broke (2026)

A rankings drop within two weeks of moving hosts or domains is almost never Google deciding you don't deserve the position anymore. It's something in the move itself that broke. Google has said as much directly: a well-executed move shouldn't cost you rankings at all. The drop is a symptom of a specific technical fault — a redirect that never fired, a certificate that didn't come across, a robots.txt file that was still set to block from the staging environment. Find the fault, fix it, and the rankings that were earned before the move come back.

The frustrating part is that most of these faults are invisible from the front end. The new site looks fine in a browser. It's only when you check what Googlebot actually sees — headers, redirect chains, certificate validity, the robots directives — that the problem shows up.

Rule out timing before you panic

Google's own guidance on site moves is blunt about the timeline: a small-to-medium site can take a few weeks for most pages to re-settle after a legitimate move, and larger sites take longer. That's normal, not a fault. If you changed hosts eight days ago and rankings dipped slightly, you might just be watching the re-crawl happen.

The line between "normal re-settling" and "something broke" is roughly this: a small dip that's already recovering by week three is timing. A drop that's still there — or getting worse — at week four or five is a fault somewhere in the move, and it's worth running a free audit to see exactly where before you lose more time waiting it out.

The five things that actually cause the drop

1. DNS didn't fully cut over before you assumed it had

When you point a domain at a new host, the change doesn't happen everywhere at once. It propagates based on the TTL (time-to-live) set on the DNS record — the old value can keep being served from ISP and resolver caches around the country for hours after you've made the switch. If you migrated content on the new host that differs from the old one, or set up redirects only on one side, some visitors and some Googlebot crawls hit the old server, some hit the new one, during the transition window. That's usually harmless if both sides serve the same thing. It's a problem if the old host was switched off, or the new host wasn't fully configured, before the cutover had time to finish.

The fix for the next migration: drop the TTL on the record to something short — a few minutes — several days before the move, then cut over, verify, and raise the TTL back afterward. It costs nothing and removes almost all of the guesswork.

2. Redirects are missing, wrong, or pointed at the wrong place

This is the single most common cause of a genuine ranking loss after a move, and it takes several forms:

• No redirect at all. The new host doesn't recognise the old URL structure, so it serves its generic 404 — sometimes with a 200 OK status instead of 404, which Google treats as a real page with no content, a "soft 404."
• A 302 instead of a 301. Google is explicit that these are treated differently: a 301 (permanent) tells the indexing pipeline the new URL should take over as canonical and inherit the old URL's signals. A 302 (temporary) doesn't — Google may keep showing the old URL in results even though it no longer resolves properly.
• Everything redirected to the homepage. A blanket rule that sends every old URL to / instead of its actual new equivalent looks like a shortcut but reads to Google as a soft 404 on every page that got swept up in it — you lose the specific ranking each page had earned.
• Redirect chains. Old URL → interim URL → final URL, sometimes three or four hops deep after a few migrations stacked on top of each other. Googlebot will follow chains, but Google's guidance is to keep them short and redirect straight to the final destination — each extra hop adds latency and risk.

The rule that actually matters here: every old URL needs its own 301 to its specific new equivalent, and Google recommends keeping those redirects live for at least a year so all the ranking signals have time to fully transfer.

3. The SSL certificate didn't come across cleanly

Moving hosts often means reprovisioning the certificate from scratch on the new server. If that step gets missed, rushed, or misconfigured, one of a few things happens: the site serves over HTTP without forcing HTTPS, the certificate doesn't match the domain and browsers throw a warning, or some resources — a script, a stylesheet, an image — still reference the old http:// URLs and get blocked as mixed content. Any of those is enough to hurt rankings and, more immediately, to scare off the human visitors who do land on the page during the transition.

The check is simple and takes thirty seconds: load the new site in a private browser window, look for the padlock, and open the developer console to check for mixed-content warnings. Do it before you tell anyone the migration is finished, not after.

4. A staging leftover made it to production

Almost every migration goes through a staging environment first, and almost every staging environment is deliberately blocked from search — a noindex meta tag, a robots.txt that disallows everything, or a password wall. The failure mode is when that staging build gets promoted straight to the live domain and the block comes with it. Rankings don't just drop in this case, they can disappear within days, because you've told Google directly not to index the page.

Checking yourdomain.com/robots.txt after any migration takes ten seconds and it's worth doing every single time, not just when something looks wrong.

5. You used — or skipped — the Change of Address tool incorrectly

Google Search Console has a Change of Address tool, and it's specifically for domain changes — moving from one domain to a genuinely different one (oldname.com.au to newname.com.au). It is explicitly not meant for hosting or CDN migrations where the URL itself doesn't change; Google handles those automatically once it re-crawls and finds the 301s in place. Running the tool for a same-URL hosting move does nothing useful. Skipping it after an actual domain change means Google has to work out the move purely from redirects, which takes longer and is less reliable than telling it directly.

Worth knowing which situation you're actually in before you either skip a step you needed or run a tool that doesn't apply.

What to check in Search Console, in order

Once the move is live, three reports in Google Search Console tell you almost everything. The Coverage (or Pages) report shows whether the new URLs are being indexed and flags anything excluded as "blocked by robots.txt," a "crawl anomaly," or "not found (404)" — any of those pointing at pages that should be live is a direct lead on the fault. The Crawl Stats report under Settings shows whether Googlebot's requests to your site are returning errors at a higher rate than before the move. And the URL Inspection tool lets you check any specific page and see exactly what Google last crawled and whether it's indexed — the fastest way to confirm a fix has actually taken.

If you've read through the broader diagnostic for a ranking drop with no migration involved, the same three reports are the backbone of that process too. A move just narrows down which of the usual suspects is most likely.

The order that avoids all of this

For the next move — or if you're mid-migration right now and reading this in a slight panic — the sequence that avoids nearly every fault above is:

1. Build and fully test the new site on staging, with staging itself blocked from indexing.
2. Map every existing URL to its new equivalent and set up 301 redirects for all of them before the DNS cutover, not after.
3. Provision and test the SSL certificate on the new host, and confirm HTTP forces to HTTPS.
4. Lower the DNS TTL a few days ahead of the cutover so propagation is fast and predictable.
5. Cut DNS over, then immediately check: the robots.txt is production-correct, redirects resolve with a 301 (not a 302, not a soft 404), the certificate is valid, and the sitemap is updated and resubmitted.
6. If the domain itself changed, submit the Change of Address tool in Search Console. If it's a hosting-only move with the same URLs, don't — there's nothing for it to do.
7. Leave the redirects live for a minimum of a year.
8. Check the Coverage and Performance reports weekly for the first six to eight weeks.

Most of this is an afternoon of careful checking, not a technical mountain. It's just the kind of afternoon that gets skipped when "go live" day arrives and everyone's attention is on whether the new site looks right, not on whether it's talking to Googlebot correctly underneath — which is exactly the step a proper build treats as part of the job, not an afterthought bolted on once the site's already live.

If you've already moved and you're staring at a rankings graph that dropped and hasn't recovered, the fastest way to sanity-check the platform side is to run the free audit — it checks the certificate, crawl readiness and Core Web Vitals in under a minute, which at least rules a few of the five faults above in or out before you go digging through Search Console at 11pm.