Is Discovered — currently not indexed bad for my site?

In small quantities it's the normal state of a crawl queue — every site has URLs waiting. It becomes a problem when it grows in step with your publishing, or when the pages stuck in it are ones you need ranking. The status is a symptom of how Google prioritizes your site, so a persistently growing pile is worth diagnosing even if individual URLs don't matter.

Does requesting indexing help pages in this status?

For a handful of genuinely important URLs, yes — URL Inspection's request effectively jumps the queue for that URL. It does not scale: you can't request your way through hundreds of pages, and the underlying priority problem remains for everything you didn't request. Use it for your best pages while the structural fixes handle the rest.

Can a JavaScript-heavy site really get crawled less?

Yes, in two ways. Each crawl is more expensive because Google must render before extracting content, and sites with a low yield per visit see reduced crawl appetite over time. Separately, if internal links only exist after rendering, discovering each new URL requires a completed render of some other page first, which slows the whole discovery pipeline. Server-rendered HTML fixes both at once.

Will a bigger sitemap or resubmitting it get these pages crawled?

No — the sitemap is how these URLs became Discovered in the first place, so resubmitting it repeats information Google already has. Sitemaps solve discovery; this status is a priority problem. Accurate lastmod values help fresh pages get recognized as fresh, but the queue position is set by importance signals, chiefly internal links.

My server is on a small VPS — could that be the cause?

It can contribute. Googlebot adapts its crawl rate to what your host handles gracefully, and a small server that slows or errors under crawler bursts gets a reduced allocation. Check Crawl Stats for response-time trends and 5xx spikes. Caching, a CDN in front, or a modest resource bump often raises the crawl ceiling more cheaply than any SEO work.

HomeFixDiscovered, not indexed

Google knows your page exists. It just keeps not showing up.

Short answer

Discovered — currently not indexed means Google knows the URL but has never crawled it, so nothing about the page itself has been judged. The causes live in crawl priority: weak internal links, crawl budget spent on URL waste, server strain, or a site that's expensive to crawl. Raise the page's apparent importance and lower the site's crawl cost.

The instinct with this status is to inspect the stuck page for flaws. Resist it — Google hasn't seen the page, so the page can't be the reason. Everything that matters here happens before the fetch: how important the URL looks from the outside, and how willing Google is to spend a visit on your site at all.

Is this actually your problem?

!Search Console shows URLs under “Discovered — currently not indexed”

!URL Inspection shows no crawl date — Google has never fetched these pages

!New content takes weeks to get crawled, or never does

!The affected pages sit deep in the site — pagination, archives, long click-paths from home

!The pile grows fastest right after you publish in bulk

!Crawl Stats shows flat or declining crawl requests while your page count grows

Why Google defers the visit

Google maintains a crawl queue per site, ordered by predicted value: how important the URL appears, how likely it is to hold worthwhile content, and how much a visit to your host costs. A URL in Discovered status is a URL that keeps losing that auction. Every scheduling pass, something else on your site — or the decision to not crawl at all — outbid it.

Four forces control the auction. Importance signals: a page linked from your homepage looks urgent; a page found only in a sitemap looks optional. Crawl waste: infinite parameter spaces and faceted URLs consume the visits your real pages needed. Host capacity: slow or erroring servers get politely throttled. And crawl cost: a site whose every page is an empty JavaScript shell makes each visit expensive — Google must render to learn anything — and expensive sites are crawled with less appetite. That last one is where rendering enters this story, at the site level rather than the page level.

Discovered vs crawled — the fork that changes everything

Status	What happened	Where the fix lives
Discovered — not indexed	Google knows the URL. It has never fetched it. Nothing about the content has been evaluated.	Crawl priority: links, budget, server health, crawl cost. This page.
Crawled — not indexed	Google fetched and evaluated the page — and declined it. The content was seen and judged.	Content quality and duplication. A different diagnosis entirely — see the sibling page.

Getting this fork wrong sends you down entirely the wrong road — auditing content Google never saw, or adding links to pages Google already rejected. Check the crawl date first, always.

Check what your site costs to crawl

