Crawled – Currently Not Indexed: How to Diagnose It

“Crawled – currently not indexed” means Google fetched a URL but did not include it in the index at the report's recorded point. Google says the page may or may not be indexed later and that you do not need to resubmit it for crawling.

The label is an outcome, not a root cause. It does not say “content too short,” “low authority” or “penalty.” You need to find out what Google received, whether the live page has changed, which other pages compete with it and whether this URL owns a useful task.

This guide handles that post-crawl diagnosis. For the complete discovery-to-indexing workflow, use the indexing diagnosis. If Search Console says Google has not crawled the URL, start instead with the Discovered status.

The status confirms a crawl, not the reason for exclusion

Google's current Page Indexing guide gives a deliberately narrow definition: Google crawled the page but did not index it. The page may enter the index later without another submission.

That gives you a fixed starting point:

• Google knew the URL.

• Google requested it.

• The indexing pipeline did not retain it as an indexed result at that recorded point.

Search Console does not expose a private score or single rejection reason behind this label. Avoid turning a broad outcome into a confident diagnosis.

The page could have returned incomplete content during the crawl. JavaScript might have failed. The page may substantially overlap another URL. A template may produce many low-distinction pages. The URL may serve no separate user task. Or Google may process and index it later without a change.

Your job is to narrow those possibilities with observable evidence.

1) Build a crawl-state packet before editing

Inspect the exact URL in Search Console before editing it. Keep the following evidence together as one crawl-state packet:

• the full inspected URL;

• the exact Page Indexing reason;

• last crawl date and time;

• crawler type;

• whether crawling and indexing were allowed;

• referring page and sitemap, when shown;

• user-declared canonical;

• Google-selected canonical, when available; and

• the date of the latest page or template deployment.

The crawl date anchors the investigation. If a developer repaired the page after that date, the recorded result may describe the old version. If the status appeared after a template release, the release becomes a useful comparison point.

Export examples from the Page Indexing group and keep a representative sample. Search Console's example lists are not a complete inventory, but they can reveal page-type patterns.

Add the tested HTML, screenshot, HTTP response and deployment note to the same packet. This prevents the team from comparing a historical Search Console status with today's page and treating the mismatch as a diagnosis.

Do not request indexing yet. Google explicitly says there is no need to resubmit an unchanged URL in this state. Preserve the evidence first, then determine whether there is something meaningful to fix.

2) Compare the recorded state with the live page

Run Test Live URL and note the test time. The live test asks whether Google can access and render the page now. It does not recreate the historical crawl and does not test every duplicate or canonical condition.

Compare these two states:

A clean live test can mean the earlier problem has already been fixed. It does not prove that the recorded crawl received the same response.

If the page changed after the crawl, document exactly what changed: server rendering, API reliability, copy, canonical markup, redirect behavior, status code or template. Vague notes such as “improved SEO” make later monitoring difficult.

3) Reconstruct what Google received

Start with the response body, not its status alone. Google's HTTP status guide says a successful 2xx response passes received content into processing; it does not guarantee indexing.

Check whether the crawled or tested page contained:

• the intended H1 and primary content;

• useful product, service, category or article information;

• crawlable internal links;

• a self-referencing or otherwise intentional canonical;

• the expected meta robots directive;

• structured data that matches visible content; and

• no error, empty state, login request or loading shell in place of the page.

Where URL Inspection allows it, open View tested page and inspect the HTML, screenshot and resources. Compare that output with an anonymous browser session and the server-rendered source.

Check JavaScript and API dependencies

A browser may display the full page after scripts run while Google receives an empty app shell or a failed data state. Google's JavaScript troubleshooting recommends examining rendered HTML, loaded resources and JavaScript errors.

Look for:

• an API call that fails without a logged-in session;

• content that depends on local storage or a cookie choice;

• blocked scripts or API routes;

• hydration errors;

• an indefinite loading state;

• content available only after interaction;

• route data keyed to a URL fragment; and

• client-side not-found pages that still return 200.

Repair the shared rendering or data path, then retest representative URLs. Do not rewrite the visible copy when the indexing system received no usable copy at all.

Check soft-404-like output

A URL can return 200 while displaying an empty listing, missing-item message or broken template. Google may classify clear cases as Soft 404, but a crawl can also capture incomplete output before the report settles into a more specific reason.

If the item no longer exists and has no replacement, return a genuine 404 or 410. If the page should remain, restore its primary content and purpose. Do not turn a missing page into a generic homepage redirect.

4) Compare the page with its closest competitors

Once the rendered page is intact, ask what other URL answers the same task.

Search within the site by title, primary phrase, product identifier, location and opening sentences. Compare:

• canonical and parameter variants;

• category and tag archives;

• location pages;

• product or service variants;

• print and mobile routes;

• updated and legacy articles;

• staging or alternate-host copies; and

• pages created from the same template.

Google's canonicalisation guide explains that Google clusters pages with the same or very similar primary content and chooses a representative URL. Redirects, sitemap inclusion and rel="canonical" contribute signals, but Google may choose a different representative.

