Wenn eine Seite aus Googles Index verschwindet, ist das nicht automatisch eine Penalty. Es ist auch nicht automatisch der Beweis für ein bestätigtes, plattformweites Ereignis. Die sichere Reihenfolge lautet: Verlust in der Search Console bestätigen, technische Ursachen isolieren, Canonical- und Overlap-Signale prüfen und dann entscheiden, ob die URL gefixt, zusammengeführt, per noindex ausgeschlossen, stillgelegt oder einfach in Ruhe gelassen werden sollte.

Was Sie in diesem Beitrag lernen

  • Wie Sie bestätigen, dass eine URL wirklich aus Googles Index verschwunden ist.
  • Wie Sie Indexierungsverluste von normalen Rankingverlusten trennen.
  • Welche technischen Prüfungen vor jedem Löschen oder Umschreiben passieren sollten.
  • Wie Sie zwischen fix, merge, noindex, retire oder belassen entscheiden.

Was „deindexed“ bedeutet – und was nicht

Wenn eine URL früher indexiert war und jetzt nicht mehr im Google-Index auftaucht, ist das ein Indexierungsdiagnose-Problem. Das bedeutet nicht automatisch Manual Action, sitewide Penalty oder ein bestätigtes Google-weites Ereignis.

Es bedeutet auch nicht automatisch, dass die Seite gelöscht werden sollte. Manche URLs sind technisch blockiert, manche werden auf stärkere Canonicals zusammengezogen, manche sind schwach oder überlappen, und manche sind es schlicht nicht wert, zurück in den Index gedrückt zu werden.

Den Verlust zuerst in der Search Console bestätigen

Bevor Sie Templates ändern, Seiten löschen oder massenhaft request indexing auslösen, sollte Search Console der erste Prüfpunkt sein.

Page indexing report

Prüfen Sie, ob die URL in einen Zustand wie `Crawled – currently not indexed`, `Discovered – currently not indexed`, `Excluded by noindex`, `Blocked by robots.txt`, `Duplicate` oder `Soft 404` gewechselt ist.

URL Inspection

Nutzen Sie URL Inspection für genau die betroffene URL. Prüfen Sie, ob Google sie crawlen kann, ob Google ein anderes Canonical auswählt und ob die geprüfte URL wirklich indexierbar ist.

Indexierungsverluste von Rankingverlusten trennen

Rankingverlust und Indexierungsverlust sind nicht dasselbe.

  • Wenn die URL noch indexiert ist, aber Sichtbarkeit verloren hat, ist das nicht das Hauptproblem dieses Flowcharts.
  • Wenn die URL nicht mehr indexiert ist, müssen Sie diagnostizieren, warum sie aus dem Index gefallen ist oder nicht gehalten wurde.

Diese Trennung ist wichtig, weil Fixes für deindexierte URLs nicht dieselben sind wie Fixes für weiterhin indexierte Seiten mit schlechterem Ranking.

Der Diagnose-Flowchart

Gehen Sie den Ablauf in dieser Reihenfolge durch. Ziel ist nicht, eine einzige Ursache zu raten. Ziel ist, die greifbarsten Erklärungen zuerst zu bestätigen oder auszuschließen.

Flowchart-Schritt Frage Wenn ja Wenn nein
Start War die URL früher indexiert und fehlt jetzt? Zur Search-Console-Bestätigung gehen Zuerst als Nicht-Indexierungs- oder Nie-Indexiert-Fall behandeln
Bestätigung Zeigt Search Console die URL als fehlend oder ausgeschlossen? In die Diagnosezweige gehen Prüfen, ob es in Wahrheit ein Rankingverlust ist
Zweig 1 Gibt es Manual Action, Security Issue oder ein Policy-Problem? Das zuerst lösen Weiter
Zweig 2 Wird die URL durch noindex, robots.txt, Redirect, Canonical oder Soft 404 gebremst? Technisches Problem zuerst beheben Weiter
Zweig 3 Wählt Google ein anderes Canonical oder sieht die Seite als Duplicate oder Overlap? Rolle der Seite klären oder konsolidieren Weiter
Zweig 4 Ist die Seite schwach, thin, veraltet oder zu ähnlich? Je nach Wert verbessern, zusammenführen oder stilllegen Weiter
Zweig 5 Sind Crawl-Pfade, Sitemap-Signale oder Internal Links schwach? Discovery- und Support-Signale verbessern Entscheiden, ob die URL die Mühe wert ist

Den Flowchart durchgearbeitet und die Seiten verschwinden trotzdem weiter? Holen Sie sich eine technische Diagnose auf Basis echter Crawl- und Indexdaten, bevor irgendetwas gelöscht wird.

Zweig 1: Manual Action, Security Issue oder Policy-Problem

Das ist der schnellste Zweig zum Ausschließen oder Bestätigen.

Manual Actions und Security Issues

Wenn Search Console eine Manual Action oder ein Security Issue zeigt, behandeln Sie das als primäre Ursache. Verlieren Sie keine Stunden mit Canonicals oder Sitemaps, bevor das eigentliche Enforcement- oder Sicherheitsproblem geklärt ist.

Wenn es weder Manual Action noch Security Issue gibt, sollte die Sprache „Penalty“ aus der Diagnose verschwinden. Sie erzeugt meist nur zusätzliche Panik.

Zweig 2: Technische Indexability-Probleme

Technische Ursachen sind konkret, testbar und oft der sauberste erste Prüfpunkt.

noindex, robots.txt, Redirects und Canonical-Fallen

Prüfen Sie, ob die URL:

  • durch `noindex` ausgeschlossen wird,
  • durch `robots.txt` blockiert wird,
  • weiterleitet,
  • auf eine andere URL canonicalisiert,
  • widersprüchliche Canonical-Signale zwischen HTML, Sitemap und Internal Links sendet.

soft 404

Eine Seite kann technisch erfolgreich antworten und dennoch als Soft 404 behandelt werden, wenn sie zu dünn, zu generisch oder zu schwach im Verhältnis zum Suchbedarf wirkt.

Zweig 3: Canonical-, Duplicate- und Overlap-Probleme

Nicht jede fehlende URL ist technisch kaputt. Manche werden zugunsten stärkerer URLs zusammengezogen, weil Google Duplikation, Overlap oder zu geringe Differenzierung sieht.

Duplicate- und Overlap-Prüfung

Suchen Sie nach:

  • fast identischen Seiten für dieselbe Suchintention,
  • Tag- oder Filterseiten, die mit Primärseiten konkurrieren,
  • älteren Versionen desselben Beitrags,
  • dünnen Standort- oder Programmatic-Seiten mit schwacher Differenzierung.

Wenn eine andere URL klar die stärkere Canonical-Kandidatin ist, ist forciertes Reindexing oft das falsche Ziel. Konsolidierung ist meist sauberer.

Zweig 4: Quality-, Usefulness- und Thin-Content-Signale

Indexability und Usefulness sind unterschiedliche Fragen. Eine Seite kann technisch indexierbar sein und dennoch kein starker Kandidat sein, im Index zu bleiben.

Thin und überlappender Content

Prüfen Sie, ob die Seite:

  • gegenüber nahen URLs wirklich etwas Eigenes sagt,
  • einen echten Suchbedarf klar beantwortet,
  • genügend Evidenz, Spezifität und Struktur enthält,
  • als separate URL überhaupt sinnvoll bleibt.

Viele Teams reagieren hier zu schnell. Sie gehen davon aus, dass jede verlorene Seite zurück in den Index muss. In Wirklichkeit sollten manche Seiten verbessert, manche zusammengeführt und manche nicht weiter forciert werden.

Zweig 5: Crawl-, Sitemap- und Internal-Linking-Probleme

Discovery- und Support-Signale bleiben wichtig, besonders bei schwächeren oder tieferen URLs.

sitemap und internal linking

Prüfen Sie, ob die URL:

  • noch in der XML-Sitemap enthalten ist,
  • sinnvolle Internal Links erhält,
  • zu tief in der Navigation versteckt ist,
  • von schwachen oder fast orphan-artigen Discovery-Mustern abhängt.

Wenn die Seite wichtig ist, sollte sie leichter auffindbar und im Kontext leichter verständlich sein.

Deindexing-Diagnosetabelle

Symptom Wo prüfen Mögliche Ursache Benötigte Evidenz Sichererer nächster Schritt
URL früher indexiert, jetzt fehlend Search Console und URL Inspection Echter Indexverlust, Canonical-Verschiebung oder Exclusion Früherer Indexstatus plus aktueller Status Zweig bestätigen, bevor etwas geändert wird
Crawled – currently not indexed Page indexing report Schwache Usefulness, Overlap, weiche Qualitätsprobleme oder unklare Rolle Inspection-Ergebnis und Seitenvergleich Je nach Wert verbessern, mergen oder belassen
Discovered – currently not indexed Page indexing report, Crawl-Pfade, Internal Links Schwache Discovery, wenig Support, niedrige Crawl-Priorität Internal-Link-Map und Sitemap-Status Discovery stärken, bevor forciert wird
Duplicate oder Canonical-Mismatch URL Inspection und HTML-Signale Widersprüchliche Canonicals oder Overlap Selected Canonical und Declared Canonical Signale ausrichten oder konsolidieren
Excluded by noindex Page indexing report und Quellprüfung Absichtliches oder versehentliches noindex Meta- oder Header-Direktive Nur entfernen, wenn die Seite wirklich indexiert werden soll
Blocked by robots.txt robots.txt-Prüfung und URL-Test Crawl-Blockade Regel, die den Pfad betrifft Nur entfernen, wenn Crawl-Zugriff nötig ist
Redirected URL URL Inspection und direkter Fetch Redirect-Kette oder stillgelegte Seite Ziel-URL und Intent-Match Redirect beibehalten, wenn Konsolidierung korrekt ist
Soft 404 Page indexing report und Seitenprüfung Dünne oder schwache Nutzererfahrung Content-Tiefe und Seitenzweck Inhalt stärken oder stilllegen
Thin oder überlappender Content Seitenvergleich Ähnliche Seiten konkurrieren um dieselbe Rolle Overlap-Review nebeneinander Mergen, umschreiben oder Scope verkleinern
Schwache Internal Links Crawl-Map und Template-Review Zu wenig Unterstützung durch die Seite Link-Anzahl und Platzierung Sinnvolle Internal Links ergänzen
Aus der Sitemap entfernt Sitemap und CMS-Ablauf Schlechte Pflege oder versehentliche Entfernung Sitemap-Präsenz und Zeitstempel Nur wieder aufnehmen, wenn die URL Indexwert hat

Entscheidung: fix, merge, noindex, retire oder belassen

Die Standardentscheidung sollte nicht automatisch „zurückholen“ sein. Die richtige Entscheidung hängt vom Wert der Seite, von der Ursache und von ihrer Rolle in der Architektur ab.

Entscheidung Einsatz, wenn Benötigte Evidenz Risiko, wenn falsch Nächster Schritt
Fix Die URL soll bestehen bleiben und das Problem ist technisch Klarer Indexability- oder Signalfehler Zeit im falschen Zweig verlieren Problem beheben und beobachten
Merge oder konsolidieren Eine andere URL bedient dieselbe Intention bereits besser Overlap, Duplicate, schwache Differenzierung Kannibalisierung weiterlaufen lassen Wert in die stärkere URL überführen
Improve and resubmit Die Seite ist wichtig, aber schwach oder unklar Quality- oder Usefulness-Lücke Eine Seite umschreiben, die eigentlich hätte gemerged werden sollen Seite verbessern und erneut prüfen
noindex intentionally Die Seite soll erreichbar bleiben, aber nicht indexiert werden Klare Business- oder Architekturbegründung Wertvolle Seite unnötig verstecken Bewusst setzen und dokumentieren
Retire oder löschen Die Seite hat keinen Such- oder Business-Wert mehr Geringer Wert und kein sauberer Recovery-Case Nützliche Assets zu früh löschen Redirect, Archiv oder Entfernung sauber planen
Leave alone Die Seite ist den Aufwand nicht wert Geringer strategischer Wert und kein starker Grund Zeit auf unwichtige URLs verschwenden Dokumentieren und weitergehen

Was vor dem Löschen dokumentiert werden sollte

Zu frühes Löschen entfernt auch Evidenz. Erst dokumentieren.

  • Aktueller Search-Console-Status
  • URL-Inspection-Ergebnis
  • Declared und Selected Canonical
  • noindex- oder robots-Befunde
  • Redirect-Verhalten
  • Sitemap-Präsenz
  • Internal Links zur URL
  • konkurrierende oder überlappende Seiten
  • ob die Seite noch Business-Wert hat

Drei illustrative Diagnoseszenarien

Szenario 1: technische Ursache

Ein illustrativer Fall: eine früher indexierte Seite verschwindet, URL Inspection zeigt ein anderes Canonical, und Internal Links verstärken genau dieses falsche Ziel. Der erste Schritt ist dann Signal-Ausrichtung, nicht Massen-Rewriting.

Szenario 2: Quality- und Overlap-Ursache

Ein anonymisiertes Muster: mehrere Seiten zielen fast identisch auf dieselbe Intention. Google behält die stärkere URL und lässt die schwächeren fallen. In so einem Fall ist Konsolidierung sicherer als der Versuch, alles zurück in den Index zu drücken.

Szenario 3: Löschen wäre zu früh

