Discovered – currently not indexed: causes and fixes

Your Page indexing report has a gray row called Discovered – currently not indexed, and it's growing. Google knows those URLs exist. It hasn't fetched them.

It's tempting to call this a crawl budget problem and stop there. Google's documents, and its spokespeople, say more: crawl limits are part of it, and so is whether Google thinks your site is worth the visits. We cover both, then show our own numbers, because on 4 October launchranked.com had this status on 613 URLs.

Short answer: Discovered – currently not indexed means Google found the URL but hasn't crawled it. On a new site that's expected, and Google's John Mueller has said it "can be forever" for pages that never earn the crawl. The usual causes: a new site on Google's default crawl limits, a site-level doubt about quality, too many low-value URLs, weak links to the pages, a slow or erroring server, and bursts of new pages. Fix the URL inventory and internal links first, then page quality and speed. Don't spam Request indexing.

What the status means

Google's Page indexing report defines it in three short sentences: the page was found but not crawled yet; typically Google wanted to crawl it but expected that to overload the site, so it rescheduled; and that's why the last crawl date is empty.

Notice what's missing: a verdict. Google hasn't judged the page, because it hasn't looked. That separates this status from its sibling, Crawled – currently not indexed, where Google fetched the page and chose not to index it. Mueller has said he'd "almost treat those two category of not indexed as a similar thing", and he has tied both to how Google sees the whole site. The checks differ, though. This post covers the queue; the Crawled post covers the verdict.

Is it a problem for you?

Not always. The same report documentation tells owners not to expect every URL to be indexed, just to make sure the key pages are, and says a new page or site can take "a week or so" to be crawled and indexed. In a 2022 office-hours answer, Mueller went further: it's "completely normal" not to have everything indexed, and on a newer site with a lot of content, "a lot of the new content for a while will be discovered and not indexed."

Calibrate with Mueller's 2021 example: for a site with a hundred pages and 80 indexed, he said he wouldn't see "a problem that you need to fix". On 4 October we had 659 of the 1,326 URLs Search Console knows about indexed, about half. Our rule of thumb, not Google's:

• Wait if the site is only weeks old, the count is flat or shrinking, and the URLs are ones you don't need in search, such as tag pages or filters.
• Act if key pages (pricing, product pages, your best content) are in the status, the count has grown for four weeks or more, or it's most of your sitemap.

Google's crawl budget guide is written for very large sites (1 million or more pages that change weekly, or 10,000 or more that change daily). It adds a third audience: sites with "a large portion of their total URLs" in this status. The numbers are "a rough estimate," Google says, not thresholds. We have 1,341 URLs and qualify on the third count only.

The real causes

Google defines crawl budget as the set of URLs it can crawl and wants to crawl. Each half has causes.

1. A new site starts with a small crawl limit. Every site starts with the same "default, conservative crawl capacity limit," and Google raises it automatically when there's demand and the site stays healthy. Crawl budget is per hostname, so a new subdomain starts from the default too. A three-week-old domain with 1,341 URLs is likely to be queued.
2. Demand: Google isn't yet convinced the site is worth the visits. Demand varies with a site's size, update frequency, page quality and relevance. For a smaller site, Mueller said in 2021, it's "mostly not a case that we're limited by the crawling capacity"; with a significant share of pages unindexed, he'd reconsider overall quality before chasing technical issues. Google's Crawl Stats help says that if a site "isn't very high quality, we might not crawl it as frequently." Mueller said on a July 2026 podcast that when Google is seriously worried about quality, "we'll probably crawl a lot less, we'll index a lot less", and you'll see statuses like this one.
3. Too many low-value URLs. Google calls it perceived inventory and says it's the factor you "can positively control the most." Left alone, it tries to crawl most URLs it knows, so duplicates, parameter variants, soft 404s and near-identical template pages burn crawl time. Google's crawl-rate guide names faceted navigation, sorting and filtering, and calendars with a URL per date as the most common causes of runaway crawling.
4. The pages are hard to reach. A page needs a link from a known page or a sitemap, and a sitemap is merely a hint. Google says every page you care about should have a link from at least one other page. Depth matters too: Mueller has said things linked from the home page are a sign you care about them, "so maybe we should care about them more". Google publishes no depth limit; we aim for three clicks from home.
5. The server asks Google to slow down. The crawl limit falls when responses slow down or the server returns 5xx errors or 429s, and Google points to "Hostload exceeded" in URL Inspection as the sign. If you rate-limit bots on purpose, the same guide, updated on 6 October, says not to serve 500, 503 or 429 for longer than a day or two: URLs that keep failing can drop from the index.
6. You published in a burst. New URLs arrive faster than trust does. That's the pattern in our 2,500-post story.

How to read your pattern:

How to diagnose it

1. Group the examples. Open the row in the Page indexing report. The examples table is limited to 1,000 rows and may not list every URL, so export it and group by URL pattern: directories, glossary, products. Then filter by sitemap (all submitted, unsubmitted, or one specific sitemap). If you split sitemaps by page family, you get status per family for free.
2. Inspect five URLs from different groups. URL Inspection shows the sitemaps that list the URL and a referring page, which can be a grandparent or great-grandparent of the page that links to it. A long chain means a deep page. The live test won't check sitemaps or referring pages.
3. Rule out blocks. Our noindex checker reads meta robots, X-Robots-Tag, robots.txt for Googlebot and the canonical for up to 20 URLs. The Google index checker runs a live site: search; that's an estimate, so confirm in Search Console.
4. Check server health in Crawl Stats. The report is for root-level properties and aimed at advanced users; Google says sites under a thousand pages shouldn't need it. Look at host status, average response time, the share of 5xx and 429 responses, and crawls by purpose: "discovery" is a URL Google has never crawled, "refresh" a recrawl. Few discovery crawls next to hundreds of queued URLs suggests Google is rationing.
5. Read your logs. Count Googlebot requests per URL pattern per day, verified by reverse DNS, and compare with your sitemap counts. Crawl Stats can differ slightly from logs. Our glossary has log file analysis.
6. Audit the sitemap. Our sitemap checker counts URLs per file and checks lastmod. Google says to list only URLs you want in search results.

