Gefunden – zurzeit nicht indexiert: Google crawlt noch nicht

Im Seitenindexierungsbericht der Google Search Console taucht immer wieder derselbe Status auf: „Gefunden – zurzeit nicht indexiert“. Er wirkt beruhigend, weil das Wort „gefunden“ so klingt, als sei die Seite schon auf dem Weg in den Index. Tatsächlich sagt der Status etwas anderes: Google kennt die URL, hat sie aber noch nicht ein einziges Mal abgerufen. Der Crawler war schlicht noch nicht da.

Das unterscheidet diesen Fall von einer Seite, die Google bereits gecrawlt, aber anschließend nicht indexiert hat – dort liegt eine inhaltliche oder technische Entscheidung vor, die nach dem Abruf getroffen wurde. Bei „Gefunden – zurzeit nicht indexiert“ gibt es noch keine Entscheidung, weil es noch keinen Abruf gab. Die Ursache liegt fast immer vor dem Crawling: in der Priorisierung, der Serverkapazität oder der Struktur der Website. Genau dort setzt dieser Beitrag an.

Wie Google überhaupt entscheidet, was gecrawlt wird

Bevor Googlebot eine Seite abruft, durchläuft jede URL eine Reihe interner Schritte: Entdeckung, Warteschlange, Crawling, Rendering und erst danach die Indexierungsentscheidung. „Gefunden – zurzeit nicht indexiert“ bedeutet, dass die URL den ersten Schritt geschafft hat – sie wurde über eine Sitemap, einen internen oder externen Link oder eine Weiterleitung entdeckt – aber in der Warteschlange steckt.

Diese Warteschlange ist keine simple Liste, die von oben nach unten abgearbeitet wird. Google gewichtet jede URL nach einer Einschätzung, wie wichtig ein erneuter oder erster Abruf gerade ist. Neue, unbekannte Domains starten mit wenig Vertrauen und entsprechend wenig zugewiesener Abrufkapazität. Etablierte Websites mit vielen bereits indexierten, gut performenden Seiten bekommen tendenziell mehr Aufmerksamkeit für neue URLs, weil der Crawler aus der Historie lernt, dass sich der Aufwand lohnt.

Für einzelne, kleine Websites ist das selten ein Problem – ein paar neue Artikel werden meist innerhalb von Tagen abgerufen. Bei großen Websites, Marktplätzen, Verzeichnissen oder Seiten mit häufigen Bulk-Imports kann sich die Warteschlange dagegen deutlich stauen, weil viel mehr URLs entdeckt werden, als in der verfügbaren Zeit sinnvoll abgerufen werden können.

Verwechslungsgefahr: drei ähnliche Meldungen

In der Praxis werden mehrere Statusmeldungen des Seitenindexierungsberichts munter miteinander verwechselt, obwohl sie unterschiedliche Ursachen und unterschiedliche Lösungen verlangen.

„Gecrawlt – zurzeit nicht indexiert“ bedeutet, dass Googlebot die Seite bereits abgerufen und häufig auch gerendert hat, sich anschließend aber gegen eine Indexierung entschieden hat. Das ist eine inhaltliche oder strukturelle Bewertung nach dem Abruf – etwa wegen dünnem Inhalt oder naher Duplizierung zu einer anderen Seite. Für diesen Fall bringt mehr interne Verlinkung allein wenig, weil das Problem nicht in der Priorisierung, sondern in der Bewertung des Inhalts liegt.

„Duplikat, vom Nutzer nicht als kanonisch festgelegt“ betrifft ebenfalls bereits gecrawlte Seiten, bei denen Google eine andere URL aus einer Gruppe sehr ähnlicher Seiten als repräsentativ ausgewählt hat. Auch das ist eine Nachabruf-Entscheidung.

„Gefunden – zurzeit nicht indexiert“ steht dagegen zeitlich vor allen diesen Fällen. Es gibt schlicht noch keinen Abruf und damit noch keine der genannten Bewertungen. Wer auf diesen Status mit Maßnahmen reagiert, die für die Nachabruf-Fälle gedacht sind – etwa das Zusammenführen vermeintlicher Duplikate oder das Umschreiben von Inhalten – behandelt ein Symptom, das hier gar nicht vorliegt, und übersieht die eigentliche Ursache: die Warteschlange vor dem Crawling.

