Website Migration SEO: What to Expect in the First 90 Days

Start here: two numbers get quoted on the question of how long a migration costs you in organic visibility, and both come from sources that hold up. Google's documentation on moving a site with URL changes puts it this way: "As a general rule, a medium-sized website can take a few weeks for most pages to move in our index; larger sites can take longer." On 26 June 2026, the agency SALT published an analysis of 1,052 domain migrations. Median time to recovery: 304 days. Mean: 489 days. A few weeks against roughly ten months.

The contradiction dissolves the moment you ask what each side is measuring. Google is talking about "most pages to move in our index". That is reindexing: the point at which your new URLs have replaced the old ones in the index. SALT defines recovery differently, in its own words: "the point at which the new domain's monthly organic search traffic equalled or exceeded the pre-migration baseline of the old domain". That is traffic recovery: the point at which monthly organic traffic is back where it was before.

Two metrics, two timescales, no contradiction. What sits between them is exactly what a migration sets off. Google has your pages back in the index, but it re-evaluates them, and that re-evaluation needs rankings, clicks and time.

Strictly speaking there are three layers, and the people who keep them apart have a better argument. First, indexing: does Google know the new addresses? Second, rankings: what positions do they hold? Third, traffic: how many people actually click? The first layer is a matter of days to weeks and you can read it straight off Search Console. The second follows with a lag and moves around. The third depends on season, competition and whether the new pages still answer the old queries at all. If your status report contains a single word, "visibility", the report is worthless.

The mix-up is expensive. Someone says "it'll have settled down in a few weeks" at kickoff, and the board hears a traffic commitment. Three months later there is a crisis meeting, even though the project is running to plan. In my experience the most common reason a migration gets written off as a failure is not a technical fault. It is an expectation nobody ever pinned down. That is why this article starts with the expected range rather than a checklist: what should you see and when, and at what point does it turn into actual damage?

The SALT series is the largest publicly available data set on this question that I know of. The distribution: 22.8% of migrations were back at their pre-migration level after 90 days, 27.8% after 120 days. 42% took longer than twelve months. 13.9% never reached the old level again within three years.

Those numbers are useful, but they carry less weight than they look like they do. Three limits you should know before one of them ends up in a board paper.

A different sample. SALT looked only at moves from one domain to another, implemented with 301 redirects. If you keep your domain and change only the URL structure, you are not in that sample. The relaunch on the same domain is by far the more common case in mid-sized companies, and it is the milder one.

Where the data comes from. The basis is SALT's own projects plus "hundreds crowdsourced from the SEO community". People who contribute cases select them. Whether that selection leans systematically towards the painful ones cannot be checked.

Huge spread. The standard deviation runs to more than two years. That makes the median a reference point, not a forecast for your case: a single project can be recovered in under three months or take several years. And the analysis is descriptive, not causal. SALT says so itself: "this study does not run regression analysis against migration quality factors". The data set tells you how long it took, not why.

What to take from it: the median of 304 days is neither a promise nor a threat. It is the antidote to the routine assurance that everything will be back after eight to twelve weeks. That figure turns up in plenty of agency guides, usually with no data behind it. At best it describes the favourable edge of the distribution.

From that follows a question you can put to an agency in a pitch, and the answer reveals a lot: where does your number come from? Most published recovery times land somewhere between a few weeks and a few months, and nearly all of them rest on the agency's own project experience, with no case count and no definition of what recovery means. That is not worthless, but it is a sample of unknown composition. Anyone quoting you a recovery time should be able to state three things: what they count, how many cases sit behind it, and what marks the end of recovery. If they cannot, the number is a guess. That applies to the 304-day median exactly as it applies to the eight weeks.

For planning it means two things. Do not put traffic parity for the first quarter after the move into your business plan. Describe a range instead, with a favourable and an unfavourable branch. And do not schedule go-live in your strongest revenue period of the year. If your business lives off November, you move in February. That one decision does more work than most of the technical fine points people argue about inside the project.

Now the specifics, from the perspective of whoever receives the reporting. Google expects turbulence and says so plainly: "Expect temporary fluctuation in site ranking during the move. With any significant change to a site, you may experience ranking fluctuations while Google recrawls and reindexes your site."

Week 1. Search Console shows falling impressions for the old URLs and rising numbers for the new ones. Both at once is the expected picture, not an alarm. The data arrives there with a delay, not in real time. Anyone drawing an interim conclusion on day two after go-live is judging incomplete data.

Weeks 2 to 4. The index sorts itself out. Rankings jump, sometimes sharply, sometimes downwards. This is the phase where the reflex to "quickly optimise something else" almost always shows up. Resist it. Every further change extends the re-evaluation, because it triggers crawling and indexing all over again.

