How Long Does Google Really Take to Crawl and Index Changes?

Short answer: On October 2, 2026, the closing day of Search Central Live Deep Dive Europe in Barcelona, Google's Gary Illyes presented typical timelines for crawling, indexing and serving. The detailed numbers currently available come from attendee reporting of that session, not from an official Google publication.

Search Central Live Deep Dive Europe is Google's own event for the search community, as Google's announcement on its Search Central Blog confirms. The session was Google's. The table of figures that has circulated since, however, comes from a recap by John Campbell of the agency ROAST, which PPC Land relayed and summarised on October 3, 2026. PPC Land itself describes these as an attendee's account of live sessions rather than a Google publication.

That distinction matters. The figures are valuable because they come from Google's own presentation, and the recap describes them as based on Google's internal analysis. But at the time of writing, Google hasn't published them as documentation, the wording of individual rows may differ from the original slides, and none of them is a commitment about how any particular website will be treated.

What Google does officially document is the underlying principle. Its guide to how Google Search works states plainly that Google doesn't guarantee it will crawl, index or serve a page, even one that follows its guidelines.

Short answer: Publishing makes a page available. It doesn't make it known, stored or visible. Between the moment you press publish and the moment a page appears for a relevant search, several separate processes have to happen, and each one takes its own time.

Google's documentation describes three broad stages: crawling, indexing and serving. Broken into the steps a business owner actually experiences, the journey looks like this:

1. 1Publish: the page or change goes live on your website. At this point, nothing outside your own site has necessarily noticed it.
2. 2Discovery: Google learns that the URL exists, usually through a link from a page it already knows or through an XML sitemap.
3. 3Crawl: Googlebot, Google's crawler, requests the page and downloads its content.
4. 4Render and process: Google runs the page's code where needed and works out what the page contains: text, links, images, structured data and signals such as canonical tags.
5. 5Index: Google decides whether to store the page in its index, and how to treat it alongside similar or duplicate pages.
6. 6Serve and rank: when someone searches, Google chooses which indexed pages to show, and in what order.

The key message is simple: publishing ≠ indexing ≠ ranking. A page can be live and undiscovered. It can be crawled and not indexed. It can be indexed and still not appear for the searches you care about.

Short answer: According to the recap of Google's Barcelona presentation, typical timelines range from about an hour and a half for indexing, once the necessary earlier steps are complete, to three to six months for recovery after a core update.

These figures represent reported typical timelines, not guaranteed processing times. Individual pages and websites may take considerably longer.

These are typical cases. The same recap makes clear that slower cases exist, and for some stages the slowest outcome is listed as "never".

One more point from the recap is worth keeping in mind: many of these processes are linked. A page can't be indexed before it has been crawled, so delays can stack.

Short answer: No. Discovery is the first step in the pipeline, not the last. A typical discovery time of around 20 hours only tells you when Google is likely to learn that a URL exists.

After discovery, Google still has to crawl the URL, process it and decide whether to index it. Ranking is a separate question entirely. Being in the index makes a page eligible to appear; where it appears depends on how relevant and useful it is compared with everything else available for that search.

Discovery itself isn't fixed, either. In our experience, how quickly a new URL is found depends largely on practical, controllable factors:

• Internal links: a new page linked from relevant, already-crawled pages gives Googlebot a clear path to it. An orphan page with no internal links is much harder to find.
• XML sitemaps: an accurate sitemap that lists the URL helps Google learn it exists. The recap puts typical sitemap processing at around 24 hours.
• Crawlability: robots.txt rules, server errors or login walls can stop Googlebot reaching a page at all.
• Crawl demand: Google's crawl budget documentation explains that more popular URLs tend to be crawled more often, so not every URL is treated the same.
• Site structure: pages buried many clicks deep in a confusing architecture are reached less easily than pages in a clear hierarchy.

None of these are ranking factors in themselves. They influence whether, and how soon, a page gets the chance to be considered. That is the day-to-day substance of technical SEO.

