How Long Does Google Take to See Changes on Your Website: Google’s Data on Crawling, Indexing and Serving

Google doesn’t see changes on your website instantly: according to Google’s internal estimates, it finds a new page in about 20 hours on average, the full indexing cycle takes ~1.5 hours, and a new title and snippet appear in search results after 1–2 days. But these are typical figures: for weak pages they stretch to weeks and months, and recovery after a core update takes 3–6 months. Below are Google’s slides with an explanation of every metric, plus a summary table.
Where the data comes from and why you can trust it
The figures in this article come from a presentation by Gary Illyes of Google at the three-day Google Search Central Live Deep Dive event in Barcelona. John Campbell (We Are Roast) was the first to share these slides, and Barry Schwartz published the data on Search Engine Roundtable. All time values on the slides are estimates based on Google’s internal analysis, not guarantees and not public SLA documentation.
Illyes’s own key caveat: many of these processes depend on each other, so delays add up. A page can’t be indexed until it has been crawled, and a new title won’t appear in search results until the page has been reindexed. So the time from an edit to a visible result is the sum of several stages.

How to read Google’s slides: one line, one process
Each slide is made of rows, and every row is one process, for example sitemap processing. The process is drawn as a line: the further right, the longer it takes. At the top there is a scale with six divisions: seconds, minutes, hours, days, weeks, months (plus a “1 Year” mark in the right corner). The divisions have equal width, but each next one covers a much longer span of time.

A line can carry up to four marks. The legend at the bottom of every slide explains them:
- Dark square on the left (Minimum starts here) — the fastest it ever gets. The lower bound.
- Coloured dot (Typical sits on this line) — how it usually goes. If the dot is a stretched “capsule”, the typical time is a range, for example “4 hours / 1–2 weeks”.
- Dark square on the right (Can be up to this end point) — the slowest it gets. The upper bound.
- Dotted line (Corner case) — a rare exception when the process may never finish at all. On the slides such dotted lines are labelled “or never (quality)” — “or never, if the page is weak in quality”.
Example. The “Sitemap Processing” row: the dot sits near ~24 hours, the right square says “up to 14 days”, and then comes a dotted line “or never (quality)”. We read it as: “Google usually processes a sitemap in about a day, sometimes up to two weeks, and for weak pages never”.
The colour of the dot shows the stage: orange — crawling (Crawl), blue — indexing (Index), green — serving (Serving). Below is a diagram of how these three stages follow one another.

Next, we go through each of the three slides: what every row means, how long it typically takes and what it means for your site. All times are taken from Google’s slides; the explanations of what hides behind each process name are ours.
Crawl: how fast Google finds and re-reads pages
Crawling is the moment Googlebot visits a URL and downloads the page. Without it, no change goes any further. The slide is titled “How long does it take to… Crawl”.

| Metric on the slide | What it means | Typical | Slowest |
|---|---|---|---|
| Discovery (New URL) | From a new URL appearing to Google finding and crawling it | ~20 hours | Weeks or never |
| Refresh (Known URL) | How quickly Google returns to a known page and sees the edits | ~30 days | Weeks or never |
| Sitemap Processing | How long it takes Google to process a new or updated sitemap | ~24 hours | Up to 14 days or never (quality) |
| Robots.txt Update | How long it takes Google to see a new version of robots.txt | ~24 hours | 25 hours |
| Crawl Capacity Update | How many pages Google is willing to crawl without overloading your server | 4 hours — 1–2 weeks | 1–3 weeks (recovery) |
| Crawl Demand Update | How much Google wants to crawl your site (popularity, freshness) | ~20 hours | Weeks — months |
What’s worth noticing here:
- A new page is found faster than an old one is re-read. Google finds new URLs in ~20 hours, while the typical point for refreshing an already known page is ~30 days. So changes on old pages may be picked up more slowly than newly published pages.
- Crawl capacity drops in seconds and recovers over weeks. Next to this row, the slide is labelled “secs (in back-off)” at the start of the line and “1–3 weeks (in recovery)” at the end. If your server starts returning errors or slowing down, Google sharply reduces its crawl rate, and returns to the previous level only slowly. We cover this in more detail in our article about crawl budget.
- robots.txt doesn’t take effect immediately. Google typically picks up a new version in ~24 hours, at most 25. Don’t “test” disallow rules on a live site. What this file is and how to write it is covered in the article about robots.txt.
- A sitemap doesn’t speed things up by magic. Processing takes ~24 hours, up to 14 days, and the dotted line on the slide means that for low-quality pages a sitemap may not help at all. More about the file in the article on sitemap.xml.
Index: when a page gets into Google’s database
After crawling, Google processes the page: it executes JavaScript, collects signals about the document itself and about links pointing to it, and decides whether to add it to the index. The slide is titled “How long does it take to… Index”.