Day 30 to 60. The curve for the new URLs should be holding up by now. The comparison that counts is not yesterday against today. It is total organic traffic against the same period a year earlier.

Day 90. Just over a fifth of the domain migrations SALT examined were back at the old level at this point, just over three quarters were not. If you are noticeably below your previous traffic on day 90 and the trend is upward, that is the normal course on this evidence, not a crisis. The crisis meeting in month three is usually an artefact of the wrong expectation.

What belongs in that reporting is short: the number of indexed new URLs against the number planned, the number of old URLs still getting clicks from search, organic traffic year on year, and the list of pages with the biggest losses. Four figures, one page. Anything beyond that turns the steering committee into a debate about how you measure instead of what you do about it.

For that range to be measurable at all, the measurement has to be in place before go-live, not after. Which events, goals and segments belong in it is a topic of its own, and so is recording the baseline before the move. Both belong on the table before you commission anyone.

Fluctuation is normal. Three observations are not, and each of them should come to you as the client directly, not in the monthly report.

First: 404 instead of a redirect on pages with history. When addresses that used to earn traffic or inbound links run into nothing, that is not a ranking topic. It is a fault in the mapping.

Second: the wrong status code. Google draws a clear line. For 301 and 308: "Googlebot follows the redirect, and the indexing pipeline uses the redirect as a signal that the redirect target should be canonical." For 302, 303 and 307: "Googlebot follows the redirect, but the indexing pipeline doesn't use the redirect as a signal that the redirect target should be canonical." A temporary redirect does not pass the canonicalisation signal.

Third: a noindex nobody ordered. If the block from the staging environment travels along with the release, the page disappears completely, not partially.

What that looks like when it goes wrong is documented in the best-known German case: frankfurt.de, the City of Frankfurt's website. Sistrix wrote it up on 9 March 2020 and updated the post on 12 April 2021. Project cost according to Sistrix: around 1.4 million euros. The body text states that since the week of 2 March 2020 the domain had lost just over 46% of its visibility in Google, and that figure sits under the chart for mobile visibility. The cause was nothing exotic, and it was not one thing alone: a 302 instead of a 301, plus old addresses from the predecessor system in the /sixcms/ directory that answered with 404. According to Sistrix, several hundred top-10 rankings still ran through those addresses.

Two notes on that, because the case gets misquoted. It is from 2020, not from recent years. And the widely repeated "almost 50%" is the headline of the source; the body text gives the mobile figure of just over 46%. If you argue with this case, date it correctly and quote it correctly.

From a decision-maker's seat the interesting part is not the technology anyway, it is the escalation path. All three fault types are visible within hours if somebody is looking for them. So agree three things before go-live: who checks daily during the first seven days, which signals get reported, and who they go to. Without a named person you get what the documented failures keep showing. The fault has been there since day one, and it gets found in the monthly report.

Start here: nothing in this section is a discovery. It is in Google's documentation, some of it for years. What separates this from most checklists is that it also tells you where. If your agency drops one of these points, it can justify that, but it is dropping it against the vendor documentation.

Complete URL mapping. Every old address with history gets exactly one target. Google explicitly applies its site-move documentation to URL structure changes on the same domain as well; the example given there is example.com/page.php?id=1 moving to example.com/widget.

301 or 308, not 302. As above: only the permanent codes act as a canonicalisation signal.

No redirect chains. "Googlebot can follow up to 10 hops in a 'chain' of multiple redirects." Ten hops is the technical ceiling, not a target. Chains cost crawl budget and break with every later change.

Self-referencing canonical. Verbatim: "Each new URL should have a self-referencing rel='canonical' link tag." Every new address points canonically at itself.

Update hreflang. For multilingual sites the instruction is: "be sure to update the annotations to use the new URLs". Stale language annotations point at addresses that no longer exist.

Sitemap cutover. Submit the new sitemap first, then remove the old one: "At this point you can remove your old sitemap, since Google will use the new sitemap going forward".

Change of address in Search Console, but only when the domain changes. The tool belongs exclusively to the case where content moves from one domain to another. Google explicitly rules out everything else: not for the switch from HTTP to HTTPS, not between www and non-www on the same domain, not for a pure rebuild of the URL structure on the same domain, and not when changing hosting provider. In those cases redirects and canonicals are the instrument. If your migration keeps the domain, this point simply does not apply to you, and a proposal that still lists it as a separate line item has not read the source.

On the deadline that reliably causes confusion: the Search Console help says "Maintain the redirects for at least 180 days — longer if you still see any traffic to them from Google Search", while the site-move documentation says "Keep the redirects for as long as possible, generally at least 1 year". That is not a contradiction but the difference between two floors. 180 days is the period the change-of-address tool ties its signal to; one year is the generally recommended lifetime of the redirect itself. What happens afterwards, the help spells out: "After the 180 day period, Google does not recognize any relationship between the old and new sites, and treats the old site as an unrelated site, if still present and crawlable." In practice that means you keep redirects alive as long as they still get clicks from search, and longer when in doubt.

