A clean migration dips for two to four weeks and is back to its previous level within four to eight. The shallowest point usually falls in the first fortnight, recovery becomes visible in week three, and larger sites take longer simply because recrawling a large site takes longer. WPBuildAI grades a launch on crawl coverage rather than on rankings, for one practical reason: coverage moves within days while rankings move over weeks, so coverage tells you whether recovery is coming while there is still time to fix something. Here is the normal curve, the abnormal one, and how to tell them apart before you have lost a quarter.
Why is there a dip at all?
Because nothing about a migration is instant on Google’s side, and the delay is mechanical rather than punitive.
When an address changes, Google has to recrawl the old URL, see the redirect, fetch the new one, evaluate it, and transfer the signals attached to the old address. Google’s documentation on site moves with URL changes describes this as a process that takes time and depends on recrawl rate. It happens per URL rather than per site, so a 400 page site is 400 separate small processes on different schedules.
Recrawl rate is the limiting factor and it is not uniform. Your homepage and most linked pages are recrawled often, sometimes daily. A service page in the navigation might be recrawled weekly. An old post with two internal links might be recrawled monthly or less. That distribution is why recovery arrives in layers, and why the total looks like a curve rather than a step.
What does the normal recovery curve look like?
Down in weeks one and two, turning in week three, back to baseline between weeks four and eight. Find your week below.
| Period | What you should see | What it means | Action | Verdict |
|---|---|---|---|---|
| Days 1 to 3 | New URLs crawled, old URLs reporting redirects | Google found the move | Submit the new sitemap | On track |
| Week 1 to 2 | Impressions down 10 to 30 percent, rankings wobbling | Recrawl in progress, signals in transit | Change nothing | Normal, hold |
| Week 3 | Impressions recovering, important pages near old positions | Signal transfer working | Fix any unmapped URLs found | Recovery started |
| Week 4 to 8 | Long tail returning, total at or above baseline | Recrawl reaching deep pages | Resume normal publishing | Complete for most sites |
| Past week 8, flat | Coverage errors, unindexed pages | A fault, not a wait | Diagnose immediately | Something is broken |
Impressions move before clicks, because impressions respond to position changes faster than click behavior does. And rankings recover unevenly, so a spot check of three keywords in week two tells you almost nothing.
Why should you watch coverage instead of rankings?
Because coverage answers the question within days, while ranking data stays noisy for a fortnight. This is the single most useful habit after a launch.
In Search Console, the page indexing report tells you how many URLs are indexed, how many are excluded, and why. After a migration the pattern you want is straightforward: new URLs moving into the indexed group, old URLs appearing as pages with redirects, and nothing significant sitting under not found.
That pattern appears within days, long before ranking data means anything. If it looks right, the dip is mechanical and waiting is correct. If it does not, waiting will not help, and every day of waiting is a day of lost traffic a twenty minute fix would have prevented. The week by week routine is in what to check in Google Search Console after a migration, and the launch sequence in what to do in the first week after a migration goes live.
How does recovery differ by page type?
Sharply, and reading it this way prevents a common false alarm where two opposite movements average to a flat line.
| Page type | Recrawl speed | Typical recovery | Check this if it lags |
|---|---|---|---|
| Homepage and navigation | Days | Usually never drops | Canonical pointing at the old domain |
| Money pages | Days to a week | Back by week three | Redirect target relevance |
| Blog archive | Weeks | Weeks four to eight | Unmapped URLs in the not found list |
| Images | Weeks to months | Eight to twelve weeks | Whether image files were redirected at all |
Image URLs change during a rebuild almost by default, and image search positions reset when files move without redirects. That recovery is the slowest of all, and it only happens if the redirects exist, which is covered in how to migrate WordPress images and media without broken links.
What actually slows recovery down?
Five causes account for nearly every migration that fails to recover on schedule, and all five are findable in the first fortnight.
Missing redirects are the largest. Old addresses returning not found lose whatever they had earned, permanently rather than temporarily, and Google’s redirect guidance is explicit that a permanent redirect is how a URL change gets communicated. The mechanics are in do 301 redirects preserve SEO when changing platforms.
Redirect chains work in a browser and cost crawl efficiency, so map old addresses directly to final destinations. Thinner content is the cause people misdiagnose most often, because the page looks better while containing less of what it ranked for. Crawl blocks left over from staging are a five minute fix that costs weeks if nobody checks. And slow responses reduce crawl rate, since Google adjusts to what a server can comfortably serve, a behavior documented in its crawl budget guidance for large sites.
How much does site size change the timeline?
More than anything else, and no amount of correctness makes a large site recrawl faster.
A twenty page site can be fully recrawled in days. A five thousand page site cannot. For small sites, four to six weeks to full recovery is typical. For sites in the low thousands of pages, six to twelve weeks. For very large sites, a phased move usually beats a single cutover, because it keeps the recrawl load in a range Google processes promptly, which is part of why timelines behave the way they do in how long does a website migration take.
Three actions help without gaming anything. Submit an accurate sitemap of the new URLs immediately. Keep the old sitemap reachable for a while so old URLs get recrawled and their redirects discovered. And make internal links point at new addresses directly rather than through redirects.
What can you do to help it along?
Four things, and they are the only four inside your control. Everything else is patience.
Submit the new sitemap on day one and keep the old one reachable. The new sitemap tells Google what exists now. The old one keeps the retired addresses in the recrawl queue so their redirects get discovered rather than waiting for a crawler to stumble across them.
Point internal links at final addresses. Links that travel through a redirect still work and waste crawl budget on every hop, and on a large site that compounds. This includes links inside old blog posts, which is the tedious part everyone skips and the part that most improves crawl efficiency.
Keep the server fast during the recrawl window. Google adjusts crawl rate to what your server comfortably serves, so a slow origin in the weeks after launch directly reduces how many URLs get processed per day. This is one of the quiet advantages of a static rebuild: response time stops being a variable at exactly the moment it matters most.
Leave the redirects alone. Rules that change during the recovery period reset progress for the affected pages, because each change means the previous signal transfer has to be reinterpreted. Fix genuine faults, and resist the urge to tidy.
What does not help: resubmitting URLs repeatedly, requesting indexing for hundreds of pages by hand, or publishing a burst of new content to signal freshness. None of those changes the recrawl schedule, and the last one adds pages to a queue that is already the bottleneck.
What does recovery not include?
Improvement. A migration does not raise rankings by itself, and expecting it to is how a normal outcome gets read as a failure.
If the same content is served faster on cleaner markup, you may see modest gains once things settle, and you should not plan around them. Pages that ranked badly before will rank badly after, in a nicer typeface.
Not every post migration change is caused by the migration either. Google ships ranking updates continuously, competitors publish, and seasonality is real. Google’s guidance on debugging search traffic drops starts by separating those causes, and it is worth doing before concluding the move was the problem, as covered in will I lose Google rankings if I change my website platform.
When is waiting the wrong response?
From week four onwards, if coverage still looks wrong. Before that, waiting is correct and interfering is harmful.
If by week four your new pages are indexed, old URLs resolve as redirects, and impressions are climbing, keep waiting and do nothing. Changing URLs again, rewriting pages, or adding redirects that were not needed is how a recovering site gets pushed back to the start.
If by week four the coverage report still shows unindexed new pages, unresolved old ones, or a large group of not found errors, stop waiting. Export the not found list, compare it against your redirect map, and you will usually find one whole category nobody mapped: paginated archives, tag pages, image files, or a parameter pattern. The file that should have caught it is described in what is a redirect map and how do you build one, and the archive specific case in how to move WordPress blog posts without losing rankings.
Key takeaways: what recovery actually looks like
A clean migration dips in weeks one and two, turns in week three, and is back within four to eight weeks. Larger sites take longer for mechanical reasons rather than because anything is wrong.
Coverage is the leading indicator and rankings are the lagging one. New URLs indexed and old URLs reporting redirects within days means recovery is coming, whatever the ranking data says that week.
Five causes explain almost every failed recovery: missing redirects, chains, thinner content, staging crawl blocks, and slow responses. All five are findable in the first fortnight if someone looks.
Week four is when waiting stops being patience and starts being neglect. Clean coverage means hold your nerve, and broken coverage means diagnose today, because it will not resolve on its own.
Quick answers
How long does it take to recover rankings after a migration? Four to eight weeks for a typical small site with permanent redirects and preserved content, with the shallowest point falling in weeks one and two and recovery becoming visible in week three. Larger sites take longer, because recrawling a large site takes longer and nothing speeds that up. WPBuildAI grades launches on crawl coverage rather than on rankings, because coverage moves within days and tells you whether recovery is actually coming.
Is a traffic drop after a migration normal? A shallow, brief one is entirely normal. Google has to recrawl every changed address, follow each redirect, and transfer the signals attached to the old URL, and none of that is instant. What is not normal is a drop that keeps deepening after week three, or one concentrated on your most valuable pages while everything else holds steady.
How do I tell a normal dip from a real problem? Look at coverage rather than rankings. If Search Console shows your new URLs being crawled and indexed and the old ones marked as redirected, the dip is mechanical and it will pass on its own. If new URLs are not being indexed, or old ones are reported as not found, you have a fault to fix rather than a wait to endure.
What makes recovery take longer than it should? Missing or chained redirects, URLs that changed without a map, pages that arrived thinner than the originals, a robots rule or noindex tag left over from staging, and slow server responses that reduce crawl rate. Site size matters too, since Google recrawls a large site over weeks, so the same fix propagates more slowly across it.
When should I worry that rankings are not coming back? If by week four the coverage report still shows unindexed new pages or unresolved old ones, stop waiting and start diagnosing, because time alone does not fix a missing redirect. The most common cause we find at that point is a whole group of URLs nobody mapped, usually paginated archives, tag pages, or image files.
