You fixed the title tag at 9:02 AM. By 9:12 you had refreshed Google eleven times, and by lunch you were questioning your career choices.
Take a breath. Google typically needs about 20 hours to discover a new page, around 1.5 hours to index it once it gets there, and one to two days to update a title or snippet. So your title tag is not ignoring you. It is just standing in a queue.
A site move can take one to three months and recovery from a core update three to six months. Those figures come from internal timing data that Google’s Gary Illyes presented at a Search Central Live Deep Dive event in Europe, as reported by Search Engine Land.
If you have ever fixed something on your site and then refreshed the search results every ten minutes, you will understand why this matters. Site owners have asked for years how long Google actually takes. This is the first time Google has put numbers on it publicly, with a typical time and a worst case for each process.
The details first surfaced through John Campbell at We Are Roast, who published notes from the third day of the event and called it the best session. French SEO Neil McCarthy shared photos of the slides, and Barry Schwartz turned the numbers into a graphic.
Each process had three reference points: the fastest time, a typical time and the slowest. All of them come from Google’s internal analysis. Illyes added one caveat. Many of the steps depend on each other, so delays stack up. A page cannot be indexed before it has been crawled, for example.
These figures are not an update to Google’s documentation. Illyes said the exercise was partly to see whether the audience could relate to the numbers he had pulled together. Schwartz also noted that his graphic was made with the help of AI, so the slide photos are the safer place to check an exact figure.
Nothing else happens until Google knows a URL exists and fetches it.
Discovering a new URL typically takes about 20 hours. The slowest case runs to weeks, or never, though that is rare. Refreshing a URL Google already knows takes longer, typically around 30 days, with the same weeks to never worst case.
That second number surprises many people. A known page is not rechecked every day just because you edited it.
Sitemaps are processed in about 24 hours, but the slow tail can stretch to 14 days or never, and the slide ties that slow end to quality. A robots.txt change also takes about 24 hours, with the slowest case listed at 25 hours. Crawl demand updates take around 20 hours typically, though at the slow end they can take weeks or even months.
Crawl capacity behaves differently. A change typically takes between 4 hours and a week or two, and recovery can take one to three weeks. It can also fall in seconds if Google decides to back off, for example because your server is struggling. Coming down is fast. Climbing back up is slow.
A pattern runs through the indexing data. The smaller the signal, the quicker it settles, and the bigger the change, the longer it takes.
End to end indexing is about 1.5 hours when everything goes smoothly, but the worst case is months, or never if quality is the problem. Rendering can take seconds, though a page may sit in a queue for hours and, in the worst case, for days or weeks.
Meta annotations usually take 45 to 90 minutes, and up to four days at worst. Link annotations range from minutes to three weeks, and sometimes months. Structured data updates take hours to two weeks, and the slow end is weeks or never if quality is a concern. Images and videos typically take hours to days, but the slowest cases run to weeks or months. For videos, the slide connects the slow end to deep analysis.
Removals take one to three weeks typically and can take months. Canonicalisation changes follow a similar pattern, with months possible when signals conflict. If you have ever wondered why Google keeps showing a canonical you did not choose, conflicting signals are the likely culprit.
Site moves take one to three months typically. The worst case is six months to a year or more. A small move can be done within a few weeks.
Because the steps run in sequence, you cannot judge one in isolation. Take a brand new page. Discovery takes about 20 hours and end to end indexing about 1.5 hours, so a page can reach the index within roughly a day if all goes well.
That is back of the envelope arithmetic rather than something Google presented, and the slow end of either step can wreck it. A page stuck at discovery for weeks never reaches indexing at all.
Serving is the stage people care about most, because it is the part visible in the results.
If you own the site, removing a URL through Search Console takes about two hours on average and up to 24 hours at worst. Title and snippet updates typically appear in one to two days, though several weeks or months is possible. Images in text results usually update in one to two weeks, again with a slow tail of several weeks to months.
Manual action removals take one to two weeks typically and four to six weeks at worst. They can take much longer for dormant sites. Core update recovery is the slowest process in the whole data set. The typical range is three to six months, and the worst case is six months to a year, which effectively means waiting for the next core update. Core updates take two to four weeks to roll out, while spam updates take one or two days.
Schwartz spotted something that does not quite fit. The slides say spam updates roll out in one to two days, yet the September 2026 spam update was expected to take two weeks to fully roll out. He was also puzzled by the serving data, where the typical time for spam update changes is one to two weeks and continuously refreshed, while the slowest case is batch refreshes with months in between.
The source does not say whether Google has clarified any of this since.
Also read: AI SEO Audits vs. Human SEO Audits: Who Wins?
Schwartz’s main argument is that these timelines set realistic expectations after a change, and that they now come straight from Google. Both points hold up.
A change that has not shown up after one day is not a problem, since one day is usually too short. Titles and snippets typically take one or two days, so waiting a week already puts you toward the far end of the range.
The same logic applies to bigger operations. Migrations typically take one to three months, so worrying about a month long delay in the first few weeks tells you very little. Canonical changes and removals take one to three weeks, so a few days of lag after either is nothing to chase.
The data also gives you a point where concern is justified. A refresh of a known URL takes around 30 days on average, so if a URL has not updated after a month, something may be wrong with it, or it may never have been meant for the index.
For planning, use the slow end of each range as your benchmark. It is the number that tells you how long to wait before concluding that something is broken. Typical figures work as a baseline for expectations. Slow figures work as a deadline for investigation.
Would you have guessed that a core update recovery could take up to a year? For anyone setting expectations with a client, that single row may be the most useful one.
Notice where the phrase “or never” appears. It sits next to quality on sitemaps, structured data and end to end indexing. That suggests the quality of a page is now tied to how long its updates take to appear, though the source offers no further explanation.
The gaps between typical and slowest figures are very wide on almost every row. The published numbers also give no reason to believe one site will land at the quick end while another waits at the slow end. Apart from naming quality as a factor for some of the slowest cases, nothing explains why.
When everything goes smoothly, a new page can be in the index within about a day. Discovery typically takes about 20 hours and end to end indexing about 1.5 hours. That calculation is simple arithmetic rather than a figure Google presented, and the slowest cases run to weeks, months or never.
Titles and snippets typically update within one to two days. Waiting longer than that is not unusual, since the slowest cases take several weeks or months. A delay of a few days is not a reason to change anything.
Refreshing a known URL typically takes about 30 days. If a URL is still unchanged after a month, there is good reason to suspect either a problem with the page or that it was never meant to be indexed.
Site moves typically take one to three months, and the worst case is six months to a year or more. A small move can be completed in a few weeks.
A robots.txt change typically takes about 24 hours to be picked up, and the slowest figure on the slide is 25 hours.
Core update recovery typically takes three to six months. The worst case is six months to a year, which means waiting for the next core update. The rollout of a core update itself takes two to four weeks.
If you are the site owner, removal through Search Console typically takes about two hours and up to 24 hours at worst. Removals handled through normal indexing are slower, typically one to three weeks.
No. They are Google’s internal estimates, shown at a live event. Illyes described them as numbers he pulled together to see whether the audience could relate to them. For ongoing guidance, keep an eye on the official Google Search Central documentation.
Related searches: