You launched the new site on a Tuesday. On Thursday, Google announced a core update. Two weeks later organic traffic is down, the developers say the migration went perfectly, and the SEO tools blame the algorithm. Who is right?
Migrations and algorithm updates both cause ranking movement, and when they land in the same weeks, the two effects blur together. Google's own documentation on site moves warns that rankings can fluctuate while it recrawls and reindexes, which is exactly when an update can also be rolling out.
This guide gives you a practical way to separate migration losses (redirects, indexing, content and technical changes) from algorithmic losses, so you fix the right problem first.
Key Takeaways
- Google says site moves can cause ranking fluctuations while it recrawls and reindexes, and small to medium sites can take a few weeks for most pages to move.
- Check the migration first: redirect mapping, status codes, indexing of new URLs and parity of content, titles and internal links.
- Compare migrated URLs against pages or sections that did not change. If unchanged areas also fell, an update is more likely.
- Look at day-level timing against the Search Status Dashboard and your launch date.
- Avoid planning a migration during a known update rollout when you can choose the date.
Why migrations and updates are hard to separate
“With any significant change to a site, you may experience ranking fluctuations while Google recrawls and reindexes your site.”
— Google Search Central, Site moves with URL changes
Google's site move documentation also says a small to medium-sized website can take a few weeks for most pages to move, and larger sites take longer. Core updates typically take one to several weeks to roll out. So a migration and an update can easily occupy the same window. Both can reduce traffic, both can reshuffle rankings, and both show up as a dip in the same chart.
Google's troubleshooting guide for traffic drops lists site moves and algorithmic changes as separate causes. The job is to test each one with evidence, starting with the one you control.
Check the migration first
Migration faults are concrete, testable and fixable. Run through our website migration SEO checklist and confirm:
- Every old URL redirects with a permanent (301 or 308) redirect to the closest equivalent new URL, not to the homepage. See 301 versus 302 redirects.
- No chains or loops. Old URLs should reach the final page in one hop; see redirect chains.
- New URLs return 200 and are not blocked by robots.txt or noindex (staging settings often survive launch).
- Canonical tags point to the new URLs, not the old domain or staging.
- Content parity: main text, headings, titles, structured data and internal links carried over.
- XML sitemaps list the new URLs, and old sitemaps are retired once redirects are confirmed.
- Change of Address tool used in Search Console if the domain changed.
- Analytics and tracking installed correctly on all new templates.
“Keep the redirects for as long as possible, generally at least 1 year.”
— Google Search Central, Site moves with URL changes
Step-by-step diagnosis
- Set the timeline. Record the launch date and time, any follow-up releases, and the start and end dates of updates on the Search Status Dashboard.
- Rule out tracking. Compare Search Console clicks with analytics sessions. If Search Console is steady but analytics fell, the tag may be missing; see tracking errors versus ranking drops.
- Crawl the old URL list. Take every URL that had traffic or links before the move and confirm each one redirects once to a live, relevant page.
- Check indexing. In the Page indexing report and URL Inspection, confirm new URLs are indexed and old ones show "Page with redirect". Our guide to crawl stats and indexing after an update explains what to look for.
- Segment by change type. Group pages into: moved with no content change, moved with content or template changes, and not moved at all (if any).
- Compare segments. Look at clicks and impressions for each group before and after, using daily data.
- Compare query-level losses. Losses limited to moved URLs suggest migration. Losses across the board, including on queries for pages that did not change, suggest an update or demand shift.
- Look at the competition. If the same competitors gained across your whole topic area during the update, that points to an algorithmic reshuffle.
- Fix migration faults immediately. Then, once any update has completed and a week has passed, analyse the remaining loss as a possible update effect.
Migration loss versus update loss: the signals
| Evidence | Points to migration | Points to update |
|---|---|---|
| Start of decline | Within days of launch | During the update rollout, not linked to launch |
| Which pages fell | Moved pages, especially those with broken or wrong redirects | Moved and unmoved pages alike |
| Index status | New URLs not indexed, old URLs still indexed, wrong canonicals | Indexing looks normal |
| Crawl responses | More 404s, redirect chains, server errors | Mostly clean 200s and single redirects |
| Query pattern | Specific pages vanish for their main queries | Many queries slip a few positions |
| Competitors | Competitor positions largely stable | Broad reshuffle in your niche |
| Template or content changes | Losses concentrated on redesigned templates | Losses spread across templates |
Template-level losses can also be algorithmic if the redesign weakened content. Our guide to template-level update analysis helps separate design changes from update effects.
Common migration faults to check
| Fault | Symptom | Fix |
|---|---|---|
| Redirects to homepage | Deep pages lose rankings; soft 404 reports | Map each old URL to its closest equivalent |
| Staging noindex left on | New URLs "Excluded by 'noindex' tag" | Remove noindex, request indexing for key pages |
| Robots.txt blocking | "Blocked by robots.txt" for new sections | Correct the rules and resubmit sitemaps |
| Canonicals to old domain | Google chooses a different canonical | Update canonicals to the new URLs |
| Lost internal links | Important pages orphaned or buried | Restore navigation and in-content links |
| Missing content | Rankings fall for informational queries | Restore text, FAQs, structured data that were removed |
When both are to blame
Often the answer is "some of each". Fix every migration issue first, because those losses are within your control and often recover once Google recrawls corrected pages. Then treat the remaining gap like any other update analysis: compare against competitors, review content quality and wait for clean data. Our post on untangling overlapping updates uses the same segmentation approach, and what to do during a core update rollout explains why big extra changes mid-rollout make diagnosis harder.
Common mistakes
- Blaming the update without crawling old URLs. Redirect faults are the most common migration problem and the easiest to fix.
- Removing redirects too early. Google suggests keeping them for at least a year.
- Launching during a known update. When you control the date, avoid confirmed rollouts.
- Changing URLs, design, content and hosting at once. Each change adds a variable.
- Losing the pre-migration baseline. Export Search Console data and crawl the old site before launch.
Related Guides
- Should You Roll Back Site Changes After an Algorithm Update?
- Template-Level Analysis: Finding Which Page Types an Update Hit
- Diagnosing Update Impact Across Countries and Languages
Frequently Asked Questions
How long do rankings fluctuate after a migration?
Google says a small to medium-sized website can take a few weeks for most pages to move, and larger sites take longer. Fluctuation during that time is normal.
How can I tell if a core update or my migration caused the drop?
Compare migrated and unchanged pages, check redirects and indexing, and match the start of the decline to your launch date and the update dates on the Search Status Dashboard.
Should I roll back the migration?
Rarely. Fix redirect, indexing and content parity issues first. Rolling back adds another major change and more fluctuation.
How long should I keep redirects?
Google recommends keeping them for as long as possible, generally at least one year.
Is it bad to migrate during a core update?
It is not forbidden, but it makes diagnosis harder. If you control the date, avoid launching during a confirmed rollout.
Conclusion
When a migration and an update overlap, start with what you can prove: redirects, indexing and content parity. Fix those, then compare changed and unchanged pages to judge whether an update played a part. For the wider diagnostic process see our ranking drop recovery guide, and for a professional migration audit our SEO services team can help. You can also request a free quote.
