How Long Google Takes to Crawl, Index and Update Your Site: Google’s Own Timelines

"How long until Google picks this up?" is the question I get most after any technical fix, migration or content rewrite. Until now, the honest answer was "it depends", backed by experience rather than data.

On October 2, 2026, at Search Central Live Deep Dive Europe in Barcelona, Google's Gary Illyes put numbers on it. He showed Google's own internal analysis of how long 27 Search processes take, from discovering a new URL to recovering from a core update. For each one he gave a typical time and a slowest time.

The slides aren't public yet. The most complete record is John Campbell's day 3 recap on ROAST, which lists every row. Most coverage so far has reproduced only part of it. Below is the full set, grouped the way Google presented it, plus how I'd use it in practice.

The short answer

• New pages: Google typically discovers a new URL in about 20 hours and finishes indexing it in about 1.5 hours after that.
• Changes to existing pages: Google typically recrawls a known URL about every 30 days, so an edit to an old page can take weeks to be noticed.
• Titles and snippets: they typically update 1–2 days after Google processes the change.
• Canonical changes: these typically settle in 1–3 weeks.
• Site moves: a move typically settles in 1–3 months. The slowest cases take a year or more.
• Core update recovery: typically 3–6 months. In the slowest cases you wait for the next core update.

Crawling: how fast Google finds and refetches pages

Two rows here matter more than they look.

Refresh at ~30 days is the one that catches most teams out. Discovery of a brand-new URL is fast, but Google doesn't revisit known URLs that often. If you rewrite an old article and nothing changes for two weeks, that's normal. Google may simply not have fetched it again yet.

Crawl capacity is how hard Google is willing to hit your server. According to the recap, it can drop in seconds when Google backs off, for example when your server starts returning errors or slowing down, but it takes from hours up to a couple of weeks to come back. One bad deploy that causes 5xx errors can slow crawling for much longer than the outage itself lasted.

The robots.txt row is the most predictable thing on the list: about a day, and never more than 25 hours. If a robots.txt change hasn't taken effect after a day, check the file is actually live, rather than waiting.

Indexing: from fetched page to searchable page

"End to end" here means every critical indexing process has finished. A few things stand out:

• Rendering is quick, but the queue isn't. The render itself takes seconds; the wait to be rendered takes hours. If your important content only appears after JavaScript runs, you're adding that queue time on top of everything else. Check what Google sees without JavaScript using a tool like my SSR Inspector.
• Link annotations can take months. New internal or external links don't pass their full value overnight. Judge an internal linking change over weeks, not days.
• Canonical changes slow down when signals conflict. Google's own canonicalization troubleshooting guide says it "might hold pages in a duplicate cluster for up to two weeks" even after you fix the content. If your canonical tag, internal links, sitemap and redirects disagree, expect the slow end.
• Small site moves are faster. The recap notes a small site move can finish in a few weeks, which matches Google's site move documentation: a few weeks or more for medium sites, longer for large ones. Google also says to keep redirects for at least a year.

Serving: when changes show up in search results

Gary also gave rollout lengths: core updates take 2–4 weeks to roll out, and spam updates take 1–2 days.

The core update row is about recovery, not the rollout. It lines up with Google's core updates guidance, which says some changes "can take effect in a few days, but it could take several months" for Google's systems to confirm a site has improved, and that if you see nothing after a few months, you may be waiting for the next core update.

Spam updates work differently. Their effects can update continuously, typically within one to two weeks, but some changes only land in periodic batch refreshes that can take months. If you're tracking an update's impact, my Google volatility tracker shows when the rollouts actually moved rankings.

Delays stack up

Gary's main caveat was that these processes are linked. A page can't be indexed until it's crawled, and a new title can't show until the page is reprocessed. So the real wait for a change is often the sum of several rows, not one.

An example: you rewrite the title of an existing page.

1. Google has to recrawl the page: typically up to ~30 days for a known URL.
2. The page is then reprocessed and indexed: about 1.5 hours end to end.
3. The new title shows in results: typically 1–2 days.

So "titles update in 1–2 days" can mean several weeks in practice, if Google hadn't planned to revisit that page soon. That's my reading of how the rows connect, not something Google spelled out. It explains why requesting indexing in Search Console after an important change still makes sense: it lets you skip the wait for step 1.

The same logic explains site moves. Google has to recrawl every old URL to see the redirect, and a ~30-day refresh cycle across thousands of pages adds up quickly.

"Never" usually means a quality problem

Look at the slowest column: "never" appears five times, for discovery, refresh, sitemap processing, end-to-end indexing and structured data updates. Three of those come with "(quality)" in brackets.

Put plainly, if Google doesn't think a page is worth it, technical fixes won't speed anything up. A perfect sitemap won't get thin or duplicate pages indexed. If your pages sit in "Discovered – currently not indexed" or "Crawled – currently not indexed" for months, treat it as a content and site-quality problem, not a crawling problem.

When a delay stops being normal

This is how I'd use the data with clients: as a point to start investigating, rather than a deadline.

What Google didn't share

These numbers come with real limits, and it's worth being upfront about them:

• No definitions. Google didn't say what "typical" means (median? most common?) or how the slowest case was measured.
• No sample size or time period. We don't know how many sites or URLs this covers, or when the data was collected.
• Fastest times are missing. Gary showed fastest, typical and slowest times, but the recap only lists typical and slowest.
• It's second-hand. Until Google publishes the slides, these figures come from an attendee's notes. I'll update this post if the official deck appears.

Treat them as reference points from Google, not guarantees. Big, frequently updated sites will sit at the fast end; small or low-quality sites at the slow end.

FAQ

How long does it take Google to index a new page?

Google typically discovers a new URL in about 20 hours and completes indexing in about 1.5 hours after crawling it. In the slowest cases it takes weeks, and some pages are never indexed, usually because of quality.

How long does Google take to recrawl an updated page?

Typically about 30 days for a URL Google already knows. Requesting indexing in Search Console's URL Inspection tool can speed this up for important pages.

How long does a site migration take to settle in Google?

Typically one to three months. Small sites can finish in a few weeks, and the slowest moves take six months to over a year. Keep redirects in place for at least a year.

How long does it take to recover from a Google core update?

Typically three to six months after you make improvements. In the slowest cases recovery only shows at the next core update, six months to a year later.

How long does a canonical tag change take?

Typically one to three weeks. It can take months when your canonical signals conflict.

Sources: John Campbell, ROAST — Search Central Live Deep Dive Barcelona, Day 3 recap (Oct 2, 2026), reporting Gary Illyes' session; Google Search Central documentation linked above.