How long Google takes to crawl, index and recover

You fixed the canonical tags a week ago and Search Console still shows the old URL. Normal, or broken? For years the honest answer was a shrug, because Google rarely put numbers on its own pipeline.

On 2 October 2026, at Search Central Live Deep Dive Europe in Barcelona, Google’s Gary Illyes did. He showed a typical time and a slowest time for 23 search processes, which answers questions like how long Google takes to index a page, change a title or lift a manual action. Below is every range, what each one means for your site, and a simple way to tell a page that’s still in Google’s queue from one that’s stuck.

How long does Google take to index a page?

Google typically discovers a new URL in about 20 hours, and indexing takes about 1.5 hours end to end once the page is crawled. Title and snippet changes usually show in 1 to 2 days. A site move takes 1 to 3 months, and recovering from a core update takes 3 to 6 months.

Those are typical times. Every one of them has a slow tail, and for five processes that tail ends at “never”.

Where these numbers come from, and how far to trust them

The figures come from an attendee’s write-up, not a Google publication. John Campbell of the agency ROAST was in the room and published the timings in his day 3 recap of the Barcelona event. Search Engine Journal and Search Engine Roundtable then reported them. At the time of writing, Google hasn’t posted the slides.

According to the recap, the numbers come from Google’s internal analysis. Three things are missing, and they matter:

• No sample size, time period or definition of “typical”.
• A “fastest” time was mentioned for each process, but the published tables only give typical and slowest.
• No breakdown by site size. A ten-page brochure site and a million-URL store sit in the same row.

Illyes’s main caveat, as reported, was that many of these processes are linked. A page can’t be indexed before it’s crawled, so a slow crawl delays everything after it. Read each row as the time a stage takes once the stage before it has finished, not as a countdown from the moment you hit publish.

Crawling timelines: discovery, refresh, sitemaps and robots.txt

Crawling is where the longest waits begin. A new URL is typically found in about 20 hours, but a page Google already knows is re-crawled only about every 30 days.

Crawling process	Typical	Slowest
Discovery (new URL)	~20 hours	Weeks to never
Refresh (known URL)	~30 days	Weeks to never
Sitemap processing	~24 hours	Up to 14 days, or never (quality)
robots.txt update	~24 hours	25 hours
Crawl capacity update	4 hours to 1–2 weeks	1–3 weeks (in recovery)
Crawl demand update	~20 hours	Weeks to months

The 30-day refresh is the number most site owners underestimate. Edit a two-year-old blog post and Google may not fetch the new version for a month. Three things shorten the wait. Link to the edited page from somewhere Google crawls often, such as your homepage or a new post. Update the page’s lastmod in your sitemap, which Google says it uses when the value is consistently and verifiably accurate. For a handful of priority URLs, use Request Indexing in Search Console’s URL Inspection tool.

robots.txt has the tightest range in the whole table: 24 hours typical, 25 hours at worst. That matches Google’s documentation, which says it caches robots.txt for up to 24 hours. The flip side is that a bad robots.txt rule also takes effect within a day. Block a folder by mistake on Friday and Google knows by Saturday.

Sitemap processing usually finishes within a day, but the slowest case is “never (quality)”. A sitemap is a list of suggestions. Google decides which URLs on it are worth crawling. If you need a clean file to start from, our XML sitemap generator builds one from your live pages.

The two crawl-rate rows explain why server trouble lingers. When your server slows down or throws errors, Google cuts how hard it crawls. Ramping back up takes 4 hours to 2 weeks, and up to 3 weeks when Google is still treating the site as recovering. A few bad days of hosting can cost you weeks of crawling.

Indexing timelines: rendering, canonicals and site moves

Indexing is quick once a page is crawled, about 1.5 hours end to end in the typical case. The slow parts are the decisions Google makes about which URL to keep and how to treat it.

Indexing process	Typical	Slowest
Rendering	Seconds to render, hours in the queue	Days to weeks
Meta annotations	45–90 minutes	1–4 days
Link annotations	Minutes to 1–3 weeks	Months
Indexing (end to end)	~1.5 hours	Months or never (quality)
Removal	1–3 weeks	Months
Canonicalisation change	1–3 weeks	Months (conflicting signals)
Site move	1–3 months	6 months to 1 year+
Structured data updates	Hours to 1–2 weeks	Weeks or never (quality)
Images	Hours to days	Weeks to months
Videos	Hours to days	Weeks to months (deep analysis)

Rendering takes seconds, but pages wait hours in the queue for it. If your main content, title or internal links only appear after JavaScript runs, they wait in that queue too. Put anything you need indexed in the server-rendered HTML.

Canonical changes take 1 to 3 weeks and stretch to months when signals conflict. Conflict means your canonical tag says one URL, the sitemap lists another, internal links point to a third and a redirect sends Googlebot somewhere else. Google’s canonicalization troubleshooting guide adds that a page can stay in a duplicate cluster for up to two weeks even after you fix the content. Make every signal name the same URL. Our canonical and indexability checker traces the redirect chain and reads the canonical tag and robots directives in one pass.

The site move row deserves a careful reading. Google’s site move guide says most pages on a small to medium site move within a few weeks, and larger sites take longer. The Barcelona figure is 1 to 3 months, with a slow tail past a year. Use the guide for when to expect the first new URLs in results, and plan client reporting around the 1-to-3-month range.

Removal here means a page leaving the index after you return a 404 or add noindex, and it takes 1 to 3 weeks. That’s different from the Search Console removal in the next table, which hides a URL within hours but, per Google, lasts only about six months. To take a page out of Google for good, use the 404 or noindex as well.

