google search console discovered vs crawled currently not indexed

Quick Answer

google search console discovered vs crawled currently not indexed describes two different stages of Google's indexing process. Discovered – currently not indexed means Google found a URL but has not crawled it yet. Crawled – currently not indexed means Google crawled the URL but did not index it. Each status calls for different checks.

Key Takeaways

These two Search Console statuses require different first steps. Knowing which stage Google reached helps you avoid making changes that do not address the problem.

• Discovered – currently not indexed means Google knows about the URL but has not yet crawled it.
• Crawled – currently not indexed means Google crawled the URL but has not added it to its search index.
• For Discovered URLs, check crawl access, internal links, server health, and sitemap entries before changing the content.
• For Crawled URLs, review index directives, canonical signals, rendered content, duplication, and the page's distinct value.
• A successful URL Inspection live test does not prove the page is indexed or guarantee that Google will index it.
• Sitemaps and indexing requests can help Google find or revisit URLs, but neither guarantees indexing.
• Fix confirmed problems, document what changed, and check later results without assuming a fixed indexing deadline.

The best next action depends on what Google has already done. First establish the intended indexing outcome. Then use evidence from the affected URL to choose the right fix.

The Difference Is Whether Google Has Crawled the URL

The main difference is simple. Discovered means found but not crawled. Crawled means crawled but not indexed. Google's Page indexing report documentation defines both statuses.

Neither label gives a complete explanation of why a URL is missing from Google Search. It also does not prove that the page will remain excluded.

A Discovered URL has reached Google's attention, but crawling has not yet happened. Google explains that it may postpone a planned crawl when fetching the URL could overload the site. This describes a possible reason for the status. It does not prove that every affected website has a server problem.

A Crawled URL has passed a different stage. Google fetched the page, but indexing did not follow. Google says the page may be indexed later. It also says that resubmitting the URL solely because it has this status is unnecessary.

The following comparison separates the confirmed meaning of each status from the checks most likely to help. These checks are diagnostic priorities, not proof of a specific cause.

The distinction changes where you should spend your time. A Discovered URL calls for a crawl-focused investigation. A Crawled URL calls for a closer look at index eligibility and the page itself. Both require URL-level evidence before changing the site.

google search console discovered vs crawled currently not indexed: Choose the First Check

Start by deciding whether the affected URL should have its own Google search result. Not every URL needs one. Filters, tracking parameters, old pages, and duplicate product variants may serve users without needing separate index entries.

Once you know the intended outcome, use the branch that matches the reported status. Google's crawling troubleshooting guidance covers common access and server problems. Use it to guide tests rather than guessing from the status label.

The two branches below focus on different stages. They share some technical checks, but the order matters. There is little value in rewriting page text before you know whether Google can reach the URL.

If Google Has Discovered but Not Crawled the URL

Start with access and discovery. Confirm that the page exists at the intended URL and that Google can reach it. Check the protocol, host, path, and any parameters. A small URL difference can lead to another page or an unwanted redirect.

Next, inspect the final HTTP response. Look for server errors, authentication rules, unexpected redirects, and firewall or CDN restrictions. A page that works in your browser may still have access problems for Googlebot.

Review internal links next. Important pages should have clear paths from relevant, accessible pages. Use standard crawlable HTML links. Avoid making key links depend entirely on a click or other user action. Check that internal links point to the preferred URL rather than an old path.

A sitemap can support discovery. Keep it focused on intended canonical URLs. Remove obsolete entries, unnecessary redirects, and deliberately excluded pages. Google's crawling and indexing FAQ explains that sitemap submission does not guarantee indexing or improve rankings merely because the sitemap was submitted.

For larger or more complex sites, server logs can add useful evidence. They may show requests from Googlebot and the responses the server returned. Search Console reports do not provide a complete request history for every URL. Logs can therefore help distinguish a reported status from actual server activity.

