The short answerA website migration runs on five clocks: build, DNS cutover, Google processing, redirects and recovery. Our two projects took about a day or two to build on a small site and about six weeks on a large one. Google says most pages of a small or medium site take a few weeks to move. Keep redirects at least a year.
Last updated 4 November 2026.
How long does each part of a migration take?
| Clock | What it measures | How long it takes | What sets it |
|---|---|---|---|
| Build and launch | First build work to the new site going live | About a day or two on a small site, about six weeks on a large one (our two projects). No official figure exists | Page count, redirect map, templates, approvals (our view) |
| DNS cutover | Switching the address until visitors reach the new host | Set by the TTL you choose. On Cloudflare, from minutes to a day. A nameserver change can take up to 24 hours | The cache setting (TTL) and your registrar |
| Google processing | Googlebot visiting and processing the moved pages | A few weeks for most pages of a small or medium site, longer for larger sites | Number of URLs and server speed |
| Redirect retention | How long the old addresses keep redirecting | At least a year, and indefinitely if you can | Google's guidance |
| Traffic recovery | The new site's traffic back at the old level | No Google figure. One study of 1,052 domain moves reports a median of 304 days | Mostly unmeasured |
Google's own guide for a move with address changes is built in four steps: prepare the new site, map the old addresses to the new ones, start the move, then monitor traffic. It gives a time for two things: a few weeks for most pages of a small to medium site to move, and at least a year of redirects. It gives none for the build, and none for recovery. Build and recovery numbers come from somewhere else, which is why two honest answers to the same question can differ by months. Anyone who quotes you one number for the whole migration is quoting one clock.
A hosting-only move has less to do. Google keeps a separate guide for it, because the addresses stay the same and the work is the DNS switch and watching Googlebot's crawl rate. A move that changes addresses adds the mapping, the redirects and, for a domain change, the Change of Address tool in Search Console.
What sets the build time?
In our experience the build is set by three things: how many old addresses need a one-to-one redirect, how many page templates the new site has, and how quickly each page gets approved. The technical cutover is rarely the long part. This is our view from client work. Google publishes no build-time figure, and neither do the platform docs we read.
Stacking changes makes the project longer on purpose. Google says to plan changes one after the other, not all at once, and its example is changing the domain, the CMS and the layout in sequence. A redesign, a platform change and a rebrand in one project is three projects sharing a launch date.
Google also says you can split a large move into smaller steps, and that a large site can move one section first to test the effect on traffic and indexing. It gives no rule for when to split. We lean towards one cutover for a small site and sections for a very large one. That is our own judgment.
Platform limits can shape the plan too. Vercel caps the redirects in a project's configuration at 2,048, so a large redirect map needs a different mechanism. Sanity limits an import to 25 requests a second per IP address, so a big content move has to be paced.
How long did it take on two real sites?
We moved two of our clients to code-based sites this year. One was a much smaller website and one was a much larger one.
| Site | Size | First build work to live | Redesign of the migrated site |
|---|---|---|---|
| Delshad Legal | Much smaller | About a day or two | About three weeks after the move |
| Transalis | Much larger | About six weeks | In phases over about eleven days, about four weeks after go-live |
Both followed the same order: move first, redesign second. That matches Google's advice to change one thing at a time. In our view size was the main difference between the two projects, but two sites do not make a formula. Use them as a reference point for the range. Do not use them as a quote for yours.
How long does the cutover itself take?
The cutover is a DNS change. The TTL on a record says how long other servers may keep a copy of it. The DNS specification defines it as the time interval, in seconds, that a record may be cached before it should be discarded. A short TTL means a change reaches visitors sooner.
Google tells you to lower the TTL at least a week before the move, to a low value such as a few hours, and to keep the old host running until traffic to it reaches zero. Cloudflare says proxied records are cached for at most five minutes, while a nameserver change at your registrar can take up to 24 hours.
After launch, Google says a temporary drop in Googlebot's crawl rate is normal, followed by a steady rise over the next few days. The DNS clock and the Google clock are separate. A clean cutover in an afternoon says nothing yet about how long Google will take.
How long does Google take to process the move?
For a small or medium site, Google says most pages can take a few weeks to move. It depends on how fast your servers are and how many addresses are involved. Google also says there are no fixed crawl frequencies, and that Googlebot has to visit every address at least once. So the move is done when Google has crawled the pages. The team finishing the project does not end it.
Asking again for the same address does not speed crawling up. Google says crawling can take anywhere from a few days to a few weeks, and that requesting a recrawl several times for the same address will not get it crawled any faster. For many pages, submit a sitemap instead.
The Page indexing report in Search Console has a Validate fix button. Google says validation typically takes up to about two weeks and can take much longer.
How long should you keep the redirects?
At least a year. Google's guide says to keep redirects as long as possible, generally at least one year, so that Google can transfer all signals to the new addresses. It adds that for visitors you should consider keeping them indefinitely. John Mueller of Google has said that three months is too short for a site move.
You may see 180 days quoted. That figure comes from a different place. The Change of Address tool in Search Console stays active for 180 days, and Google's help page says to keep the redirects for at least that long. Treat 180 days as the floor for the tool and one year as the general rule. Google also suggests paying for the old domain for at least a year, so nobody else can register it.
How long until traffic comes back?
Google gives no number. It says to expect temporary fluctuation in rankings during the move and that rankings settle over time.
Two studies measured it for domain moves. SALT.agency looked at 1,052 domain migrations and found a median recovery of 304 days and a mean of 489 days. A Search Engine Journal study of 892 domain migrations reported an average of 523 days, with the fastest cases at 19 to 33 days. The gap between the average and the fastest cases is the reason a careful answer starts with "it depends".
Read both with care. They cover domain changes only, part of each dataset was crowdsourced, and the Search Engine Journal study uses third-party traffic estimates. In our judgment neither one describes a same-domain redesign. For that case, and for how to measure it, read our guide to website redesign SEO.
Do AI crawlers pick up a migrated site faster?
Nothing published says so. OpenAI and Perplexity both say a robots.txt change can take about a day to apply. None of the pages from OpenAI, Perplexity or Anthropic that we read gives a recrawl time for a moved site. Treat any promised date for AI pickup as a guess. We cover what to track and how to read it in AI visibility after a website migration.
What should you ask before you accept a timeline?
Use these five questions on any quote or plan. The answers tell you which clock the number belongs to.
- Which clock is this number for? Build, cutover, Google processing or recovery. A strong answer names one. A number with no label is a red flag.
- Do the addresses change, or only the hosting? A hosting move is mostly DNS. A move with address changes adds mapping and redirects.
- Is the redesign inside this project or after it? Google advises one change at a time. A combined project should say why.
- Who owns the redirect map, and who signs off each page? In our experience this decides the build time more than the code does.
- How long will the old redirects stay live? The answer should be at least a year.
Once you launch, work through our SEO migration checklist for the first days.
If a quote cannot say which clock it counts, ask for one that can.