Die häufigsten Ursachen im Detail

Vier Faktoren erklären den größten Teil der Fälle. Sie wirken oft gemeinsam, nicht isoliert.

Ein Sonderfall lohnt eine eigene Erwähnung: Die nicht standardisierte robots.txt-Direktive crawl-delay, die einige andere Suchmaschinen respektieren, wird von Googlebot ignoriert. Wer versucht, über diese Direktive die Abrufrate gegenüber Google zu steuern, verändert damit nichts – die tatsächliche Steuerung läuft ausschließlich über die serverseitige Reaktionsfähigkeit und die Grundeinstellungen, die Google selbst beobachtet.

• Crawl-Budget und Serverkapazität: Google passt die Abruffrequenz an die Reaktionsfähigkeit des Servers an. Antwortet der Server unter Last langsam oder mit Fehlern, reduziert Googlebot die Abrufrate automatisch – das betrifft dann auch neue, noch nicht gecrawlte URLs.
• Schwache interne Verlinkung: Seiten, die von keiner oder kaum einer anderen Seite verlinkt werden, senden ein schwaches Prioritätssignal. Der Crawler bewertet eine URL auch danach, aus wie vielen und wie wichtigen Kontexten heraus sie erreichbar ist.
• Zu viele Low-Value-URLs: Facettennavigation, Sortierparameter, Session-IDs oder automatisch generierte Kombinationen erzeugen oft ein Vielfaches der eigentlich relevanten Seitenzahl. Jede dieser URLs konkurriert um dieselbe begrenzte Abrufkapazität wie die Seiten, die wirklich indexiert werden sollen.
• Neue oder wenig etablierte Bereiche: Ein frisch gestarteter Blog, eine neue Subdomain oder ein komplett neu strukturierter Bereich einer bestehenden Website startet crawltechnisch praktisch bei null, unabhängig vom Alter der übrigen Domain.

So liest du das Muster richtig aus der Search Console

Öffne den Seitenindexierungsbericht und filtere auf „Gefunden – zurzeit nicht indexiert“. Der erste Blick gilt dem Verlaufsdiagramm über die letzten Monate, nicht der aktuellen Zahl allein. Eine Zahl ohne Zeitverlauf sagt wenig – ob 40 betroffene URLs ein Problem sind, hängt komplett davon ab, ob diese Zahl seit Wochen sinkt, steigt oder stagniert.

Öffne anschließend einzelne betroffene URLs über die URL-Prüfung. Das Feld „Zuletzt gecrawlt“ bleibt hier leer oder zeigt keinen Wert – das ist der Bestätigungspunkt, dass wirklich noch kein Abruf stattgefunden hat, und nicht bloß eine veraltete Berichtsanzeige. Führst du an derselben Stelle einen Live-Test aus, bekommst du sofort eine aktuelle Momentaufnahme, ob die Seite grundsätzlich abrufbar ist.

Ein zweiter, oft übersehener Bericht ist die Crawling-Statistik unter den Website-Einstellungen. Sie zeigt die Gesamtzahl der Abrufe über die Zeit, aufgeschlüsselt nach Antwortcode und Dateityp. Ein deutlicher Rückgang der Gesamtabrufe im selben Zeitraum, in dem die Zahl der unentdeckten URLs steigt, ist ein starkes Indiz für ein Kapazitäts- oder Prioritätsproblem auf Seiten von Google, nicht für ein einzelnes fehlerhaftes Dokument.

Wer zusätzlich Zugriff auf Server-Logfiles hat, kann die Search-Console-Berichte mit echten Zugriffen von Googlebot abgleichen. Filterst du die Logs nach dem User-Agent von Googlebot, siehst du unmittelbar, welche URLs tatsächlich abgerufen wurden und wie sich die Frequenz über die Zeit verändert – eine Detailebene, die kein Search-Console-Bericht in dieser Genauigkeit liefert, weil dort immer nur Stichproben und aggregierte Trends dargestellt werden.

Ein typisches Muster in der Praxis

