How long does Google actually take to crawl, index and rank your changes?

The short answer: According to timing ranges Google’s Gary Illyes reportedly presented in October 2026, Google typically finds a new URL in about 20 hours and indexes it about 1.5 hours after crawling. It takes about 30 days to revisit a page it already knows. Title and snippet changes usually show in 1–2 days after that, site moves take 1–3 months, and core update recovery takes 3–6 months. The slowest cases run to weeks, months or never, and “never” is usually a quality problem.

Every SEO has been asked some version of this question: “We changed it last week. Why hasn’t anything moved?”

It usually comes from a client, a product manager or a founder who has just watched a developer ship a fix. The ticket is closed, the change is live, and Search Console looks exactly the same as it did on Monday. To them, the silence looks like failure. To us, it looks like Tuesday.

The problem is that our answers have mostly been built on experience and educated guesses. We say “give it a few weeks” because that is what we have seen work, not because Google ever told us so. That makes it hard to push back when someone wants to roll back a perfectly good change after five days.

Earlier this month that changed, at least a little. Google’s Gary Illyes presented internal timing data for how long crawling, indexing and serving take. This post walks through those numbers, what sits behind them, and how I think we should use them.

Where these numbers came from

At Google Search Central Live Deep Dive in Barcelona, Gary Illyes from Google presented internal timing data for the three stages every page goes through: crawling, indexing and serving.

For each process, he gave two figures. The first was a typical time, meaning what happens in the normal case. The second was the slowest time, meaning what happens at the tail end when something gets in the way.

That second number is the one most of us have been missing. Anecdotes tell you how fast things can go. They rarely tell you how slow things can get, or why. Having both ends of the range, from Google itself, gives us a much better way to frame expectations.

Below are the figures we think matter most for day-to-day SEO work, grouped by stage, with some context on why each one behaves the way it does.

Crawling: getting Google to the page

Crawling is the first gate. If Google hasn’t fetched the page, nothing else in this post applies.

New URL discovery is faster than many people assume. Twenty hours is a reasonable expectation for a new page on a site Google already trusts and crawls regularly. The slow end is where it gets interesting. A new URL buried deep in a site with weak internal linking, on a domain Google doesn’t prioritise, can sit undiscovered for weeks. Some never get found at all. If that sounds like your site, see how enterprise teams diagnose crawl and indexing problems at scale.

Refreshing a known URL takes around 30 days in the typical case. This is the number I think most people underestimate. If you update an existing page, Google may not come back to look at it for a month. Pages that change often and attract links get revisited more frequently. Static pages deep in the archive get revisited less.

Sitemaps are processed in about a day, but a sitemap is a hint, not an instruction. Listing a URL tells Google it exists. It doesn’t make Google want to crawl it. If the URLs in your sitemap look low value, Google can take two weeks to get to them, or simply decide not to.

robots.txt changes are picked up in roughly 24 hours, and at most about 25, because Google caches the file and refreshes that cache about once a day. That is useful to know in both directions. Unblocking a section won’t take effect instantly, and neither will an accidental block, which gives you a small window to catch a mistake.

Crawl capacity can drop within seconds when your server struggles, but recovery takes one to three weeks. A bad night of 5xx errors can slow crawling for a long time.

Indexing: deciding what the page is and whether to keep it

Once a page is fetched, Google has to render it, work out what it’s about, pick a canonical version and decide whether it belongs in the index at all.

End to end indexing is surprisingly quick in the normal case. An hour and a half from crawl to index is fast. But the slowest case is months, or never, and that gap tells you everything. When a page is stuck in “Crawled, currently not indexed” for a long time, the bottleneck usually isn’t a technical one.

Rendering is a good reminder that speed and waiting are different things. Google can render a page in seconds, but the page may wait hours for its turn, and at the slow end that stretches to days or weeks. If your critical content only appears after JavaScript runs, that queue sits between you and indexing. Server side rendering or static HTML for key content removes the wait entirely.

Link annotations are the signals Google takes from links pointing at a page. They can take anywhere from minutes to weeks to count, so new internal links won’t change anything overnight.

Canonical changes take one to three weeks, and months when your signals disagree. Google doesn’t simply obey a rel=canonical tag. It weighs it against internal links, redirects, sitemaps, hreflang and the content itself. If your canonical tag points one way and your internal links point the other, Google will take its time deciding who to believe.

Removals through normal indexing, such as a noindex tag or a 404, take one to three weeks, and months at the slow end. Google needs to recrawl the page to see the change, which ties back to that 30 day refresh figure above.

Site moves are the big one. One to three months is typical. Six months to a year or more is the slow end, although a small move can settle in a few weeks. A domain migration means Google has to recrawl the old URLs, follow the redirects, reprocess the new URLs and transfer signals across. Every one of those steps carries its own delay, and they stack. If a move is on the cards, work through a website migration checklist before launch, so redirects, canonicals and sitemaps agree.