| Metric on the slide | What it means | Typical | Slowest |
|---|---|---|---|
| Rendering | Executing JavaScript and building the final page. Seconds is the render itself, hours is the time spent waiting in the queue | Seconds (render) / hours (queue) | Days — weeks |
| Meta Annotations | Signals Google derives from the page itself: language, canonical, directives, etc. | 45–90 minutes (minimum 200 s) | 1–4 days |
| Link Annotations | Signals from links pointing to the page: internal and external, their anchors | From minutes to 1–3 weeks | Months |
| Indexing (End-to-End) | The whole cycle: all critical processes completed successfully | ~1.5 hours | Months or never (quality) |
What to pay attention to:
- ~1.5 hours doesn’t mean “your page is in the index after an hour and a half”. It’s the typical time of the indexing process itself after the page has already been crawled. The overall path is crawling (~20 hours) plus indexing, and for weak pages the figure on the slide ends with the words “months or never (quality)”.
- Rendering is critical for JavaScript sites. If content appears only after scripts run, the page first waits in the rendering queue — that’s why the slide says “hrs (queue)”. Content in plain HTML skips this step.
- Link annotations is the most stretched metric. Signals from links accumulate over anywhere from minutes to several weeks, so new link building doesn’t work immediately.
- The word “quality” on the slide is not decoration. For “or never”, Google states the reason directly: quality. This matches the experience of pages hanging in Search Console for months with the status “Discovered – currently not indexed”.
Google’s table, which we showed at the beginning, has six more indexing processes that aren’t on this slide:
| Process | Typical | Slowest |
|---|---|---|
| Removal from crawling and the index (Removal) | 1–3 weeks | Months |
| Canonical page change (Canonicalisation change) | 1–3 weeks | Months (conflicting signals) |
| Site move (Site move) | 1–3 months | 6 months — over a year |
| Structured data update | Hours — 1–2 weeks | Weeks or never (quality) |
| Images | Hours — days | Weeks — months |
| Video | Hours — days | Weeks — months (deep analysis) |
Google also stresses separately: “end to end” means all critical processes finished successfully, and a small site move can be completed in a few weeks. If you’re planning a domain or structure change, use our SEO checklist for site migration, and for changing the canonical address read the article about the canonical tag.
Serving: when changes become visible in search results
The third stage is when updated information reaches people: the title, snippet and the image next to the result change, and algorithmic updates and penalties are applied. The slide is titled “How long does it take to… in Serving”.