Ein wiederkehrendes Muster hilft, die Mechanik greifbar zu machen. Ein Online-Shop mit einem mittelgroßen Produktkatalog führt eine Facettennavigation ein: Filter nach Farbe, Größe, Preisspanne und Verfügbarkeit, jede Kombination mit eigener URL und eigenem Parametersatz. Innerhalb weniger Wochen entdeckt Google über interne Links plötzlich ein Vielfaches der ursprünglichen URL-Zahl – die eigentlichen Produktseiten sind darin nur noch eine kleine Minderheit.

Weil die Gesamtzahl entdeckter URLs so stark steigt, die verfügbare Abrufkapazität für diese Domain aber nicht im gleichen Maß mitwächst, verteilt sich das Crawling über deutlich mehr Adressen. Neue Produktseiten, die eigentlich Priorität verdienen würden, landen im selben großen Topf wie tausende Filterkombinationen ohne eigenständigen Wert – und bleiben entsprechend länger im Status „gefunden, zurzeit nicht indexiert“, einfach weil die Warteschlange vor ihnen so viel länger geworden ist.

Die wirksame Reaktion ist in diesem Muster fast immer dieselbe: Der crawlbare Bereich wird wieder auf die URLs verengt, die tatsächlich eigenständigen Wert bieten, entweder über robots.txt-Regeln für die Parameterkombinationen oder über Canonical-Tags, die die Varianten auf die Hauptproduktseite konsolidieren. Der Effekt zeigt sich nicht sofort, aber die Crawling-Statistik beginnt innerhalb einiger Wochen, wieder mehr Kapazität auf die verbleibenden, relevanten URLs zu konzentrieren.

Ein zweites, ebenso häufiges Muster betrifft Migrationen: Wechselt eine Website die Domain, das Content-Management-System oder die URL-Struktur in einem Schritt, entdeckt Google auf einen Schlag einen großen Teil der Website neu – selbst wenn der Inhalt inhaltlich identisch bleibt. Die neuen URLs gelten technisch als unbekannt, und die Warteschlange füllt sich entsprechend schnell. Hier hilft vor allem Geduld in Kombination mit korrekten 301-Weiterleitungen von den alten auf die neuen Adressen, weil die Weiterleitungen selbst wieder als Entdeckungspfad und als Vertrauenssignal wirken.

Temporärer Rückstand oder strukturelles Problem?

Ein Rückstand ist normal nach einer Migration, einem großen Content-Import oder dem Start eines neuen Seitenbereichs mit vielen URLs auf einmal. In diesem Fall sinkt die betroffene Zahl über die folgenden Wochen von selbst, während die Crawling-Statistik parallel ansteigt – Google arbeitet die Warteschlange sichtbar ab.

Strukturell wird es, wenn dasselbe Muster über Monate bestehen bleibt und auch neu veröffentlichte Inhalte denselben Status erhalten, unabhängig davon, wie lange sie schon online sind. Ein weiteres Warnsignal: Die Crawling-Statistik bleibt flach oder fällt sogar, obwohl ständig neue URLs entstehen. Das bedeutet, dass Google der Website insgesamt keine höhere Abrufkapazität zuweist, egal wie viel neuer Inhalt angeboten wird.

Am eindeutigsten lässt sich das an einer Stichprobe zeigen: Wähle zehn betroffene URLs aus unterschiedlichen Bereichen der Website. Verlinken sie alle nur von einer einzigen, tief verschachtelten Übersichtsseite aus? Das ist ein struktureller Befund, keine Momentaufnahme.

Was du konkret verändern kannst

Reduziere zunächst die Zahl der Low-Value-URLs, die um Abrufkapazität konkurrieren. Facettennavigation, Such-Ergebnisseiten und Parameter-Varianten gehören selten in den crawlbaren Bereich der Website; ein sauberes robots.txt-Regelwerk entlastet die Warteschlange spürbar, weil gesperrte Parameter-URLs gar nicht erst abgerufen werden; konsolidierende Canonical-Tags helfen bei der Bündelung, sparen aber kaum Crawling, weil Google die Seite dafür trotzdem abrufen muss.

Stärke danach die interne Verlinkung zu den Seiten, die wirklich indexiert werden sollen. Eine Verlinkung von einer stark frequentierten, oft gecrawlten Hub-Seite aus wirkt deutlich mehr als ein Eintrag in einer XML-Sitemap allein. Sitemaps sind ein zusätzliches Signal, kein Ersatz für Linkstruktur.