Link annotations range from minutes to 1 to 3 weeks, and can take months. A new backlink is not counted the day it goes live, so judge a link campaign over weeks, not days. Structured data updates take hours to two weeks; run new markup through a structured data checker first, because markup with errors can sit there indefinitely.

Search result and recovery timelines: titles, manual actions and core updates

Changes to how a page looks in results are quick: a new title or snippet typically appears in 1 to 2 days. Recovering from a ranking demotion is the slowest thing in the whole set.

Serving process	Typical	Slowest
Removal in Search Console (owner)	~2 hours	24 hours
Snippet update	1–2 days	Several weeks to months
Title update	1–2 days	Several weeks to months
Text result image update	1–2 weeks	Several weeks to months
Manual action removal	1–2 weeks	4–6 weeks, or much longer for dormant sites
Core update change	3–6 months to recover	6 months to 1 year (next core update)
Spam update change	1–2 weeks (continuous)	Months (batch refreshes)

The 1-to-2-day title figure counts from when Google re-crawls the page, not from when you saved it. On an old page with a 30-day refresh cycle, a new title can take a month to show. Google may also rewrite the title anyway; our guide to how Google picks the order of results covers what it weighs.

Manual actions clear in 1 to 2 weeks after a successful reconsideration request, and 4 to 6 weeks in slow cases. Sites that have been dormant take much longer, so if the site has sat idle, plan for the slow end.

Core update recovery is 3 to 6 months, and the slow case is simply the next core update, 6 months to a year away. Google’s own core updates documentation agrees: some improvements show within days, but confirming that a site is consistently helpful can take several months, and if nothing changes after a few months, the next core update may be when it does. If a client was hit by a core update, don’t promise a recovery date. Promise the work, and review it at six months.

Spam updates run in two speeds: 1 to 2 weeks when the change comes through continuous systems, months when it waits for a batch refresh.

The pattern: mechanical changes take hours, judgements take months

Put the twelve most-asked-about rows on one chart and a pattern shows. Anything mechanical, such as a robots.txt rule, a Search Console removal or a title tag, moves in hours or days. Anything that needs Google to judge your site again, such as which URL is canonical, whether a moved site has kept its standing or whether a site has recovered from a core update, takes weeks to a year.

That split tells you where to spend effort while you wait. You can’t hurry a judgement by resubmitting a URL. You can make sure the signals Google is judging are clean and consistent before it looks.

Why “never” appears five times

Five slowest-case cells end in “never”: discovery, refresh, sitemap processing, end-to-end indexing and structured data updates. Three of them say “quality” in brackets.

“Never” is not a queue problem. Google can find a page, crawl it and still decide it isn’t worth keeping. In Search Console that usually shows up as “Crawled - currently not indexed” or “Discovered - currently not indexed”. Requesting indexing again won’t change the decision, because the page Google would fetch is the same page it already turned down.

What changes the decision is a better page, or fewer weak ones:

• Merge thin pages that target the same query into one stronger page, and redirect the rest.
• Add internal links from pages Google already values. Our internal link finder suggests where they fit.
• Cut boilerplate so each page says something the others on your site don’t.
• Check the page honestly against Google’s helpful content questions. Our helpful content review runs through them.

Still processing or stuck? A check you can run

Use the typical time as your “wait” line and the slowest time as your “act” line. That turns the tables into a three-question check.

1. Find the row for the change you made, and note its typical and slowest times.
2. If the typical time hasn’t passed, wait. Open URL Inspection and confirm the last crawl date is after your change. If Google hasn’t crawled since, the clock hasn’t started.
3. If you’re between typical and slowest, look for blockers: a robots.txt rule, a stray noindex, canonicals that disagree, a page with no internal links pointing to it, or server errors in the Crawl Stats report. Our broken link checker lists every dead link on a page, so you can repair the paths that lead to it.
4. If the slowest time has passed, treat the page as stuck. At that point the cause is usually quality or conflicting signals, so change the page or the signals, then wait for the next crawl.

Remember the stacking. A title change on an old page means up to 30 days for the refresh, then 1 to 2 days to show. Add the stages together before you decide anything is broken.

How to set client expectations with these ranges

Agencies get the most out of these numbers before work starts, not after a client asks why nothing has moved.

Here’s how we’d frame the common requests. The “Tell the client” column uses the typical ranges; “Start investigating” uses the slow end.

Change	Tell the client	Start investigating if nothing after
New page published	Found within about a day, indexed shortly after the crawl	2 weeks
Title or meta description edit	1–2 days after Google re-crawls the page (up to ~30 days on old pages)	6 weeks
Canonical or duplicate fix	1–3 weeks	6 weeks
Site migration	1–3 months to settle	3 months
Manual action reconsideration	1–2 weeks after the request	6 weeks
Core update recovery	3–6 months, or the next core update	6 months, then review the work

A migration still unsettled at three months is at the slow end of normal, not necessarily a failure. Saying that on day one saves an awkward call in month two.

If you’d rather find the blockers before the clock starts, a free RankNexus site audit checks the ones in this article: robots.txt rules, noindex conflicts, canonical problems and broken internal links. And if any of the terms here are new, the SEO, AEO and GEO glossary defines them in plain English.

Sources

• John Campbell, ROAST: Google Search Central Live Deep Dive, Barcelona – Day 3 Recap, 2 October 2026.
• Matt G. Southern, Search Engine Journal: Google Shows How Long Crawling, Indexing & Recovery Can Take, 4 October 2026.
• Barry Schwartz, Search Engine Roundtable: Google Search Data On Crawling, Indexing & Serving Timelines, 5 October 2026.
• Google Search Central: Google Search’s core updates and your website, Fix canonicalization issues, Site moves and migrations, How Google interprets the robots.txt specification, Build and submit a sitemap.
• Google Search Console Help: Removals and SafeSearch reports tool.