Neu: IndexNow-Push + Alerts bei Indexverlust — die Abdeckung, die zählt

Crawled — currently not indexed: what it means and what actually fixes it

Dieser Beitrag ist derzeit nur auf Englisch verfügbar.

The indexsubmit team
06.10.2026

"Crawled — currently not indexed" is the most common verdict in Search Console's Page Indexing report, and the least explained. Google crawled the URL, parsed it, and chose not to put it in the index. That is a quality decision, not an error — which is exactly why it is so frustrating: there is nothing to fix in the obvious sense.

What Google is actually saying

The verdict means the crawl budget was spent and the page lost the quality race. Google evaluates pages against everything else it could crawl with the same resources. "Currently" is doing a lot of work in that sentence: the decision is revisited on later crawls, which is why pages drift in and out.

The useful mental model: for any given crawl, Google asks three questions.

  1. Is this page worth fetching at all (priority)?
  2. Once fetched, is it worth indexing (quality)?
  3. Is it worth serving for queries (value)?

"Crawled — currently not indexed" fails at step 2 or 3, not step 1.

The five causes that matter

In practice, almost every case falls into one of five buckets. They need different fixes, so telling them apart is the whole job.

1. Thin or duplicated value. The page repeats what other pages — yours or someone else's — already say, with nothing added. Tag archives, paginated stacks, and boilerplate-driven product variants live here.

2. Orphan-ish internal linking. The page is reachable, but barely: three clicks from the homepage and zero contextual links. Google treats crawl signals as a proxy for importance.

3. Content sits behind a render or interaction step. The primary content only appears after JavaScript does something a crawler does not replicate — pagination clicks, filters, scroll-driven loads.

4. The site publishes more than Google wants to index. This is the unpopular one. If you emit thousands of low-value URLs, Google quietly lowers its trust in the whole class of URLs, and good pages get caught in that.

5. It is a timing problem. New pages often sit here for days before being indexed. The verdict is correct today and wrong next week.

Telling them apart

The buckets look identical in Search Console — the report aggregates, it does not diagnose. What separates them is history per URL:

  • A page that has been "crawled, not indexed" for months with stable content is bucket 1, 2, or 4. Check whether any internal page links to it contextually, and whether the content adds anything its siblings do not.
  • A page that flips between indexed and not indexed across crawls is usually bucket 5 — sometimes 3, if rendering is flaky.
  • A whole section with this verdict (all blog tags, all filtered categories) is bucket 4. The pattern across URLs matters more than any single URL.

This is why we built indexsubmit's coverage history the way we did: the URL Inspection API gives you a snapshot, but the diagnosis lives in the time series. When a URL's verdict, its neighbors' verdicts, and the site's 30-day trend are visible in one place, the bucket usually announces itself.

What actually fixes it

Ordered by effort-to-result ratio:

  1. Consolidate. Merge thin pages into the strongest sibling and redirect. This fixes bucket 1 and shrinks bucket 4 simultaneously.
  2. Link internally, contextually. Two or three links from real pages beat a sitemap entry every time.
  3. Server-render the primary content. If the page's point needs a click to appear, emit it in HTML.
  4. Cut emissions. Noindex or remove URL classes you do not actually want indexed. Trust is a budget; stop spending it on pages you do not care about.
  5. For genuinely new pages: wait, then push. Get the page into the index queue with IndexNow, then watch its verdict over the next days instead of re-submitting manually.

How to watch it

Search Console's Page Indexing report updates slowly and only aggregates. To work a list instead of a chart, you want the per-URL verdict plus a recorded history: when it was first seen, when the verdict changed, what the trend was around the change.

That is exactly what indexsubmit tracks — every monitored URL gets its verdict recorded daily, transitions are logged, and a whole site degrading shows up as a scored trend rather than a surprise. If you are staring at a few hundred "crawled, currently not indexed" URLs right now, connect your property and sort the section by state — the pattern across URLs is the diagnosis.