Short answer: Because a technically accessible page can still fail to be indexed. In the recap of Google's presentation, the slowest case for several stages, including new URL discovery, sitemap processing and indexing, is listed as "never".

It's tempting to read a table of typical timelines and focus on the fastest number. For business owners, the more important figure may be the one that sits outside the typical column: some URLs never reach the outcome their owners expected.

This is consistent with Google's own documentation, which, as noted earlier, makes no promise to index any page. Crawlable ≠ guaranteed to be indexed.

Why would Google decline to index a page it can reach? The recap attributes some of the slowest cases to quality. Google's own documentation also explains that, during indexing, it groups duplicate and near-duplicate pages and selects one as canonical, so a page that closely repeats another may be crawled but not shown as the main version.

Our interpretation is that Google is constantly judging whether a URL warrants processing and storage. In our experience, pages that add little beyond what already exists, thin service or location pages produced at scale, near-identical variants and pages sending conflicting signals are the ones most likely to sit in the "crawled but not indexed" grey zone.

That reframes the goal. Technical accessibility is a prerequisite, not a result. The real objective is a page that is accessible and worth indexing.

Short answer: AI Search doesn't remove the need for machine discoverability. Before a business can be described, cited or recommended in an AI-generated answer, its information has to be reachable, understandable and current.

The questions we hear most often from businesses now sound like this:

• "How do we get mentioned by ChatGPT?"
• "How do we appear in AI answers?"
• "How do we optimise for GEO?"

Those are valid questions. But there is an earlier one: can machines reliably discover, access, interpret and trust the information about your business?

It's important to be precise here. AI systems gather information in different ways. Some run their own crawlers, some draw on search results, some rely on what a model learned during training, and many combine several sources. We're not suggesting that ChatGPT, Perplexity or any other AI engine simply relies on Google's index. The principle is broader: whatever the system, it can only use information it is able to find, read and interpret. That is machine discoverability.

Google is the case where the connection is documented. Google's generative AI guidance says its AI features in Search are rooted in its core Search ranking and quality systems, and that SEO best practices remain relevant. In our reading, that makes the crawling and indexing pipeline described above part of the foundation for Google's AI Overviews and AI Mode, not a separate concern.

That's why we see the disciplines as layers rather than rivals:

• SEO creates much of the machine-readable foundation: crawlable pages, clear architecture, indexable content and consistent signals.
• AEO (Answer Engine Optimization) improves answer readiness: clear questions, direct answers and content structured so it can be extracted.
• GEO (Generative Engine Optimization) considers visibility across generative systems: how a business is understood, described and cited in AI-generated responses.

These disciplines increasingly overlap, and our guide to AI-driven business discovery explains how they relate. But none of them makes technical accessibility, information architecture, entity clarity, quality or freshness irrelevant. GEO tactics layered on pages that machines can't reliably reach have very little to work with.

Foundations are necessary, not sufficient. A business can rank well on Google and still be overlooked in AI answers, because being found is only the first part of being understood and chosen.

Short answer: Every search and AI system has to notice, re-process and re-store an update before it can reflect it. Publishing a correction on your website doesn't instantly change what those systems show.

Consider the kinds of changes businesses make all the time:

• Services added, renamed or discontinued
• Prices and packages
• A new location or address
• Leadership and key people
• Product information and availability
• Structured data, such as opening hours or business details
• Canonical configuration after a restructure
• Core page content and messaging

Even the reported typical figures show the lag. Structured data updates are reported at hours to one or two weeks, and canonical changes at one to three weeks. Other search engines and AI systems have their own crawling and update cycles, which generally aren't publicly documented in the same way.

In practice, outdated information can keep circulating after you've corrected it: in search snippets, in third-party listings and in AI-generated answers. For businesses in fast-moving markets, where services, pricing, teams and locations change often, that lag is a real commercial risk. A customer acting on last quarter's price or a closed branch is a lost enquiry at best.

The practical response is not to panic. It is to update important information consistently everywhere it lives, signal changed pages properly through internal links and sitemaps, and allow realistic time before judging whether an update has landed.

