„Crawled, currently not indexed“ bedeutet: Googlebot hat die URL gefetcht, aber Google hat sie nicht in den Index aufgenommen. Das ist oft ein Qualitäts-, Duplicate-, Nachfrage- oder Site-Structure-Signal, nicht automatisch ein technischer Fehler. Dieser Guide garantiert keine Indexierung; er hilft zu diagnostizieren, welche autorendefinierte Ursache zur URL passt und was als Nächstes repariert werden sollte.
Was Sie lernen
- Was der Search Console Status bedeutet und wann er wichtig ist.
- Wie crawled-not-indexed URLs von discovered-not-indexed URLs, noindex, canonicalized Pages und Deindexing getrennt werden.
- Wie die 9 autorendefinierten Diagnoseursachen genutzt werden, ohne sie als offizielle Google Liste auszugeben.
- Wie Page Indexing und URL Inspection Evidence ohne erfundene Search Console Daten gelesen werden.
- Wann Request Indexing sinnvoll ist und wann es ablenkt.
Was „Crawled, currently not indexed“ wirklich bedeutet
Der Status bedeutet, dass Google die URL gefetcht hat, sie aber aktuell nicht im Index ist. Er beweist allein keine Penalty, keine Crawl-Budget-Krise und kein kaputtes Plugin. Die praktische Frage ist enger: Sollte diese URL indexiert werden, und welches Signal verhindert, dass sie ein starker Indexkandidat ist?
Zuerst prüfen: Ist dieser Status überhaupt ein Problem?
Es ist ein Problem, wenn die betroffene URL ranken, Nutzern dienen oder einen Business Path unterstützen soll. Es muss kein Problem sein, wenn die URL ein schwaches Tag Archive, eine interne Suchseite, eine Duplicate Parameter URL, eine expired thin Product Page oder eine Seite ist, die in eine stärkere Ressource konsolidiert werden sollte.
Klassifizieren Sie zuerst die URL: keep and improve, merge, noindex, canonicalize, redirect, aus Sitemap entfernen oder mit dokumentiertem Grund lassen.
Crawled not indexed, discovered not indexed und deindexed: der Unterschied
Diese Status brauchen unterschiedliche Antworten. Crawled not indexed heißt, Google hat die Seite erreicht. Discovered not indexed heißt, Google kennt die URL, hat sie aber noch nicht gefetcht. Deindexing heißt, dass eine vorher indexierte Seite später den indexed Status verloren hat.
| Status | Was es bedeutet | Typische Ursache | Erster Check | Wann eskalieren |
|---|---|---|---|---|
| Crawled, currently not indexed | Google hat die URL gefetcht, aber nicht indexiert | Quality, Duplication, weak Signals oder low-value URL | URL Inspection plus Content Review | Wenn wichtige URLs nach Diagnose betroffen bleiben |
| Discovered, currently not indexed | Google kennt die URL, hat sie aber nicht gecrawlt | Priority, Crawl Path oder Site Capacity | Sitemap und Internal Links | Wenn wichtige URLs als Pattern uncrawled bleiben |
| Alternate page with proper canonical | Google sieht andere URL als Preferred Version | Duplicate oder Canonical Consolidation | Selected Canonical | Wenn Selected Canonical falsch ist |
| Excluded by noindex | noindex weist Google an, nicht zu indexieren | Intentional oder accidental noindex | HTML/meta und HTTP Headers | Wenn noindex versehentlich ist |
| Not found / soft 404 | Page fehlt oder wirkt leer trotz Laden | Deleted, expired, empty oder thin Template | Rendered Page und Status Behavior | Wenn wertvolle URLs schwachen Output liefern |
| Indexed, then lost | URL war indexiert und ist es nicht mehr | Deindexing, Canonical Shift, noindex, Quality oder Consolidation | Historischer Status plus aktuelle URL Inspection | Dann den Deindexing Guide nutzen |
Wenn die Seite früher indexiert war und später verschwunden ist, nutzen Sie den Deindexing Diagnostic Flowchart. Wenn WordPress Archive Bloat oder Plugin Output beteiligt ist, ist der WordPress SEO Guide die bessere Ergänzung.
Die 9 autorendefinierten Ursachen nach Diagnosepriorität
Diese 9 Ursachen sind meine Diagnose-Buckets, nicht Googles offizielle Liste und nicht jede mögliche Erklärung. Sie sind in der Reihenfolge sortiert, in der ich sie in einem Indexing Audit meist prüfe, weil sie Content, Duplication, Internal Linking, Canonical Signals und site-wide Patterns schnell trennen.
| Ursache | Symptom in GSC / Site Review | Diagnose | Was fixen | Was danach beobachten |
|---|---|---|---|---|
| Thin oder low-value Content | Die URL wurde gecrawlt, aber die Seite liefert außer Title, kurzem Text oder Boilerplate wenig eigenständigen Wert. | Seite gegen Search Intent prüfen, rendered Content ansehen und klare Aufgabe der Seite bewerten. | Seite verbessern, mit stärkerer Seite mergen oder noindex/retire, wenn keine Suchrolle existiert. | Interne Unterstützung und klarere Page-Indexing-Signale beobachten. |
| Duplicate oder near-duplicate Content | Mehrere URLs bedienen denselben Intent mit ähnlicher Copy, Titles oder Templates. | Title, Einstieg, URL Pattern und Canonical-Hinweise vergleichen. | Duplicates konsolidieren und Preferred URL stärken. | Canonical, Sitemap und Internal Links zur Preferred URL beobachten. |
| Internal Link Starvation / orphan-like URL | Die Seite existiert, bekommt aber kaum relevante interne Links. | Navigation, Hub Pages, Related Posts und Crawl Paths prüfen. | Kontextlinks aus relevanten Hubs und Artikeln ergänzen. | Crawl Discovery und URL Inspection Signale beobachten. |
| Weak Search Intent Match oder unklarer Page Purpose | Die Seite zielt auf eine Query, löst aber das Problem nicht klar. | Title, H1, Intro und Section-Reihenfolge gegen die Nutzerfrage lesen. | Seite auf eine Primary Job fokussieren und irrelevante Teile entfernen. | Content Focus und interne Unterstützung beobachten. |
| Crawl-then-quality-filter Verhalten | Technischer Zugriff wirkt korrekt, aber die URL bleibt nach Crawl ausgeschlossen. | Technische Blocks ausschließen, dann Usefulness und Duplication prüfen. | Nur indexwürdige Seiten verbessern; andere konsolidieren oder noindexen. | Template Patterns statt einzelner URL isoliert beobachten. |
| Canonical oder Duplicate URL Pattern Confusion | Canonical, Sitemap und Internal Links stützen nicht dieselbe Preferred URL. | URL Inspection und rendered HTML für Canonical Signale vergleichen. | Canonical Tags, Internal Links, Sitemaps und Redirects ausrichten. | Beobachten, ob Google weiter eine andere Canonical wählt. |
| Archive, Tag, Parameter oder Faceted URL Bloat | Viele low-value generated URLs erscheinen in Page Indexing Gruppen. | Category, Tag, Search, Parameter und Faceted URLs stichprobenartig prüfen. | Je nach URL-Typ noindex, canonical, consolidate oder Crawl Paths steuern. | Sitemap Cleanliness und Links zu low-value URLs beobachten. |
| Soft 404, Empty Template oder Thin Template Page | URL antwortet normal, wirkt aber leer, abgelaufen, kaputt oder dünn. | Rendered Page, CMS Data, Product/Category State und Template Output prüfen. | Richtigen Status liefern, Content ergänzen, redirecten oder aus Index-Zielen entfernen. | Wiederkehrende Template-Probleme nach CMS-Änderungen beobachten. |
| Site-wide Quality oder Trust Pattern | Viele ähnliche Seiten einer Template-Familie werden gecrawlt, aber nicht indexiert. | Betroffene URLs nach Template, Content Type, Author, Category und Internal-Link Path gruppieren. | Schwache Template-Familie verbessern, low-value Pages prunen und Architektur stärken. | Pattern auf Template-Level beobachten. |
Pages bleiben außerhalb des Index? Buchen Sie einen Technical Audit; ich ordne Ihre URLs einem dieser 9 Diagnose-Buckets zu, mit Evidence aus Ihrem Setup.
Diagnose und Fix pro Ursache
Thin oder low-value Content
Symptom: Die URL lädt, aber der Main Content liefert keinen starken Grund für ein eigenes Index Result. Diagnose: Seite gegen Search Intent und rendered Content prüfen. Fix: Seite zu einer nützlichen eigenständigen Antwort ausbauen, in stärkere Page mergen oder noindexen, wenn keine Suchrolle existiert.
Duplicate oder near-duplicate Content
Symptom: Mehrere URLs sagen fast dasselbe. Diagnose: Titles, Intro, Headings, Body Copy und Template Output vergleichen. Fix: Duplicates konsolidieren, Preferred URL stärken und Internal Links sowie Sitemap Signale auf diese URL ausrichten.
Internal Link Starvation / orphan-like URL
Symptom: Die Seite existiert, bekommt aber wenig sinnvolle Unterstützung aus der Site. Diagnose: Prüfen, ob Nutzer und Crawler über relevante Hubs, Categories, Navigation oder Kontextlinks zur URL gelangen. Fix: Internal Links aus topical relevanten Seiten ergänzen, nicht zufällige Footer Links.
Weak Search Intent Match oder unklarer Page Purpose
Symptom: Die Seite zielt auf eine Query, beantwortet sie aber nicht klar. Diagnose: Title, H1, Intro und Section Order gegen das Suchproblem lesen. Fix: Page auf eine primäre Aufgabe fokussieren, irrelevante Sektionen verschieben und die Antwort früh sichtbar machen.
Crawl-then-quality-filter Verhalten
Symptom: Technischer Zugriff sieht sauber aus, die URL bleibt aber nach Crawl außerhalb des Index. Diagnose: Erst noindex, robots.txt, canonical und Template Issues ausschließen; danach Usefulness und Duplication prüfen. Fix: Nur indexwürdige Pages verbessern; andere konsolidieren oder noindexen.
Canonical oder Duplicate URL Pattern Confusion
Symptom: Inspected URL und Googles Preferred URL zeigen nicht in dieselbe Richtung. Diagnose: Declared Canonical, selected Canonical Hinweise, Sitemap URL, Internal Links und Redirects vergleichen. Fix: Alle Signale um die intended URL ausrichten.
Archive, Tag, Parameter oder Faceted URL Bloat
Symptom: Viele low-value generated URLs erscheinen in Page Indexing Gruppen. Diagnose: Tag, Archive, Parameter und Faceted URLs auf Unique Value prüfen. Fix: Je nach URL Type noindex, canonicalize, consolidate oder Crawl Paths steuern.
Soft 404, Empty Template oder Thin Template Page
Symptom: URL liefert eine normale Response, wirkt aber leer, expired, broken oder thin. Diagnose: Rendered Page, CMS Data, Product/Category State und Template Output prüfen. Fix: Richtigen Status ausgeben, nützlichen Content ergänzen, redirecten oder aus Index Targets entfernen.
Site-wide Quality oder Trust Pattern
Symptom: Viele ähnliche Pages einer Template Family werden gecrawlt, aber nicht indexiert. Diagnose: Betroffene URLs nach Content Type, Author, Category, Template und Internal-Link Path gruppieren. Fix: Schwache Template Family verbessern, low-value Pages prunen und Internal Architecture stärken.
Prüfung in Google Search Console
Nutzen Sie Search Console als Evidence, nicht als Magic Fix Button. Der Page Indexing Report hilft bei Patterns. URL Inspection vertieft eine einzelne URL. Beides ersetzt nicht die Prüfung von Page, Template, Internal Links und Canonical Signals.
| Schritt | Wo prüfen | Worauf achten | Was es meist bedeutet | Nächste Aktion |
|---|---|---|---|---|
| Page Indexing Report | Search Console > Indexing > Pages | Excluded URLs nach Status | Ein Pattern über Templates oder URL Types kann bestehen | URLs samplen und nach Template gruppieren |
| URL Inspection | Exakte URL inspecten | Crawl, Indexability, Canonical und Sitemap Hinweise | Einzelne URL kann vom Gruppenpattern abweichen | Evidence vor Änderungen sichern |
| Canonical Status | URL Inspection und Page Source | Declared Canonical vs Google-selected Canonical Hinweise | Google bevorzugt eventuell andere URL | Canonical, Internal Links und Sitemap Signale ausrichten |
| Sitemap und Internal Links | Sitemap, Navigation, Hub Pages | Preferred URL enthalten und verlinkt? | Weak Discovery kann niedrige Priorität verstärken | Relevante Links ergänzen oder URL aus Sitemap entfernen |
| Content Duplication Check | Site Search, Crawl Export oder manueller Vergleich | Near-duplicate Copy, Title oder Template Intent | Google hat eventuell genug ähnliche Seiten | Merge, Rewrite oder Consolidation |
| Internal Link Review | Relevante Hubs, Categories, Related Articles | Bekommt die Page sinnvolle Links? | Page kann orphan-like sein | Kontextlinks aus topical relevanten Seiten ergänzen |
| Request Indexing Decision | URL Inspection nach Fix | Ist die Page wirklich verbessert? | Request Indexing ist keine Garantie | Nach substantiellen Änderungen nutzen |
| Escalation to Audit | Gruppierte GSC und Site Evidence | Wiederholte Patterns über viele URLs | Problem kann structural oder template-level sein | Technical/Indexing Audit mit Evidence starten |
Wann Request Indexing hilft und wann nicht
Request Indexing kann nach einem sinnvollen Fix helfen: noindex war versehentlich gesetzt, Canonical wurde korrigiert, Content wurde deutlich verbessert oder Internal Links wurden ergänzt. Als alleinige Taktik ist es schwach. Wenn die Page weiter thin, duplicate, unsupported oder confusing ist, macht Request Indexing sie nicht zu einem besseren Indexkandidaten.
Wann Warten sinnvoll ist
Warten kann sinnvoll sein, wenn die URL neu, technisch erreichbar, intern verlinkt, passend in der Sitemap und klar nützlich ist. Warten ist keine Strategie, wenn dasselbe Template, derselbe Archive Type oder dasselbe Duplicate Pattern viele URLs betrifft. Dokumentieren Sie das Pattern und beheben Sie die Ursache.
Unterschied zu Deindexing
Crawled, currently not indexed betrifft eine URL, die Google gefetcht, aber nicht indexiert hat. Deindexing betrifft eine URL, die indexiert war und diesen Status später verloren hat. Die Evidence ist anders: Für Deindexing brauchen Sie historischen indexed Status und aktuellen Verlust; für crawled-not-indexed müssen Sie zeigen, warum die URL nach Crawl indexwürdig ist.
Falscher Artikel: Deindexing oder never indexed?
Wenn die Page früher indexed Impressions hatte oder klar indexiert war, nutzen Sie einen Deindexing Workflow. Wenn die Page gecrawlt, aber nie für den Index ausgewählt wurde, bleiben Sie bei dieser Diagnose.
Häufige Fehler vermeiden
- Den Status ohne Evidence als Penalty behandeln.
- Request Indexing drücken, bevor die Page repariert wurde.
- Jede unindexed URL löschen, ohne ihre Rolle zu prüfen.
- Crawl Budget beschuldigen, bevor Content, Duplication und Internal Links geprüft wurden.
- Annehmen, Schema oder Core Web Vitals lösen Indexation allein.
- Canonical und Duplicate URL Patterns ignorieren.
- Eine einzelne URL prüfen, obwohl das echte Problem eine Template Family ist.
Abschließende Empfehlung
Beginnen Sie mit Intent und Usefulness, dann Duplication, Internal Links, Canonical Signals und Generated URL Bloat. Wenn nur eine low-value Page betroffen ist, kann der Fix einfach sein. Wenn viele wichtige URLs betroffen sind, behandeln Sie es als Indexing Audit: URLs gruppieren, GSC Evidence sammeln und das Pattern reparieren.
Pages bleiben außerhalb des Index? Buchen Sie einen Technical Audit; ich ordne Ihre URLs einem dieser 9 Diagnose-Buckets zu, mit Evidence aus Ihrem Setup.
FAQ
Was bedeutet „Crawled, currently not indexed“?
Googlebot hat die URL gefetcht, aber Google hat sie zu diesem Zeitpunkt nicht indexiert. Der nächste Schritt ist Diagnose, nicht Penalty-Vermutung oder wiederholtes Request Indexing.
Ist „Crawled, currently not indexed“ eine Penalty?
Nicht automatisch. Der Status kann durch Quality, Duplication, Canonical, Internal Linking, Generated URLs oder Site Structure entstehen. Penalty-Sprache braucht Evidence.
Wie lange dauert es, bis Google eine reparierte Page indexiert?
Es gibt keine sichere universelle Timeline. Nach einem sinnvollen Fix sollten URL Inspection, Page Indexing Patterns, Sitemap Inclusion und Internal Links beobachtet werden.
Löst Request Indexing diesen Status?
Request Indexing kann Google helfen, eine reparierte URL erneut zu prüfen, garantiert aber keine Indexierung. Es sollte nach echten Verbesserungen genutzt werden.
Sollte ich Pages löschen, die crawled but not indexed sind?
Nicht automatisch. Manche Pages sollten verbessert, manche gemerged, manche noindexed, manche redirected und manche belassen werden. Die Rolle der Page und Evidence entscheiden.
Was ist der Unterschied zwischen crawled not indexed und discovered not indexed?
Crawled not indexed bedeutet, Google hat die URL gefetcht. Discovered not indexed bedeutet, Google kennt die URL, hat sie aber noch nicht gecrawlt.
Wie unterscheidet sich das von Deindexing?
Deindexing bedeutet, eine Page war früher indexiert und hat diesen Status später verloren. Crawled currently not indexed bedeutet, Google hat die Page gefetcht, aber nicht in den Index aufgenommen.
Quellenhinweise
Dieser Guide basiert auf Google Search Central und Search Console Dokumentation zu Crawling and Indexing, Search Essentials, Sitemaps, robots.txt, URL Inspection, Page Indexing Concepts und Structured Data Limits. Das 9-Ursachen-Framework ist eine autorendefinierte Diagnostic Taxonomy, keine offizielle Google Liste.