{"id":6030,"date":"2026-10-05T06:16:22","date_gmt":"2026-10-05T06:16:22","guid":{"rendered":"https:\/\/elyspace.com\/blog\/?p=6030"},"modified":"2026-10-05T06:16:22","modified_gmt":"2026-10-05T06:16:22","slug":"discovered-currently-not-indexed","status":"publish","type":"post","link":"https:\/\/elyspace.com\/blog\/discovered-currently-not-indexed\/","title":{"rendered":"“Discovered – Currently Not Indexed”: What It Means and How to Actually Fix It"},"content":{"rendered":"\n

You open Google Search Console, go to Indexing \u2192 Pages, and see a list of URLs sitting under “Discovered – currently not indexed.” Maybe a few. Maybe hundreds.<\/p>\n\n\n\n

The instinct for most people is immediate: click Request Indexing. Push Google to crawl these pages and get them indexed.<\/p>\n\n\n\n

That’s usually the wrong move, and understanding why is the whole point of this guide.<\/p>\n\n\n\n

Discovered currently not indexed<\/strong> means Google found the URL: through your sitemap, through an internal link, through an external link pointing to your site; but made a deliberate choice not to crawl it yet. That choice is meaningful. Google isn’t slow or forgetful. It made a priority decision. Your page was found and deprioritised.<\/p>\n\n\n\n

Blindly requesting indexing for a deprioritised page doesn’t fix whatever caused Google to deprioritise it. And for a significant portion of pages showing this status, the correct action isn’t to index them, it’s to improve or remove them.<\/p>\n\n\n\n

Discovered vs Crawled vs Indexed: The Three Stages<\/strong><\/h2>\n\n\n\n
\"Diagram<\/figure>\n\n\n\n

Understanding the three stages makes the status report in Search Console much less confusing.<\/p>\n\n\n\n

Discovered:<\/strong> Google’s crawler found the URL. It knows the page exists. I haven’t visited it yet.<\/p>\n\n\n\n

Crawled:<\/strong> Google visited the page, read its contents, and evaluated it. This produces sub-statuses: crawled but not indexed (Google read it and decided not to add it to the index), or crawled and indexed (Google read it and added it to the index).<\/p>\n\n\n\n

Indexed:<\/strong> The page is in Google’s database and can appear in search results.<\/p>\n\n\n\n

“Discovered – currently not indexed” is stuck between stage one and stage two. Google knows the URL exists but hasn’t gone to look at it. The question is always: why?<\/p>\n\n\n\n

The answer is almost always one of two things. Either Google doesn’t have enough crawl budget to get to it yet, there are too many other pages on your site demanding attention first. Or Google’s algorithm has already judged from available signals (URL structure, incoming links, surrounding content) that this page probably isn’t worth crawling. Pages that look low-value from outside get deprioritised before Googlebot even visits them.<\/p>\n\n\n\n

Why “Request Indexing” Is Usually the Wrong First Move<\/strong><\/h2>\n\n\n\n

Most articles about discovered currently not indexed<\/strong> start with “use the URL Inspection Tool and click Request Indexing.” That’s understandable, it’s the most visible button available, it gives you a feeling of doing something, and it occasionally works.<\/p>\n\n\n\n

But it doesn’t fix the underlying reason Google deprioritised the page. It’s asking Google to index a page before you’ve established whether the page deserves to be indexed. Submitting a request is not a substitute for making the page worth Google’s attention.<\/p>\n\n\n\n

Worse, repeatedly requesting indexing for low-quality or duplicate pages teaches Google’s algorithms that your site produces a lot of content that isn’t worth its crawl resources. That erodes crawl budget trust, making it harder to get your actually important pages crawled promptly.<\/p>\n\n\n\n

The right process is: understand why the page is in this status \u2192 fix the underlying issue \u2192 then request indexing if appropriate.<\/p>\n\n\n\n

The Real Questions to Ask Before Doing Anything<\/strong><\/h2>\n\n\n\n

Before touching Search Console, answer these four questions for each affected URL:<\/p>\n\n\n\n

Should this page be indexed at all?<\/strong> Not every page on a website should be in Google’s index. Pagination pages, tag archives, internal search result pages, thin category pages, duplicate variations, these often shouldn’t be indexed. If the answer is no, noindex or remove the page rather than fighting to index it.<\/p>\n\n\n\n

Does this page offer unique, genuine value?<\/strong> If the content is thin, generic, or nearly identical to another page on your site, Google is making the right call by not crawling it. The fix is improving the content, not convincing Google to index what’s currently there.<\/p>\n\n\n\n

How many internal links point to this page?<\/strong> A page with zero or one internal link looks like a low-priority orphan. Pages that matter in a site’s architecture have multiple internal links from relevant pages pointing to them.<\/p>\n\n\n\n

Is your site publishing more pages than Google considers worth crawling?<\/strong> A site with 5,000 pages and a new domain has a crawl budget problem. Google will prioritise its strongest pages and leave the rest in discovered status indefinitely.<\/p>\n\n\n\n

Reason 1: The Page Has Low or No Value to Google<\/strong><\/h2>\n\n\n\n
\"Thin<\/figure>\n\n\n\n

This is the most common reason and the most important to address honestly.<\/p>\n\n\n\n

Google’s crawlers make pre-crawl judgements. Based on the URL structure, the anchor text of internal links pointing to the page, the overall quality signals of your domain, and patterns seen from similar URLs, it estimates whether crawling this specific page is likely to surface quality content.<\/p>\n\n\n\n

Pages that give off low-value signals from outside get left in discovered status. The signals that suggest low value: very few internal links pointing to the page, a URL structure that matches patterns Google associates with thin content (parameterised URLs, tag archives, paginated pages beyond page 2), and a site that has a lot of already-crawled thin content.<\/p>\n\n\n\n

The fix isn’t mechanical. It’s editorial. The page needs to offer something genuinely useful; specific information, real depth, content that helps a real person with a real question. If the page doesn’t do that, discovered status is the right outcome and requesting indexing won’t change it for long.<\/p>\n\n\n\n

Reason 2: Your Crawl Budget Is Being Wasted on Other Pages<\/strong><\/h2>\n\n\n\n
\"Search<\/figure>\n\n\n\n

Google allocates a crawl budget to your site, a limit on how many pages it will crawl within a given period. This budget is influenced by your site’s authority, server response speed, and historical crawl efficiency.<\/p>\n\n\n\n

If your site has hundreds or thousands of low-value pages: tag archives, outdated posts with zero traffic, paginated URLs deep into category structures, parameter URLs that create near-duplicate content; Google’s crawlers spend budget on these pages and don’t get to your new content.<\/p>\n\n\n\n

The result: important new pages sit in discovered status for weeks because the crawl budget was exhausted on pages that shouldn’t be crawled in the first place.<\/p>\n\n\n\n

This is surprisingly common on WordPress sites. A new website that publishes posts also generates tag pages, category pages, author archive pages, and date archive pages, sometimes five or six URLs for every one post published. Most of those additional pages have thin or duplicate content and waste crawl budget.<\/p>\n\n\n\n

How to check:<\/strong>
<\/strong>In Search Console, go to Settings \u2192 Crawl Stats. Look at the Crawl Requests Breakdown. Are significant crawl resources going to pages you don’t actually need indexed? If so, noindexing or disallowing those pages through robots.txt frees up the budget for your valuable content.<\/p>\n\n\n\n

Reason 3: Weak Internal Linking<\/strong><\/h2>\n\n\n\n
\"Site<\/figure>\n\n\n\n

Sitemaps tell Google your URL exists; which is why the page is “discovered.” But sitemaps alone don’t tell Google the page matters. Internal links from relevant, well-indexed pages do.<\/p>\n\n\n\n

Google treats internal links as editorial endorsements. When an already-trusted, well-crawled page links to a new page using descriptive anchor text, it sends a signal: this page is important, it relates to this topic, it’s worth visiting.<\/p>\n\n\n\n

A page that only appears in a sitemap but has no internal links is like a book with no citations, Google knows it exists but has no evidence anyone considers it worth reading.<\/p>\n\n\n\n

How to fix it:<\/strong>
<\/strong>For each page in discovered status that you want indexed, identify two or three existing well-indexed pages on your site covering related topics. Add a natural internal link from those pages to the discovered page using descriptive anchor text. Don’t use “click here” or “read more”, use text that describes what the linked page is about.<\/p>\n\n\n\n

This is often the fastest fix for legitimate, quality pages stuck in discovered status. Internal links from strong pages push new pages through the crawl queue faster than any other method.<\/p>\n\n\n\n

Reason 4: Server Problems Slowing Googlebot Down<\/strong><\/h2>\n\n\n\n
\"Search<\/figure>\n\n\n\n

Search Console crawl stats showing server error rate causing pages to stay discovered not indexed<\/p>\n\n\n\n

If your server responds slowly or throws errors when Googlebot visits, Google’s crawler backs off. It crawls less frequently to avoid overloading your server, and pages in the crawl queue get pushed back further.<\/p>\n\n\n\n

A server that takes more than 200ms to respond to the first byte of a request is already a problem. Servers that occasionally time out or return 5xx errors cause Googlebot to reduce crawl rate significantly.<\/p>\n\n\n\n

How to check:<\/strong>
<\/strong>In Search Console, go to Settings \u2192 Crawl Stats \u2192 Server Response Breakdown. Look for spikes in error rates. Also check your Time to First Byte, Google’s PageSpeed documentation identifies anything above 600ms as a problem. A site on cheap shared hosting with dozens of other sites on the same server is particularly vulnerable to this.<\/p>\n\n\n\n

Better hosting infrastructure, faster server response times, more reliable uptime, directly improves crawl efficiency and gets pages out of discovered status faster.<\/p>\n\n\n\n

Reason 5: The Page Is Too New<\/strong><\/h2>\n\n\n\n

Sometimes discovered currently not indexed,<\/strong> is just the normal state for a recently published page on a new or modest-authority domain. There’s no problem to fix.<\/p>\n\n\n\n

Google crawls new pages in order of perceived priority. On an established high-authority domain, a new page can be crawled and indexed within hours or days. On a newer or lower-authority domain with modest internal links, new pages sometimes wait four to eight weeks in discovered status before Google gets to them.<\/p>\n\n\n\n

If your page is less than four to six weeks old, has good content, reasonable internal links, and you haven’t seen a spike in this status across many pages, wait. Check again in a month. If the page moves to indexed without intervention, the discovery queue was simply the normal process.<\/p>\n\n\n\n

The problematic scenario is a page sitting in discovered status for months with no movement. That’s when the other causes above apply.<\/p>\n\n\n\n

Reason 6: Duplicate or Near-Duplicate Content<\/strong><\/h2>\n\n\n\n

Google doesn’t need to crawl five versions of essentially the same page. When it identifies URL patterns that suggest duplicate or near-duplicate content: ?ref=, ?utm_source=, ?page=2, ?sort=price, it often discovers these URLs through sitemaps or links and then leaves them in discovered status rather than wasting crawl resources on content it’s already seen.<\/p>\n\n\n\n

Common culprits on WordPress sites:<\/strong>
<\/strong>Category pages and tag pages that contain the same post excerpts. Paginated versions of archive pages (\/page\/2\/, \/page\/3\/). URL parameters added by tracking scripts or filtering tools that create near-duplicate versions of pages.<\/p>\n\n\n\n

How to fix it:<\/strong>
<\/strong>Use canonical tags to tell Google which version of a page is the “real” one. For WordPress specifically, make sure your SEO plugin is properly handling canonical URLs. For parameterised URLs, block crawling of the parameter variations in your robots.txt or configure parameter handling in Search Console (if that feature is available for your property).<\/p>\n\n\n\n

Consolidating thin or duplicate pages through merging content or applying noindex also helps, fewer low-value pages means more crawl budget for the pages that matter.<\/p>\n\n\n\n

Reason 7: Poor Site Architecture<\/strong><\/h2>\n\n\n\n
\"Site<\/figure>\n\n\n\n

How your site is structured affects how efficiently Googlebot can navigate it. A well-structured site leads crawlers from your homepage through categories to individual pages in a logical, shallow hierarchy. A poorly structured site has important pages buried four or five clicks deep, orphaned pages with no navigation path to reach them, and important content sitting behind infinite scroll or JavaScript rendering that Googlebot doesn’t handle well.<\/p>\n\n\n\n

The further a page is from your homepage in click depth, the less crawl priority it tends to receive. Pages that are three clicks from the homepage get crawled far more readily than pages that are seven clicks deep.<\/p>\n\n\n\n

How to check:<\/strong>
<\/strong>Use a site crawler like Screaming Frog (free for up to 500 URLs) to map out your site architecture. Look for important pages with high click depth. For any page you want prioritised by Google, it should ideally be reachable within three clicks from the homepage; through the navigation, through category pages, or through internal links in relevant content.<\/p>\n\n\n\n

According to Google’s own documentation on crawling and indexing<\/a>, crawl budget management is most important for larger sites, but the principles: quality over quantity, strong internal linking, avoiding URL bloat, apply to sites of all sizes.<\/p>\n\n\n\n

The Right Fix Process: In the Right Order<\/strong><\/h2>\n\n\n\n

Work through this sequence for pages showing discovered currently not indexed:<\/p>\n\n\n\n

Step 1: Assess whether the page should be indexed at all.<\/strong>
<\/strong>Open the URL. Read the page honestly. Is it genuinely useful? Is it unique, not a near-duplicate of another page? Does it serve a real search query? If the answer to any of these is no, plan to noindex or consolidate rather than fix.<\/p>\n\n\n\n

Step 2: Audit your crawl budget.<\/strong>
<\/strong>In Search Console Crawl Stats, check what’s consuming your crawl resources. If tag archives, author pages, or parameterised URLs are being crawled heavily, noindex those first to free up budget for valuable pages.<\/p>\n\n\n\n

Step 3: Improve internal linking to the affected pages.<\/strong>
<\/strong>Find two to three relevant, well-indexed pages on your site and add natural internal links to the discovered page using descriptive anchor text.<\/p>\n\n\n\n

Step 4: Improve the page’s content quality if needed.<\/strong>
<\/strong>If the page has thin or generic content, improve it. Add depth, specifics, and genuine value before asking Google to crawl it.<\/p>\n\n\n\n

Step 5: Ensure server performance is not a bottleneck.<\/strong>
<\/strong>Check your Time to First Byte and Crawl Stats error rate. Address hosting issues if they’re consistently showing errors or slow response times.<\/p>\n\n\n\n

Step 6: Request indexing.<\/strong>
<\/strong>After completing the steps above for specific high-priority pages, use the URL Inspection Tool to request indexing. Now you’re requesting indexing for a page that has earned it, not hoping Google overlooks its deficiencies.<\/p>\n\n\n\n

When Requesting Indexing Actually Makes Sense<\/strong><\/h2>\n\n\n\n

It’s not that requesting indexing is never the right move. It absolutely is, in specific situations:<\/p>\n\n\n\n