Post-Migration SEO Recovery: A 90-Day Plan
On this page
Every other article in this cluster is about preparation. This one is about the ninety days afterwards, which is where migrations are either confirmed successful or quietly lost.
The pattern we see repeatedly: a migration launches, everyone is relieved, attention moves to other work, and nobody is specifically watching. Traffic drifts down in week five. By week ten someone notices. By then the cause is harder to diagnose, the decline has compounded, and what would have been a two-day fix has become a recovery project.
So this is a schedule. It also covers the harder case: what to do when the numbers do not come back.
First, what is normal
You need this calibration before you can interpret anything, because reacting to normal volatility causes its own damage.
Weeks 1–2: expect movement. Google is recrawling, following redirects, and reprocessing your URL set. Rankings fluctuate, impressions move, and traffic commonly dips 10–20%. Search Console will show a spike in crawl activity and some temporary coverage oddities. This is the system working, not failing.
Weeks 3–4: expect recovery to begin. The trend should be upward. Rankings should be stabilising, and your most important pages should be returning toward their previous positions.
Weeks 5–8: expect baseline. Traffic should be at or near pre-migration levels. If you also improved speed or structure, it may be above.
Weeks 9–12: expect stability or growth. The migration should no longer be visible in your data.
What is not normal at any point: new 404s appearing in Search Console, redirect chains, staging canonicals on production URLs, pages excluded by noindex you did not set, a specific set of pages that never recover while everything else does, or a decline that deepens after week four. None of those are volatility, and none resolve themselves.
The distinction matters because the correct response to volatility is patience and the correct response to a defect is immediate action. Confusing the two in either direction is costly.
Week 1: verify, do not optimise
The priority is confirming the migration is technically sound. Change nothing else.
Crawl production immediately and diff against your pre-migration crawl. Compare URL coverage, titles, H1s, canonicals, and word counts. Word count differences are your best indicator of content that did not survive.
Run your full redirect map through a bulk checker. Every entry should return one 301 to a 200. Any 404, 302, chain, or loop is a defect to fix today.
Check Search Console coverage daily. New 404s, new exclusions, and crawl anomalies.
Validate structured data on every template type.
Confirm robots.txt and meta robots are correct on production, and that staging is blocked.
Submit your new sitemap and keep the old one available for now.
Verify tracking is firing. Analytics, ad pixels, and conversion events. Broken conversion tracking is silently expensive and easy to miss for weeks.
Test the customer journey on mobile, including a real order.
Resist the urge to improve anything. Every change you make this week is a variable that complicates diagnosis later. Stabilise first.
Weeks 2–4: monitor and fix defects
Set a weekly recurring task with a named owner. Not “we will keep an eye on it”. The single biggest predictor of migration recovery is whether one person has this in their calendar.
Weekly review: Search Console performance by page for your priority URLs, coverage report for new issues, crawl stats, organic landing pages in analytics against your baseline, and Core Web Vitals.
Track your tier one URLs individually. The few hundred pages carrying most of your traffic. Aggregate numbers hide the situation where your top twenty pages have collapsed while long-tail growth masks it.
Fix defects as you find them, and keep a log of what you changed and when. You will need this to interpret what happens next.
Still do not optimise. Not new content, not rewritten titles, not structural changes. You are establishing whether the migration worked, and you cannot do that while changing things.
Watch conversion as well as traffic. Some migrations hold rankings and lose conversion — usually a filtering, navigation, or page-content problem rather than an SEO one. Traffic-only monitoring misses this entirely, and it is a common failure in platform-to-platform moves.
Weeks 5–8: diagnose if recovery has not happened
If you are at or above baseline, monitoring continues and you can begin normal improvement work. If you are not, this is the diagnostic sequence, in order.
Is it all pages or specific pages? Pull organic traffic by landing page, before and after. If a specific set is down while the rest is fine, you have a specific problem — usually a page type, a template, or a content category. That is good news, because it is findable.
Are the affected pages indexed? Check directly in Search Console’s URL inspection for a sample. Not indexed means a technical problem: redirect, canonical, noindex, or crawl issue.
If indexed, is the content the same? Compare against your pre-migration capture. This is where most unexplained declines live. Pages that return 200, are indexed, and contain a third of their previous content will lose rankings, and nothing in your redirect audit will reveal it.
Are the redirects correct for those URLs specifically? Not the map in aggregate — those URLs. Check for chains, and check that the destination is equivalent rather than a convenient parent.
Did titles or H1s change? Even small changes to pages ranking on exact phrases matter. Compare against your capture.
Is internal linking intact? Pages that lost internal links lose authority. Check whether the affected pages are still linked from where they used to be — navigation, related blocks, contextual links in content.
Did structured data change? Lost review schema causes traffic loss through click-through rather than ranking, so your position reports look fine while traffic falls. Check whether star ratings still appear in search results for affected pages.
Did speed regress? Compare Core Web Vitals against your baseline, on mobile.
Are you sure it is the migration? Check whether a Google update landed in your window, and compare against your category’s general trend if you have visibility. Attributing an algorithmic shift to your migration sends you looking for a defect that does not exist.
In our experience the ranked causes are: content loss during rebuilding, incomplete or poor-quality redirects, lost structured data, lost internal linking, and speed regression. Content loss is first by a wide margin and is the one people check last.
Weeks 9–12: recover or rebuild
If diagnosis found specific causes, fix them and expect four to eight weeks for recovery to show. Search engines need to recrawl, reassess, and re-rank.
Fix in order of traffic value. Your highest-traffic affected pages first.
Restore content properly. Full length, from your capture, backups, or the Wayback Machine. Not an approximation — the actual content.
Rebuild internal links to the affected pages.
Fix redirects to point directly at correct equivalents, flattening any chains.
Restore structured data and verify with a testing tool.
Then request indexing for your most important fixed pages through Search Console. It does not guarantee speed but it does help.
Document what happened. Genuinely useful next time, and useful for whoever inherits the site.
If you cannot identify a cause and traffic remains meaningfully down, that is the point to bring in someone who does this specifically. A technical audit from someone who has diagnosed migration losses before will usually find it, because the causes are a known and fairly short list.
A worked example: found in week six
A pet supplies retailer migrated and monitored properly. Weeks one and two showed the expected dip. Week four should have shown recovery and did not — traffic sat around 18% below baseline.
Segmenting by landing page took an hour and found the answer. Product and collection traffic had fully recovered. Blog traffic was down 60%.
The blog posts were indexed and returned 200. Redirects were correct. Titles were unchanged.
The content was 40% shorter. During the theme and platform work, posts had been reimported through a process that dropped their formatted sections — bulleted lists, comparison tables, and embedded images had not survived, and someone had tidied the resulting mess by trimming.
They restored the full content from their backup across 140 posts over two weeks. Blog traffic recovered over the following six weeks and finished slightly above where it started.
Total elapsed damage: about ten weeks of reduced traffic. Had nobody been monitoring by landing page, this would have been discovered in month four or five, by which point the rankings would have decayed further and recovery would have taken considerably longer.
The diagnosis was an hour of segmentation. The reason it happened in week six rather than week twenty was that someone had a weekly recurring task.
What to do when it will not recover
Occasionally a migration causes lasting damage — usually where redirects were wrong or absent for months, or where substantial content was lost and cannot be recovered.
Accept the situation and change strategy. At some point continued diagnosis stops paying and rebuilding starts. Recognising that moment is a judgement call, but if you have been at it for six months with no identified cause, you are probably there.
Rebuild the content that mattered. If your best pages are gone and unrecoverable, write them again, better. You know what they ranked for, which is more than you knew the first time.
Reclaim your backlinks. Identify external links pointing at URLs that broke, and contact the linking sites with the correct destination. Tedious, effective, and routinely ignored.
Focus on what the migration improved. If your store is faster and better structured, that is a foundation. Build on it rather than mourning the old site.
Invest in the channels you control. Email, retention, and paid acquisition while organic rebuilds. This is where a migration’s damage is survivable rather than fatal.
Treat it as a rebuild with better information. You have your old crawl, your old performance data, and knowledge of what worked. That is a considerably better starting position than a new site.
The monitoring setup, concretely
Rather than leaving “monitor for ninety days” as an instruction, here is what the weekly hour actually consists of.
Search Console, performance report. Compare the last seven days against the equivalent period before migration, filtered to web search. Look at clicks, impressions, and average position. Then switch to the pages view and sort by clicks to see which pages moved. Save this as a bookmarked view so you are not rebuilding the filters weekly.
Search Console, coverage report. Check the “Not indexed” section for categories that have grown: 404s, redirect errors, pages excluded by noindex, crawled but not indexed, and discovered but not indexed. New entries in any of these warrant investigation. Pay particular attention to soft 404s, which is where inappropriate redirect destinations reveal themselves.
Search Console, crawl stats. A large sustained increase in crawl activity paired with an increase in non-200 responses points to a redirect problem. Also check for any spike in server errors.
Analytics, organic landing pages. Compare against your pre-migration baseline for the same day count. Sort by the largest absolute losses rather than percentages, since a 90% drop on a page with four visits does not matter and a 15% drop on your top collection does.
Core Web Vitals, from Search Console’s report where you have enough data, or PageSpeed Insights on your three main page types with the mobile setting.
Conversion rate by device and page type, from analytics. This is the check that catches migrations which held their rankings and lost their usability.
Your tier one URL list. Keep the few hundred priority URLs from your pre-migration classification in a spreadsheet, and spot-check a rotating sample each week rather than all of them. Over ninety days you will have covered the list several times.
A simple log. Date, what you observed, what you changed. Three lines a week. When something unexpected happens in week nine, this log is how you work out what preceded it.
Setting expectations with stakeholders
A practical problem that causes real damage: someone senior sees a traffic dip in week two and demands action, and the resulting panic changes produce genuine harm.
Explain the expected curve before launch, in writing. A dip of 10–20% in the first fortnight, recovery beginning week three, baseline by weeks five to eight. If people know this is expected, week two produces questions rather than emergencies.
Distinguish volatility from defects explicitly. Tell stakeholders in advance what would actually warrant concern — new 404s, a deepening decline after week four, specific pages that never recover — so that the conversation has an agreed threshold rather than being about who feels more anxious.
Report weekly, briefly, whether or not there is news. A three-line update every week builds confidence and prevents the vacuum that speculation fills. It also means bad news arrives in a familiar format rather than as an alarm.
Resist the pressure to optimise during the volatility window. This is the hard one, because doing something feels better than waiting. Explain that changes made now destroy your ability to diagnose, and offer a date when improvement work resumes.
Do not promise a specific recovery date. You control the technical quality of the migration; you do not control how quickly search engines recrawl and reassess your pages. Give the expected range, explain what it depends on, and report against it each week rather than committing to a date you cannot influence.
Have the conversation about paid cover before you need it. If organic dips as expected, some businesses want to bridge with paid spend. Deciding that in advance is calmer than deciding it in week two.
The bottom line
Assign one person a weekly recurring task for ninety days. That single practice prevents most migration losses from becoming permanent, and its absence is the common factor in almost every recovery project we take on.
Know what normal looks like: volatility for two to four weeks, recovery by week five to eight, stability after. Anything else is a defect, and defects have a short list of causes — content loss first, then redirects, structured data, internal linking, and speed.
Verify in week one and change nothing else. Monitor by landing page, not just in aggregate, because segmentation is what turns an unexplained decline into a findable cause. And when you do find it, fix it properly and give it six weeks.
Migrations that are watched recover. Migrations that are launched and forgotten are the ones that cost a year of organic traffic.
Frequently asked questions
How long does it take for traffic to recover after a migration?
Expect two to four weeks of volatility while Google recrawls and reprocesses your URLs, recovery beginning by week three or four, and a return to baseline by weeks five to eight. By weeks nine to twelve the migration should no longer be visible in your data, and if you also improved site speed or structure you may be above your previous level. A decline that deepens after week four, or a specific group of pages that never recovers while everything else does, is not volatility — it is a defect, and defects do not resolve on their own.
My traffic dropped after migration — what should I check first?
Segment by landing page before anything else. Pull organic traffic per page for the period before and after, and identify whether the loss is spread across everything or concentrated in a specific group. Concentrated loss is good news because it is findable — usually a page type, a template, or a content category. Then for the affected pages check in this order: are they indexed, is the content the same length as before, are the redirects correct and free of chains, did titles or H1s change, is internal linking intact, and did structured data survive. Content loss is the most common cause and the one people check last.
What is the most common cause of post-migration traffic loss?
Content that did not survive the move. Pages redirect correctly, return a healthy 200 status, and are properly indexed — but contain a fraction of what they used to, because they were rebuilt manually and got shortened, or because section-stored content was not recreated, or because an import stripped formatting and someone tidied the result by trimming. Nothing in a redirect audit reveals this, which is why it goes undetected for months. Comparing word counts against a pre-migration crawl is a crude check that catches almost all of it in an afternoon.
Should I make SEO improvements right after migrating?
No — wait until things have stabilised, typically four to six weeks. Every change you make during the volatility period is another variable, and if traffic moves you will not be able to tell whether the cause was the migration, your change, or ordinary fluctuation. Fix genuine defects immediately, since those are not optional, but hold new content, rewritten titles, structural changes, and design tweaks. Once you are back at baseline and confident the migration is sound, resume normal improvement work with a clean picture to measure against.
Who should monitor a migration, and how often?
One named person, with a weekly recurring task in their calendar for ninety days. This is the single strongest predictor of whether a migration recovers, and its absence is the common factor in nearly every recovery project. “We will keep an eye on it” reliably means nobody does, because attention moves to other work within a fortnight of launch. The weekly review is roughly an hour: Search Console performance for priority pages, the coverage report for new issues, organic landing pages against baseline, Core Web Vitals, and conversion by device.