Your canonical fix went live three weeks ago, and Search Console still shows the old URL. Is Google being slow, or is something broken?
Search Engine Journal reports that Google's Gary Illyes showed timing ranges for crawling, indexing, site moves and recovery at Search Central Live Deep Dive Europe in Barcelona. This guide turns those ranges into a triage workflow you can run on any pending change.
Read the numbers for what they are
The figures come from an attendee recap of the Oct. 2 session, written by John Campbell of ROAST. They are not published Google slides, and the report says the slides did not appear on Google's Search Central events page at the time of publication.
The recap lists a fastest, typical and slowest time for each process, attributed to Google's internal analysis. According to the report, it gives no sample size, no measurement period and no definition of "typical." The tables also leave out the fastest times.
Treat every range below as a reference point, not a deadline. Don't promise a client that a change will land by a date, and don't promise any ranking or traffic result. Indexing status is not a ranking outcome.
One more detail matters. Illyes warned that the processes are interconnected: a page must be crawled before it can be indexed, so delays accumulate. A slow crawl can look like an indexing problem.
Step 1: Place your change on the timeline
Write down the ship date and count the days elapsed. Then find your change type in the table. Figures come from the attendee recap as reported by Search Engine Journal, except where noted.
| Change type | Reported typical | Reported slowest | First check to run | |---|---|---|---| | New URL discovery | About 20 hours | Not given in the report | Sitemaps report, then server logs for the first Googlebot request | | Refresh of a known URL | About 30 days | Not given in the report | URL Inspection: last crawl date | | Title and snippet update | 1 to 2 days | Several weeks to months | URL Inspection: compare live page to indexed version, then check the displayed title | | Canonical change | Pages can stay in a duplicate cluster up to two weeks after content fixes (Google's troubleshooting guide, as cited in the report) | Not given in the report | URL Inspection: user-declared vs. Google-selected canonical | | Small site move | A few weeks; three months is the high end of typical | The report says the slowest cases in the recap run from six months to over a year, without tying that to one process | Page indexing report plus logs for old and new URLs | | Removal request in Search Console | About 2 hours | 24 hours | Removals report status | | Manual action removal | 1 to 2 weeks | 4 to 6 weeks, much longer for dormant sites | Manual actions report | | Core update recovery | About 3 to 6 months | 6 months to a year, shown as the "next core update" | No technical check; compare your fixes to update dates |
The report notes that five of the slowest times in the recap include "never." Three of them (sitemap processing, end-to-end indexing and structured data updates) add "quality" in parentheses. The report doesn't explain these entries, so don't treat them as diagnostics. One cautious reading, which is my inference, is that a page that never gets indexed may have a content-value problem rather than a timing problem.
Now sort your change into one of three zones:
- Under the typical range: log it and do nothing else.
- Between typical and slowest: run the checks below.
- Past slowest: assume a fault until a check proves otherwise.
Step 2: Run the first check for your change type
The table names one check per change. Here is what each one tells you.
URL Inspection
Inspect the exact URL. Record the last crawl date, whether indexing is allowed, the crawl status, and the user-declared and Google-selected canonicals. Then run the live test and compare it to the indexed version. If the live page shows your new title and the indexed version doesn't, Google has not reprocessed the page yet.
Page indexing report
Find the URL's status. "Discovered - currently not indexed" points at the crawl stage. "Crawled - currently not indexed" means Google fetched the page but has not indexed it. "Duplicate, Google chose different canonical than user" points at a canonical conflict. A noindex or robots block is a fault you fix, not a delay you wait out.
Sitemaps report
Confirm that Google read the sitemap, and note the last-read date and the discovered URL count. A sitemap that was never read, or that lists redirected or non-canonical URLs, explains slow discovery. See related: turn off shopify agentic storefronts? audit settings first for additional background.
Server logs
Search for Googlebot requests to the URL and record the dates and status codes. Verify that the requests come from genuine Googlebot rather than a spoofed user agent. No hits means a crawl-stage problem. Hits that return 200 mean the bottleneck sits later.
Canonical comparison
For each affected URL, line up four signals: the rel=canonical tag, the redirect target, the sitemap entry and internal links. If they disagree, Google has a reason to pick its own canonical. Fix the disagreement before you blame timing.
Step 3: Find the bottleneck stage
Delays carry forward, so work from the earliest stage to the latest and stop at the first failure.
- Discovery. Is the URL in a sitemap and linked internally? If not, fix that first.
- Crawl. Do the logs show Googlebot requesting the URL and getting a 200? If not, check robots.txt, server errors and redirect chains.
- Processing. Does URL Inspection show a recent crawl but an old indexed version? Google has the page and hasn't finished with it. Waiting is reasonable while you're inside the ranges.
- Canonical selection. Does the Google-selected canonical differ from the user-declared one? Resolve the conflicting signals.
- Indexing. Is the page crawled and unique but excluded? Review content value and duplication.
The first stage that fails is your bottleneck. A clean pass through all five, with elapsed time inside the ranges, is your evidence for "wait."
Step 4: Decide whether to wait, fix, resubmit or escalate
Apply these rules in order:
- Wait when elapsed time is under the slowest range and every check passes.
- Fix when any check finds a block, a conflict or a broken signal.
- Resubmit only after a fix. That means a sitemap update or an indexing request on a handful of key URLs. Resubmitting won't clear a systemic fault.
- Escalate when time has passed the slowest range, every check is clean and you can hand over documented evidence, for example in the Search Central help community.
Core update recovery is the exception, because no Search Console check can show a stall. Google's core update documentation, as summarized in the report, says some changes can show effects within days, but confirming overall improvement can take several months. It also says that if you see no effect after a few months, you may be waiting for the next core update. Document what you improved and when, then reassess after the next update.
Worked example (hypothetical): a small site move
This scenario is invented to show the method. The domain, dates and findings are illustrative, not real data.
A small brochure site moves from oldbrand.example to newbrand.example on a Monday, with page-to-page 301 redirects.
Week 1. Capture the baseline: a crawl of the redirect map showing each old URL returning a 301 to a 200 page, robots.txt for both domains, and the submitted sitemap on the new property. Inspect five sample URLs (home page, two top pages, two deep pages) and save screenshots. Nothing is expected yet.
Week 2. Pull the logs. Say Googlebot is requesting old URLs and following the 301s, and has begun requesting new ones. Save the log lines. They confirm the crawl stage is moving.
Week 5. Elapsed time now exceeds "a few weeks" but sits well inside the three-month high end of typical. Re-inspect the five samples. Suppose four show the new URL as the Google-selected canonical and one still shows the old one. Check that one URL's redirect and internal links. If both are clean, the decision is wait, with a recheck set for week 8.
Now suppose instead that the Page indexing report shows the new URLs as "Discovered - currently not indexed" and the logs show no Googlebot requests to them. That is a crawl-stage fault at week 5, and waiting is the wrong call. Check the new domain's robots.txt, server responses and sitemap first.
Month 3. You are at the high end of typical. Suppose the samples still show the old canonical, but the logs show Googlebot hitting the new URLs and getting 200s, and you find no fault to fix. Document everything and escalate with the evidence package. If you instead find a stray noindex or a conflicting canonical tag, fix it and restart the clock from the fix date.
In every branch, the log tracks crawl, canonical and index status. It says nothing about rankings or traffic.
Step 5: Log the decision and write the client note
Use one row per change. The row shows that you made the decision on evidence.
| Field | What to record | |---|---| | Date shipped | Deployment date and time, with timezone | | URLs affected | Full list, or a sample set plus the pattern for large changes | | Change type | From the Step 1 table | | Reported range used | Typical and slowest, labeled "attendee recap, not official" | | Verification method | URL Inspection, Page indexing report, Sitemaps report, crawl logs | | Checks run | Date of each check, result and screenshot or log reference | | Bottleneck stage | Discovery, crawl, processing, canonical or indexing | | Decision | Wait, fix, resubmit or escalate, with the reason | | Next review date | A specific date, not "soon" |
For the client, a short template works:
"This change shipped on [date]. Reported timing ranges for this process put typical completion at [range]. We are at day [n]. We checked [methods] on [date] and found [result]. We are [waiting until / fixing / escalating], and we will review on [date]. These ranges are reference points from an attendee recap, not guarantees, and we cannot promise ranking or traffic outcomes."
What to expect next
"Wait" is a legitimate decision when the evidence backs it. Revisit the ranges if Google publishes the slides or defines "typical," since the numbers could shift once the sample size and method are known. Until then, rerun the checks on your review dates and let the log, not the calendar alone, tell you when waiting has stopped being the right answer.
