Google puts numbers on site moves and core update recovery
Summary
The ranges reported from Gary Illyes' Barcelona session give SEO teams something to hold a client timeline against. They come from an attendee recap rather than Google's documentation, and nothing in them defines what counts as typical.
Used as escalation triggers they still work: a canonical change or a site move past its typical window is a defect to investigate, not a wait to extend.
Google’s Gary Illyes gave typical and slowest times for common Search processes at Search Central Live Deep Dive Europe in Barcelona on October 2, among them about 20 hours to discover a new URL. Search Engine Journal’s writeup reports that the figures come from Google’s internal analysis.
None of it is published anywhere Google controls. The figures circulate through a recap of the session by John Campbell of ROAST, a search agency, who was one of the event’s community speakers, and the slides do not appear on Google’s Search Central events page. Neither the recap nor Google gives a sample size, a measurement period, or a definition of “typical,” and the recap leaves out the fastest times it says each process had.
Six of the processes cover most of what an SEO team gets asked to forecast.
| Process | Typical | Slowest |
|---|---|---|
| Discovery (new URL) | ~20 hours | Weeks to never |
| Refresh (known URL) | ~30 days | Weeks to never |
| Canonicalization change | 1 to 3 weeks | Months |
| Manual action removal | 1 to 2 weeks | 4 to 6 weeks, or longer for dormant sites |
| Site move | 1 to 3 months | 6 months to 1 year+ |
| Core update recovery | 3 to 6 months | 6 months to 1 year |
Quoted as deadlines, the figures will make whoever cites them wrong in front of a client. Quoted as escalation triggers, they do real work. The typical column marks the point where waiting stops being a plan and the change becomes something to investigate.
Illyes warned that the processes feed each other, per Campbell’s recap. A page has to be crawled before it can be indexed, so a delay at an early stage lands on every stage after it. That makes the stage figures additive rather than alternatives. The recap lists about 1.5 hours as the typical end-to-end indexing time, and the likelier reading is that the clock starts after Google has found the URL, not when the page goes live. A canonical change runs on the same dependency. When a canonical has not resolved in three weeks, the first check is the last crawl date in URL Inspection, because a URL Google refreshes on a roughly monthly cycle cannot process the change any sooner.
The site move row reads differently depending on site size. Google’s site-move documentation says a small to medium-sized website can take a few weeks for most pages to move, while larger sites take longer. The recap allows that a small move can be done in a few weeks as well, which leaves the 1 to 3 month figure as the one to use on large sites. A move that has not settled at three months is at the top of the typical range rather than inside it, and that is the moment to go looking for a defect in the redirect chains, the canonicals or the internal links. Where a migration is already costing revenue, that marker is not the one that matters.
Core update recovery is the row most likely to be misread, since the 3 to 6 months describes recovery after a site has made changes, not how long the update itself runs. Google’s core update guidance says some changes can take effect in a few days but that it could take several months for its systems to learn, and that no effect after a few months can mean waiting until the next core update. The typical figure is the window in which to finish the work, not the window in which to expect the reversal.
Five of the slowest entries in the recap’s tables are “never,” and three of those, for sitemap processing, end-to-end indexing and structured data updates, add “quality” in parentheses. No timing range helps a URL Google has decided is not worth indexing, and a page can sit indexed and still never get served. An overdue change on any of those three processes is better treated as a quality judgment than as a queue.
What to do
- Write down the typical figure for whatever you ship and book the review for that date. Checking a 30-day refresh cycle daily produces anxiety, not information.
- Check the last crawl date in Search Console’s URL Inspection before escalating a title, snippet or canonical change. The change cannot process on a URL Google has not refetched.
- Attribute the numbers to the attendee recap, not to Google, in anything a client reads. The slides are not public and the definition of typical is not given.
- Escalate at the top of the typical range rather than the bottom of the slowest. Three months on a site move and six months on core update recovery are investigation triggers.