Search Console Says “Discovered – Currently Not Indexed”: What Can a Small Site Check?

You publish a useful page, add it to your sitemap, and later see “Discovered – currently not indexed” in Google Search Console. The page opens for you. Is something broken?

Not necessarily. Google's Page indexing report says this status means Google found the URL but had not crawled it when the report was recorded. Google lists anticipated host load as a reason a crawl may be rescheduled; it does not say why any particular URL has this status. The label does not establish that your server is overloaded or that the page has a quality problem.

This guide is for a small site with a few important pages in that report. It separates what the report says from checks you can make now, so you can decide whether there is anything to fix. The examples are illustrative; they are not results from a customer site.

Start with one URL you actually want indexed

In Search Console, open Pages, select the status and choose an important URL. Copy the entire address: protocol, hostname, path, trailing slash and any query parameters. If it contains a ?, include everything after it as well. Record the status and the date shown by the report.

Then inspect that same address with URL Inspection. The page report and the inspection result can reflect observations from different times. If inspection now says the URL is indexed, check that the protocol, hostname, path, trailing slash and any query parameters match, and compare the dates before changing anything. If it is still excluded, save the result as your baseline.

An empty last-crawl date is consistent with this status. It does not tell you precisely when a crawl will happen. “Discovered” is also different from “Crawled – currently not indexed”: the latter means Google fetched the page but did not index it. If that is the status you see, use the separate crawled-page guide.

Check the address you submitted, not just the address you remember

Open the exact URL in a private browser window without signing in. Does it reach the page a visitor should see, or redirect to a different address? If you control the site, check the response and redirect chain with your normal site tools as well. A browser visit is useful, but it is not a Googlebot crawl.

Imagine a sitemap contains https://example.com/service?ref=email, while the intended page is https://example.com/service. First confirm the parameter does not change the page content. If it only tracks a campaign, use the preferred clean URL in the sitemap and relevant internal links. If the addresses serve different purposes, investigate that difference before treating either as a duplicate. This is an example; the status does not establish that your page has a parameter or redirect problem.

Google's sitemap guidance explains that a sitemap helps search engines discover URLs; it does not guarantee crawling or indexing. Repeatedly submitting the same sitemap does not by itself resolve the status.

Check access separately from the old report

Use the inspection tool's live test for the same URL when you need a current access check. Check the crawl result, HTTP response and any robots or noindex message the tool displays. If the live test reports a robots restriction, login wall or error, investigate that specific evidence with whoever controls the site. A successful live test reports on the URL's current availability; it does not show whether Google has indexed it. Check the indexed-data view for Google's recorded indexing status.

The live test also does not check every possible indexing issue, and it does not predict Google's selected canonical. Keep its result separate from the older indexed-data view. A 200 response alone does not establish that Google has indexed the page.

If the reported URL redirects, is intentionally private, or is not the page you want searchers to find, it may not need to be indexed. Align the sitemap and links with the intended public destination rather than trying to make every reported URL appear in search.

Look for a site-wide access pattern before blaming crawl budget

Crawl budget describes how much Google can and wants to crawl on a site; it is not a setting you switch on. One discovered URL on a small site is not enough evidence to conclude that the server cannot handle Googlebot. If many important URLs have the same status, look for a pattern: did they all launch at once, share a path, or start after a server change? Compare a small sample rather than treating every excluded URL as a separate emergency.

Check Search Console's crawl statistics and your hosting provider's available error or capacity information if you have access. Google's crawling troubleshooting guidance discusses host-load warnings and crawl errors. A warning or a pattern of server errors can guide a hosting investigation; this status alone does not confirm either. Do not increase server capacity, remove pages or change crawl settings solely because one URL is listed.

Make the intended page reachable from a relevant place

Find an existing page where a link would help a reader. For example, a service overview might link to a genuinely useful page explaining that service's process. Use descriptive link text and the intended destination URL. A link is worth adding because it helps people navigate; it is not an instant indexing switch.

If the link already exists and the correct URL is in the sitemap, note those facts. You do not need to add the same link to every page or publish extra articles just to provoke a crawl.

Record the result and give Google time to revisit

Write down the URL, report date, observed status, what the live test showed, and any specific change you made. If you fixed a genuine access issue, check the live URL again. You can then request indexing for that important URL in Search Console; repeating the same request as a routine is unnecessary. Google's recrawl guidance makes clear that a request does not guarantee immediate crawling or inclusion.

On your next review, compare the same URL and the dates. If the report has not changed, you may not yet have a new observation. If the status changes to “Crawled – currently not indexed,” Google has reached a different stage; use that status's evidence rather than continuing to diagnose discovery alone. There is no universal waiting period in this guide that proves a page is broken.

For a separate homepage check, SEOHabit's website SEO checker offers a first check with limited homepage scope after registration. Site ownership verification is required for ongoing checks, but not for that first limited check. It cannot tell you why Google has not crawled an inner page. Use Search Console for Google's report and inspection results.

Start with one important URL, record what you know, and change only what the evidence supports. Sometimes the useful result is knowing that the current checks found no specific fix yet.