Discovered Currently Not Indexed: A Small-Site Fix
Discovered currently not indexed means Google knows your URL but has not crawled it. Check links, server health, sitemaps, and URL bloat, not crawl budget.
TL;DR Discovered – currently not indexed means Google knows the URL exists but hasn't fetched it yet. On a site with a few hundred pages, that's almost never a crawl budget problem. Check how Google found the URL, whether your server and robots.txt respond cleanly, whether your sitemap is honest, and whether your site is generating junk URLs that compete for Googlebot's attention.
A founder with a 90-page marketing site shows me their Page indexing report. Eleven blog posts sit under Discovered – currently not indexed, some for weeks. They've already read three articles about crawl budget and are about to rewrite their robots.txt to "save budget" for the posts that matter.
Then I open one of those posts in URL Inspection. The only discovery source is the sitemap. No referring page. Nothing on the site links to it. Google knew the URL existed because the founder told it so, and nothing else on the site suggested it was worth fetching soon.
That's not a crawl budget problem. It's a site that whispers about its own pages.
This post covers the pre-crawl status. If Google already fetched your page and declined to keep it, that's a different stage with different fixes, and I cover it in what to check first for crawled currently not indexed. If you're not sure which stage is failing yet, start with my diagnostic for a website not showing up on Google.
Discovered currently not indexed meaning, in Google's words
The Page indexing report help page defines it this way: "The page was found by Google, but not crawled yet. Typically, Google wanted to crawl the URL but this was expected to overload the site; therefore Google rescheduled the crawl."
Two things follow from that definition.
First, discovery worked. Google has the URL. Your problem is the gap between knowing and fetching, so nothing about the page's content has been judged yet. Rewriting the intro does nothing for a page Googlebot hasn't read.
Second, the stated reason is load on your server, not quality. Google expected that crawling right then would strain the site, so it pushed the fetch later. On a small site that should be easy to crawl, that tells you where to look: how your server responds, and how many URLs Google thinks it has to get through.
So when the Page indexing report lists a URL as discovered currently not indexed, the question isn't "is this page good enough?" It's "why didn't Google prioritize fetching it?"
How it differs from Crawled – currently not indexed
| Status | Has Google fetched the page? | What it's waiting on | Where to look |
|---|---|---|---|
| Discovered – currently not indexed | No | A crawl | Discovery paths, server health, URL volume |
| Crawled – currently not indexed | Yes | An indexing decision | Rendering, duplicates, distinct value |
If you spend a week improving content on a Discovered URL, you've worked on the wrong stage.
You probably don't have a crawl budget problem
This is where most advice for small sites goes wrong. Search for a discovered currently not indexed fix and much of the advice jumps straight to crawl budget optimization, a discipline built for sites with millions of URLs.
Google's own crawl budget management guide says who it's for: "Large sites (1 million+ unique pages) with content that changes moderately often (once a week)," "Medium or larger sites (10,000+ unique pages) with very rapidly changing content (daily)," and sites with "a large portion of their total URLs classified by Search Console as Discovered - currently not indexed."
That third bullet is the one people quote to justify panic. Read it in context. It sits next to the other two size-based criteria, and the guide adds: "If your site doesn't have a large number of pages that change rapidly, or if your pages seem to be crawled the same day that they are published, you don't need to read this guide."
The Crawl Stats report help is even blunter. It calls the report "aimed at advanced users" and says sites with fewer than 1,000 pages "should not need to use this report."
A bootstrapped SaaS site with 60 to 400 URLs is nowhere near those thresholds. If a chunk of your posts sit in this status, the useful reading is that something on your site makes those URLs look low-priority or makes your server look fragile. Both are fixable, and neither requires enterprise crawl tooling.
Check 1: how did Google find the URL?
Open the URL in the URL Inspection tool and expand the Discovery section. It shows two things: Sitemaps, meaning "any sitemaps submitted using the Sitemaps report or listed in the robots.txt file for this site that point to this URL," and Referring page, "a page that Google possibly used to discover this URL."
The help page notes that a missing referring page doesn't prove no page links there. Still, the pattern is telling. When I see sitemap-only discovery on a stuck URL, I check the site's link graph, and more often than not the page is an orphan or buried four clicks deep in a paginated archive.
Google's How Search Works guide says most new pages are found by following links from pages Google already knows. Internal links are also how you tell Google which pages matter. A post linked from your homepage, your pillar, and three related posts looks worth fetching. A post that only exists in an XML file doesn't.
What to do:
- Find orphans. Compare your sitemap against pages that receive internal links. My guide to finding and fixing orphan pages walks through doing this without a paid crawler.
- Link from pages Google already crawls often. Your homepage, main feature pages, and your strongest posts get fetched regularly. A contextual link from one of them is a much stronger hint than a sitemap entry.
- Shorten click depth. If the only path is blog index, page 7 of the archive, then the post, flatten it with links from the cluster.
The durable version of this is structural: every new post goes live already linked from its pillar and siblings. That's the approach in my internal linking strategy for topic clusters, and it's the single most effective fix I know for this status on small sites.
Check 2: does your server give Google a reason to back off?
Google's definition points at overload, so take it literally. The crawl budget guide explains that Google sets a crawl capacity limit per site, and "if the site slows down (latency increases or response times become longer), or responds with server errors (5xx HTTP status codes) or rate-limiting signals (such as HTTP 429), the limit goes down and Google crawls less."
On small SaaS sites, I see a few repeat offenders:
- Cold-start serverless pages that take several seconds on the first request.
- Bot protection or a WAF that rate-limits or challenges Googlebot. Your security layer may be serving 429s or challenge pages to the crawler without you knowing.
- A shared host or cheap plan that throws intermittent 5xx under any load.
- A flaky robots.txt. Google's robots.txt specification says that when robots.txt returns a server error, "for the first 12 hours, Google stops crawling the site but keeps trying to fetch the robots.txt file." A robots.txt served by the same fragile app as everything else can pause crawling of your whole site.
The Crawl Stats report is aimed at larger sites, but it's still the fastest way to check this. Its Host status section covers robots.txt fetching, DNS resolution, and server connectivity, and the response breakdown shows what share of Googlebot's requests got 200s versus errors. If you see server errors or failed robots.txt fetches, fix the infrastructure before touching anything else.
Also run Test live URL in URL Inspection on a stuck page. If the live fetch fails or the rendered page is a challenge screen, you've found your problem.
Check 3: is your sitemap an honest signal?
Google's sitemaps overview says a site with "about 500 pages or fewer" that is "comprehensively linked internally" might not need a sitemap at all. It also says a sitemap "doesn't guarantee that all the items in your sitemap will be crawled and indexed."
So a sitemap won't rescue a poorly linked page. But a bad sitemap can make things worse. The build a sitemap guide says Google uses the lastmod value only "if it's consistently and verifiably" accurate, and that it ignores the priority and changefreq fields entirely.
Common problems I find:
- Every URL has today's date as lastmod because the CMS regenerates it on each build. Google can verify that's not true, so the field stops meaning anything for your site.
- The sitemap lists redirects, noindexed pages, or non-canonical variants. Google's guidance is to include the URLs you want to appear in search results.
- Tag and author archives listed alongside real content, which inflates the list of URLs Google thinks you want crawled.
Keep the sitemap to canonical, indexable URLs you care about, with lastmod that changes only when the content does.
Check 4: are you generating URLs nobody needs?
The crawl budget guide says that "without guidance from you, Google tries to crawl all or most of the URLs that it knows about on your site." On a small site, the number of URLs Google knows about can quietly be many times larger than the number of pages you wrote.
Google's faceted navigation guide describes the worst version: parameter-based filters "can generate infinite URL spaces," and "if crawling is spent on useless URLs, the crawlers have less time to spend on new, useful URLs."
You don't need an ecommerce store to have this. On SaaS sites, the sources are usually:
- Tag pages. Twenty posts with eight tags each can mean dozens of thin archive URLs, each paginated.
- Tracking and sort parameters that get linked internally, such as UTM-tagged links in your own nav or changelog.
- Calendar or date archives that go back or forward forever.
- Search result pages on your docs or blog that are crawlable and linked.
- Templated pages for every integration or use case that differ by one word.
Fixes, in order of preference: stop linking to the junk URLs internally, stop creating them, then block truly infinite spaces in robots.txt. Don't use robots.txt as a blanket fix for pages you want deindexed; for those, a noindex tag that Google can actually crawl is the tool.
Discovered currently not indexed fix: what to do, in order
| Finding | Fix | Then |
|---|---|---|
| Sitemap-only discovery, no referring page | Add contextual links from your pillar, homepage, or strong posts | Request indexing once |
| 5xx, 429, or slow responses in Crawl Stats | Fix hosting, cold starts, or bot rules for Googlebot | Wait for crawling to recover |
| robots.txt fetch failures | Serve robots.txt as a static file | Recheck Host status |
| Sitemap full of junk or fake lastmod | Trim to canonical URLs, make lastmod truthful | Resubmit the sitemap |
| Tag pages, parameters, infinite archives | Stop linking and generating them, block true infinite spaces | Watch the known-URL count drop |
On Request indexing, the URL Inspection help mentions a daily limit on requests. Use it once per URL after you've fixed something. Clicking it daily on an unchanged, unlinked page doesn't address why Google deprioritized it.
What "discovered currently not indexed validation passed" actually tells you
Once you've fixed the cause, you can validate the issue in Google Search Console like any other. The Page indexing help defines Passed as "all known instances of the issue are gone (or the affected URL is no longer available)," and says validation "typically takes up to about two weeks, but in some cases can take much longer."
Note what Passed does not say. It means the URLs left this status. Some will have moved to Indexed. Others may have moved to Crawled – currently not indexed, which means Google fetched them and is now judging the content. Check where each URL landed before celebrating. If it's the crawled status, the next step is the content checks in my post on crawled currently not indexed.
And keep Google's reminder in mind from the same page: "Don't expect every URL on your site to be indexed." Tag archives stuck in Discovered forever are fine. Your pricing page and core posts are not.
The upstream fix
Most of what I've described comes from publishing faster than you link. A post goes live, gets a sitemap entry, and waits for someone to remember to link to it. Multiply that by a 30-day content push and you get exactly the list of stuck URLs that founder showed me.
That's the part of the problem I'm building Boomranq around. It plans a 30-day calendar in clusters, so each post has a defined pillar and siblings to link from on publish day, instead of a sitemap line and a hope. Fewer orphaned URLs means fewer pages Google has no reason to fetch.