Warum Seiten aus dem Index fliegen (und wie Sie es mit einem Crawl diagnostizieren)

Die Traffic-Kurve der letzten Woche sieht aus wie eine Klippe. Seiten, die gestern noch rankten, sind weg. site:ihredomain.de in Google liefert einen Bruchteil dessen, was es einmal war. Sie haben nichts geändert, oder so fühlt es sich an. Kennen Sie das? Sie sind nicht allein. In jeder beliebigen Woche sind die Technical-SEO-Foren voll mit demselben Post: “1800 Seiten über Nacht deindexiert, was ist passiert?”

Die ehrliche Nachricht lautet: “Deindexiert” hat fast nie eine einzelne Ursache und ist fast immer diagnostizierbar. Die Arbeit ist nicht Panik, sondern Triage. Dieser Leitfaden geht durch, was das Wort tatsächlich bedeutet, die acht Ursachen, die die überwältigende Mehrheit der Fälle erklären, eine 15-minütige crawl-basierte Prüfung, die Ihren Fall findet, was bei jeder Ursache zu tun ist und wie die Seiten wieder in den Index kommen.

”Deindexiert” bedeutet eigentlich drei verschiedene Dinge

Bevor Sie etwas reparieren, bringen Sie die Begriffe in Ordnung. Die drei Situationen werden ständig verwechselt und sie verlangen unterschiedliche Antworten.

War indexiert, jetzt entfernt. Google hatte Ihre URL im Index, lieferte sie in den Ergebnissen und entfernte sie dann. Das ist der Klippen-Fall. Es ist auch der Fall, in dem eine technische oder qualitative Änderung den Drop meistens erklärt und in dem Sie ihn oft umkehren können.

Gecrawlt, derzeit nicht indexiert. Google hat die Seite abgerufen, sich aber entschieden, sie nicht in den Index aufzunehmen. In der Search Console erscheint das als “Gecrawlt - zurzeit nicht indexiert” oder “Gefunden - zurzeit nicht indexiert”. Die Seite existiert, der Crawler hat sie gefunden, aber Google hielt sie nicht für indexwürdig. Die Lösung ist hier meist Inhaltsqualität, interne Verlinkung oder ein Duplicate-Content-Signal, keine technische Blockade.

Nie indexiert. Die URL war nie im Index. Kann eine neue Seite sein, zu der Google noch nicht gekommen ist, oder eine durch robots.txt blockierte, oder eine mit noindex von Anfang an, oder einfach eine verwaiste, nicht auffindbare.

Der Bericht Seitenindexierung in der Search Console ist der sauberste Ort, das auseinanderzuhalten. Öffnen Sie ihn, bevor Sie irgendetwas tun, und schauen Sie, in welchem Bucket Ihre verlorenen URLs sitzen. Der Fix-Pfad von “Eingereicht und indexiert” zu “Gecrawlt - zurzeit nicht indexiert” sieht ganz anders aus als der für “Durch ‘noindex’-Tag ausgeschlossen”.

Dieser Leitfaden konzentriert sich auf den ersten Fall, “war indexiert, jetzt entfernt”, denn das ist es, worum es in den meisten “1800 Seiten über Nacht verschwunden”-Meldungen geht.

Die acht Ursachen, die fast jeden Fall erklären

Massendeindexierung hat fast immer eine dieser acht Ursachen. Die Liste steht in etwa der Reihenfolge, in der ich sie prüfe, weil manche viel häufiger sind als die anderen.

1. Ein noindex-Meta-Tag oder X-Robots-Tag-Header wurde versehentlich deployt. Das ist die häufigste Einzelursache von “Seiten über Nacht deindexiert”. Eine Staging-Umgebung ging mit <meta name="robots" content="noindex"> im Template in Produktion. Ein CMS-Plugin-Update kippte einen Default. Ein Header am CDN begann, X-Robots-Tag: noindex auszuliefern. Die Seiten lösen weiter auf, der Inhalt sieht in Ordnung aus, aber Google sieht die Direktive und entfernt sie beim nächsten Crawl. Prüfen Sie sowohl den HTML-Head als auch die HTTP-Response-Header, weil beide noindex tragen können.

2. robots.txt begann, die URLs zu blockieren. Eine neue Disallow: /-Zeile, ein zu weit gefasster Pfad oder ein CDN, das eine andere robots.txt ausliefert. Eine wichtige Feinheit: Eine robots.txt-Blockade entfernt eine Seite meist nicht aus dem Index, sondern verhindert künftiges Crawlen. In Kombination mit einem kürzlichen Re-Crawl oder der Unfähigkeit, ein noindex neu zu bestätigen, kann sie aber zum Drop führen. Prüfen Sie immer die aktuelle, gerenderte robots.txt, die Google sieht, nicht die Datei im Repository. Die Komplettanleitung zu robots.txt und KI-Crawlern führt die Syntaxfehler auf, die die Datei stillschweigend kaputt machen.

