Google Says Recovery Takes 3 to 6 Months, So Stop Judging SEO Fixes at Week Two

Google's Gary Illyes shared typical timing ranges for crawling, indexing and recovery at Search Central Live Deep Dive Europe in Barcelona on October 2, 2026, Search Engine Journal reported. Known URLs get refreshed roughly every 30 days, and core update recovery typically takes 3 to 6 months. Any SEO fix judged on a two-week dashboard is being judged before Google has even seen it.

None of these numbers are shocking on their own. Most SEOs have been quoting "give it a few months" for years. What changes things is that Google put the ranges on a slide, stage by stage, which means you can finally hand your CMO something better than a shrug when they ask why the March content cleanup hasn't moved anything.

The full table, because the details matter

The numbers come from an attendee recap by John Campbell of ROAST, who wrote up day three of the Barcelona event. Here's the version worth bookmarking:

• New URL discovery: about 20 hours typically, weeks to never at the slow end
• Known URL refresh (recrawl): about 30 days typically, weeks to never
• Sitemap processing: about 24 hours typically, up to 14 days or never
• End-to-end indexing: about 1.5 hours typically, months or never
• Canonicalization changes: 1 to 3 weeks typically, months when signals conflict
• Site moves: 1 to 3 months typically, 6 months to a year or more
• Title and snippet changes: 1 to 2 days typically, several weeks to months
• Manual action removal: 1 to 2 weeks typically, 4 to 6 weeks or longer for dormant sites
• Core update recovery: 3 to 6 months typically, 6 months to a year (the next core update) at the slow end

Illyes also made a point that I think gets lost when people just screenshot the table: delays in one stage carry into the next. If a page takes 30 days to get recrawled, and the canonical change on it takes another 1 to 3 weeks to settle, you're at seven weeks before the ranking systems are even working with the new version. Stack a core update evaluation on top and the 3-to-6-month figure starts looking optimistic.

"Never" is the word to pay attention to

Look at how many rows end in "never." Discovery, recrawl, sitemap processing, indexing. According to ROAST's recap, Illyes said the word "never" shows up a lot and is usually tied to quality, and that fast technical fixes don't help if Google doesn't think the page is worth it.

That's the line I'd tape to the monitor.

Because the instinct, when pages aren't getting indexed, is to treat it as plumbing. Resubmit the sitemap. Request indexing in Search Console. Fiddle with internal links. Those things are fine, and sometimes they're exactly the fix. But if the bottleneck is that Google has decided your pages aren't worth the crawl, you're basically ringing the doorbell louder at a house where nobody wants to answer. The same recap notes Google filters out around 40 billion spam pages a day, which gives you a sense of how ruthless the "is this worth it" filter has to be.

Where teams actually lose the plot

The pattern that shows up in a lot of post-update forum threads goes something like this. Traffic drops. Team ships a batch of changes in week one: prunes some thin pages, rewrites titles, adds author bios, maybe consolidates a cluster. By week three nothing has recovered, so someone decides the changes didn't work and either reverses them or piles on a second round that muddies the first.

Illyes' numbers say that's backwards. At week three, a big chunk of those changed URLs probably hasn't even been recrawled (30-day typical refresh, remember). The title rewrites might show up in a couple of days, which is part of what makes this so confusing. Some changes show fast, so teams assume everything should.

Google's own core updates documentation says roughly the same thing in softer language: some changes take effect in a few days, but it "could take several months for our systems to learn and confirm" that a site as a whole is producing helpful content. It also warns against quick-fix changes, like removing a page element because you heard it was bad for SEO. So the slow timeline and the "don't thrash" advice come from the same place.

And to be fair to the teams that panic, the pressure is real. Nobody gets a budget renewed by saying "check back in Q2." Which is honestly the strongest argument for getting these numbers in front of leadership before the next drop, not during it.

What the recovery data says about the slow end

The "6 months to a year" row isn't theoretical. Sites hit by the September 2023 helpful content update waited about eleven months for the first real movement. SE Ranking summarized Glenn Gabe's tracking during the August 2024 core update: of 390+ heavily hit sites he monitored, 81 had surged back to some extent, roughly 20%. Most of the rest saw modest gains at best, with some recovering only 10 to 20% of their prior traffic.

So the 3-to-6-month figure is the typical case for sites that fixed the right thing. If you fixed the wrong thing, or only some of it, the clock doesn't really start. We wrote about a version of this with programmatic SEO sites that deleted pages and still didn't recover, and the timing table fits that story pretty well. Trust is a site-level judgment that seems to get re-evaluated on Google's schedule, not yours.

Set your evaluation windows from Google's clock

Here's how I'd turn the table into an actual operating rule this week. It takes maybe 20 minutes in a spreadsheet.

1. Tag every SEO change by which pipeline stage it depends on. Title tag rewrite? Serving stage, 1 to 2 days. Canonical consolidation? 1 to 3 weeks after recrawl. Content quality overhaul in response to a core update? 3 to 6 months minimum. Write the expected window next to each change in your changelog.

2. Don't evaluate a page-level change until the page has been recrawled. Use URL Inspection on a sample of 10 to 20 changed URLs and check the last crawl date. If fewer than half have been recrawled since your change, you have no result yet, positive or negative. For larger sites, the Crawl Stats report gives you a broader read on how often Googlebot is actually coming back.

3. For core update recovery, set a 90-day minimum before calling anything. Ninety days is the floor of Illyes' typical range. If you're reversing quality work before then, you're reacting to noise. My rough benchmark: if fewer than 10% of your affected pages have improved by day 90, it's time to question the diagnosis, not the patience.

4. Budget site moves in quarters, not sprints. Google's site move documentation covers the mechanics, but Illyes' range (1 to 3 months typical, up to a year) is the number your stakeholders need to see before anyone signs off on a domain migration in Q4.

5. If canonicals aren't sticking after three weeks, look for conflicting signals. The slow end of that row is explicitly "months with conflicting signals." Google's canonicalization troubleshooting guide is the place to start: sitemaps listing the non-canonical URL, internal links pointing the wrong way, hreflang mismatches.

A small prediction, and a less small worry

I'd guess this slide gets quoted in at least half of the agency recovery proposals written over the next six months. Which is mostly good. Having a Google-sourced reason to hold the line for 90 days will save a lot of decent fixes from getting rolled back.

The worry is the flip side. "Google says it takes 3 to 6 months" is also a very convenient thing to say when you aren't sure your fix was right. Patience only helps if the diagnosis was correct, and the table can't tell you that. So I'd pair every long evaluation window with one leading indicator you check monthly, like recrawl coverage or impressions on the pages you actually changed, just so you know whether you're waiting on Google or waiting on nothing.