Short answer: Check that Google can reach the change, has processed it and is reflecting it, in that order. Google Search Console is the primary tool for doing so.

• Google Search Console: Google's own view of how it sees your site. Start here.
• Indexing status: use URL Inspection and the Page indexing report to see whether key URLs are indexed and, if not, why.
• XML sitemap: confirm it is submitted, processed without errors and lists only the URLs you want indexed.
• Internal links: make sure new and updated pages are linked from relevant, well-crawled pages.
• Canonical signals: check that canonical tags, redirects, internal links and sitemaps agree, and compare your declared canonical with the one Google selected.
• Crawlability: watch robots.txt rules, noindex directives and the Crawl stats report for unexpected blocks.
• Structured data: validate markup with the Rich Results Test and watch the relevant reports for errors.
• Server health: slow responses and server errors can reduce how much Google crawls, so watch for error spikes after a launch.
• Content quality: ask honestly whether each page adds something genuinely useful and distinct.
• Updated information: confirm each change is consistent across your website, Google Business Profile, directories and social profiles.

If AI visibility matters to your business as well, our framework for measuring AI search visibility covers the AI side of the same monitoring discipline.

Short answer: Match the measurement window to the type of change. A sitemap fix, a canonical change, a site migration and core update recovery work on very different timescales, so they shouldn't be judged on the same schedule.

We see the same pattern repeatedly. A change is made, results are checked almost immediately, and a decision is taken before the change has had any realistic chance to be processed. Sometimes good work is reversed. Sometimes a genuine problem is missed because everyone was looking at the wrong window.

A site migration shouldn't automatically be declared a failure after five days when the reported typical timeline is one to three months. That isn't a reason to wait passively, though: broken redirects, missing pages and indexing errors should be caught in the first days, which is why careful migration planning matters so much.

A canonical change shouldn't necessarily be judged after 24 hours when reported typical processing takes one to three weeks.

Recovery after a core update is a long game. The reported typical timeline is three to six months, and in our experience recovery depends on genuine improvement rather than quick fixes.

The opposite mistake matters just as much: faster indexing doesn't mean higher rankings. A page indexed in an hour is simply eligible to compete sooner.

A useful discipline is to set the review date when the change is made: what we expect to see, where we'll check, and when it is reasonable to judge. Then tie those checks to enquiries and revenue, since visibility and business growth are not the same thing.

Short answer: They are typical, reported timelines, not promises. They describe how long things usually take, not what will happen to any particular page.

• 20 hours ≠ ranking guarantee. Discovery is the first step, not the result.
• 1.5 hours ≠ every URL will be indexed. Some pages never are.
• Structured data processing ≠ rich result guarantee. Valid markup makes a page eligible; Google decides whether to show a rich result.
• Fast indexing ≠ higher rankings. Indexing makes a page eligible to compete, nothing more.
• 1–3 months ≠ every migration recovers within three months. It is a typical figure, and some site moves take considerably longer.
• Typical ≠ guaranteed. These are reported typical times, not service levels.

The interfaces of search are changing. People now discover businesses through:

• Traditional search results
• AI-generated answers
• Recommendation engines
• Conversational search
• Multimodal experiences that start with a photo or screenshot

Underneath every one of those interfaces, the requirement is the same. A business needs information that machines can:

1. 1Discover.
2. 2Access.
3. 3Understand.
4. 4Verify.
5. 5Connect to the correct entity.
6. 6Keep current.

The Barcelona timelines are a useful reminder that even the most established search system takes time, and sometimes declines, to process what businesses publish. That doesn't make AI Search optimisation less important. It makes the order of work clearer.

Our view at OMSA is simple: before asking how to become an AI citation, make sure your business has built information worth discovering, understanding and trusting.

To see how AI search currently represents your company, our AI visibility diagnostic shows what to check first. If you'd like a clear view of how search engines are reaching, processing and indexing your key pages, our technical SEO team can help. Talk to us.