3. Canonical-Tags, die woanders hinzeigen. Ein rel="canonical", das auf die Startseite, eine einzelne Hub-Seite oder eine falsche Sprachversion zeigt, fasst die Indexeinträge auf das Canonical-Ziel zusammen. Die Seiten bleiben technisch erreichbar, gelten aber nicht mehr als kanonisches Dokument. Besonders unangenehm, weil sonst alles an der Seite normal aussieht. Der Leitfaden zu Canonical-Tags zeigt die Muster, die schiefgehen.

4. Statuscodes, die die URLs hinausgedrängt haben. Seiten, die plötzlich 404 oder 410 zurückgeben, werden entfernt. Seiten, die lange genug 5xx zurückgeben, ebenfalls. Soft-404s, bei denen die URL 200 zurückgibt, die Seite aber leer ist oder “nicht gefunden” sagt, bekommen dieselbe Behandlung. Erstaunlich viele Klippen lassen sich auf ein Deployment zurückführen, das einen Route-Handler kaputt gemacht hat und einen ganzen Bereich in 404 schickt.

5. Eine versehentlich auf Produktion deployte Staging- oder Dev-Umgebung. Das Deployment ging mit dem Staging-Template, der Staging-robots.txt, den Staging-Meta-Tags oder allem zusammen raus. Die Seite sieht lebendig aus, aber ihre Indexierungssignale sind invertiert.

6. Hreflang-Konflikte. Ein falsch verkabeltes hreflang-Setup kann dazu führen, dass Google Sprachversionen zusammenfasst oder die falschen entfernt. Der Leitfaden zur Hreflang-Implementierung ist die Anlaufstelle zur Verifizierung.

7. Eine manuelle Maßnahme oder Neubewertung durch ein Core Update. Seltener als die technischen Ursachen, aber sehr real. Eine manuelle Maßnahme erscheint in der Search Console unter “Sicherheit und manuelle Maßnahmen”. Ein Core Update ist unsichtbar, aber sein Fingerabdruck ist erkennbar: ein breiter, allmählicher Rückgang von Rankings und Indexierung, der mit einem von Google angekündigten Update-Fenster zusammenfällt und oft dünne oder vertrauensarme Inhalte zuerst trifft. Die ruhige Variante davon behandelt der Leitfaden zum Jahres-Mythos im Titel und zum Core Update, sobald die technischen Ursachen ausgeschlossen sind.

8. Dünner, doppelter oder automatisch erzeugter Inhalt, den Google für nicht indexwürdig gehalten hat. Zeigt sich meist als “Gecrawlt - zurzeit nicht indexiert”. Die Lösung ist redaktionell: betroffene Seiten ausmisten, zusammenführen oder substanziell verbessern.

Achtzig Prozent der Geschichten über “Seiten über Nacht deindexiert” gehen auf die Ursachen eins bis fünf zurück. Arbeiten Sie diese Liste immer zuerst ab.

Diagnose mit einem Crawl: eine 15-minütige Triage

Die Search Console allein ist bei großen Sites langsam. Der schnellste Weg, Ihre Ursache zu finden, ist, den betroffenen Bereich selbst zu crawlen und aggressiv zu filtern. So geht es:

Schritt 1: Symptom in der Search Console bestätigen (2 Minuten).

• Öffnen Sie Seitenindexierung. Notieren Sie die Buckets, in denen Ihre URLs sitzen. “Durch ‘noindex’-Tag ausgeschlossen”, “Durch robots.txt blockiert”, “Soft 404”, “Nicht gefunden (404)”, “Alternative Seite mit richtigem kanonischen Tag”, “Duplikat, Google hat anderen kanonischen Tag gewählt” und “Gecrawlt - zurzeit nicht indexiert” zeigen jeweils auf eine andere Ursache aus der obigen Liste.
• Öffnen Sie URL-Prüfung für eine konkrete verlorene URL. Die Verdikt-Zeile und das Indexierungsdetails-Panel sind das einzelne nützlichste Diagnoseinstrument in der Search Console.

Schritt 2: Die Site crawlen und filtern (8 Minuten). Führen Sie einen Crawl Ihrer Domain durch, dann filtern Sie die Ergebnisse in dieser Reihenfolge:

• Seiten, die noindex ausliefern entweder im HTML oder im X-Robots-Tag-Header. Schon eine Zeile auf einem Template-URL-Muster reicht aus, einen Massendrop zu erklären.
• Statuscodes ungleich 200. Bringen Sie jeden 3xx, 4xx, 5xx an die Oberfläche. Suchen Sie nach Mustern: ein ganzer Bereich, der 404 zurückgibt, eine Kategorieseite in einer Redirect-Schleife, ein 5xx-Spike.
• Canonical zeigt woanders hin. Filtern Sie nach Seiten, deren Canonical-URL nicht der Seiten-URL selbst entspricht. Prüfen Sie dann, ob der Canonical beabsichtigt ist. Ganze Sites werden durch einen globalen Canonical auf die Startseite deindexiert.
• Durch robots.txt blockiert. Bringen Sie jede URL an die Oberfläche, die der Crawler wegen robots.txt übersprungen hat. Quervergleich mit Ihrer Sitemap.

Schritt 3: Sitemap vs. Crawl vs. Index vergleichen (3 Minuten). Eine saubere Sitemap, die Menge der URLs, die der Crawler tatsächlich erreicht und mit 200 bekommen hat, und die Menge der URLs, die die Search Console als indexiert meldet, sollten sich stark überlappen. Das Delta erzählt die Geschichte:

• URLs in der Sitemap, aber nicht gecrawlt → Auffindbarkeits- oder robots.txt-Problem
• URLs gecrawlt, aber nicht indexiert → Qualitäts-, Canonical- oder noindex-Problem
• URLs indexiert, aber nicht in der Sitemap → Sitemap-Aktualität (weniger dringend)

Schritt 4: Server-Logs nach Bot-Traffic anschauen (2 Minuten). Wenn Sie Zugriff auf die Access-Logs haben, greppen Sie in den letzten 72 Stunden nach Googlebot und sehen Sie, ob er die betroffenen URLs überhaupt anfasst. Ein plötzlicher Rückgang der Crawl-Frequenz auf einem Bereich ist selbst ein Signal. Es ist auch der einzige Ort, an dem Sie bestätigen können, ob KI-Crawler und Such-Bots tatsächlich das erreichen, was Sie denken. Dieselbe Routine ist Teil jedes gesunden Crawl-Budget-Audits.

Die meisten Ursachen zeigen sich in Schritt 2. Die Fälle bei großen Sites, in denen es länger dauert, laufen fast immer auf ein Canonical- oder Hreflang-Problem hinaus, das sich dünn über viele Seiten zieht.

Jede Ursache beheben

Sobald Sie die Ursache identifiziert haben, ist die Lösung meist kurz.

Noindex in Produktion gelassen: Tag oder Header entfernen. Mit curl -I für den Header und view-source: für das HTML bestätigen. Für eine Beispiel-URL in der Search Console eine Indexierung anfragen. Die meisten Seiten kommen innerhalb von Tagen zurück, große Bereiche brauchen länger, weil Google nach eigenem Zeitplan neu crawlt.

robots.txt-Blockade: Datei bearbeiten, ausrollen, mit dem robots.txt-Tester in der Search Console oder einfach durch Abruf von ihredomain.de/robots.txt im Browser verifizieren. Dann die Sitemap erneut einreichen, um einen Re-Crawl anzustoßen.

Falscher Canonical: Den rel="canonical"-Wert auf die Seite selbst korrigieren oder auf das tatsächliche Canonical-Ziel. Vorsicht vor Canonicals, die von SEO-Plugins oder CMS-Einstellungen injiziert werden, nicht nur im Template.

4xx / 5xx-Fehler: Das zugrunde liegende Routing- oder Serverproblem beheben. Für absichtliche Entfernungen ist 410 entschiedener als 404, beides funktioniert. Bei Soft-404s entweder sinnvollen Inhalt wiederherstellen oder tatsächlich 404 zurückgeben.

Staging in Produktion deployt: zurückrollen. Dann untersuchen, wie es passieren konnte: noindex / Staging-robots.txt sollten niemals ausgeliefert werden.

Hreflang-Konflikte: Der Hreflang-Leitfaden listet die fünf üblichen Brüche. Die meisten laufen auf nicht-reziproke Annotationen oder falsche Regionscodes hinaus.

Manuelle Maßnahme: Bericht “Manuelle Maßnahmen” öffnen, den konkreten Befund lesen, beheben und eine Reconsideration-Anfrage einreichen. Ehrlich in der Anfrage sein, vage Entschuldigungen kommen nicht durch.

Qualitätsneubewertung / Core Update: Die Lösung ist redaktionell und langsamer. Identifizieren Sie die betroffenen Seiten, entscheiden Sie, welche eine substanzielle Überarbeitung verdienen, welche zusammengeführt oder gelöscht werden sollten und welche in Ruhe gelassen werden. Der Jahres-Mythos- und Core-Update-Leitfaden deckt das längere Playbook ab.

