Every year we get three or four calls opening with the same sentence: "we changed the website a month ago and we have lost half our traffic." And nearly always with the same follow-up: "the design agency says SEO recovers on its own."
It does not recover on its own. What happens in most of these cases is that three to ten years of accumulated signals were destroyed in a single night: URLs Google knew, authority concentrated on specific pages, external links pointing at paths that now return 404, content that vanished in the redesign because "it was too much text".
The good news is that a migration is one of the few SEO processes you control almost entirely. It does not depend on competitors or on an algorithm: it depends on a checklist executed in order. This article is that checklist, as we run it at ValenciaSEO, with the three phases and the points where traffic genuinely gets lost.
The word suggests a large project, but the risk shows up in changes many teams consider minor.
| Change | Risk | Critical point |
|---|---|---|
| Domain change | High | Redirects and signal consolidation |
| Platform or CMS change | High | URL structure and content loss |
| Redesign keeping the same structure | Medium | Removed content and internal linking |
| Category reorganisation | High | Redirect map and new cannibalisation |
| HTTPS or www change | Low if done properly | Redirect chains and mixed resources |
| Adding languages | Medium | Hreflang, canonicals and duplication |
The "just a redesign" that keeps the URLs. Since nobody touches paths, nobody calls the SEO. And in the process two thousand words per page disappear, the menu is trimmed "to keep it clean" and two hundred internal links go with it. The URLs are still there; what Google valued is not.
The project is won or lost here. Anything you fail to capture now is unrecoverable later.
If you cannot find an equivalent destination for a critical URL, the problem is not redirects: the new site fails to cover something the old one covered. Fix it by building the page, not by redirecting somewhere convenient.
On deployment day the work is verification, not creation. These are the five points we always check, in this order, within the first hour.
robots.txt and meta robots. The industry's most repeated error: staging carried Disallow: / or a global noindex and shipped as-is. Check it before anything else because it invalidates everything else.
Redirects genuinely work. Existing in a config file is not enough. Test the fifty critical URLs one by one and confirm they return 301 — not 302, not 200 with different content — and land on the destination in a single hop. Chains of three redirects dilute and slow.
Correct canonicals. Each page pointing at itself, not at the old version or a staging domain. A canonical pointing at staging is a classic that can deindex an entire site.
Sitemaps regenerated and submitted. With the new URLs, without the old ones. A sitemap where half the entries return 301 is a carelessness signal.
Internal linking rebuilt. Confirm critical pages still receive internal links from where they used to. This is the most forgotten point and it explains many "inexplicable" drops in redesigns that kept their URLs.
Once everything is verified, submit the new sitemap and the critical URLs for indexing, and watch the bot log for the first few days. The sooner Google crawls the redirects, the sooner signals transfer and the shorter the dip. It is one of the few moments where fast indexing changes the outcome tangibly.
This is where most projects declare themselves finished and where the useful work actually begins. What to watch, and how often:
| When | What to check | What to expect |
|---|---|---|
| Days 1-3, daily | 404 errors, bot visits, indexing of critical URLs | Bots crawling actively; a controlled, declining 404 spike |
| Week 1 | Clicks and impressions per URL against baseline | A 10-25% drop. Normal, and no reason to revert anything. |
| Weeks 2-4 | Positions across the query set | High fluctuation, progressive recovery |
| Week 4 | Full comparison against the before | 70-90% of traffic recovered |
| Week 8 | Final assessment | Previous level or better; if not, there is a specific problem to locate |
On patience: the temptation to intervene in week two is enormous and almost always counterproductive. If the launch checks were clean, what you see in those weeks is reprocessing, not damage. Intervening blind — reverting, changing canonicals, editing redirects — lengthens the process rather than shortening it. The exception is a technical fault identified with data: fix that the same day.
Most migrations that go wrong do not fail through technical ignorance. They fail on scheduling and on who owns what, and this is worth saying because it is the part a single meeting can fix.
The usual pattern: the redesign kicks off in January, SEO hears about it in March, and the launch date is already committed to the board. When the request arrives for two weeks of inventory and redirect mapping, the answer is that there is no room. It ships anyway, traffic drops, and in April someone is hired to fix it for considerably more than prevention would have cost.
Three agreements avoid nearly all of this. First: SEO joins the project when design does, not when the site is finished. Its early-phase job is not to comment on colours; it is to protect the pages that generate business and to flag when a structural decision is expensive. Second: access to a real staging environment, with final content and blocked from crawling, at least two weeks ahead. Auditing mockups is useless; faults surface once the content is in. Third: nobody launches on a Friday or the day before a holiday. It sounds trivial and it is the reason an inherited noindex lives three days in production with nobody looking.
And a fourth that is a precaution rather than an agreement: keep the old site reachable for a few days, even internally. When you need to compare lost content or rebuild a block that disappeared, having the original in front of you turns an hours-long investigation into a two-minute lookup.
Bulk redirect to the homepage. Every old URL pointing at the front page. The fastest way to lose everything. Google reads it as the content no longer existing.
Content lost in the redesign. Pages that had two thousand words now have three hundred because the new design "is cleaner". The design improved; the relevance disappeared.
Structural change with no need for it. Reorganising categories because the new team finds it more logical, with no data behind it. Every URL change costs signals; doing it without a reason is paying without buying.
Forgetting the assets. Images, PDFs and documents that also carried traffic and links, and that nobody put in the map. In sectors with catalogues and spec sheets this can be a notable slice of traffic.
Not preserving the history. Property, domain or tool changes and the "before" is gone. From then on nobody can demonstrate whether the migration went well, and the discussion turns political.
If the proposal has no explicit line for URL inventory, redirect mapping and post-launch monitoring, those hours are not budgeted and therefore will not happen. Asking before signing costs one sentence; fixing it afterwards costs months.
Diagnose in this order; most cases resolve at point one or two.
noindex inherited from staging. Five minutes to fix, two weeks to recover.Clicks per URL, positions and indexing status. Ten minutes of work now that is worth weeks of argument later. The analytics layer is free.
Sign in to Semalt See the analyticsBetween 10% and 25% for the first weeks, with full recovery in four to eight. A bigger drop, or a recovery that never arrives, points to a specific fault rather than to migration itself.
301 whenever the change is permanent, which it is in a migration. Reserve 302 for genuinely temporary changes.
A year minimum; in practice indefinitely if they cost nothing. Old external links keep sending traffic for a very long time.
Yes, and on large sites it is advisable: section by section, verifying each before continuing. It reduces risk and makes isolating a fault far easier.
Rebuild it from whatever historical per-URL performance data you still hold, plus coverage reports. Worse than having it, but enough to locate the broken critical URLs.
A migration is one of the few moments in SEO where the outcome depends almost entirely on discipline rather than luck. No competitor beats you and no algorithm punishes you: there is an inventory that either gets done or does not, a redirect map that is either reviewed one by one or generated in bulk, and four weeks of monitoring that either happen or get replaced by hope.
If a redesign or platform change is on your horizon, the most profitable thing you can do today — before anything else — is freeze the baseline. Connect your domain, store clicks and impressions per URL and the positions of your main queries. Half an hour that can save you half a year.
And if the redesign already happened and you are in the uncomfortable part, get in touch: migration diagnosis is part of the free initial audit, and in most cases the cause surfaces within the first couple of checks.
Free analytics for Google Search, SERP rankings and AI answers - plus fast indexing for your new pages.
Sign in to Semalt semalt.comGet in touch for a free audit
