“Discovered – currently not indexed” means Google knows the URL but has not crawled it yet. It is not proof that the page has bad content, a wrong canonical, or a noindex tag: Google has not downloaded the page from that URL and cannot have made those page-level judgements. The useful question is therefore not “how do I force indexing?” but “why is this URL receiving too little crawl priority, and is it a URL that belongs in search at all?”
Google's Page indexing report documentation says the crawl was postponed because visiting the site was expected to overload it, and that the last crawl date is consequently empty. This article turns that short definition into a reproducible diagnosis. The method uses four signals available in the SEOKit GSC URL Auditor: live HTTP response, sitemap membership, internal-link evidence and crawl access. Those facts do not prove what Google will index, but they separate technical contradictions from a simple priority problem.
What does the status prove — and what does it not prove?
The status proves two things: Google discovered an address, and the indexed-data view has no completed crawl for it. The empty last-crawl field matters. It distinguishes this status from “Crawled – currently not indexed,” where Google fetched the page and may already have evaluated its content and canonical signals. The difference changes the investigation.
| Signal in Search Console | What you can conclude | What you cannot conclude |
|---|---|---|
| Discovered, not indexed; no last crawl | Google knows the URL but has not recorded a crawl for it. | That the text is thin, duplicated or low quality. |
| Live test returns 200 | Googlebot can fetch the current version now. | That the indexed system has already scheduled or accepted it. |
| URL is in a sitemap | You explicitly submitted the canonical-looking address for discovery. | That a sitemap creates crawl demand or guarantees indexing. |
| URL has internal links | The site exposes a navigational path and context. | That the page is important enough to crawl immediately. |
Google also warns that “Not indexed” does not automatically mean an error and recommends determining why a URL was excluded before fixing anything. That is why a generic list of possible causes is weak advice: the same status can describe a new product page waiting its turn, an orphan URL known only from a sitemap, or thousands of filter combinations that should never have been submitted.
Which URLs should be indexed in the first place?
Start by classifying intent, not by pressing “Request indexing.” A page belongs in the index when it is canonical, returns a useful answer on its own and is meant to attract search visits. Internal search results, empty filters, tracking parameters, calendar combinations and duplicate faceted URLs usually fail that test. Their correct outcome may be removal from the sitemap, consolidation or a crawl-control change — not faster indexing.
For every affected URL, answer three questions:
- Would a search visitor be satisfied on this exact URL? Judge the rendered page, not the database record or planned template.
- Is this the canonical address? Do not spend crawl attention on a parameter version while the site points to another URL.
- Can a person reach it through normal navigation? A URL that exists only in a sitemap has discovery but weak site-level evidence of importance.
If the answer is “no,” exclude or consolidate the URL deliberately. If all three answers are “yes,” move to the four-signal check.
How does the four-signal SEOKit diagnosis work?
Export the affected group from the Page indexing report and load the file into the GSC URL Auditor. Search Console's examples table is capped at 1,000 URLs and may be incomplete even below that limit, according to Google's documentation. Treat the export as a diagnostic sample, not a complete crawl inventory.
| Check | Healthy evidence | Contradiction to investigate |
|---|---|---|
| Live HTTP response | Stable 200 on the intended canonical URL. | Redirect, intermittent 5xx, timeout, 403 or a 200 page that renders an error. |
| Sitemap membership | Only canonical, indexable pages you want in search are listed. | Obsolete, redirected, parameterised or intentionally excluded URLs remain submitted. |
| Internal links | Relevant indexable pages link to the URL with crawlable links. | The sitemap is the only source, or links appear only after interaction. |
| Crawl access | Googlebot can load the page and required resources without authentication. | robots rules, a firewall, rate limiting or unstable hosting blocks the request. |
The value is in combinations. A 200 URL in the sitemap with several internal links but no crawl date is a plausible queue or capacity case. A 200 URL found only in a sitemap is an orphan-priority case. Hundreds of parameter URLs with no internal links are an inventory problem. A URL that now redirects is stale report data or a cleanup task, not an indexing task.
Why should you diagnose clusters instead of isolated URLs?
One delayed page and a growing folder of delayed pages require different decisions. Group the export by directory, template or parameter pattern. Compare how many affected addresses each group contributes and whether the four signals repeat. This is the article's main practical distinction: a repeated pattern is evidence about a template; a single URL is not.
For example, imagine an export with product pages, tag pages and filtered categories. Products return 200, appear in the product sitemap and receive links from categories. Tag pages return 200 but have no internal links. Filter URLs are absent from the sitemap yet appear in crawlable navigation. Sending all three groups for reindexing hides the cause. Products may simply need time; tag pages need an editorial decision; filter navigation needs crawl-inventory cleanup.
Google's crawl-budget guidance recommends managing duplicate and low-value inventory, fast server responses and resources that return errors. Crawl-budget work is mainly relevant to large or rapidly changing sites, but the cluster method is useful on any site because it prevents fixing the wrong URL one by one.
What should you fix for each evidence pattern?
| Observed pattern | Likely task | Verification |
|---|---|---|
| Wanted page; 200; sitemap; strong internal links; live test works | Do not rewrite blindly. Check whether the cluster is new and monitor the indexed-data status. | Inspect one representative URL and watch the group trend. |
| Wanted page; 200; sitemap; no internal links | Add contextual links from relevant indexed pages and make the URL part of normal navigation. | Re-crawl your site and confirm the link is present without a click or script-only event. |
| Wanted page; unstable response, 5xx or timeout | Fix capacity, caching or rate limiting before requesting another crawl. | Repeat live checks at different times and inspect server logs. |
| Wanted page; blocked by robots or authentication | Remove the unintended block. Do not use robots.txt as a noindex mechanism. | Use the URL Inspection workspace and confirm crawl access. |
| Unwanted filter, search or duplicate URL | Remove it from the sitemap and internal crawl paths; consolidate when a canonical alternative exists. | Confirm that the intended canonical page remains reachable. |
| URL now redirects or is gone | Clean the sitemap and internal links. Keep the redirect only when there is a true replacement. | Check the final response and destination; do not request indexing for the old URL. |
This matrix deliberately avoids a “quality” diagnosis until a crawl has actually occurred. If the status later changes to “Crawled – currently not indexed,” content, duplication and canonical selection become reasonable areas to investigate. Before that change, presenting a page rewrite as a proven fix confuses two different stages of Google's pipeline.
Should you request indexing after the fix?
Use the live URL Inspection tool for a small number of important pages after the technical contradiction is removed. For many URLs, Google recommends a sitemap. The recrawl documentation is explicit: submitting a request does not guarantee immediate inclusion or inclusion at all, and repeating requests does not make crawling faster.
Record the date of the fix, the affected template and one representative URL. Then monitor the group in the SEOKit indexing workspace. A useful result is not “the button was clicked”; it is that new URLs stop entering the cluster and existing URLs eventually receive a crawl date or move to a more informative status.
What this method cannot tell you
The four signals cannot predict Google's schedule or guarantee indexing. Search Console exposes examples rather than a complete list, its indexed data can lag behind the live page, and a successful live test proves present access only. SEOKit reads the evidence and prioritises work; it does not change Search Console, submit hidden commands or know Google's internal crawl queue.
It also does not turn every URL into an indexing candidate. The correct conclusion for a large filter cluster may be “stop exposing these URLs,” while a single strategic landing page deserves better navigation and a stable server response. That distinction is more valuable than a universal fix.
What should you do next?
Export the “Discovered – currently not indexed” group, run it through the GSC URL Auditor, and group the results before changing any page. Fix repeated technical contradictions first, strengthen discovery for wanted orphan pages, and remove unwanted inventory from your signals. For the wider difference between discovery, crawling and indexing, use the indexing guide; for pages that return 200 but look missing after a crawl, see the soft 404 diagnosis.