Follow this order before choosing a fix. Each step tests a different possible obstacle.

1. Confirm that the URL needs its own index entry.
2. Check the final response code and redirect chain.
3. Review robots.txt, authentication, firewall rules, and CDN restrictions.
4. Confirm that relevant internal pages link to the intended URL.
5. Check the sitemap entry if a sitemap is used.
6. Review available server logs for Googlebot requests.
7. Correct confirmed access or discovery problems before requesting another crawl.

An accessible, well-linked URL may still remain in Discovered status. That alone does not establish a crawl-budget fault. Record what you have checked and avoid broad server or content changes without supporting evidence.

If Google Has Crawled but Not Indexed the URL

Begin with technical eligibility, then examine the page and its relationship to other URLs. A past crawl proves that Google fetched the URL. It does not prove that Google should keep that URL as a separate search result.

Check the current response and indexing controls first. Look for unwanted redirects, a noindex meta tag, or an X-Robots-Tag response header. Review robots.txt as a separate control. It manages crawler access rather than acting as a universal way to remove URLs from Google's index.

An important detail is easy to miss. If robots.txt blocks a URL, Google may not be able to fetch its HTML and read a page-level noindex instruction. The correct setting depends on the outcome you want.

Next, inspect canonical signals. A canonical tag suggests the preferred version of duplicate or similar pages. Google can choose a different canonical. Compare the declared canonical with redirects, internal links, sitemap entries, and Google's selected canonical when available.

Then inspect the rendered page. Confirm that the main content, title, and key links appear as intended. Look for empty templates, missing text, blocked resources, or content that fails to load. A successful HTTP 200 response does not prove the page contains the material Google needs to process.

Finally, assess duplication and usefulness. Several URLs may serve nearly the same purpose. Common cases include filtered category pages, sorted product listings, tracking variants, and syndicated articles. Decide whether each URL offers enough distinct value to need its own search result.

For syndicated material, our guide to syndicated content SEO and canonical signals explores the role of preferred URLs and duplicate material. Similar content is a reason to investigate. Its presence alone does not prove why Google excluded a specific page.

Depending on the evidence, you may improve the page, merge overlapping content, correct canonical signals, redirect an obsolete URL, or leave an intended exclusion in place. Google's status label does not identify weak content as the cause in every case.

Our broader guide to Google indexing troubleshooting covers related technical checks. Use those checks only where they fit the evidence from the affected URL.

Use URL Inspection Without Confusing a Live Test With Index Inclusion

URL Inspection provides two different views. The indexed-version information shows what Google has recorded about the URL. The live test checks certain current conditions. A successful live test does not prove that Google has indexed the page.

Google explains these limits in its URL Inspection tool documentation. The tool can show available crawl details, indexing information, and rendered output. Stored information may also show Google's selected canonical URL. The live test cannot predict Google's final canonical choice or confirm that Google will index the page.

This distinction matters after a site change. Suppose you fix an access rule in the morning. The live test may show that Google can now fetch the page. The stored report may still show an earlier exclusion. Those results are not necessarily in conflict. They describe different points in the process.

The following evidence map helps you avoid drawing conclusions that a test cannot support.

When inspecting a URL, record the exact status and available last-crawl details. Run a live test when you need to assess current access or rendering. Compare the results with the stored report. Then review canonical information where available.

A live test that passes while the stored status remains unchanged is not, by itself, evidence of a new problem. You need to see whether the intended fix took effect and whether Google later changes its recorded state.

For a field-by-field explanation, see our URL Inspection live test guide. Use it alongside Google's own tool guidance. Neither view should be treated as a promise of future index inclusion.

Request Indexing Only After the Relevant Checks

Request indexing after you have confirmed that the URL belongs in the index and corrected any relevant problem. A request can make sense after a meaningful change. It cannot replace technical diagnosis or force Google to include a page.

