Crawled but Not Indexed: What the Status Really Means

Crawled - currently not indexed means the crawler requested your URL, got the page back without incident, and then a separate selection step declined to store it. Search Console's own help text for the status says the page may or may not be indexed in the future, and that there is no need to resubmit the URL for crawling.

Read that second half again. The documentation is telling you the resubmit button is not the fix, which is the exact thing almost everyone reaches for first.

Getting a page into search results takes four steps, and they fail in different ways.

Everything technical is already proven by the time you see this status. The URL resolves, robots.txt allows it, there is no noindex, the server returned content. Your problem sits one step further down, and it is a judgment about value rather than a fault in delivery. If you're not sure the earlier steps are solid across your site, what technical SEO covers walks the full pipeline.

The Page indexing report (older guides call it Index Coverage) lists every reason a URL is missing under one heading. That layout puts a considered selection decision in the same visual bucket as a 500 error and a broken redirect. They are not the same kind of thing, and treating them the same is where the wasted weeks come from.

Three of those rows are directives you set on purpose. Two are genuine faults. Crawled - currently not indexed is the only one that is purely an opinion about your page, which is why no amount of technical work clears it and why the technical audits people run in response come back clean.

Directive-caused statuses have a different repair path entirely. If your missing pages sit under Blocked by robots.txt or Excluded by 'noindex' tag instead, start with robots.txt vs noindex.

These two statuses sit next to each other in the report, they read almost identically, and nearly every guide gives them the same advice. Their causes barely overlap.

Search Console describes the discovered case as a crawl the engine rescheduled, typically because fetching it then was expected to overload the site. That is a capacity decision made before anyone read your writing. The crawled case is the opposite: the content was received and assessed.

One shared cause is worth naming, because it is the most common real fix for both. Sites that publish large numbers of near-identical URLs (filtered listings, tag archives, paginated combinations, thin location variants) push both counts up at once. In the discovered case they exhaust the crawl schedule. In the crawled case they compete with each other.

The framing that makes this tractable: indexing is not a pass or fail test the page takes alone. It is a comparison against what is already stored, including your own other pages. The question is not "is this page good", it's "what does this page add that something already indexed does not".

The orphan case deserves more attention than it gets. A sitemap tells an engine a URL exists. Internal links tell it the URL matters to you, and how it relates to everything else. A page that appears in your sitemap and nowhere else in your navigation is making a weak argument for itself, and it is the cheapest thing on the list to fix.

The last row is real and gets overused as an excuse. New pages do sit in this status and then get indexed later without anyone touching them. That is genuinely common. It stops being the explanation once the page has been crawled several times over a couple of months and still isn't in.

Here is the part almost nothing written about this status says out loud.

The verdict describes the page as it was on the last crawl date, not as it is today. The status is a stored decision with a timestamp. Read it without checking that timestamp and you can spend a month convinced your rewrite failed, when the engine has not seen the rewrite.

That last-crawl gap also explains the effect people misread as "requesting indexing worked". Request indexing, the page gets fetched sooner, and the status updates to reflect a page you had already improved. The request changed the timing of the recheck. It didn't change the opinion. On an unchanged page, the same request returns the same verdict.

Every figure below is an illustrative example, not SparkCliks data.

Say https://www.sparkcliks.com/blog/example-post/ has been live for ten weeks with no impressions.

1. Confirm the status and get the date. Paste the full URL into the search bar at the top of Search Console. The result reads URL is not on Google. Open the Page indexing panel and read two fields: the status line, and Last crawl. Example: status Crawled - currently not indexed, last crawl 4 August 2026.

2. Compare that date against your own edit history. If you rewrote the page on 20 August and the last crawl is 4 August, stop diagnosing. The verdict is older than the version you care about.

3. Check whether it ever ranked. Go to Performance, then Search results. Set the date range to Last 16 months, which is the full retention window. Add a filter: Page, URLs containing, and paste the path. Zero impressions across 16 months means it never made it in. Impressions that stop on a specific date mean it was indexed and then dropped, which is a different problem (see the next section).

4. Find its competition, starting with your own site. Take the page's target phrase, go back to Performance, filter Query by that phrase, then switch to the Pages tab. If another of your URLs already picks up impressions for it, the new page is competing with a page you already own. That is a consolidation decision, not a content quality problem.

