If Search Console reports “Crawled – currently not indexed,” Google says it crawled the URL but has not indexed it. That label does not tell you why, and Google says you do not need to resubmit that URL just because it has this status (Page indexing report). Before changing the page, decide whether this exact URL should appear in Search, then compare the report, the indexed URL Inspection record, the current live test, the page’s canonical signals, and the answer Google can render. Each view answers a different question.
This guide is for a human-facing page that has a distinct search job. A feed, duplicate URL, removed page, or intentionally excluded utility URL may be correctly absent. The aim is to find evidence for one useful action—or to stop when the evidence supports no action.
What “Crawled – currently not indexed” does and does not mean
Google defines the status narrowly: it crawled the page, but did not index it. The page might be indexed later, or it might remain outside the index. The status alone does not identify a quality penalty, a robots.txt block, a noindex directive, a canonical problem, or a technical error. Search Console lists those conditions under their own issue types. Read the reason as an observed state, then diagnose the page itself.
That makes it different from “Discovered – currently not indexed.” For that status, Google says it knows the URL but has not crawled it; the report has no last-crawl date. Google says this can happen when crawling a URL is expected to overload a site and the crawl is rescheduled. That is Google’s general explanation, not proof that any particular site was overloaded. The Page indexing report documentation also says that some URLs should not be indexed at all.
| What Search Console shows | What the label establishes | What it does not establish | First useful check |
|---|---|---|---|
| Crawled – currently not indexed | Google crawled the URL and has not indexed it in the reported state. | Why it was not indexed, whether it will be indexed later, or whether the page needs a change. | Inspect the indexed record and its last crawl; compare the intended URL and the current page. |
| Discovered – currently not indexed | Google found the URL but has not crawled it; the report has no last-crawl date for it. | That the page was fetched, that crawl budget is the cause, or that the page has a content problem. | Check whether this URL should be indexed, then review useful internal discovery paths and the current sitemap. |
| URL marked noindex | Google encountered a noindex directive when it tried to index the page. | That the directive is accidental; it may be intentional. | Confirm the page’s search purpose and inspect the current HTML and response headers before changing the directive. |
| Blocked by robots.txt | The crawl was blocked by a robots.txt rule. | That Google has seen a noindex directive. A crawler blocked from fetching the page cannot read it. | Check the matching rule and whether blocking the URL is intentional. |
| Duplicate or alternate canonical | Google sees another URL as the representative page, or the URL is an alternate version. | That the other URL is the wrong choice. Duplicate or alternate pages are often expected. | Compare the user-declared and Google-selected canonicals with the content and the intended owner. |
| Server, redirect, access, or soft 404 issue | Search Console reports a specific fetch or response problem. | That every URL in the same site or template has the same defect. | Reproduce the named issue on an affected URL and test a representative peer before applying a shared fix. |
Google also limits the example URL list in the Page indexing report and says it is not guaranteed to show every URL in a status. Use that report to spot patterns and affected groups. For the index state of one important page, use URL Inspection. If the issue appears across many URLs, group them by a shared template or response pattern before assuming they share one cause.
Reconcile four dates before you edit anything
A page can appear to have conflicting statuses because the screens describe different snapshots. Write down the date you checked the aggregate report, the “Last crawl” time shown for the indexed URL, the live-test time, and the date of the page’s last meaningful change. Do not collapse those timestamps into one “current status.”
The Page indexing report summarizes known URLs and groups them by status. When a URL is indexed, the indexed URL Inspection result describes the version Google stored; its “Last crawl” field records when Google last fetched the URL. A crawl date alone does not prove the URL was indexed. Google says its stored version may differ from the current page. The Google-selected canonical is available in the indexed data, and Google notes that this value can be a few hours behind its index.
A live URL test is different again: it fetches the URL at the time of the test. It can show whether Google’s inspection tool can access the current page, and—when the test succeeds—show a rendered screenshot, returned HTML, headers, loaded resources, and JavaScript console output. But it does not test whether the URL is a duplicate or predict Google’s canonical choice. It also does not test manual actions, security issues, legal content removals, or temporary URL blocks; check the Manual Actions, Security Issues, or Removals reports when those conditions could explain an appearance problem. A successful test means the tested page can be crawled and parsed under those conditions; it does not guarantee indexing.
Use this sequence when the screens disagree:
- Check the exact URL in URL Inspection. Read whether the indexed result says the URL is on Google, the last-crawl date, and the Google-selected canonical. “URL is on Google” means eligible to appear, not guaranteed to appear for a particular query.
- Compare the indexed crawl with your change log. If you corrected a page after Google’s last crawl, an old indexed result can describe the previous version.
- Run a live test. Record its time, fetch result, crawl and indexing permissions, redirect behavior, and rendered page. The live test follows redirects but does not identify the final URL it tested, so trace redirects separately if the destination is uncertain.
- Keep aggregate and search visibility separate. If URL Inspection now shows an indexed URL while a report still shows an older status, record the two dates and recheck the report later. If it is indexed but absent for a query, investigate query visibility separately; do not keep “fixing” its index state based on a search operator alone.
Google’s URL Inspection documentation explains these limits. The practical rule is simple: the indexed view answers what Google last stored; the live test answers what its inspection crawler can fetch now; the report shows a broader, potentially older group view.
A page-first diagnosis, in evidence order
1. Decide which URL is meant to represent the answer
Before checking a fix, write down the exact URL you want indexed and the job it serves. Is it a useful landing page for a distinct query, or is it a filtered view, tracking-parameter variant, feed, redirect, print page, or alternate language/device URL? A site can have many URLs that are correctly absent from Google. The goal is the canonical version of each important page, not 100% index coverage.
If the URL is an intentional duplicate or utility endpoint, close the issue with that rationale. Do not make it indexable just to reduce a report count. For useful technical context, follow the crawl, render and index sequence; this page focuses on diagnosing the specific status.
2. Verify access and indexing directives
On an intended search landing page, check the exact response and final destination: does the URL return the page you expect, or does it redirect, time out, return a 4xx/5xx response, or show a “not found” message with a successful status? Then check robots.txt, the HTML robots meta tag, and the X-Robots-Tag response header.
Do not treat “Indexing allowed? Yes” as proof that Google read the page. Google explains that when robots.txt blocks a URL, it cannot see a noindex directive and that field can still say “Yes.” Conversely, if the URL is deliberately noindex or behind access control, its absence may be correct. Match the fix to the intended search purpose and the actual issue shown; see Google’s URL Inspection details and issue definitions.
For a true response or configuration issue, fix that issue first and retest the same URL. For a removed page with no replacement, a 404 can be appropriate; if it has moved, use the appropriate redirect. Do not add a request-indexing action while a confirmed block, access failure, or wrong destination remains.
If the historical report shows a server error but a live test now succeeds, compare the host-availability window in Crawl Stats with server logs from the same period. Verify any suspected Googlebot request from its logged IP with reverse DNS, confirm the Google domain suffix specified for that crawler, then check that a forward lookup resolves to the original IP; a user-agent string alone does not verify the crawler. Google notes that server errors can be transient and that a live test can succeed after an earlier crawl failed. This comparison can confirm a past access event or a shared host issue, but it does not establish that overload caused the current indexing status. See the Page indexing troubleshooting guidance and Google’s Google crawler verification steps.
3. Compare the declared and selected canonical
In the indexed URL Inspection result, compare “User-declared canonical” with “Google-selected canonical.” Then open both pages and compare their actual main content, purpose, and page versions. If the two URLs are intended duplicates, the alternate may be working as designed. If the selected URL is unexpected, look for contradictory canonical tags or headers, sitemap entries, redirects, and internal links that point to different versions.
For duplicate or very similar pages, Google treats redirects and rel="canonical" as strong signals and sitemap inclusion as a weaker signal. These preferences are not guarantees. Keep the signals consistent, link internally to the preferred URL, and use a permanent redirect only when retiring a duplicate. Google advises against using robots.txt or noindex to choose a canonical. See its guidance on canonical signals and duplicate URLs.
If the page is meant to be distinct, do not point its canonical at a different page just because that URL already ranks. Confirm that the page really has a separate reader job, then correct any conflicting signals and make its main answer distinct. If it does not have a separate job, audit overlapping content and consolidate around the best owner.
4. Check what Google can render, not just what a person sees
A browser screenshot of a page that looks complete to you does not show what the live inspection crawler received. In URL Inspection, open “View tested page” after a successful live test. Confirm that the page’s main answer, primary text, and essential links are present in the rendered screenshot and returned HTML. Review the loaded-resource list and JavaScript console if the answer is missing or incomplete. Google documents these render details in its URL Inspection guide.
This is a way to find a current rendering or resource problem, not proof that rendering caused the indexing status. The live view is a fresh test; it does not reconstruct what Google saw on the stored version at its last crawl. If that crawl predates a rendering fix, note the gap and wait for a subsequent crawl and inspection record before concluding that the change failed. The URL may have been crawled without being indexed.
If a template hides its main answer until a script runs, test the relevant resources and the rendered output on affected URLs. Compare one affected page with a known-good page using the same template. Fix a confirmed shared rendering defect at the template or resource layer; avoid changing unrelated pages because they share a status label.
5. Review discovery and whether the page adds a distinct answer
For a URL Google has discovered but not crawled, check whether a relevant, crawlable page links to it and whether the current sitemap contains the preferred canonical URL. For a URL that Google has already crawled, discovery alone is not the whole question; focus on what Google fetched, which canonical it selected, and whether the page contributes a useful answer that is distinct from its closest owner.
Compare the intended query and reader job with the pages that already own them. Does this URL answer a different question, or does it repeat the same answer with a new title? If two pages are interchangeable for the same reader, consolidation may be more useful than asking Google to index both. If the job is distinct, add the missing decision, explanation, evidence, or worked example that makes that distinction real. A longer word count by itself is not a diagnosis or fix.
Use the evidence to prioritize SEO audit findings. Add contextual links only where a reader can continue to a related answer; improve contextual internal links when discovery or page importance evidence supports it. A page’s existence in a sitemap, or a single missing internal link, does not guarantee indexing.
Evidence-to-action matrix
Use the first confirmed finding as the next action. Several checks may be useful, but the status label itself is never enough to select a technical fix. Google distinguishes the aggregate Page indexing report, indexed URL Inspection, and the live test; consult the report guide and URL Inspection guide for each tool’s limits.
| Evidence | What it can establish | Next action when the finding matters | Stop when |
|---|---|---|---|
| Page indexing report | A group-level status and the issue types Google reports for known URLs. | Open URL Inspection for priority URLs; compare affected URLs by template or shared response. | The URL is intentionally excluded or the report is an older group snapshot with a newer per-URL indexed result. |
| Indexed URL Inspection | Google’s stored crawl and indexing record, its crawl date, indexing state, and selected canonical when available. | Compare the stored version with the page change log and intended canonical. | The URL is indexed and the original question was whether it is missing from the index. Check query appearance separately if needed. |
| Live URL test | Whether the current URL can be fetched and parsed under the test conditions; current directives and render evidence when available. | Fix a reproduced access or rendering problem, then retest the same page and a comparable template peer. | The confirmed technical issue is fixed in the live result. Continue to monitor indexed state; a successful test does not promise inclusion. |
| Canonical comparison | Whether Google selected the intended representative URL in the indexed record and whether declared signals conflict. | Align tags, headers, sitemap, redirects, and internal links with the actual owner decision; consolidate true duplicates. | The preferred URL is clear, signals agree, and any duplicate URL has an intentional disposition. |
| Rendered main answer | Whether the current inspection render contains the core content and resources needed to understand the page. | Repair only a reproduced rendering or resource failure; separately review the useful answer and source support. | The answer is present in the test render and no specific rendering defect remains. Do not infer that this alone makes the page indexable. |
| Overlap and intent review | Whether another page already serves the same query and reader job, or whether this page adds a separate answer. | Consolidate interchangeable answers; strengthen the original contribution where the job is distinct. | The page has a defensible owner and distinct purpose, or the redundant URL has been retired into its owner. |
| Cohort comparison | Whether a defect repeats within a shared template, response pattern, or canonical setup. | Verify the shared cause on affected pages, compare with a known-good peer, and fix at the narrowest common layer. | The common defect is fixed and affected URLs can be retested. Do not expand a one-template finding to unrelated pages. |
Five illustrative cohort cases
The URLs and observations below are fictional diagnostic scenarios. No example URL was tested, and none claims a successful indexing result. They show how the same status can lead to different decisions when the evidence differs.
| Fictional URL / case | Illustrative evidence recorded | What the evidence supports | Next action and stop rule |
|---|---|---|---|
https://example.com/feed.xmlIntentional feed exclusion | The feed is a machine-readable feed, not a human-facing landing page. The operator does not expect it to appear in Search. | Its absence may be intentional. The label alone does not require the feed to be made indexable. | Record the intended disposition and leave it alone. Reopen only if this URL is actually meant to be a search landing page or related human pages show a confirmed shared defect. |
https://example.com/guides/index-checkStale aggregate state | The aggregate report shows a non-indexed example. A later indexed URL Inspection result says the page is on Google and has a newer last-crawl date than the report check. | The two views describe different snapshots. The per-URL indexed record supports that the page is indexed; appearance for a query is a separate question. | Log the dates and stop treating this URL as missing from the index. Check the relevant query or landing-page performance if visibility remains the concern; do not repeat an indexing request to refresh an older aggregate row. |
https://example.com/audit/technical-seoUnexpected canonical | The intended canonical is this page, but the indexed inspection selects https://example.com/technical-seo/. The owner confirms the pages serve distinct reader jobs. | The indexed canonical choice conflicts with the owner’s intended separation. This does not establish which individual signal caused the choice. | Compare both pages, canonical tags, sitemap entries, redirects, and internal links. Align the intended signals and keep the answers distinct; then monitor a subsequent crawl and inspection record, then confirm the selected canonical and indexing state. Stop changing signals once they agree. |
https://example.com/tools/inspection-guideMain answer missing in render | The live inspection fetch succeeds, but its screenshot and returned HTML omit the page’s core answer. The example does not assume why it is missing. | The current test render is incomplete. The indexed status may have another or additional explanation. | Inspect loaded resources and the JavaScript console; reproduce the missing content and fix the confirmed delivery issue. Retest the render, then wait for indexed data before judging indexing. Stop the rendering branch once the answer appears in the tested output. |
https://example.com/blog/crawl-status-fixRedundant article | The page and an existing owner answer the same reader question. A review finds no separate query job or useful evidence; indexed inspection selects the established owner as canonical. | The two pages appear interchangeable for this reader job. Adding more words or another request would not create a distinct answer. | Consolidate the useful material into the established owner, retire the redundant URL with the appropriate redirect, and update internal links. Stop pursuing separate indexing for the retired URL. |
Use cohort sampling to locate common technical patterns, not to assign one cause to every URL with the same status. Group pages by template, response type, canonical setup, and intended search role. Compare an affected URL with a known-good peer in the same group; then inspect each priority canonical page on its own. A sample can reveal a shared defect, but it cannot prove that unrelated pages have it.
When to request indexing—and when to stop
For the Crawled status itself, Google explicitly says there is no need to resubmit the URL for crawling. First fix any confirmed access, directive, canonical, rendering, or content-owner issue. If an important page has changed substantially since its last crawl and the current version is available to Google, you can request a recrawl for that individual URL in URL Inspection.
A request enters a queue; it does not guarantee indexing or immediate search appearance. To request indexing in URL Inspection, you must be an owner or full user of the Search Console property. Google says crawling can take from a few days to a few weeks, individual requests have daily quotas, and submitting the same URL repeatedly will not make it crawl faster. For many new or updated URLs, Google recommends a sitemap, with updated pages marked by <lastmod>. Those are discovery and recrawl paths, not a way to override canonical selection or make a page qualify for the index. See Google’s recrawl guidance and URL Inspection requirements.
Close the investigation or pause edits when one of these conditions applies:
- The URL should not appear in Search. Record why it is a feed, alternate, duplicate, removed page, or intentional exclusion, then stop trying to raise its indexed count.
- The indexed inspection already says the URL is on Google. Stop diagnosing an indexing failure; investigate query visibility separately if that is the actual problem.
- The live technical defect is fixed and verified. Stop changing unrelated parts of the page. Record the retest and wait for a subsequent crawl record, then check its indexing state separately.
- The page is redundant with its real owner. Consolidate and retire the duplicate, then stop requesting indexing for that URL.
- No evidence identifies a cause. Record “unknown,” preserve the timestamps and checks, and set one evidence-based revisit point. Do not turn the status into a quality verdict or repeatedly rewrite the page.
A monitoring row you can reuse
Keep one row per intended canonical URL. Update it only when a test, page change, or report adds evidence. This makes stale snapshots visible and keeps “requested,” “crawled,” “indexed,” and “appearing for the target query” as separate outcomes.
| Canonical URL and reader job | Report status / checked date | Indexed status / last crawl | Declared / selected canonical | Live test time / fetch / main answer | Action, owner, and evidence | Next check trigger and outcome |
|---|---|---|---|---|---|---|
| [URL] — [intended search job] | [status] [YYYY-MM-DD] | [status] [crawl date or not shown] | [declared URL] [selected URL] | [time] [fetch result; answer present?] | [one action] [page-change date; request date or none; owner/evidence link] | [trigger/date] [requested / crawled / indexed / query visibility] |
Use crawl-budget guidance only when the evidence concerns a meaningful group of URLs or site capacity; a single crawled-but-not-indexed page does not establish a crawl-budget problem. The useful fix is the one supported by the URL’s intended role and the evidence you can reproduce.