Prüfe außerdem die Serverantwortzeiten unter Last, besonders bei größeren Websites. Wiederholte Zeitüberschreitungen oder 5xx-Antworten während der üblichen Crawling-Zeitfenster führen dazu, dass Google die Abruffrequenz vorsichtshalber selbst reduziert – unabhängig davon, wie wichtig der Inhalt eigentlich ist.

Wenn Zeit und Entwickler-Ressourcen begrenzt sind, lohnt sich eine Reihenfolge: Serverkapazität zuerst, weil eine langsame oder instabile Infrastruktur jede andere Maßnahme entwertet – Google reduziert die Abrufrate serverweit, nicht nur für einzelne URLs. Danach die Reduktion von Low-Value-URLs, weil sie den größten Hebel auf die Größe der Warteschlange hat. Interne Verlinkung kommt an dritter Stelle: Sie verbessert die Priorisierung innerhalb der verbleibenden, bereinigten URL-Menge, wirkt aber wenig, wenn die Warteschlange insgesamt weiterhin von tausenden irrelevanten Adressen verstopft ist.

Nach jeder dieser Änderungen lohnt sich Geduld statt sofortiger Kontrolle: Auswirkungen auf die Warteschlange zeigen sich in der Regel erst nach mehreren Crawling-Zyklen, nicht innerhalb von Stunden oder einzelnen Tagen.

• Lastmod-Angaben in der Sitemap nur setzen, wenn sich der Inhalt tatsächlich geändert hat – ein falsches Datum verliert mit der Zeit an Vertrauenswürdigkeit als Signal.
• Große Bulk-Importe in Wellen veröffentlichen statt an einem Tag, um Warteschlangen-Spitzen zu vermeiden.
• Serverseitiges Rendering oder zumindest schnelles Rendering für wichtige Seiten bevorzugen, damit ein Abruf nicht durch lange Rendering-Zeiten zusätzlich verzögert wird.

Was dabei nicht hilft

Die URL-Prüfung bietet die Möglichkeit, Indexierung für einzelne Adressen zu beantragen. Für ein einzelnes wichtiges Dokument ist das ein sinnvoller Weg, um einen Abruf anzustoßen. Als Lösung für ein strukturelles Problem mit hunderten betroffenen URLs funktioniert es nicht – das Werkzeug ist für Einzelfälle gedacht, nicht für Masseneinsatz, und ein wiederholtes Anfordern ohne inhaltliche oder strukturelle Änderung an der Seite selbst ändert an der zugrunde liegenden Priorisierung nichts.

Ebenso wenig hilft ein wiederholtes erneutes Einreichen der Sitemap. Die Sitemap wurde bereits gelesen, die URLs sind bereits bekannt – genau deshalb tragen sie ja den Status „gefunden“. Das erneute Einreichen ändert nichts an der Warteschlange.

Und schließlich: Versuche, Wichtigkeit künstlich zu erzeugen, etwa über gekaufte oder ausgetauschte Links allein zu dem Zweck, ein Crawling-Signal zu simulieren, adressieren die eigentliche Ursache nicht. Wenn die Serverkapazität begrenzt ist oder die Website Tausende Low-Value-URLs produziert, bleibt das Grundproblem bestehen, unabhängig davon, wie viele zusätzliche Signale von außen hinzukommen.

Ein weiterer verbreiteter Fehler ist, den Status vorschnell als Bewertung der Inhaltsqualität zu lesen und deshalb Inhalte in großem Umfang zu löschen oder umzuschreiben, bevor überhaupt ein Abruf stattgefunden hat. Ohne Abruf gibt es keine inhaltliche Bewertung, gegen die man reagieren könnte – das Problem liegt vor dieser Stufe, nicht in ihr.

Ebenfalls wenig hilfreich ist es, den Server künstlich mit wiederholten manuellen Abrufanfragen oder Drittanbieter-Monitoring-Tools zusätzlich zu belasten, in der Hoffnung, dadurch häufigeres Crawling zu erzwingen. Zusätzliche Last auf einem bereits angespannten Server bewirkt tendenziell das Gegenteil: Googlebot reagiert auf schlechte Antwortzeiten mit einer weiteren Reduktion der Abrufrate, nicht mit mehr Geduld.