5. Test the live page, not the stored one. In URL Inspection, click Test live URL, then View tested page, then the HTML tab. Copy a distinctive seven or eight word sentence from the middle of your body copy and search for it in that HTML. Missing means the crawler never received your main content, and you have found a technical cause hiding inside a status everyone treats as a quality issue.

6. Size the problem before acting on one page. Open Indexing, then Pages, and click the Crawled - currently not indexed row. Export the example URLs. Search Console shows a sample capped at 1,000 URLs per reason, so on a large site treat this as a sample rather than the full list. Example: 38 URLs, 31 of them under /blog/tag/. That distribution answers the question faster than reading any single page.

Steps 1 through 5 take about ten minutes per URL. Step 6 usually makes steps 1 through 5 unnecessary for most of the set, which is why it is worth doing first on any site with more than a handful of affected pages.

Search Console gives these two situations the identical status label, and they call for opposite responses. The Performance report separates them in about a minute.

The drop case carries information the never-indexed case does not: the page cleared the bar at some point, so the bar is reachable. Line the last-impression date up against your publishing log. Pages that fall out shortly after you launch a similar page are being deduplicated against it, and the fix is to merge them rather than to strengthen both.

The highest-value analysis here is not about any individual URL. Export the affected list and group it by path prefix.

That last row is the one to take seriously. A count that climbs every week while your indexed count stays flat is telling you something specific about your publishing operation, and no page-level edit answers it. The response is fewer, more distinct pages, which is unwelcome advice and usually the correct one.

A page whose main content is injected by JavaScript can be fetched perfectly and still arrive nearly empty. The response code is 200, the fetch is successful, and the stored version is your header, navigation and footer wrapped around nothing. That produces exactly this status, and it will not show up in any crawl or response code audit.

Step 5 of the worked example is the whole test, and running it beats reading your framework's documentation. The Screenshot tab next to HTML confirms it visually: a bare layout with no article body is the same finding in picture form.

If your phrase is present, rendering is fine and the cause is elsewhere on the list. If it's missing, you have a delivery problem wearing a selection problem's label, and it almost always hits the entire template at once. Check whether every affected URL shares one layout before assuming it is only this page.

Run this in order. It is deliberately front-loaded with the least popular option.

1. Decide whether the page should exist. If it duplicates something you already publish, merge it and redirect. Removing pages is a legitimate outcome here, and on sites with hundreds of affected URLs it is usually the main one.
2. Answer the marginal contribution question in one sentence. What does this page give a reader that the closest already-indexed page, yours or anyone's, does not? If you can't finish the sentence, no rewrite will fix it. That is the actual bar, and it is higher than "well written".
3. Add something that cannot be found elsewhere. Your own measured results, a worked example with real numbers, a narrower scope, a comparison nobody has published. Length is not the variable people think it is.
4. Link to it from indexed pages that already get traffic. Contextual links from within body copy, not just a sitemap entry and a footer link.
5. Fix rendering if step 5 of the worked example failed. Server-render or pre-render the main content.
6. Fix the template, not the page, if the export clustered under one path.
7. Request indexing once, after the change is live. Once. It schedules a recheck of the new version. It does not argue your case.

Then leave it alone and check the last crawl date in three or four weeks. The one thing that guarantees a wasted month is changing something small and re-requesting indexing every few days, because you'll keep collecting fresh verdicts on a page that hasn't meaningfully changed.

That last row matters here because SparkCliks sells click and traffic services, so we should be direct about where they do not apply.

A page that is not indexed has no listing in the results. No listing means no impressions, no click-through rate to improve, and nothing for a searcher to click. Sending visits directly to the URL does not create an index entry, because indexing is decided from the crawl, not from your visitor log. Whatever you believe about engagement signals, and the evidence there is genuinely contested (we go through it in what search engines say about click data), the argument cannot even begin on a page that has no result to click. SparkCliks' own FAQ puts the general version plainly: there are no guarantees in SEO unless you happen to own the search engine.

Indexing comes first. Click work like SERP Clicks applies to pages that already rank and are already collecting impressions you can see in the Performance report. If the Performance report has no row for the URL, that is the work you have, and it is a content and site architecture problem.