Search Console often reports more explicit canonical reasons, such as Duplicate, Google chose different canonical than user. If you see one of those labels, follow that diagnosis instead of forcing the URL into a generic content-improvement exercise.

For URLs still grouped as Crawled – currently not indexed, build a comparison table:

This comparison changes “make it better” into a concrete ownership decision.

5) Decide whether the URL deserves a separate page

An index is not a database backup. A public URL can work for users without needing its own search result.

Define the page's job in one sentence:

This page helps specific reader complete specific task using information or utility not owned elsewhere.

If you cannot distinguish that job from another page, separate indexation may not be the right goal.

Review the page against evidence-led questions from Google's people-first guidance:

• Does it provide original information, reporting, research or analysis?

• Does it give a substantial and complete answer for its intended scope?

• Does it add value beyond rewriting another source?

• Would the intended audience find it useful if they reached it directly?

• Does it leave the reader able to complete the task?

• Is the author, method or source clear where readers need that context?

These questions are not a scoring formula, and they do not prove why Google omitted one URL. Use them to decide whether the page has a defensible job.

Google explicitly says it has no preferred word count. Adding 500 generic words does not create distinct value. Useful improvement may instead require a calculation, original comparison, current specification, decision rule, local process, verified example or clearer ownership.

6) Diagnose the pattern, not only one URL

Group affected URLs by:

• template;

• directory;

• content type;

• publication period;

• author or workflow;

• data source;

• canonical component;

• word-for-word overlap;

• rendered state; and

• internal-link source.

Glarify can help group connected Search Console page and query data so you can compare affected URLs with healthier siblings. Treat that grouping as a prioritisation aid, then verify the indexing reason, rendered response and crawl evidence in Search Console and your own logs. No third-party dashboard can reveal a guaranteed indexing cause or outcome.

Use a sample large enough to include different outcomes from the same template:

• affected URLs;

• indexed siblings;

• recently improved examples; and

• intentional duplicates or retired pages.

Comparing indexed and non-indexed siblings helps isolate what differs. If both use the same renderer and metadata, the shared technology may not explain the split. If every affected URL comes from one failed API-backed template, a shared technical cause becomes more plausible.

Do not mass-delete pages because one report count looks large. First determine which pages serve real tasks, which overlap and which are broken outputs.

7) Choose retain, repair, merge or retire

Match the action to the evidence.

Amplify's content-audit workflow provides the broader keep, improve, merge, redirect and retire process. Apply it after technical checks show that Google received the intended page.

If you make a substantial repair, a recrawl request for an important representative URL can help Google notice it. Do not submit every unchanged URL or treat the request as an override.

8) Work through a hypothetical Kenyan listing-site case

Consider a hypothetical Kenyan commercial-property website with individual office listings for Nairobi.

Search Console groups several listing URLs under Crawled – currently not indexed. The URLs return 200 in a browser. The team initially proposes adding longer neighbourhood descriptions to every page.

Reconstruct the crawl

The recorded crawl dates coincide with a deployment that changed listing data to a client-side API. In the live test, most listings render, but expired records display a loading skeleton followed by “property unavailable.” The raw HTML contains only the shell. Some API requests fail for anonymous sessions.

Compare the page set

The export shows three distinct groups:

1. Active listings with unique rent, floor area, amenities and contact details.

2. Multiple tracking and print variants of the active listings.

3. Expired listings with no replacement information and an error-like 200 response.

This is not one “quality” problem.

Apply separate decisions

• The developer makes essential active-listing content available reliably in the rendered response and fixes anonymous API access.

• Tracking and print variants consolidate to clean canonical listing URLs; internal links and the sitemap use the same clean forms.

• Expired listings with no relevant replacement return a genuine 404 or 410. Listings with a clear successor may redirect to that specific replacement.

• The editor improves active pages only where users lack decision-critical information. The team does not manufacture generic neighbourhood paragraphs for every listing.

The team validates representative URLs from all three groups and records the deployment date. It does not promise when Google will recrawl or index the active listings.

If the repaired URLs later receive a specific canonical or soft-404 label, the team follows that new evidence rather than continuing to diagnose the old status.

9) Monitor status changes without treating every move as failure

Create a compact change log:

Possible transitions mean different things:

• Indexed: Google selected the page for the index; ranking remains a separate question.

• Duplicate/canonical reason: Google grouped the page with another representative; verify whether that choice matches your intent.

• Soft 404: Google interpreted the response as missing or error-like; correct the page or status.

• Still Crawled – currently not indexed: Recheck whether Google crawled after the change and whether the URL truly owns a distinct task.

Do not reset the diagnosis every morning. Compare the latest Google crawl date with the deployment date and monitor representative groups.

The defensible workflow is: preserve the crawl record, reconstruct the received page, compare competing URLs, decide the page's job, repair the shared cause and then monitor. That gives your team a reasoned action even when Google does not disclose a single page-level explanation.

If you need a broader site baseline, use Amplify's SEO scorecard. When the affected set spans many templates, rendered applications, migrations or conflicting URL systems, move to an SEO audit and bring the Search Console export, representative inspections, release timeline and server evidence.