Serving: what actually shows up in search

Serving is the part clients see: titles, snippets, rankings and whether a page appears at all. It is also where the longest waits live.

Search Console removals are the fastest lever on the entire list. About two hours, and 24 at the slow end. If something sensitive is showing in search and you need it gone now, this is the tool. Keep in mind it hides the result temporarily. You still need a noindex, a 404 or a password to make the removal stick.

Title and snippet updates usually show within a day or two of Google reprocessing the page. The slow end is weeks to months, partly because the page has to be recrawled first, and partly because Google rewrites titles and snippets when it thinks it can do better. A title that hasn’t changed after a month may not be a crawling problem at all. Google may just prefer its own version.

Manual action removal takes one to two weeks after a reconsideration request in the typical case, and four to six weeks at the slow end. Dormant sites take much longer, presumably because there is less crawl activity to confirm that things have actually been fixed.

Core update recovery takes three to six months, and up to a year if your improvements need the next core update to be recognised. This is the number to show anyone expecting a bounce back within a few weeks of a content overhaul. Recovery isn’t a switch. It depends on Google reassessing the whole site, and some of that reassessment only happens when the next core update rolls out. That fits what the Google ranking factors leak suggested about site-level signals.

What stood out

“Never” shows up a lot

Reading through the slowest times, and one word keeps appearing.

In almost every case, “never” is tied to quality. This is Google saying that some pages aren’t worth the effort of crawling, indexing or enhancing, and no amount of technical polish changes that.

That matters if you’re paying for technical fixes. Faster servers, cleaner sitemaps, better internal linking and correct canonicals are all worth doing, but they only remove friction. They don’t give Google a reason to care.

If a page is thin, duplicated, or adds nothing that isn’t already ranking, a perfect technical setup just means Google can decide faster that it doesn’t want it. Speed won’t save a page that isn’t worth indexing.

Waiting isn’t the same as failing

You approve a change, your developer ships it, and a week later nothing has moved. It’s easy to think that the change isn’t working, and to ask for it to be rolled back or tried a different way.

These timelines suggest that’s usually too early to call. Canonical changes take weeks. Site moves take months. Core update recovery takes a season or two. These aren’t signs that something went wrong. They are, as reported, Google’s own description of a normal timeline.

What to do with this

Don’t judge a change before its window has passed. Don’t call a title test a failure after three days or a canonical fix a failure after one week. Check where the change sits against the typical time for that process. If you’re still inside the window, the honest answer is “too early to tell”.

Agree the review date before the work starts. Ask whoever is doing the work how long each change should take to show, and put the review date in the diary. A migration plan that says “expect volatility for one to three months” up front makes month two a lot calmer. For large sites, our enterprise SEO migrations work builds these windows into the plan.

Put quality alongside technical fixes. When the slow case is “never”, the problem is rarely a missing tag. If pages are stuck unindexed, ask whether they deserve to be indexed before you pay to fix the sitemap. That’s the premise of intent-led SEO: build pages around what people are trying to do.

Use Search Console removals when you need speed. If something sensitive is showing in search, ask your developer or SEO to use the Search Console removal tool. It takes about two hours. Pair it with a permanent fix so the page doesn’t return.

Help Google along where you can. Strong internal links to new pages, accurate sitemaps, consistent canonical signals and key content that sits in the page’s HTML, not only appearing after scripts run, all push you towards the typical end of each range rather than the slow end.

FAQs

How long does Google take to index a new page?

Reportedly about 20 hours to discover a new URL, then about 1.5 hours to index it once crawled. At the slow end it can take weeks, months or never, usually because of quality.

How long until a title or snippet change shows in search?

Typically one to two days after Google reprocesses the page. The slow end is weeks to months, and Google may rewrite your title or snippet anyway.

How long does a site migration take to settle?

Typically one to three months, and six months to a year or more at the slow end. A small move can settle in a few weeks.

How long does core update recovery take?

Typically three to six months. If your improvements miss the window, it can stretch to a year, when the next core update reassesses the site.

The bottom line

If you’ve ever wondered why a change hasn’t shown up yet, you’ve probably been missing a benchmark. Now there’s a reported one. The numbers aren’t perfect, and they won’t match every site. But they replace “give it a few weeks” with ranges you can plan around.

The bigger lesson sits in the slowest column. Most delays are a matter of patience. The ones that end in “never” are a matter of quality. Knowing which one you’re dealing with is half the job.

So the next time you wonder why nothing has moved since last week, the answer might simply be: it hasn’t been long enough yet. And now there’s a reported Google benchmark to back it up.

If pages are slow to appear and you can’t tell whether it’s timing, technical or quality, a marketing and SEO audit will show which.