Seiten wieder in den Index bringen

Sobald die Ursache behoben ist, springt die Seite nicht automatisch zurück. Sie können die Re-Indexierung beschleunigen:

• Indexierung anfragen im URL-Prüfungstool für hochwertige Seiten. Es ist rate-limitiert, also für Templates und Hubs nutzen, nicht für jede URL.
• Sitemap erneut einreichen. Das stupst Google an, die URLs darin neu zu crawlen. Wenn die Sitemap selbst veraltet ist, zuerst die fixen. Der Leitfaden zu XML-Sitemaps deckt den Validierungsschritt ab.
• Interne Links auf die betroffenen URLs stärken. Manchmal waren die deindexierten Seiten auch verwaist oder schwach verlinkt. Ein paar gut gesetzte interne Links von gesunden Hub-Seiten helfen bei der Wiederentdeckung.
• Geduldig bleiben. Kleine Sites re-indexieren oft binnen weniger Tage. Große Sites mit tausenden verlorenen URLs brauchen Wochen, bis der Index aufholt, selbst wenn alles behoben ist.

Technisches Problem oder Strafe? Wie man es erkennt

Diese Frage kommt jedes Mal, und die Antwort lautet fast immer “technisch, nicht Strafe”. Die schnelle Prüfung:

• Manuelle Maßnahme: Es gibt einen Hinweis im Bericht “Manuelle Maßnahmen”. Ist der Bericht leer, ist es keine manuelle Maßnahme.
• Algorithmisch / Core Update: Der Rückgang ist allmählich, breit und passt zeitlich zu einem bekannten Google-Update-Fenster. Andere Sites in Ihrem Bereich sehen ähnliche Bewegungen an denselben Tagen.
• Technisch: Der Rückgang ist plötzlich, das Timing passt meist zu einem Deployment oder einer Plattformänderung, und die Seitenindexierung in der Search Console zeigt auf eine konkrete Ursache (noindex, robots-Blockade, 404, Canonical).

Der technische Fall ist mit Abstand der häufigste. Die meisten “Google hat mich abgestraft”-Posts entpuppen sich als ein noindex, das zwei Tage vor dem Traffic-Einbruch ausgeliefert wurde.

Vorbeugen: eine Indexierungs-Checkliste vor dem Deployment

Die meisten Deindexierungs-Vorfälle sind vermeidbar. Eine kurze Pre-Deploy-Checkliste fängt die schlimmsten ab:

• Produktions-HTML darf kein noindex auf einer Seite haben, die im Index sein soll. CI kann das greppen.
• Produktions-robots.txt darf kein Disallow: / enthalten. CI kann sie abrufen und prüfen.
• Produktion muss auf einer Liste kritischer URLs mit 200 (oder absichtlichem 301) antworten. CI kann curlen und asserten.
• X-Robots-Tag-Header auf Schlüssel-URLs dürfen kein noindex enthalten.
• Canonical-Tags auf einer Stichprobe von URLs müssen auf sich selbst zeigen (oder auf einen beabsichtigten Canonical).
• Die ausgelieferte Sitemap entspricht den Live-URLs.

Ein nächtlicher externer Crawl, der den Build scheitern lässt, wenn eine dieser Prüfungen regrediert, kommt einem echten Sicherheitsnetz am nächsten. Die Checkliste zum technischen SEO-Audit deckt das breitere wiederkehrende Audit ab.

Schluss

Massendeindexierung fühlt sich wie eine Katastrophe an und ist es meistens nicht. In der überwältigenden Mehrheit der Fälle ist die Ursache technisch, sie ist in unter 15 Minuten mit einem Crawl plus dem Seitenindexierungsbericht der Search Console identifizierbar, und der Fix ist kurz. Panik ist der Feind der Triage. Beginnen Sie mit der Acht-Ursachen-Liste, fahren Sie die Vier-Schritte-Diagnose, beheben Sie, was Sie finden, und fragen Sie eine Neu-Indexierung auf einer Stichprobe hochwertiger URLs an.

Wenn Sie diesen 15-minütigen Crawl jetzt fahren wollen: Seodisias herunterladen und auf Ihre Site zeigen. Es crawlt lokal auf Ihrer Maschine ohne URL-Limit, bringt jedes noindex-Tag, jeden Statuscode ungleich 200, jeden auf etwas anderes zeigenden Canonical und jede durch robots.txt blockierte URL in einem Durchgang an die Oberfläche. Kein Upload, keine Anmeldung, alle Daten bleiben bei Ihnen. Vergleichen Sie, was es findet, mit Ihrem Seitenindexierungsbericht in der Search Console, und die Ursache liegt fast immer in der Lücke zwischen beiden.