If your traffic dropped after you moved domains, changed your URL structure, switched CMS, or redesigned your templates, you are dealing with site migration traffic loss, and it has a short list of real causes. This piece walks through those causes in the order they usually turn out to be the problem, functioning as a migration seo checklist you can work top to bottom, so you can find yours and hand your team a specific fix instead of a vague "check the SEO." By the end you will know what to look at, how to confirm it in Search Console, and what a real fix looks like for each one.
This is the most common shape of site migration traffic loss: nothing about your product or content changed, but the technical plumbing between the old URLs and the new ones did, and that is almost always fixable once you know where to look. One thing worth saying up front: some ranking movement right after a migration is normal. Google has to recrawl and reprocess every URL that changed, and that takes time, more for a large site than a small one. What is not normal is a drop that stays flat for weeks, or one that only gets worse. If that is what you are seeing, work through the causes below in order, because they are ranked by how often they turn out to be the actual problem, not by how interesting or severe they sound.
The new site is blocked from Search
This is the first thing to rule out because it can wipe out an entire site's worth of pages in one move, and it is an easy mistake to make. Development and staging environments are usually built behind a robots.txt block or a blanket noindex tag so search engines do not index a half-finished site. If that block gets copied into production at launch, the new site goes live and nothing on it can be indexed.
What it looks like: your old site's pages fell out of Search, but the new URLs never showed up to replace them. Page indexing in Search Console reports URLs as blocked by robots.txt or marked noindex. Something similar happens with leftover authentication or IP restrictions from staging that quietly lock search engines out of a public site.
To confirm it, pull up a handful of important new URLs in URL Inspection and check three things: is crawling allowed, is indexing allowed, and what does the rendered page actually show. Then fetch your production robots.txt directly and read it line by line against what staging used. Search the page's HTML and response headers for a noindex directive too, since a page can look fine in the browser and still be carrying one.
The fix is to strip out the migration-only blocks: remove the blanket robots.txt disallow, remove staging noindex tags, and drop any authentication or IP rules that were never meant for the live site. Keep robots.txt for the narrow things you genuinely want excluded, and remember that robots.txt only stops crawling, not indexing. A URL blocked there can still surface in Search if something links to it, so use a proper noindex tag if you actually want a page out of results.
The redirect map is missing, wrong, or incomplete
Once the site is reachable, this is usually the biggest source of traffic loss, and it is the first thing to check on a domain change, a URL rewrite, or a large path change. A redirect mapping traffic drop shows up fast because it touches every old URL at once, not just a handful of pages. Old URLs that used to carry rankings, backlinks, and traffic need to land on the equivalent new page, and when that mapping is missing or careless, the signal that page had built up simply stops transferring.
The pattern to watch for as a redirect mapping traffic drop: old high-traffic URLs return a 404, a 500, or an unexpected page instead of a redirect. Or they redirect, but to the wrong product, the wrong category, or a generic homepage instead of the actual equivalent. Traffic to the old URL falls without a matching rise anywhere on the new site, which is the clearest sign the destination is wrong rather than just slow to recrawl.
To confirm it, build a list of your important old URLs from the old sitemap, your Search Console pages and queries with prior clicks, your analytics landing pages, and your backlink list. Request every one of them and record the status code, the redirect target, how many hops it takes, and whether that final destination is actually equivalent and indexable. Do this with a crawler or command-line tool rather than just clicking through a browser, since Google can see a different response than you do.
The fix is a row-by-row old-to-new URL map built before the migration, not patched together after. Send each URL to its closest relevant new page, never automatically to the homepage. Use a permanent 301 or 308, redirect straight to the final destination rather than chaining through several hops, and keep chains short if you cannot avoid them entirely. Do not use a temporary 302 for something that is permanent. And do not pull the redirects down the moment traffic looks like it is coming back. Search Console's own Change of Address guidance says to keep them live for at least 180 days, and longer if traffic is still landing on the old URLs, while the broader site-move guidance recommends at least a year where you can manage it.
Pages return 404, soft 404, or server errors
Sometimes the redirect exists but the page it points to is broken. Content that was deleted during a CMS migration without a replacement, a page that technically loads but shows a generic "not found" template, or a server that is timing out under the new hosting setup all produce the same result: the page Google is supposed to index simply is not there.
What it looks like: Page indexing shows a spike in "Not found" or server-error categories. A page returns a successful status code but the body is an empty or generic error page, which is what makes a soft 404 more dangerous than an honest one. Server or CDN logs show 4xx or 5xx responses, timeouts, or firewall denials specifically for the crawler, even while your own browser loads the page fine.
To confirm it, check both the actual HTTP response code and what is actually in the response body, since those can disagree. Look at server and CDN logs for error and timeout patterns. Confirm the content still exists in the new CMS at all, and whether it is linked and included in the new sitemap.
A 404 by itself is not automatically wrong. Content you genuinely removed with nothing to replace it can return a clean 404 or 410 and that is fine. The fix only applies where a page moved or should still exist: restore anything accidentally deleted, redirect genuinely moved pages to their closest replacement, and fix the underlying server, CDN, or firewall issue causing the errors rather than papering over it with a redirect.
Canonicals, sitemaps, and redirects disagree with each other
This one is subtler because nothing is technically broken. Every individual piece works, but they are not all pointing at the same URL. A canonical tag references an old path, the sitemap lists a URL that itself redirects, internal links still point at the old address while the canonical says otherwise, and Google ends up choosing a different version of the page than the one you intended.
What it looks like: Search Console's Page indexing report shows "duplicate without user-selected canonical" or "duplicate, Google chose a different canonical." New pages are indexed only as an alternate or duplicate rather than the primary result. HTTPS and HTTP, www and non-www, or trailing-slash variants are all still competing after the move instead of one version clearly winning.
To confirm it, take an important new URL and compare four things side by side: the final redirect destination, the canonical tag you declared, the canonical Google actually selected in URL Inspection, and the URL as it appears in your sitemap. When those four disagree, you have found the problem.
The fix is to make every signal agree on one preferred version. Put a self-referencing canonical on the real page, link to it internally using that same URL rather than an old one that redirects, and only list canonical, indexable URLs in your sitemap. Redirects, canonical tags, and sitemap entries are ranked signals in that order of strength, so when they conflict, the redirect usually wins, which is exactly why a stray old-URL redirect can quietly override a correct canonical tag elsewhere.
Internal links and navigation no longer expose the pages
A page can be live, indexable, and correctly canonicalized and still lose rankings if nothing on the site links to it anymore. Migrations often rebuild navigation, breadcrumbs, and related-content modules from scratch, and it is easy for a page to come through technically fine while quietly dropping out of the click paths that used to lead to it.
What it looks like: important pages are in the sitemap but not reachable through normal navigation. Internal links across the site still point at old URLs and rely on a redirect to get the visitor where they are going. Buttons that used to be crawlable links became JavaScript-only interactions with no real href. Rankings tend to fall hardest for exactly these pages, more than for pages with a straightforward redirect problem.
To confirm it, crawl the new site and compare the internal link count for each important page against what it had before the migration. Check whether the links pointing to a page use its new canonical URL or an old one, and whether the navigation, breadcrumbs, and category structure still expose the same hierarchy they used to.
The fix is to restore real internal links using the current, canonical URLs, and rebuild whatever breadcrumbs or related-content modules disappeared. Make sure every important page is reachable from at least one other crawlable page, using descriptive anchor text rather than generic. There is no target link count to hit here; the goal is that a page a crawler used to reach easily can still be reached just as easily.
A domain move was never fully registered with Search Console
If your migration involved a domain or subdomain change, there is a Search Console step that is easy to skip or get wrong, and skipping it slows down how fast Google treats the new domain as the real one. This is specifically about domain migration ranking loss, not the technical redirect itself; the redirects can be perfect and this step can still be missing. A stalled Change of Address is one of the few causes on this list that is purely a Search Console problem rather than a site problem.
What domain migration ranking loss looks like: the old site redirects correctly, but the new domain is slow to take over in Search results. Only some host or protocol variants of the old domain were verified as properties. The Change of Address tool fails its pre-move checks, or traffic seems to be transferring for some URL variants but not others.
To confirm it, check that every relevant variant of the old domain, including www, non-www, and both protocols, is verified as its own property in Search Console. Confirm the redirects were actually live before you submitted anything.
The fix is to use the Change of Address tool, and only for an actual domain or subdomain move; it is not the right tool for an HTTPS switch, a path change, or a hosting move where the URLs themselves did not change. Both the old and new properties need to be owned by the same account, redirects need to be live first, and any pre-move check failures need fixing before you continue. Once submitted, keep monitoring both properties rather than assuming the new one instantly replaces the old.
Templates, rendering, or content changed along with the URLs
Sometimes every URL-level thing checks out and the drop is still real, because the migration changed what is actually on the page. A template redesign that quietly dropped headings, structured data, or body copy; a JavaScript-heavy rebuild where Google's rendered version does not match what a visitor sees in a browser; a mobile template that carries less content than desktop now does. A redirect cannot preserve a ranking for content that was materially removed or replaced along the way.
What it looks like: URLs and redirects are correct, but rankings fall specifically for pages whose titles, headings, body content, or structured data changed. Search impressions stay roughly the same but click-through rate drops, which usually points at a title or snippet change rather than a ranking change. The drop clusters around one template family, one content type, or one device rather than the whole site.
To confirm it, use URL Inspection's live test and rendered screenshot to see what Google is actually reading off the page, and compare that against what you see in a normal browser. Check Search Console's performance filters by device and page to see whether the pattern is template-specific.
The fix here is different from the others: restore content and metadata that were unintentionally dropped, and make sure primary content is actually present in the rendered HTML rather than only appearing after a script runs. But be honest that a technical fix cannot recover a ranking for content whose meaning genuinely changed. If the new page answers a narrower or different question than the old one did, no redirect fixes that.
When none of these match what you are seeing
If you have checked robots and noindex, redirects, error pages, canonicals, internal links, and Search Console registration, and everything genuinely checks out, step back before assuming something more exotic broke. First confirm the drop is actually organic Search traffic and not an analytics or attribution change that happened to land at the same time as the migration; compare Search Console clicks and impressions directly rather than trusting analytics sessions alone. Then segment the decline by page, query, device, and template to see if it clusters somewhere specific. Compare the new page's actual content against the old one, since a technically clean migration can still change what a page says. And check whether the timing lines up with something unrelated, like a broader ranking-system change or a shift in demand, rather than the migration itself. At that point, pull in a technical SEO specialist to crawl both URL sets and reconcile the exceptions directly, and keep your redirects live while that investigation runs.
What a realistic recovery looks like
Recovery is not a matter of waiting it out. It is a reconciliation problem: every URL that used to earn traffic needs a relevant, accessible, indexable new home, and your redirects, canonicals, sitemap, and internal links all need to agree on where that home is. Once those signals actually line up, Search Console, server logs, and a fresh crawl are how you confirm old URLs are being replaced by the right new ones instead of just disappearing.
Treat this as a migration seo checklist you work in order of impact, not a list you tackle alphabetically. If you are building your own version, keep it in this order: get the new site itself unblocked first, fix the redirects for your highest-value old URLs next, then chase down broken destinations, then align canonicals and sitemaps and internal links, then rebuild anything missing from navigation, then check templates and rendering, and only then worry about long-tail URLs and external references you do not control. Attach every fix to an actual URL sample and what you expect to see change, and keep monitoring rather than repeatedly requesting a recrawl on the same handful of pages. Google gives no guarantee on timing, but small and medium sites typically see most of this settle within a few weeks once the underlying signals actually agree, and that is the point to expect to recover traffic after migration rather than before. Most teams that recover traffic after migration successfully are the ones that worked this list in order instead of chasing whichever symptom looked most alarming that week.
