Discovered Currently Not Indexed: Meaning and How to Fix It

What "discovered currently not indexed" means in Google Search Console#

When you open the Page indexing report in Google Search Console and see "Discovered - currently not indexed," it means Google found the URL but has not crawled it yet. Google typically reschedules the crawl because it estimates that crawling it immediately might overload your server. Because the page hasn't been crawled, the last crawl date is empty in the report. This is different from "Crawled - currently not indexed," where Google fetched the page but chose not to add it to the index.

For a small or new site, Google notes that you might not even need this report if you have fewer than 500 pages. You can check if key pages are indexed by searching site:yourdomain.com directly on Google. If your site is new, it can take a week or so for Google to start crawling and indexing. The issue lifetime for this status extends from the first time an instance is detected until 90 days after the last instance is marked as gone. If 90 days pass without recurrences, the issue is removed from the issues table.

Why Google knows about a URL but won't crawl it#

Google allocates resources to crawl each site through a system based on crawl capacity limits and crawl demand. Your site starts with a default, conservative crawl capacity limit, also known as hostload. Google wants to crawl your site without overwhelming your servers, so it limits the total amount of time your server spends holding connections open, factoring in both the number of parallel connections and their duration.

The crawl capacity limit adjusts based on crawl health. If your site responds consistently and its response times, including latency and Time-to-First Byte, remain stable or improve, the limit goes up. If the site slows down or responds with server errors (5xx HTTP status codes) or rate-limiting signals (such as HTTP 429), the limit goes down. Google's crawling resources are finite, so it must prioritize resource allocation across the web.

Crawl demand for Googlebot depends on your site's size, update frequency, page quality, and relevance compared to other sites. The primary factors you can influence are perceived inventory, popularity, and staleness. Perceived inventory is the factor you can control the most: without guidance, Google tries to crawl all or most of the URLs it knows about. If many of these URLs are duplicates or unimportant, it wastes crawling time. Popularity means URLs that are more popular on the internet tend to be crawled more often. Staleness means Google wants to recrawl documents frequently enough to pick up changes.

Checks that separate quality from crawl-budget causes#

Before trying to force indexing, verify that the page quality isn't the problem. Google does not index duplicate content or soft 404s, but it crawls them, which wastes your crawl budget. If you see more non-indexed pages than indexed pages, look at the reason shown in the report.

Common reasons for large groups of non-indexed pages include a robots.txt rule blocking large sections of your site, or a large number of duplicate pages using parameters to filter or sort a common collection, such as type=dress or color=green. These duplicate pages probably shouldn't be indexed if they just show the same content sorted or filtered differently.

Check for these quality issues: - Duplicate content: Consolidate duplicate content to focus crawling on unique URLs rather than unique URLs with the same content. - Soft 404 errors: These pages will continue to be crawled and waste your budget. Check the Page indexing report for soft 404 errors. - Long redirect chains: Avoid long redirect chains, which have a negative effect on crawling. - Permanently removed pages: Return a 404 or 410 status code for permanently removed pages. A 404 is a strong signal not to crawl that URL again.

If you cannot consolidate unimportant pages, block them using robots.txt. Blocking URLs with robots.txt prevents Google from crawling them and significantly decreases the chance they will be processed by other Google systems. Improving your page load speed can also help your crawl health; see our guides on CSS Animation Performance and CSS Container Queries for front-end optimization techniques.

Keeping your sitemap up to date#

Google reads your sitemap regularly, so keeping it current is one of the most effective ways to guide crawling. If your site includes updated content, include the <lastmod> tag in your sitemap. Note that the date must reflect when the linked page was last modified, not when the sitemap was generated.

A sitemap file must follow the sitemaps.org protocol. Each sitemap file can contain a maximum of 50,000 URLs and must be no larger than 50MB uncompressed. The <loc> tag, which holds the URL, must be less than 2,048 characters. All URLs listed in the sitemap must use the same protocol and reside on the same host as the sitemap. For example, a sitemap at http://example.com/catalog/sitemap.xml can include URLs starting with http://example.com/catalog/ but not http://example.com/images/.

