Move a WordPress site to a new host, watch organic traffic drop 15–30% for three to five days, then recover. If you’ve migrated hosting recently, you’ve probably seen this pattern. The culprit isn’t downtime, broken redirects, or angry Google crawlers—it’s DNS Time To Live (TTL) settings interacting badly with search engine cache behavior.
Most solo operators treat host migration as a one-afternoon task: export database, move files, update DNS A record, wait. But DNS propagation isn’t instant, and search engines don’t immediately trust the new IP. The gap between those two realities creates a window where crawlers hit stale IPs, time out, or mark pages unreachable.
What TTL does during migration
DNS TTL tells browsers and crawlers how long to cache your domain’s IP address before checking again. If your TTL is set to 86400 seconds (24 hours)—a common default—and you migrate hosting, visitors and bots will keep hitting the old IP for up to a full day after you update DNS.
That’s fine for human visitors using browsers with retry logic. It’s terrible for search crawlers operating on tight schedules. Googlebot doesn’t wait around. If your old host shuts down the account before TTL expires, crawlers see timeouts. Timeouts signal unreliability. Unreliability triggers temporary ranking suppression while Google reassesses your site’s health.
The fix is simple but requires planning a week ahead: lower your DNS TTL to 300 seconds (five minutes) at least 48 hours before migration. This ensures that by the time you flip the DNS A record, cached lookups expire within minutes, not hours.
Why old hosts break this silently
Most shared and managed WordPress hosts auto-cancel accounts within hours of migration completion. You export your files, move DNS, and assume the old server stays online long enough for TTL to expire. It doesn’t.
If your old host deactivates your account six hours after DNS changes, but your TTL is still set to 24 hours, a large percentage of cached DNS lookups will resolve to a dead IP for the next 18 hours. Crawlers see repeated failures. Analytics show a sudden drop in organic sessions. By the time TTL expires and traffic recovers, you’ve already lost several days of visibility in search results.
Hosts rarely warn you about this because DNS management sits outside their direct responsibility—it’s handled by your registrar or a separate DNS provider like Cloudflare. The coordination gap means the problem only surfaces after migration is complete.
The pre-migration checklist
Start by logging into your DNS provider (Cloudflare, your registrar, or wherever your nameservers point). Locate the A record for your root domain and www subdomain. Check the TTL value—if it’s above 3600 seconds (one hour), lower it to 300.
Wait 48 hours. This gives the current high TTL time to expire across the internet’s DNS cache layers. If you skip this step and lower TTL five minutes before migration, the old 24-hour TTL is still active everywhere—your change won’t take effect in time.
Migrate your site. Update DNS A records to the new host’s IP. Keep the old hosting account active for at least 24 hours after DNS changes, even with the low TTL. This provides a safety buffer for any lagging DNS resolvers or aggressive caching layers.
Monitor Google Search Console’s crawl stats and Coverage report during the 72 hours post-migration. If you see a spike in server errors or timeouts, your TTL window was too short or the old host deactivated too early. You can’t fix it retroactively, but you’ll know what broke.
When managed hosts handle DNS
Some managed WordPress hosts—Flywheel, WP Engine, Kinsta—offer DNS management as part of their platform. If your domain’s nameservers point directly to your host, TTL control sits inside their dashboard, and migration becomes trickier.
These hosts typically manage TTL automatically, and you may not have manual override. The workaround: move DNS to a standalone provider (Cloudflare’s free tier works) at least a week before migration. Point your domain’s nameservers to Cloudflare, replicate all DNS records, lower TTL, then migrate hosting. It adds a step, but it gives you control over the timing.
If you’re migrating to a managed host that includes DNS, ask support whether they lower TTL automatically during migrations. Most don’t. If they can’t confirm, assume you need to handle it manually.
One operator I work with migrated a 40,000-session-per-month site from shared hosting to BigScoots in June. They followed the 48-hour TTL reduction, kept the old account live for 36 hours post-migration, and saw zero crawl errors in Search Console. Organic traffic dipped 4% for two days—within normal daily variance—then returned to baseline. Total cost of the precaution: two extra days of overlap billing at $6. Cost of not doing it: potentially two weeks of suppressed rankings while Google re-crawls and re-establishes trust.
If you’re planning a host migration in the next quarter, add “lower DNS TTL 48 hours early” to your runbook now. It’s the one step that prevents an invisible SEO penalty most operators don’t connect to hosting until it’s too late.
Have a hosting or infrastructure question you’d like covered? Reply to this email—I read every one.