Ein illustrativer ungeklärter Fall: Die Seite fehlt, es gibt keine Manual Action, keinen klaren technischen Block, und die Seite unterstützt weiterhin einen wertvollen Use Case. Dann ist die richtige Reaktion, langsamer zu werden, Evidenz zu sammeln und nicht vorschnell zu löschen.

Screenshot-Checkliste

Screenshot Warum erfassen Wo erfassen Was schwärzen
Page indexing report Den aktuellen Status belegen Search Console Queries, Kontoetiketten, sensible Pfade
URL Inspection Ergebnis Canonical- und Indexability-Hinweise sichern Search Console Sensible Property-Details
Manual Actions oder Security Issues Enforcement schnell ausschließen Search Console Markensensible Hinweise
robots.txt oder noindex Evidenz Technische Exclusion beweisen Quellcode, Header oder robots-Datei Interne Umgebungsdetails
Entscheidungs-Matrix Gewählte Maßnahme dokumentieren Editorial Asset oder Audit-Deck Kundennamen und URL-Listen

Screenshot-Placeholder-Notizen

  • Full-page Deindexing-Diagnose-Flowchart Placeholder
  • Search-Console-Page-indexing-report Screenshot Placeholder
  • URL-Inspection Screenshot Placeholder
  • Manual-Actions- und Security-Issues Screenshot Placeholder
  • Canonical-, noindex- und robots-Prüfung Screenshot Placeholder
  • Fix-, merge- und retire-Entscheidungsmatrix Placeholder
  • Downloadbarer PNG- oder PDF-Flowchart Placeholder

Häufige Fehler vermeiden

  • Jede fehlende URL sofort als Penalty zu bezeichnen.
  • Rankingverlust und Indexverlust als dasselbe Problem zu behandeln.
  • URLs zu löschen, bevor Canonical-, noindex-, Redirect- und Sitemap-Evidenz dokumentiert wurde.
  • Request Indexing als komplette Strategie zu behandeln.
  • Davon auszugehen, dass jede verlorene Seite zurück in den Index muss.
  • Davon auszugehen, dass jede verlorene Seite ein rein technisches Problem ist.

Abschließende Empfehlung

Arbeiten Sie mit Diagnose-Reihenfolge statt mit Panik-Sprache. Bestätigen Sie den Status in der Search Console, trennen Sie technische Ursachen, vergleichen Sie Overlap und Usefulness und entscheiden Sie dann, ob die URL gefixt, gemerged, per noindex ausgeschlossen, stillgelegt oder einfach belassen werden sollte.

Wenn Sie zusätzlichen Reporting-Kontext zur Search Console brauchen, hilft der Search Console generative AI report guide bei der Oberfläche und beim Workflow. Die Diagnose hier sollte aber klar auf Indexverluste fokussiert bleiben.

Den Flowchart durchgearbeitet und trotzdem weiter Seiten verloren? Holen Sie sich eine technische Diagnose auf Basis echter Crawl- und Indexdaten, bevor etwas gelöscht wird.

FAQ

Ist die Deindexing-Welle 2026 eine Google-Penalty?

Nicht automatisch. Wenn es keine Manual Action und kein Security Issue gibt, sollte ohne Evidenz nicht von einer Penalty gesprochen werden.

Warum zeigt Search Console Crawled – currently not indexed?

Das bedeutet meist, dass Google die Seite gecrawlt, aber nicht im Index behalten hat. Ursache kann Overlap, schwache Usefulness, weiche Quality-Signale oder etwas anderes sein. Es gibt keine universelle Einzelerklärung.

Sollte ich deindexierte Seiten löschen?

Nein. Prüfen Sie zuerst den Business-Wert der URL, technische Ausschlüsse und ob ein Merge sicherer ist als eine Löschung.

Hilft Request Indexing gegen Deindexing?

Nicht allein. Es kann nach einem echten Fix als Nachfolgeaktion sinnvoll sein, ist aber keine Diagnose oder vollständige Recovery-Strategie.

Wie lange dauert Reindexing nach einem Fix?

Es gibt keinen garantierten Zeitrahmen. Zuerst muss die eigentliche Ursache behoben werden, danach sollte beobachtet statt versprochen werden.

Können Canonical-Tags Deindexing verursachen?

Ja. Wenn Canonical-Signale Google zu einer anderen URL lenken, kann die geprüfte Seite ihren Indexstatus verlieren, obwohl sie normal lädt.

Wann sollte ich eine Seite mergen statt fixen?

Wenn eine andere URL dieselbe Intention bereits besser bedient und die fehlende Seite hauptsächlich duplicate, thin oder schwach differenziert ist, ist Merge meist die bessere Entscheidung.

Quellenhinweise