You can compress your sitemap files using gzip to reduce bandwidth, but the uncompressed file must still be no larger than 50MB. If you have more than 50,000 URLs, you must create multiple sitemap files and list them in a sitemap index file. A sitemap index file can list up to 50,000 sitemaps.

An internal-link and sitemap routine to move pages to indexed#

If a page is discovered but not indexed, Google needs a way to find it from a known page. For a new website, the best first step is to request indexing of your homepage, which should prompt Google to start crawling the rest of the site. For missing parts of a site, make sure they are linked properly from established pages.

Use this routine to move pages from discovered to indexed: 1. Add a prominent internal link: Link to the new page from your homepage or a high-traffic category page. 2. Update your sitemap: Add the URL to your sitemap and set the <lastmod> tag to the current date. 3. Check robots.txt: Ensure you are not blocking Googlebot from crawling the page or its parent directory. 4. Inspect the URL: Use the URL Inspection tool in Search Console to check the specific page's status. You can request indexing for individual pages from this tool.

You can generate a valid sitemap snippet using Python:

import datetime

urls = [
    "https://example.com/",
    "https://example.com/about/",
    "https://example.com/contact/",
]

today = datetime.date.today().isoformat()

sitemap = '<?xml version="1.0" encoding="UTF-8"?>\n'
sitemap += '<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">\n'

for url in urls:
    sitemap += f"  <url>\n    <loc>{url}</loc>\n    <lastmod>{today}</lastmod>\n  </url>\n"

sitemap += '</urlset>'

print(sitemap)

Requesting validation and what to expect#

If you fix an issue that was causing pages to sit in the Discovered - currently not indexed bucket, you can click "Validate Fix" in the Search Console issue details page. When you click it, Search Console immediately checks a few pages. If the current instance exists in any of those pages, validation ends and the state remains unchanged.

If the sample pages do not have the error, validation continues with a "Started" state. Search Console then works through the list of known URLs affected by this issue, queuing them for recrawling. Validation typically takes up to about two weeks, but in some cases it can take longer.

When a URL is checked during validation, if the issue is not found, the instance validation state changes to "Passing". If it is the first instance checked after validation started, the issue validation state changes to "Looking good". If the URL is no longer reachable, the instance state changes to "Other" (which is not an error state). If the instance is still present, the issue state changes to "Failed" and validation ends. Even if you never click "Start validation", Google can detect fixed instances of an issue during its regular crawl and change the issue count to 0 on the report.

Wait for a validation cycle to complete before requesting another cycle, even if you have fixed some issues during the current cycle.

Gotchas and common mistakes#

• Checking the wrong report: The Page indexing report is not used to investigate the index status of specific pages. To find the index status of a specific page, use the URL Inspection tool.
• Mismatched totals: Do not expect the totals in the report to match your exact estimate of URLs on your site. The indexed and not indexed totals are complete and accurate from Google's perspective, but small discrepancies occur for various reasons.
• Blocked sitemaps: Submitting a sitemap that includes URLs blocked by robots.txt, noindex, or a login requirement causes error spikes. Ensure your sitemap URLs are accessible.
• Drops without errors: A drop in total indexed pages without corresponding errors might mean you are blocking access to existing pages via robots.txt, noindex, or a required login. Look for a spike in non-indexed URLs that corresponds to your drop in indexed pages.
• Overusing "Validate Fix": Clicking "Validate Fix" repeatedly without waiting for the cycle to complete will not speed things up. The system requires a full cycle to finish.
• Server errors: A server error means Googlebot couldn't access your URL, the request timed out, or your site was busy. You can use the Crawl Stats report to see if Google is reporting site availability issues.

Quick reference checklist#

• Use site:yourdomain.com on Google to check if key pages are indexed, especially if your site has fewer than 500 pages.
• Use the URL Inspection tool for specific pages instead of the Page indexing report.
• Ensure no robots.txt blocks or noindex tags are preventing crawling.
• Consolidate duplicate content and fix soft 404 errors to stop wasting crawl budget.
• Include the <lastmod> tag in your sitemap for updated content.
• Keep internal links pointing to your new pages from established, known URLs.
• Wait for the validation cycle to finish before requesting another.

Quick answers