Website Migration SEO: How to Rescue One That Has Already Gone Wrong

The migration launched three weeks ago and organic traffic is down by half. Somebody has already said “Google just needs time,” and somebody else has already said “roll it back.” Both are guesses. A website migration that damages search almost always has a specific, findable cause — usually two or three stacked on top of each other — and the way out is to find them in order, not to wait or to panic. This is that order.

It is written for the week after, when the site is live and the graph is falling. If you are still before launch, our migration checklist is the piece that prevents this; the article you are reading is the one that repairs it.

First: is it actually broken?

Every migration produces a dip. Google has to recrawl the new URLs, reconcile the redirects, and rebuild its picture of the site, and rankings wobble while it does. A dip of a few weeks that recovers is the normal cost of changing addresses. A drop that is still falling at week three, or that landed on specific sections while others held, is damage.

Two readings from Search Console settle it. In the Performance report, compare the fortnight before launch to the fortnight after, by page: if the losses are spread evenly, you are probably in the dip; if a handful of URLs or one directory lost everything, something specific is wrong with those. In the Pages report, look at what went from Indexed to anything else. That list is your suspect list.

The eight causes, in the order to check them

1. Redirects that are wrong, chained, or missing. This is the cause more often than the other seven combined. Crawl the complete list of old URLs — from the old sitemap, the old crawl, Search Console’s page list, and Analytics — and request every one. Each must answer with a single 301 to a live page that is the same content. The failures you will find: 302s where 301s were intended, chains through two or three hops, redirects to the homepage instead of the equivalent page, and old URLs that were never mapped because nobody had the full list. We migrated over 50,000 pages between platforms without losing a ranking, and the entire discipline was this list. On Drupal the Redirect module holds them; on WordPress it is usually a plugin or the server config; either way, export and verify, do not trust the UI.

2. Staging directives that went live. A noindex meta tag, a Disallow: / in robots.txt, or password protection that was correct on staging and copied to production. It sounds too obvious to check. Check it first anyway, on the templates, not just the homepage.

3. Canonicals pointing to the old site. When a domain changes and the canonical tag still names the old one, you have told Google the new pages are duplicates of pages that now redirect. Every page’s canonical must be its own new URL.

4. The sitemap nobody regenerated. The new site is still serving the old sitemap, or a sitemap of new URLs that was never submitted, or one that includes the redirecting old URLs. Submit the correct one in Search Console and watch the Sitemaps report for Discovered against Indexed.

5. Internal links to old URLs. Navigation, footers and in-body links that still point at the previous URLs, so every internal link now goes through a redirect. Crawl the new site and look at the redirect column; there should be almost nothing in it.

6. Content that thinned or merged. Migrations consolidate. Two pages became one, the FAQ was dropped, the product descriptions were shortened, a template stopped rendering the second half of the body. The page that ranked for a query may simply no longer contain the words. Compare word counts old against new, per URL; the outliers are the story.

7. Rendering. The new front end renders the content with JavaScript that Google indexes late or partially. Use Search Console’s URL Inspection on a lost page and look at the rendered HTML, not the source. If the words are not there, the crawler did not see them either.

8. Speed and Core Web Vitals. A slower site rarely causes a collapse on its own, but a migration that added a page builder and doubled the page weight will drag, and it compounds the rest. Compare field data in the Core Web Vitals report before and after.

Drupal-specific things that bite

Pathauto patterns changed between versions and regenerated every alias, so old URLs 404 unless the Redirect module’s “create redirects on alias change” was on before the regeneration. Metatag defaults got reset, so titles fell back to node titles and descriptions went blank. The language negotiation switched from domain to path prefix and every hreflang broke — which is exactly the failure that produced a hundred dead Arabic URLs on our own site earlier this month, and one we found only by crawling. Simple XML Sitemap was installed but never generated after launch. Each of these is ten minutes to fix and weeks of loss if nobody looks.

Then, in Search Console

If the domain changed, use the Change of Address tool; it is the one signal that tells Google explicitly what happened. Submit the new sitemap. Request indexing on the twenty most valuable lost pages — not to game anything, but so the fixes are seen this week rather than next month. Then leave it alone and watch, because every day you keep changing things is a day Google is measuring a moving target.

How long recovery takes

Once the causes are fixed, most sites recover the bulk of their position in weeks, not days, and the tail takes months. Anyone who promises faster is guessing. The variable is how much of the original signal survived: a site whose URLs, content and links all carried across cleanly recovers fast; one that also lost half its content is not recovering, it is starting again with a head start.

When to roll back

Almost never, and only in the first days. A rollback after a few weeks means Google has now seen three site states, and you have added a second migration to the first. The exception is a launch that went out with the staging directives or with no redirects at all, caught within days: reverting and relaunching properly is faster than repairing in place. Past that window, fix forward.

The uncomfortable part

Every item above was checkable before launch, in an afternoon, against the old site. The reason migrations lose traffic is not that the problems are hard; it is that the crawl comparison is never done, because the launch date arrives and the site “looks fine.” It looked fine on the day. Search is measured over the following months, and those are the ones this article is trying to give back.

Gspikes rescues migrations that have already gone wrong — we crawl the old site from whatever archives exist, crawl the new one, diff them, and hand back the list. If yours is three weeks in and still falling, send us the two domains and we will tell you what we find. More on our technical SEO work, on migrating WordPress to Drupal and off Joomla, and on what the whole job costs.