Google's request-to-recrawl guidance says that crawling can take several days to several weeks. A request does not guarantee immediate inclusion or inclusion at all. Repeated requests for the same unchanged URL do not make Google crawl it faster.

Sitemaps have a related but different purpose. They help Google learn about URLs. They do not require Google to fetch each page, include every page in its index, or improve rankings merely because they were submitted.

This difference also matters when evaluating URL submission services. A provider may accept a URL, process a request, report a submission, or record a crawl event. None of those events proves that Google's index contains the requested page. Each describes an earlier or separate step.

IndexNowFast describes its URL submission and tracking services. Those service descriptions should be treated as provider claims, not independent evidence of an indexing result. A successful service workflow must not be confused with a Google indexing guarantee.

If you have fixed a confirmed issue and need the submission steps, our guide to submitting a URL to Google explains the practical process. Follow Google's official guidance for the limits of requests and the likely variation in crawl timing.

Use a clear decision sequence. Confirm the page's intended role, investigate the status, make a justified correction, and request indexing when appropriate. Then check later evidence. Record the date and nature of each change so you can tell what happened after the request.

Avoid using a universal 24-hour or 48-hour deadline. Google does not promise that an individual page will enter its index within either period. A delayed status change is not proof that the correction failed. Likewise, a processed submission is not proof that indexing succeeded.

Follow a URL-Level Decision Path

A repeatable process helps separate what Google has done from what you think it might do next. Begin with the intended outcome. Then check technical access and index eligibility before changing the page.

The workflow below combines Google's status definitions, URL Inspection guidance, and crawl troubleshooting advice. It is an editorial diagnostic method, not an official Google tool. Each action should respond to evidence from the URL or its site.

Step 1: Decide what should happen to the URL. Determine whether the page should be indexed, use another canonical, redirect, or remain excluded. Some URLs should never have separate search results.

Step 2: Record the reported state. Save the exact URL, its Page indexing status, the inspection date, and any available last-crawl information. Do not guess when a field is unavailable.

Step 3: Check access and response behavior. Review the final HTTP response, redirects, authentication, robots.txt, firewall rules, CDN behavior, and server availability. Fix confirmed fetch problems before changing page text.

Step 4: Check index directives and canonical signals. Inspect meta robots and X-Robots-Tag rules. Compare declared canonicals with redirects, internal links, sitemap entries, and Google's selected canonical when shown.

Step 5: Inspect rendered content. Confirm that the title, main content, and important links appear as expected. If the rendered page lacks key content, investigate why before assuming a content quality issue.

Step 6: Follow the correct status branch. For Discovered, focus on crawl access, discovery, internal links, and server health. For Crawled, focus on index eligibility, canonical signals, rendering, duplication, and usefulness.

Step 7: Make a targeted correction. Change only what the evidence supports. If the URL is an unwanted duplicate, a redirect or canonical decision may be more useful than trying to force a separate index entry.

Step 8: Request indexing when justified and review later results. Record the change and revisit the stored status. Do not treat a successful live test as proof that indexing is complete.

This process is especially useful when several URLs share one reported status. Examine representative URLs, but avoid assuming they all have the same cause. Different templates, content types, access rules, and URL variants can create different problems.

For instance, a product page and a filtered category URL can both appear as Crawled – currently not indexed. The product page may deserve its own search result. The filtered URL may simply duplicate the main category page. The right outcome differs even though the reported status is the same.

A status change also needs careful interpretation. Moving from Discovered to Crawled shows a change in the reported processing stage. It does not prove the URL is indexed. A fixed canonical tag shows that you changed a signal, not that Google accepted the intended canonical.

Track the observed state, the action taken, and the later outcome as separate facts. That record is more useful than submitting the same URL repeatedly.

Avoid Common Misinterpretations

An indexing label describes a processing state, not a complete diagnosis. A wrong assumption can lead to wasted work or changes that harm useful pages.

The following claim check compares common interpretations with what the evidence supports. It also shows the more useful response for each case.