| Metric on the slide | What it means | Typical | Slowest |
|---|---|---|---|
| Removal on SC (Owner) | Temporarily hiding a URL with the Search Console removal tool, available to the site owner | ~2 hours (from minutes) | 24 hours |
| Snippet Update | When a new page description appears in search results | 1–2 days | Several weeks — months |
| Text Result Image Update | When the image next to a text result changes | 1–2 weeks | Several weeks — months |
| Title Update | When a new title appears in search results | 1–2 days | Several weeks — months |
| Manual Action Removal | When a manual action is lifted after a fix (minimum 2–3 days) | 1–2 weeks | 4–6 weeks, and much longer for “dormant” sites |
| Core Update Change | How long positions take to recover after a core update. The rollout itself takes 2–4 weeks | 3–6 months | 6 months — a year (until the next core update) |
| Spam Update Change | When the effect of a spam update becomes visible. The rollout itself takes 1–2 days | 1–2 weeks (continuous) | Months (batch updates) |
What this means for your website:
- The title and snippet update in 1–2 days, but only if the page has already been reindexed. If you changed the Title and nothing has changed after a day, that’s still normal. It’s worth getting concerned after 2–3 weeks.
- Google may rewrite the title and snippet on its own. So even an updated Title doesn’t always match what you put in the markup.
- The Search Console removal tool works in ~2 hours, but only temporarily. It hides the URL in search results. To remove a page permanently you need a 404 or 410 status code, or a noindex directive, and that already means weeks to months, as in the indexing table. Read about the consequences in the article on site deindexing.
- A core update is a marathon. It rolls out over 2–4 weeks, and recovery typically takes 3–6 months; if the site didn’t manage to fix its issues before the next core update, the delay stretches from 6 months to a year. Judging the results of your fixes after 2–3 weeks makes no sense.
- Manual actions take longer to lift for “dormant” sites. For them Google states directly “much longer (dormant sites)”.
What this means in practice
- Don’t panic before 1–2 days. For a new page, ~20 hours for discovery plus an hour or two for indexing are typical. Check with the URL Inspection tool in Search Console, not by searching for the page in the results.
- Until a page is crawled, the remaining stages don’t start. If a new URL still hasn’t appeared after 2–3 weeks, look for the cause in quality, internal links and technical blocks, rather than repeating “Request indexing”.
- Watch your server’s performance. Crawl capacity drops in seconds and recovers over 1–3 weeks. A single overnight series of 5xx errors can slow crawling for a long time.
- Build time into your plans. A site move takes 1–3 months, recovery after a core update 3–6 months, a structured data change up to 2 weeks. These are normal timeframes, not a sign that something is broken.
- Change one thing at a time and record the date. Because the stages are interlinked, if you change the Title, canonical and structure at once, you won’t know what actually worked. An annotation in GSC is the cheapest way to keep a record.
- Don’t promise clients dates. All values on the slides are estimates, not guarantees. We explained why SEO has none in the article “Why there are no guarantees in SEO”.
Summary table: how long each change takes
We put everything into one table: all 23 processes from Google’s slides and table, the typical and slowest times, and a practical takeaway. All values are Google’s estimates based on its internal analysis.
| Stage | Process | Typical | Slowest | What to do |
|---|---|---|---|---|
| Crawl | Discovery of a new URL | ~20 hours | Weeks or never | Add internal links and a sitemap, don’t expect instant results |
| Crawl | Refresh of a known URL | ~30 days | Weeks or never | New pages are found faster than old ones are revisited |
| Crawl | Sitemap processing | ~24 hours | Up to 14 days or never | A sitemap doesn’t replace page quality |
| Crawl | Robots.txt update | ~24 hours | 25 hours | Don’t test disallow rules on a live site |
| Crawl | Crawl capacity | 4 hours — 1–2 weeks | 1–3 weeks (recovery) | Avoid errors and server slowdowns |
| Crawl | Crawl demand | ~20 hours | Weeks — months | Keep content fresh and high quality |
| Index | Rendering | Seconds / hours in the queue | Days — weeks | Keep important content in HTML, not only in JS |
| Index | Meta annotations | 45–90 minutes | 1–4 days | Check canonical and directives before publishing |
| Index | Link annotations | Minutes — 1–3 weeks | Months | The effect of links is not instant |
| Index | Full indexing (end-to-end) | ~1.5 hours | Months or never (quality) | Weak pages may never make it into the index |
| Index | Removal | 1–3 weeks | Months | For permanent removal: 404/410 or noindex |
| Index | Canonical change | 1–3 weeks | Months | Don’t send conflicting signals |
| Index | Site move | 1–3 months | 6 months — over a year | Plan the migration with a checklist and don’t rush to conclusions |
| Index | Structured data | Hours — 1–2 weeks | Weeks or never (quality) | Check markup in a validator, not in search results |
| Index | Images | Hours — days | Weeks — months | Give images alt text and proper URLs |
| Index | Video | Hours — days | Weeks — months | Video is indexed more slowly than text |
| Serving | Removal in Search Console | ~2 hours | 24 hours | This is temporary hiding, not permanent removal |
| Serving | Snippet update | 1–2 days | Weeks — months | Don’t change the description every day |
| Serving | Title update | 1–2 days | Weeks — months | Wait at least 2–3 weeks |
| Serving | Image next to the result | 1–2 weeks | Weeks — months | Update the image together with the page |
| Serving | Manual action removal | 1–2 weeks | 4–6 weeks and longer | Allow more time for “dormant” sites |
| Serving | Changes after a core update | 3–6 months | 6 months — a year | Don’t judge the result sooner than after several months |
| Serving | Changes after a spam update | 1–2 weeks | Months | Remove spammy practices and wait for batch updates |
In addition: a core update rolls out over 2–4 weeks, a spam update over 1–2 days, and crawl capacity can drop within seconds if Google “backs off” from a problematic server.
When to bring in an agency
If you don’t understand which stage a page is stuck at (it hasn’t been crawled, hasn’t been indexed or isn’t being shown), the answer is usually in the server logs, Search Console and a technical audit. You also need help when you’re planning a migration, a move to a new CMS or a structure change and don’t want a traffic drop.
At Spilno Agency we run technical SEO audits, handle site migrations and explain to clients what to expect and when.
FAQ about Google crawling and indexing timelines
How long does it take Google to index a new page?
According to Google’s estimates, discovering a new URL takes ~20 hours, and indexing itself after crawling takes ~1.5 hours. But for pages of weak quality this process can take months or never complete at all.
How long does it take Google to update the Title and snippet?
Typically 1–2 days after reindexing, and in the slowest cases several weeks or even months. Google may also rewrite the title and snippet on its own.
How long does recovery after a core update take?
The update itself rolls out over 2–4 weeks, and positions typically take 3–6 months to recover. If the site didn’t manage to fix its issues before the next core update, it’s from 6 months to a year.
How long does a site move take?
Typically 1–3 months, and in the slowest cases from 6 months to over a year. A small move can be completed in a few weeks.
Does a sitemap speed up indexing?
It helps Google find pages: processing takes ~24 hours, up to 14 days. But a sitemap doesn’t guarantee indexing, especially for low-quality pages.
Why is Google taking so long to show my changes?
Often the reason is that the page hasn’t been reindexed yet: the typical point for refreshing a known URL is ~30 days. Check with the URL Inspection tool in Search Console whether Google has seen the new version, and only then wait for the Title and snippet to update.


