You publish 80 articles, submit your sitemap, and a week later Search Console shows 60 of them stuck on “Discovered — currently not indexed.” The instinct is to assume something is broken. It is not. The status means exactly what it says: Google found the URL (from your sitemap or a link) but has not yet spent the resources to crawl it. This is a queue, not a rejection. Below is why a new indie site lands here and the playbook that actually moves URLs out. (If you just want fast triage steps, see Fix the Search Console error — quick triage.)
TL;DR
- “Discovered — currently not indexed” = Google knows about the URL but has not crawled it. It is a priority/queue issue, not a quality verdict.
- Do not touch robots.txt, canonicals, or your sitemap. Those are not the cause and changing them wastes days.
- The three levers that work: stronger internal links to the stuck URLs, fewer thin pages competing for crawl, and time — for a brand-new domain the long tail commonly takes 4-12 weeks to drain.
- Use URL Inspection → Request indexing only on your 5-10 most important URLs. The manual button is capped at roughly 10-12 URLs per day per property, so it cannot rescue a 500-URL backlog.
- The Google Indexing API does not help here. As of June 2026 Google still officially supports it only for
JobPostingandBroadcastEventpages, and ignores or penalizes general blog/product URLs.
Discovered vs. Crawled: do not confuse them
Two Search Console buckets sound similar and have opposite fixes.
| Status | What Google did | Root cause | Fix direction |
|---|---|---|---|
| Discovered — currently not indexed | Knows the URL, has not crawled it | Crawl priority / budget / weak signals | Internal links, prune thin pages, wait |
| Crawled — currently not indexed | Read the page, declined to index | Quality / duplication / thin content | Rewrite, consolidate, add depth |
“Discovered” is usually the easier of the two: the content may be perfectly fine, you just have not convinced Google it is worth fetching yet. (For the other bucket, see Crawled — currently not indexed — how to fix.)
How to confirm you are actually in this bucket
You are looking at a “Discovered” problem, not something else, when:
- Search Console shows “Discovered — currently not indexed” on URLs that have sat in your sitemap for over a week.
- The URLs are real, return 200, and live on the same domain as URLs that did get indexed.
- The affected pages are newer or deeper in your structure (more clicks from the homepage).
- You recently shipped 50+ pages and only a handful were picked up.
If a URL returned 200 last week but 404s today, the bucket is misleading you — that is a redirect/404 issue, not crawl priority. Run a URL Inspection live test to confirm before doing anything else.
Why a new site lands here
Google’s crawling is governed by crawl budget, which its own crawl budget documentation splits into two parts: a crawl capacity limit (how hard Googlebot can hit your server without degrading it) and crawl demand (how much Google wants your content, based on popularity and freshness). A brand-new domain has almost no demand signal yet, so Googlebot crawls conservatively and de-prioritizes deep, lightly linked URLs.
Worth knowing: Google says the dedicated crawl-budget guide is really aimed at sites with 1 million+ pages, or 10,000+ pages that change daily. A 200-page indie site is nowhere near those limits, which is the tell that your real bottleneck is demand and internal signals, not raw budget. You are not being throttled for size — you simply have not given Google a reason to prioritize the deep pages yet.
The playbook (step by step)
- Confirm the bucket. Open the Pages report, click the “Discovered — currently not indexed” row, and copy 3 example URLs. Inspect each one; the live test should pass with no issues. If it does, the content is not the problem.
- Count internal links to each stuck URL. Use a crawler (Screaming Frog, Sitebulb) or grep your codebase. Anything with fewer than 2-3 inbound internal links reads to Google as “low priority.” Bring every stuck URL to at least 2-3 contextual internal links from already-indexed pages.
- Prune thin / duplicate URLs. Near-empty pages — paginated archives, tag pages with 1-2 posts, near-duplicate templates — dilute crawl demand across junk. Cull, consolidate, or
noindexthem so Googlebot’s attention concentrates on your real articles. - Link the stuck URLs from pages Google visits often. The fastest way to get a deep URL crawled is a link from your homepage, a hub page, or a high-traffic article. Shorten the click depth from the homepage to 3 or fewer.
- Request indexing for 5-10 priority URLs. In URL Inspection, run the live test, then click Request indexing. As of June 2026 the manual tool allows only about 10-12 submissions per day per property, and the button is a hint, not a command — so reserve it for your best pages and do not try to clear a backlog this way.
- Give it 30-60 days, then re-measure. New domains and large content drops genuinely take weeks to drain. If after 60 days the bucket has not shrunk meaningfully, the bottleneck is site authority — shift effort to earning external links and deepening content rather than re-poking Search Console.
Common pitfalls
- Treating it as a technical bug. Editing robots.txt, canonicals, or hreflang does nothing here and can introduce real problems. The cause is priority, not configuration.
- Re-submitting your sitemap daily. Sitemap submission does not raise crawl priority; internal and external links do.
- Spamming Request indexing. Past the ~10-12/day cap Google simply queues or ignores extras, and the long tail does not move.
- Reaching for the Indexing API. It is restricted to
JobPostingandBroadcastEventcontent; using it on ordinary articles is ignored and, per repeated Google guidance, can hurt rather than help. - Adding structured data to change priority. Schema affects how a result looks in search, not whether or when it gets crawled.
- Panicking on a 30-day-old site. It is normal for a fresh domain to keep most of its content in “Discovered” for 1-2 months while Google decides whether the site is worth crawling in full.
Who this is for
Indie content sites that just shipped a batch of articles and are watching only some get indexed, plus bloggers who created new URLs after a redesign or migration.
FAQ
- How long until Google crawls a “Discovered” URL?: Established site: days to a week. New site: 2-8 weeks. Long tail of a new site: sometimes 3+ months. Internal and external links are the main accelerator.
- Is “Discovered” worse than “Crawled — not indexed”?: They are different problems. Discovered = a priority issue; Crawled = a quality issue. Discovered is usually easier because the content may be fine — you just need to signal it is worth crawling.
- Will publishing more often help?: Often the opposite. If you 10x output without 10x quality, crawl demand spreads thinner across more thin pages. A steady cadence with strong internal linking beats raw volume.
- Can I force a crawl with IndexNow or the Indexing API?: IndexNow is used by Bing and Yandex; Google does not consume it. The Indexing API is officially limited to job postings and livestream events. For ordinary content, the only real Google levers are internal links, external links, and a few targeted URL Inspection requests.
- Does Google’s crawl budget guide apply to my small site?: Not really. Google scopes that guide to sites with 1M+ pages, or 10,000+ rapidly changing pages. On a 200-page indie site your bottleneck is crawl demand and internal signals, not capacity.
Related
- Crawled — currently not indexed — how to fix
- When Google won’t crawl your new pages
- Reading the Pages report
- URL Inspection — the practical guide
Tags: #Indie dev #SEO #Google #Search Console #Indexing #Troubleshooting