Fixes, in order of impact

1. Shrink the inventory. Mueller has said that making your important content easy to recognize "sometimes means making less content and making better content". Merge or remove duplicates, return 404 or 410 for pages that are gone, fix soft 404s, keep parameters and filters out of crawl paths, and list only canonical, indexable URLs in sitemaps. Note that a noindex tag doesn't save crawl time: Google still fetches the page to read it. Block only truly useless sections in robots.txt, and never combine the two.
2. Link pages that matter from pages Google already crawls. Hubs, "related" blocks, breadcrumbs and a homepage module for new pages, as real links with descriptive anchors to canonical URLs. Our internal link checker finds orphan candidates, and internal linking for small sites has a four-rule system.
3. Make each page worth a visit. Unique data per page, not a name swapped into a template. Set a minimum bar per page family and noindex what falls below it: programmatic SEO without deindexing has the method.
4. Fix speed and errors. Fewer 5xx and 429 responses, faster server responses, and 304 support so unchanged pages cost little.
5. Slow the pace. Publish in batches and wait for the report to clear before the next one.
6. Earn references. Google lists popularity among crawl demand factors. Real links and mentions help, slowly.
7. Use Request indexing sparingly. It has a daily limit, and asking twice for one URL won't speed it up.
8. Measure weekly. Watch the trend and note what you changed.

What we'd avoid: mass Request indexing, deleting pages in a panic, adding more pages to make up for the unindexed ones, and hunting for a crawl-rate setting. Google says you can't tell it to crawl more; for small and medium sites it suggests updating your sitemaps and making sure you aren't blocking pages. The Indexing API isn't a shortcut either: Google says it can only be used for pages with JobPosting or BroadcastEvent (livestream) markup.

For the vocabulary, see our glossary entries on Discovered – currently not indexed, crawl budget and internal linking.

Our own case: 613 URLs on a three-week-old domain

launchranked.com is three weeks old. On 4 October 2026, the latest day in our Search Console export, the Page indexing report showed:

Our sitemaps list 1,341 URLs: 724 in the main sitemap, 127 for products and 490 for directories. So 613 is 46% of the 1,326 URLs the report knows about. It's the pattern this post describes: a new domain, a lot of URLs fast, and Google crawling at its default pace. It's the burst problem from the causes list. We chose to build page families quickly (directories, comparisons, alternatives, glossary, tools), each with a quality bar, and Google is now deciding how much of it deserves a crawl.

One caution about that 46%. The report's default view, "All known pages", counts every URL Google has found, including URLs in no sitemap. The dropdown above the chart switches to "All submitted pages" (only URLs in your sitemaps), "Unsubmitted pages only", or a single sitemap. Check both views before you decide what the queue is made of.

Where Google has looked first, going by pages with at least one impression in our first ten days of data: glossary 197 of 275, directories 110 of 440, tools 47 of 108, alternatives 31 of 79, comparisons 18 of 91, products 6 of 72, makers 2 of 50. Impressions aren't an index count, since an indexed page nobody searches for shows none, but they show where Google started.

How we read it. Two things are true at once. Google has indexed 659 of our URLs in three weeks, so it isn't ignoring us. And 46% of the URLs it knows are queued, which is what Mueller described for a newer site with a lot of content. One snapshot can't tell scheduling from a quality doubt. The trend can.

What we're doing:

• Adding fewer new URLs. New pages only where a working tool or real research sits behind them, not new families.
• Cutting crawl waste. A crawl of our own site on 7 October found that the "Sign in" and "Continue with Google" links in our header gave every page its own sign-in URL (/signin?next=/the-page): about 2,900 URLs that were never meant for search, more than our whole sitemap. The links now carry the return path only on pages where sign-in uses it (launching, upvoting and reviews), which cut the sign-in URLs a re-crawl found from 1,474 to 229, and the URLs our links expose from 4,425 to 1,957. We don't yet know how many of the 613 were these; the "Unsubmitted pages only" view will tell us.
• Trimming heavy pages. Our longest directory lists had grown past 4 MB of HTML, and Googlebot crawls the first 2 MB of a page, so the end of those pages was never read. Long lists now show the first 40 directories in full and the rest as one line each.
• Linking deep pages better. About 1,300 new links from glossary, blog, tool and directory pages to related pages, chosen by subject. In a re-crawl after the change, every glossary term and playbook had at least three internal links pointing to it; before, 73 of them had one or two.
• Improving thin families before adding more. The weakest page families get work before any family grows.

What we'll watch over the next few weeks: whether the queue shrinks while we add almost nothing; which families move first (our three sitemaps let us filter the report by main, products and directories); and whether pages we re-link move faster than comparable pages we leave alone. If the queue stalls even after links and pace are fixed, we'll treat it as a quality problem and work on the pages themselves.

What we won't claim: that any of this works yet. Search Console moves slowly, and the status can last, as Mueller said. We'll add the numbers to this post in a few weeks.

If you'd rather not run this loop by hand, pace and quality gates are what Autopilot is built around.