Crawled—currently not indexed: what to check before requesting again

Keep the indexed observation and the live test apart

In URL Inspection, record the reported status and last crawl date before running a live test. The indexed report describes Google’s stored observation. The live test evaluates the page you serve now and does not test every indexing or canonical condition. Inspection documentation

A page can have changed since that stored crawl. A successful live fetch can therefore coexist with an older exclusion report. That is a reason to compare versions and dates, not proof that the live test has confirmed indexing.

Also keep “Discovered—currently not indexed” separate. That label concerns a URL Google knows about but has not yet crawled. A response to a confirmed past crawl and a response to a missing crawl start with different evidence. Status definitions

If the review finds a representative-selection problem, compare a duplicate without a declared canonical with a correctly canonicalized alternate before seeking a separate listing.

Establish the technical floor

Check that Googlebot can access the page, that it receives a successful response and that there is indexable content. Google lists these as minimum technical requirements and explicitly says eligibility does not guarantee indexing. Technical requirements

Inspect the actual public GET response, relevant headers and rendered page. Look for an unintended noindex instruction, a redirect or failure response, a login requirement, an empty main body, or a canonical pointing to another destination. Do this for the exact URL in the report, including its hostname and parameters.

For a JavaScript site, compare the useful material in the response with the material visible after rendering. Google can render JavaScript, so an HTML shell alone does not diagnose a rendering failure. Check the rendered main content and the resources needed to produce it. The HTML-versus-DOM guide and React/Vite release checklist show how to separate those observations. Google’s rendering explanation

One exclusion report can lead to three different repairs

Consider an authored publishing fixture with a storage-cost comparison, a campaign variation of the same comparison and an unfinished version that serves only an application shell. The table describes the publisher’s decisions after inspection. It does not predict the exact label Google will assign.

Decide whether this URL should be a representative

Compare the page with its closest equivalents on your own site. Does it answer a different question or merely change the title, date or a few parameters? Which destination should a reader encounter if Google keeps one version?

If the page is a true duplicate, resolve the URL family rather than trying to make every copy independently indexable. The guides to duplicate without user-selected canonical and an alternate with a proper canonical describe the two relevant selection outcomes.

If the page should stand alone, make that distinction visible in the main content and its internal links. A comparison needs a comparison: named alternatives, explicit assumptions, the difference that changes the decision and enough evidence to inspect the answer. A generic introduction with a new headline may leave the underlying duplication intact.

Improve the answer instead of adding length

Read the page against the task its title promises. Identify the decision the reader should be able to make afterward. Then inspect whether the body supplies the missing facts, working example, original analysis or direct explanation.

For the fixture’s storage-cost comparison, useful additions might be a dated price basis, a stated workload and an explanation of which cost changes the result. Those additions make the page’s purpose more concrete. Repeating definitions or padding the introduction would add words without resolving that purpose.

Check the path into the page too. A maintained guide should link to it where the comparison helps a real question. A sitemap can expose the address, while an ordinary contextual link explains its relationship to the rest of the site. Google’s description of indexing involves understanding and evaluating content after crawling; receipt of a URL is not the endpoint. How Search works

Verify the change you actually made

After the repair, recheck the public response and rendered result. Record the URL, status, main content, canonical and relevant directives beside the date. That creates a concrete expected state for the next indexed observation.

If you use a crawl request after a substantive update, Google says it does not guarantee inclusion, and repeated requests for the same URL do not make crawling faster. Recrawl guidance

Judge the next observation against the intended outcome: the useful representative is indexed, the duplicate remains consolidated, or the unfinished page is no longer promoted. A lower exclusion count is not the whole goal. The goal is for the site’s useful destinations and the evidence Google receives to agree.