Two of these mistakes can be costly. A site owner may rewrite useful content because a Discovered URL appears unindexed, even though the first issue to investigate is crawling. Another may remove a valuable Crawled URL without checking whether an unwanted canonical signal or missing rendered content contributed to the problem.

Neither status alone proves a penalty. Neither proves that Google considers the content poor. A page also does not need a separate index entry merely because someone submitted it in a sitemap.

These distinctions are useful when reviewing work done by an SEO provider. Ask what was actually observed. A screenshot showing a submitted URL, a crawl request, or a successful live test is not the same as evidence of inclusion in Google's index.

When a URL remains excluded, the best response is a documented finding. State what was checked, what is still unknown, and what action is justified. Avoid confident diagnoses based only on the label.

Frequently Asked Questions

These questions address the common decisions that arise after checking either status. The answers follow Google's documented status meanings and the limits of Search Console evidence.

Which status means Google has actually visited the page?

Crawled – currently not indexed means Google crawled the URL but has not indexed it. Discovered – currently not indexed means Google found the URL but has not yet crawled it, according to the reported status. These labels describe different stages rather than different levels of a confirmed content problem.

Should I request indexing again?

Google says resubmission is unnecessary solely because a URL has Crawled – currently not indexed status. For either status, first check whether a relevant problem exists. A request may make sense after a meaningful correction. It does not guarantee inclusion, and repeating an unchanged request does not speed up crawling.

Can a page pass the live test and remain unindexed?

Yes. The live test checks certain current conditions. It does not establish that the URL is included in Google's index. Compare the test with the stored inspection result and examine any confirmed technical or canonical issue. A passing test cannot predict Google's final indexing decision.

Does submitting a sitemap guarantee indexing?

No. A sitemap helps Google discover URLs. It does not force Google to crawl or index every entry. Submitting one does not improve rankings merely because it was submitted. Keep sitemap entries accurate and support important pages with relevant, crawlable internal links.

How long should I wait before investigating again?

There is no universal deadline for individual URLs. Google's recrawl guidance says crawling may take several days to several weeks. Index inclusion is not guaranteed. Review the page after a correction and check later evidence, but do not treat a fixed number of hours as proof of success or failure.

Can an indexing service guarantee that Google will index a URL?

A submission or tracking service cannot guarantee Google's final indexing decision. The service may process requests or report workflow events. Google still controls crawling and indexing. Judge results by the actual indexing state rather than a provider's submission status or processing estimate.

Should every URL in the Page indexing report be fixed?

No. Some URLs are intentionally excluded, redirected, or consolidated with other pages. Begin by deciding which URLs deserve their own search results. Use report patterns to find areas worth reviewing, then inspect specific URLs before making changes.

Does Crawled – currently not indexed always mean the content is too thin?

The label does not prove a thin-content problem. It confirms that crawling occurred without indexing. Check directives, canonicals, rendered content, duplication, and distinct usefulness. Reach a content conclusion only after reviewing the page and the competing URLs that serve a similar purpose.

Final Decision: Diagnose the Stage Before Changing the Page

Discovered – currently not indexed and Crawled – currently not indexed are different signals. One means Google has found the URL but has not yet crawled it. The other means Google crawled it but did not include it in the index. That distinction should guide the first investigation.

For Discovered URLs, check whether Google can find and fetch the intended page. Review internal links, crawl controls, redirects, and server behavior. For Crawled URLs, examine index directives, canonical choices, rendered content, duplication, and the value of a separate search result.

Use URL Inspection to keep stored indexing information separate from a live test. Make changes only where the evidence supports them. If a URL should remain excluded or consolidated, do not treat that outcome as a technical failure.

Sitemaps, indexing requests, and submission services may support parts of the workflow. They cannot guarantee index inclusion. The reliable approach is to record the reported status, make a justified correction, and review later evidence without relying on an invented deadline.