A word on what this list covers: it is the minimum, not the programme. Internal linking, navigation depth, structured data and the question of which pages should move at all come on top. Those are design decisions with room for judgement. The points above are not. If the redirect plan, the canonical logic and the sitemap cutover disappear into a single line item called "SEO support", ask about it. Those three belong in the proposal separately, each with its own date. How we set up a B2B website technically, and what counts as standard rather than an extra, is on our B2B website service page.

A clarification is due here, because numbers show up in migration proposals that do not exist. The valid Core Web Vitals thresholds are: LCP at most 2.5 seconds, INP at most 200 milliseconds, CLS at most 0.1. Measured at the 75th percentile of page loads, separately for mobile and desktop.

Not valid are the values circulating as tightened thresholds for 2025 and 2026: LCP under 2.0 seconds, CLS under 0.08, FID under 80 milliseconds. Those numbers appear in no Google source. The third one gives itself away. FID has not been a Core Web Vital since 12 March 2024, the day INP replaced it. Anyone writing an FID target into your proposal today is working with a metric that has not held that role for over two years.

Two sentences from the same Google page experience documentation, for weighting. One: "Core Web Vitals are used by our ranking systems." The other: "There is no single signal. Our core ranking systems look at a variety of signals that align with overall page experience." Both are true. Good scores are necessary hygiene, not a lever that pulls back lost visibility. If a migration proposal explains post-move recovery mainly through performance work, the redirect half of the equation is missing.

The three values still belong in acceptance testing, for a different reason than ranking. They are the only objective measure of build quality you can check without specialist knowledge. Measure them on real user data, not in a lab test on a developer machine, and measure them on mobile. The stack you pick decides a lot here. A server-rendered frontend on Next.js that pulls its content from a headless CMS such as Sanity reaches those values in our experience without extra tuning; a heavily loaded page builder rarely does. That is not an argument against page builders. It is an argument for honest target values in the specification.

That leaves the question of what drags recovery out. SALT describes the cases that take more than a year and names three patterns, verbatim: "a combination of domain authority gaps between old and new, significant content restructuring at migration time, or technical issues that were not identified and resolved promptly." Translated into decisions that land on your desk:

The domain change itself. If the new domain has little history of its own, the move transfers signals to a target with no standing. So check seriously whether the domain change really has to happen. A relaunch on the same domain never enters this category in the first place.

Rebuild and move at the same time. "Significant content restructuring at migration time" is the point where most projects get in their own way: new domain, new structure, new copy, new system, all in one night. Afterwards nobody can tell which change caused which effect. Separate the steps. First prune and consolidate, then move, then expand the content.

Late detection. "Technical issues that were not identified and resolved promptly": the cost is not the fault, it is the time until someone finds it. That is why status code checks, index coverage and server logs belong in the first week after go-live, with a named owner.

A scope that is too large. When one project is supposed to deliver a website, a customer portal and a web application at once, the migration becomes a sideshow. I drew the line between those three in website, web app or portal. The practical answer is the same every time: cut the programme into stages with their own dates, and keep the move as a stage of its own. What the application side costs to build is a separate budget question, and the mechanics are in what custom software development costs.

A note on honesty: these four points are derived from SALT's description, not statistically proven. The analysis makes no causal claim of its own. They match what I see in projects, and I claim no more than that.

You do not have to become an SEO to judge a migration proposal. Four demands are enough, and each has evidence behind it.

First: a timeline with two curves. Reindexing and traffic recovery kept apart, with target values per month. Anyone who puts both into one curve is selling you Google's "a few weeks" as a traffic commitment.

Second: named responsibility for URL mapping, status codes and the sitemap cutover. With a date before go-live, not after. What belongs in it is above, and it is in Google's documentation.

Third: a monitoring window in the first seven days. Status codes, index coverage, logs, fixed ownership. The cost driver is late detection, not the fault itself.

Fourth: scepticism towards guarantees. A proposal that contractually promises no ranking loss at all contradicts the vendor documentation. Google writes: "Expect temporary fluctuation in site ranking during the move." Anyone guaranteeing the opposite has either not read the documentation or plans to explain the promise away later.

And after go-live: a migration is not a finish date, it is the start of an operating phase. Budget, ownership and a monthly rhythm belong in the plan from the outset, and the way we build and run B2B websites is set up around that. If the project has an application side to it as well, the same arithmetic decides when custom software pays off.

If you are heading into a migration and want to know what the move looks like in your case: we go through your URL inventory, the redirect logic and the schedule in one conversation, and you leave with an assessment of where your project sits in the expected range. Book a call directly.