One of the hardest things to explain in SEO is time.
You can identify a problem today, implement the correct fix tomorrow and still see very little movement for weeks afterwards.
That creates an awkward gap between when the work is completed and when the result of that work becomes visible.
For years, SEOs have generally understood this. We know Google needs to discover changes, crawl pages, process signals, update its index and eventually reflect those changes in search results.
What we haven't had is much clarity from Google on how long the individual stages can actually take.
That changed at Google's Search Central Live Deep Dive Europe event in Barcelona.
On 2 October, Google's Gary Illyes presented internal timing data covering crawling, indexing and serving. The figures were subsequently shared by attendees including John Campbell from ROAST and reported by Barry Schwartz at Search Engine Roundtable.
And some of the numbers are worth paying attention to.
Google can discover a page quickly. That doesn't mean SEO happens quickly.
The headline figures create an interesting contrast.
According to the data presented, Google typically discovers a new URL in around 20 hours.
End-to-end indexing can take around 1.5 hours once the relevant processes are running.
That sounds incredibly fast.
But a refresh of a URL Google already knows about typically takes around 30 days.
A canonicalisation change can take one to three weeks.
A site migration can take one to three months.
And recovery following a core update can take three to six months.
In slower cases, some of those processes can take considerably longer.
That distinction matters.
SEO isn't one process called "Google".
It is a collection of systems operating on different timescales.
Google's reported SEO timelines
The data shared at the event gives us a useful indication of what "typical" actually looks like.
| Process | Typical timeframe |
|---|---|
| Discover a new URL | ~20 hours |
| Refresh a known URL | ~30 days |
| Sitemap processing | ~24 hours |
| robots.txt update | ~24 hours |
| Crawl capacity update | 4 hours to 1-2 weeks |
| Crawl demand update | ~20 hours |
| Rendering | Seconds, potentially hours in the queue |
| Meta annotation processing | 45-90 minutes |
| Link annotation processing | Minutes to 1-3 weeks |
| End-to-end indexing | ~1.5 hours |
| Removal from the index | 1-3 weeks |
| Canonicalisation change | 1-3 weeks |
| Site move | 1-3 months |
| Structured data update | Hours to 1-2 weeks |
| Title change appearing | 1-2 days |
| Snippet change appearing | 1-2 days |
| Search Console removal | ~2 hours |
| Manual action recovery | 1-2 weeks |
| Core update recovery | 3-6 months |
| Spam update change | 1-2 weeks |
Crawl capacity can drop in seconds when Google backs off, for example if your server struggles.
There are much slower ranges too.
| Process | Slowest timeframe |
|---|---|
| Discover a new URL | Weeks to never |
| Refresh a known URL | Weeks to never |
| Sitemap processing | Up to 14 days, or never (quality) |
| robots.txt update | 25 hours |
| Crawl capacity update | 1-3 weeks (in recovery) |
| Crawl demand update | Weeks to months |
| Rendering | Days to weeks |
| Meta annotation processing | 1-4 days |
| Link annotation processing | Months |
| End-to-end indexing | Months or never (quality) |
| Removal from the index | Months |
| Canonicalisation change | Months (conflicting signals) |
| Site move | 6 months to more than a year |
A site move, for example, can take six months to more than a year in the slowest cases. Core update recovery can extend to the next core update. Indexing may take months - or not happen at all where quality becomes a factor.
These aren't service-level agreements from Google.
The slides haven't been formally published by Google at the time of writing, and we don't have the sample sizes or methodology behind what Google classifies as "typical". They should therefore be treated as useful reference ranges rather than deadlines.
But they tell us something important.
SEO has a latency problem
I've always thought there is a fundamental problem with the way SEO performance is sometimes evaluated.
We treat the date something was changed as though that is the date the experiment started.
It isn't.
Imagine I change the canonical on an important commercial page today.
From my perspective, the work is finished.
But Google now needs to:
- discover the updated page,
- crawl it,
- render it where necessary,
- process the relevant annotations,
- reconcile potentially conflicting canonical signals,
- update the index,
- and then reflect those changes across its search systems.
If Google's typical timeframe for processing a canonicalisation change is between one and three weeks, judging the impact five days later tells me very little.
The same problem becomes much larger with significant site changes.
A developer might complete a migration on Friday.
The SEO team might sign it off on Monday.
The board might expect an answer about performance by the end of the month.
Google is telling us that the underlying process can typically take one to three months.
The technical work finishing and Google finishing are two completely different things.
A 30-day refresh cycle is particularly interesting
The figure I find most interesting is probably not the 20-hour discovery figure.
It's the 30-day typical refresh time for a known URL.
Most SEO work isn't publishing completely new websites.
We're changing existing ones.
We rewrite content.
Change internal links.
Update metadata.
Alter page templates.
Improve category pages.
Change canonicals.
Consolidate content.
Add or remove sections.
Fix technical problems.
If a URL Google already knows takes roughly 30 days to refresh under typical circumstances, there is an obvious problem with making conclusions too quickly.
You make a substantial content change on 1 October.
Two weeks later, rankings haven't improved.
Was the change ineffective?
Maybe.
Or Google may not have fully processed the change yet.
Making another major change at that point can make the situation worse because you've now changed the variable before the first test has had enough time to produce a meaningful result.
SEO teams can quite easily optimise themselves into circles.
Crawling is not indexing, and indexing is not ranking
The other useful reminder from this data is how dangerous it is to collapse Google's entire process into the word "indexing".
A page can be discovered without being crawled.
It can be crawled without being indexed.
It can be indexed without ranking particularly well.
And individual signals associated with that URL can be processed at different speeds.
Google says link annotation processing, for example, can typically take anywhere from minutes to one to three weeks.
Canonicalisation changes typically take a similar amount of time.
Structured data changes can take hours or weeks.
A title might change in the search results within a couple of days.
These things aren't happening simultaneously.
So when somebody asks:
"How long does it take Google to recognise a change?"
The correct answer is increasingly:
Which change?
This also changes how we should think about SEO recovery
The three-to-six-month figure for recovering from a core update will probably attract the most attention.
But I think it needs interpreting carefully.
It does not mean that every site hit by a core update simply needs to wait six months.
Waiting isn't a strategy.
If a site has poor content, weak architecture, technical problems, conflicting signals or a broader quality issue, time doesn't solve those problems.
They still need fixing.
What the data tells us is that fixing the cause and recovering from the cause are separate events.
You could identify the problem correctly.
Make the right changes.
Improve the site materially.
And still need to wait for Google's systems to reassess enough of the site and its signals before the full impact becomes visible.
That difference matters enormously when diagnosing a recovery.
One of the biggest mistakes in SEO is changing too much, too quickly
There is a natural reaction when SEO performance falls.
Do something.
Then, if that doesn't work immediately, do something else.
Change the content.
Change the URL.
Change the template.
Alter the internal linking.
Merge another page.
Change the title again.
Add more content.
Then six weeks later you have made twelve different changes and no longer have any idea which one caused what.
Google's timing data is another argument for being more disciplined.
Make changes for a reason.
Record when they happened.
Understand which Google processes the change depends upon.
Give those processes a realistic amount of time.
Then evaluate the result.
That isn't the same as passively waiting.
It's measurement.
It should also change client expectations
Anyone who has worked agency-side will recognise this conversation.
Monday: SEO team identifies the problem.
Wednesday: development implements the fix.
Friday: client asks whether rankings have recovered.
The temptation is to give a vague answer about SEO "taking time".
Now we have something a little more concrete.
A simple expectation model might look something like this:
Hours to days: Google can discover new URLs, process sitemaps and begin recognising straightforward changes.
Days to weeks: titles, snippets, structured data, links, canonicals and other signals can begin to update.
Weeks to months: significant architectural changes and site migrations settle.
Months: reassessment and recovery from broader algorithmic or quality issues may become visible.
That is a far better framework than saying SEO takes three months.
Because SEO doesn't take three months.
Different parts of SEO take different amounts of time.
Faster crawling doesn't necessarily mean faster outcomes
This distinction is becoming increasingly important as SEO tooling gets faster.
We can crawl a website in minutes.
We can identify technical issues almost instantly.
AI can help analyse hundreds of thousands of URLs quickly.
Development teams can deploy fixes continuously.
Google isn't necessarily working on the same clock.
The speed at which we can identify and implement a change has increased dramatically.
The speed at which every downstream Google system processes that change has not necessarily increased at the same rate.
That creates an interesting situation.
The bottleneck in SEO is increasingly not our ability to make changes.
It can be our ability to wait long enough to measure them properly.
The bigger lesson from Google's numbers
The individual figures are useful.
Twenty hours for discovery.
Thirty days for a refresh.
One to three weeks for canonicalisation.
One to three months for a site move.
Three to six months for core update recovery.
But I think the bigger lesson is more important.
Google Search is asynchronous.
There isn't a single moment when Google "sees the change".
Different systems see different things at different points in time.
And that should affect how we diagnose problems, run experiments, communicate results and make decisions.
Sometimes an SEO change doesn't work.
Sometimes we made the wrong diagnosis.
Sometimes a site genuinely needs much more substantial work.
But sometimes the answer is considerably simpler:
Google hasn't finished yet.
