New article hasn’t indexed 2 weeks in, new site still in Discovery a month after launch, post-redesign traffic dropped — most people immediately edit canonical / resubmit sitemap / panic-troubleshoot. But 80% of the time these are normal indexing delays, and thrashing only resets the “wait period.”
This is a baseline reference: how slow is normal in each scenario, and when it becomes a real problem.
Symptoms
- New article: 0-14 days stuck in Discovered before being crawled
- New site: full indexing typically takes 60-120 days
- Post-redesign: 2-8 weeks of Pages report fluctuation
- Performance impressions don’t track publish cadence
Quick verdict
Indexing is asynchronous and uneven. Unless something technical is broken, “slow” is part of how Google works.
Common causes
1. New domain sandbox effect (officially denied, observably real)
Google officially denies a “sandbox” but the observed behavior: new domains have very low crawl rate, most pages take 6-12 weeks before steady indexing. Not a penalty — Google judging whether the site is spam.
Normal baseline:
- New article on new site: discovery 1-7 days, crawl 7-30 days, indexed 14-60 days
- New article on established site (DR > 30): discovery < 24h, crawl 1-3 days, indexed 3-14 days
2. Crawl budget allocated by site age and authority
Crawl budget (daily requests Google is willing to spend) scales with:
- Site age (older → more)
- Backlink count (more → more)
- Historical crawl health (fewer 5xx, faster response → more)
New site: 50-200 requests/day. Established active site: 5,000+.
3. Post-redesign URL discovery and re-evaluation cycle
Redesign triggers site-wide re-evaluation; 2-8 weeks of decline is baseline. See Indexing coverage drop after redesign.
4. Sitemap pingbacks are advisory, not real-time
Google receives sitemap submission but doesn’t crawl immediately — it queues. Sitemap status “Success” after new submission only means parseable, not that all URLs get crawled right away.
Actual crawl depends on crawl budget and priority, may take 7-30 days to get to.
5. Core Update period data lag
Google ships 3-4 Core Updates/year (1-3 weeks each). During rollout, Search Console data may lag or fluctuate. Stabilizes after the update ends.
Shortest path to fix
Step 1: Record key timestamps
Launch date: 2026-04-01
Today: 2026-05-21
Site age: 50 days
Last change: 2026-05-10 sitemap edited (11 days ago)
Last Core Update: 2026-04-15 (~5 weeks ago)
Without time anchors you can’t judge whether the current state is normal.
Step 2: Cross-reference the baseline table
| State | New site baseline | Established baseline | Abnormal threshold |
|---|---|---|---|
| New article → indexed | 14-60 days | 1-14 days | New 90+ days / established 30+ days |
| Site-wide indexing rate | 0-8w < 30%; 8-16w 30-70% | N/A | 16w+ still < 30% |
| Post-redesign indexed drop | -20% to -40% normal | Same | -50%+ sustained 12 weeks |
| Single URL Discovered → Crawled | 7-30 days | 1-7 days | 60+ days |
| Performance new-page 0 impressions | 2-8 weeks | 0-2 weeks | 12+ weeks |
Within “normal baseline” = don’t panic, wait.
Step 3: Take weekly Pages snapshots
# Export Pages report every Monday to history/
DATE=$(date +%Y-%m-%d)
# Manual: Search Console → Pages → Export → rename to pages-$DATE.csv
mv pages.csv history/pages-$DATE.csv
Week-to-week differences matter more than daily fluctuation.
Step 4: Resist changing inside the normal window
Don’t do during a new-site period:
- Change canonical structure (unless there’s a clear error)
- Change URL structure (resets all signals)
- Add / remove noindex rules
- Repeatedly resubmit sitemap
- Mass Request Indexing
These stack “re-evaluation cycles.” One cycle = 4-8 weeks. Stacking 3 = 24 weeks.
Step 5: Wait but be productive — do useful things
These don’t waste the waiting window:
- Keep publishing new content (2-3/week)
- Get backlinks (3-5)
- Optimize internal link network (add hub pages)
- Refresh old content (add new data / current year)
These don’t “reset” signals — they “strengthen” them.
Step 6: Only escalate when past the baseline
New site 8-12 weeks without improvement + tech blockers ruled out → real problem (see [New site stuck in discovery])
Single URL 60 days still Discovered → real problem (see [Discovered not indexed])
Post-redesign 12+ weeks still declining → real problem (see [Coverage drop after redesign])
At that point, dig in seriously.
When this is not on you
Most “indexing is broken” reports turn out to be “indexing is in progress and the user got impatient.” Patience is the real fix.
Easy to misdiagnose
- Doing many things at once: sitemap changes + canonical changes + new content = impossible attribution
- Panicking at daily data: Search Console data is 2-3 day lagged and sampled, look at weekly trends
- Thinking repeated Request Indexing accelerates: burns today’s quota
- Thinking sitemap resubmission is free: each submission triggers re-evaluation but doesn’t accelerate crawl
Prevention
- Schedule launches with a 60-90 day quiet observation period
- Avoid major structural changes during the indexing ramp
- Weekly Search Console snapshot for trend comparison
- Install Analytics + Search Console before launch — without historical data, diagnostics later are guesswork
- New content follows a fixed cadence (X/week) so Google forms an expectation
FAQ
Q: What’s the absolute minimum to wait? A: A few hours for single URLs on established sites, weeks for new sites; weeks to months for site-wide changes.
Q: Can I speed it up? A: Marginally — solid internal links, real backlinks, quality content. But fundamentally it’s Google’s evaluation cycle, and technical acceleration is limited.
Q: How do I know if I’m waiting on normal vs. a real problem? A: Cross-reference Step 2’s baseline table and Step 6’s thresholds.
Q: Why doesn’t Google publish exact timing? A: Every site / article / period is different — no formula. Google itself dynamically computes priority.
Related
- Why resubmitting URL Inspection doesn’t solve indexing
- Indexing slow on a brand-new site
- New site stuck in discovery phase
Tags: #SEO #Google #Search Console #Indexing #Troubleshooting #Discovery