Point the check at your main templates — homepage, a category page, an article — not at the stuck URLs (Google hasn't seen those, and neither has the problem). What you're measuring is the yield of a typical crawl of your site: does one cheap HTTP fetch return real content, or does every visit require a render before Google learns anything?

Check what a crawl of your templates yields

https://

Reading the result

Result	What it means for crawl priority
SSR	Crawling your site is cheap — every fetch yields content immediately, and crawl cost is not your bottleneck. Your Discovered pile is about importance and budget: internal links, crawl waste, and server health carry the whole diagnosis.
HYBRID	Fetches yield partial content. Usually acceptable for crawl economics — but check that your internal LINKS are in the raw HTML. Links that only exist after rendering slow discovery itself: Google can't queue URLs it hasn't seen yet.
CSR	Every crawl of your site costs a render before it yields anything — the expensive-site profile. This suppresses crawl appetite site-wide and compounds your Discovered problem: fewer visits, and each new page's links are invisible until a render happens. Server-rendering your templates changes the site's whole crawl economics, not just one page's.

Image slot

Screenshot: the links panel \u2014 raw vs rendered link counts. Rendered-only links slow discovery itself.

If your internal links only exist after rendering, Google finds new URLs one render at a time.

How to fix it

Six steps, ordered by leverage: importance first, waste second, cost third.

Confirm the pages have never been fetched

URL Inspection on a few affected URLs: 'Discovered' with no crawl date means Google has never visited. If you see a crawl date, you're actually in crawled-not-indexed territory and on the wrong page. Also check your server logs for Googlebot hits on these URLs — the absence there is the same confirmation from your side.

Link the pages from somewhere that matters

A URL known only from a sitemap has the weakest possible claim on Google's attention. Internal links from your homepage, hub pages, and frequently-crawled articles are how importance is communicated. Deep pages reachable only through five clicks of pagination are telling Google exactly how much they matter — and Google is listening.

Stop wasting the crawl you already get

Faceted filters, calendar pages, session parameters, and infinite URL spaces eat crawl capacity that your real pages need. Every crawl spent on ?color=blue&sort=price is a crawl your new content didn't get. Block genuinely infinite spaces in robots.txt, canonicalize variants, and cut parameter URLs out of internal links so the budget flows to pages that matter.

Check what a crawl of your site costs Google

Run the check below on your key templates. If every page is an empty shell that requires a full render to yield content, your site is expensive to crawl — each fetch costs Google a headless render before it learns anything. Expensive, low-yield sites get visited less enthusiastically, which is felt exactly as a growing Discovered pile. Server-rendered HTML makes every crawl cheap and immediately informative.

Fix server health signals

Googlebot backs off from hosts that strain: slow responses, 5xx errors, and timeouts all shrink your crawl allocation. Check Search Console's Crawl Stats for average response time and error spikes — a host that answers fast and clean gets crawled more. If your VPS chokes when a crawler burst arrives, that choke is being recorded and priced in.

Prioritize ruthlessly, then let the queue drain

If you publish faster than Google crawls you, the pile grows arithmetically — no trick outruns that. Make sure your best pages are the well-linked ones, keep sitemap lastmod honest so fresh content is identifiable, and accept that the long tail clears on Google's schedule. Sustained growth in this status on a modest site usually means the site is generating more URLs than it deserves crawls — which is a strategy question, not a technical one.

One tactical note on sitemap.xml: it aids discovery, not priority. Submitting a sitemap tells Google URLs exist — which, for pages in this status, Google already knows. A sitemap with honest lastmod values helps fresh content get identified; it does not push anything up the queue. Internal links do that.

How long it takes

When	What to expect
Week 1	Ship the linking and crawl-waste changes. Watch Crawl Stats — average response time and error rate are the two host signals you can move fastest.
Weeks 2–3	Crawl requests per day should start rising as waste stops absorbing them. Newly well-linked pages get fetched first; pages move from Discovered to Crawled (and ideally to Indexed) in that order.
Weeks 3–6	The queue drains from the top down. Deep pages clear last. If pages move Discovered → Crawled-not-indexed rather than to Indexed, the crawl problem is solved and you've surfaced an evaluation problem — continue on the sibling page.
Ongoing	Track the ratio of pages published to pages crawled per week. If publishing outpaces crawling durably, the site is minting URLs faster than it earns visits — slow down, consolidate, or accept a permanent backlog.

Common questions

Anywhere from days to months, because it resolves when your URL wins a scheduling pass — not on a fixed timer. Well-linked pages on healthy, cheap-to-crawl sites clear in days; deep pages on sites with crawl waste can sit for months. The levers that shorten it are exactly the fix steps: stronger links, less waste, faster host, cheaper crawls.