The Silent SEO Killer: How I Lost 30% of Organic Traffic on a Site Migration

We’ve all been there. You migrate a site to a new server or change your permalinks, feeling confident because the new UI looks great. Then, a week later, you open Google Search Console and see a massive cliff: a 30% drop in organic traffic.

A migration is never just about moving files. It’s a complex DNS and routing operation. When it goes wrong, search engines don't forgive easily.

After spending three days debugging a client's botched migration, I realized that 90% of post-migration traffic drops are caused by four easily preventable technical issues. Here is the checklist I now strictly follow before and after any site move.

1. The Silent Fail: Broken Internal Links (404s)

When you change URLs, it's easy to miss internal links in old blog posts or documentation. If a crawler hits a 404 page, it stops traversing that path. Too many 404s, and your site's crawl budget takes a hit.

How to audit: Don't just click around manually. You need to extract all links from a page and check their HTTP response codes.
Instead of writing a complex Python script with requests and BeautifulSoup, I usually run a quick batch scan.

(Example: I use the bulk dead link scanner on Site Tools Box to scan the top 50 pages of the site. It crawls the DOM, sends HEAD requests to every anchor tag, and spits out a list of any 404s or 500s in seconds.)

2. The TTL Trap: DNS Propagation and AAAA Records

You updated the A record to the new server IP, but did you check the AAAA record? If you have an IPv6 record pointing to the old server, users on IPv6 networks (which is a huge percentage of mobile traffic) will still hit the dead server.

How to audit: Use a thorough DNS lookup. You need to verify A, CNAME, MX (don't forget emails!), and TXT records.
Before you switch the nameservers, lower your TTL (Time To Live) to 300 seconds at least 24 hours in advance. This ensures that when you make the switch, global ISPs pick up the change instantly rather than caching the old IP for 48 hours.

3. The Redirect Chain Nightmare

You moved from http://website.com/old-post to https://website.com/new-post.
If your redirects look like http -> https -> www -> new-url, you are burning server resources and leaking PageRank with every hop.

The rule: Every old URL should 301 redirect to its final destination in exactly one hop.

How to audit: Write down your 10 most valuable URLs (highest traffic pages). Check their status codes.
You can use an HTTP header/status checker to see the exact response and how long it takes the server to respond. If it's a 301, ensure Location headers point directly to the final HTTPS URL.

4. The Pre-Migration Domain Vetting

If you are migrating to a brand new domain, buying a clean domain is half the battle. If the previous owner was running a PBN (Private Blog Network) or was penalized by Google, your traffic will never recover.

How to audit: Before you even pay for a domain, do a deep Whois lookup. You need to check the creation date, the registrar, and most importantly, whether the domain has been dropped and re-registered multiple times.
A quick RDAP lookup is usually enough to reveal the registration history. If it was created 3 weeks ago but has 10,000 backlinks, run away.

Summary Checklist

1. Lower DNS TTL 24 hours prior.
2. Verify A, AAAA, and CNAME records.
3. Ensure single-hop 301 redirects for all legacy URLs.
4. Crawl the entire new site to find dead internal links.
5. Submit the new sitemap.xml to Google Search Console immediately.

The Takeaway
A successful migration isn't a visual success; it's a routing success. Take 30 minutes to run these technical diagnostics before you hit "deploy" in production. Your organic traffic (and your client) will thank you.