Indexierung blockiert: Ursachen erkennen und gezielt beheben

Die häufigsten Ursachen für eine blockierte Indexierung sind ein Disallow in der robots.txt, ein noindex-Tag oder ein X-Robots-Tag-Header, 4xx- oder 5xx-Statuscodes sowie fehlerhafte Canonical-Signale, die auf eine andere URL verweisen. Der erste Prüfschritt führt immer über die Google Search Console und dort über das URL-Prüftool. Eine eingereichte Sitemap garantiert dabei zu keinem Zeitpunkt eine Indexierung, sie ist lediglich ein Signal unter mehreren.

Technische Ursachen im Detail: robots.txt, noindex und Statuscodes

Jede dieser Ursachen wirkt an einer anderen Stelle im Crawling- und Indexierungsprozess, und genau das macht die Diagnose anspruchsvoll. Eine robots.txt-Sperre verhindert bereits das Crawlen: Googlebot ruft die Seite gar nicht erst ab, wodurch er auch ein vorhandenes noindex-Tag im Quelltext niemals zu Gesicht bekommt. Die Regeln greifen über User-Agent-Gruppen und Disallow-Pfade, die case-sensitive ausgewertet werden, kleine Tippfehler im Pfad genügen für einen folgenschweren Block, wie die Spezifikation zur robots.txt-Interpretation beschreibt.

Noindex und X-Robots-Tag lösen eine ähnliche Wirkung aus, sitzen aber an unterschiedlichen Stellen. Das Meta-Robots-Tag funktioniert ausschließlich im HTML-Quelltext einer Seite. Für Nicht-HTML-Ressourcen wie PDFs oder Bilddateien gibt es keinen Platz für ein Meta-Tag im Dokument selbst, deshalb setzt man die Anweisung dort über den X-Robots-Tag im HTTP-Header. Beide Varianten werden von Google erst erkannt, wenn die URL tatsächlich gecrawlt werden darf, eine robots.txt-Sperre blockiert also indirekt auch die Entdeckung dieser Anweisungen.

Typische technische Stolpersteine, die wir in Prüfungen immer wieder finden:

• Disallow-Regeln, die versehentlich ganze Verzeichnisse statt einzelner Unterseiten sperren.
• 301-Weiterleitungsketten über mehrere Stationen statt einer direkten Weiterleitung auf das Ziel.
• Domainübergreifende Canonical-Tags, die auf eine falsche oder veraltete Domain zeigen.
• Login-geschützte Bereiche, die mit 401 antworten und so das Crawling verhindern.
• CMS-Vorlagen, die auf allen Seiten dieselbe, falsche Canonical-URL ausgeben.

Bei Duplicate Content entscheidet Google anhand von Signalen wie rel=“canonical”, internen Links und Sitemap-Einträgen, welche URL als kanonisch gilt. Stimmen diese Signale nicht überein, kann eine eigentlich indexierbare Seite zugunsten einer anderen URL aus dem Index fallen, auch ganz ohne technischen Fehler im engeren Sinn.

Schritt für Schritt zur Diagnose: Checkliste mit Tools und Befehlen

Eine saubere Diagnose folgt immer derselben Reihenfolge, vom groben Überblick zum Detail.

1. Öffnen Sie den Bericht zur Seitenindexierung in der Search Console und sichten Sie die Ausschlussgründe.
2. Prüfen Sie die betroffene URL im URL-Prüftool und lesen Sie die Felder „Crawling erlaubt?“, „Indexierung zulässig?“ und „Seitenabruf“.
3. Starten Sie einen Live-Test derselben URL, um den aktuellen Zustand statt eines alten Crawls zu sehen.
4. Reichen Sie bei positivem Ergebnis eine Indexierungsanfrage ein und notieren Sie das Datum.
5. Testen Sie die relevante Disallow-Zeile mit einem robots.txt-Prüfwerkzeug, um die genaue blockierende Regel zu identifizieren.
6. Prüfen Sie HTTP-Header und Statuscodes per curl oder über die Netzwerk-Ansicht der Browser-DevTools, inklusive Weiterleitungsketten.
7. Werten Sie Server-Logs aus: Wie oft ruft Googlebot die URL ab, und mit welchem Statuscode antwortet der Server?

Profi-Tipp:Prüfen Sie bei Verdacht auf ein Server-Problem zuerst die Logs und erst danach die Search Console, denn die Logs zeigen den Rohzustand, während die Konsole bereits aggregierte und leicht verzögerte Daten liefert.

Der Bericht zur Seitenindexierung unterscheidet außerdem zwischen zwei Zuständen, die unterschiedliche Reaktionen verlangen. „Gefunden – zurzeit nicht indexiert“ deutet meist auf ein Kapazitäts- oder Relevanzproblem hin, Google kennt die URL, hat aber keine Priorität gesehen, sie abzurufen. „Gecrawlt – zurzeit nicht indexiert“ bedeutet dagegen fast immer eine bewusste Qualitäts- oder Duplikat-Entscheidung. Eine erneute Indexierungsanfrage bringt in diesem zweiten Fall ohne inhaltliche Anpassung in der Regel wenig, wie Beobachtungen zu Crawling- und Indexierungsentscheidungen zeigen.

Behebungen priorisieren: Was zuerst, was kann warten

Nicht jede Ursache verlangt dieselbe Dringlichkeit, und wer alles gleichzeitig angeht, verliert Zeit an den falschen Stellen.

• Robots.txt-Fehler korrigieren Sie sofort: Regel anpassen, Live-Test durchführen, danach Indexierung beantragen.
• Wollen Sie eine Seite dauerhaft aus dem Index entfernen, genügt eine robots.txt-Sperre nicht: Der korrekte Ablauf ist, die Sperre zu lösen, noindex zu setzen, das erneute Crawling abzuwarten und die Sperre danach bei Bedarf wieder zu aktivieren, wie die Dokumentation zur Indexierungssteuerung beschreibt.
• Noindex-Anweisungen entfernen Sie dort, wo Indexierung gewünscht ist, bei Nicht-HTML-Dateien setzen Sie stattdessen das X-Robots-Tag im Header.
• 5xx-Fehler erfordern eine Ursachenanalyse auf Serverebene, ein kurzfristiger Neustart ohne Fehlerbehebung löst das Problem meist nur vorübergehend.
• Canonical- und Weiterleitungsprobleme beheben Sie über konsistente 301-Weiterleitungen und interne Links, die ausschließlich auf die gewünschte kanonische URL zeigen.
• Validieren Sie die Sitemap regelmäßig und entfernen Sie darin URLs, die mit 404 antworten, denn eine fehlerhafte Sitemap garantiert ohnehin keine Indexierung.

Als grobe Faustregel gilt: robots.txt-Fehler, 5xx-Serverfehler und unbeabsichtigte Login-Sperren sind Sofortmaßnahmen. Canonical-Bereinigungen und Weiterleitungsstandardisierung sind mittelfristige Projekte. Fragen der Inhaltsqualität, die eine Seite trotz technisch korrekter Konfiguration aus dem Index halten, sind die langfristige Aufgabe.

Prävention und Monitoring: So bleibt die Indexierung stabil

Die beste Behebung ist die, die gar nicht nötig wird, und dafür braucht es feste Routinen statt punktueller Kontrollen.

• Richten Sie Benachrichtigungen in der Google Search Console ein, damit neue Probleme bei der Seitenindexierung automatisch gemeldet werden.
• Prüfen Sie robots.txt und relevante HTTP-Header als festen Bestandteil jedes Deployments, bevor eine Änderung live geht.
• Trennen Sie Staging- und Produktivumgebungen sauber, damit eine für Staging gedachte Sperre nie in die Produktion gelangt.
• Automatisieren Sie die Sitemap-Generierung und validieren Sie sie regelmäßig, statt sie nach der Einrichtung zu vergessen.
• Legen Sie Template-Standards für rel=canonical und Weiterleitungen fest, damit CMS-Vorlagen nicht wiederholt denselben Fehler produzieren.
• Definieren Sie ein Kontroll-Set repräsentativer URLs, dessen Indexierungsstatus Sie wöchentlich prüfen.

Profi-Tipp:Legen Sie für geschäftskritische Seitentypen, etwa Produktseiten oder Kategorieseiten, eine feste Stichprobe an, die Sie nach jedem größeren Relaunch zuerst kontrollieren.

Bedeutung und Einfluss von Crawl-Budgets auf die Indexierung

Das Crawl-Budget beschreibt, wie viele Seiten Googlebot innerhalb eines bestimmten Zeitraums auf einer Domain abruft. Für kleinere Websites ist das selten ein begrenzender Faktor, für große Websites mit sehr vielen URLs oder häufig wechselnden Inhalten kann es dagegen entscheidend werden, welche Seiten überhaupt zum Crawlen ausgewählt werden.

Wird Crawl-Kapazität durch unwichtige Parameter-URLs, Duplikate oder Endlos-Filterkombinationen verbraucht, bleibt für die eigentlich relevanten Seiten weniger übrig. Das äußert sich oft genau in dem Zustand „Gefunden – zurzeit nicht indexiert“, den der Bericht zur Seitenindexierung ausweist. Eine Seite ist Google also bekannt, wurde aber aus Priorisierungsgründen noch nicht abgerufen.

Praktisch bedeutet das: Wer unnötige URL-Varianten per robots.txt ausschließt, Parameter konsolidiert und verwaiste oder redundante Seiten entfernt, lenkt das verfügbare Budget auf die Inhalte, die tatsächlich im Index erscheinen sollen. Für die meisten mittelgroßen Websites ist das Crawl-Budget selbst kein Problem, die Ursache liegt dann eher in robots.txt-Fehlern, Statuscodes oder Canonical-Signalen, wie sie weiter oben beschrieben sind. Erst bei sehr großen oder technisch wild gewachsenen Websites lohnt sich eine gezielte Betrachtung des Crawl-Budgets als eigener Hebel.

Auswirkungen von Ladezeiten und Seitenperformance auf die Indexierung

Langsame Ladezeiten blockieren eine Indexierung nicht direkt, sie wirken aber indirekt auf das Crawling-Verhalten. Antwortet ein Server träge oder instabil, reduziert Googlebot häufig die Abruffrequenz für diese Domain, um den Server nicht zusätzlich zu belasten. Weniger Abrufe bedeuten weniger Gelegenheiten, neue oder geänderte Seiten zu entdecken und erneut zu bewerten.

Besonders kritisch wird es, wenn Performance-Probleme zeitweise zu Zeitüberschreitungen oder serverseitigen Fehlern führen. Ein Server, der unter Last mit 5xx-Statuscodes antwortet, signalisiert Google technische Instabilität, und genau solche Fehler gehören zu den Ursachen, die eine Indexierung direkt verhindern können. Die Performance ist also oft die Ursache hinter der eigentlichen Ursache.

Für die Praxis heißt das: Seitenperformance ist kein separates Kapitel neben der Indexierungsdiagnose, sondern ein Faktor, der die anderen Ursachen verstärkt oder auslöst. Wer Serverlogs ohnehin auf 4xx- und 5xx-Häufigkeiten prüft, sollte dieselben Logs auch auf Antwortzeiten hin durchsehen, denn beide Symptome treten häufig gemeinsam auf, besonders bei Shared-Hosting-Umgebungen oder während Lastspitzen.

Google-Indexierungsstatistiken im Search Console-Dashboard richtig lesen

Der Bericht zur Seitenindexierung gliedert URLs in klar benannte Kategorien, und jede davon verlangt eine andere Reaktion. Seiten unter „Index: Erfolgreich“ sind indexiert, Seiten unter den verschiedenen Ausschlussgründen sind es nicht, aus sehr unterschiedlichen Gründen.

Die Kategorie „Durch robots.txt blockiert“ ist eindeutig und meist schnell behoben. „Alternative Seite mit richtigem kanonischem Tag“ bedeutet, dass Google eine andere URL als kanonisch gewählt hat, das ist nicht zwingend ein Fehler, sondern oft eine korrekte Entscheidung bei echtem Duplicate Content. „Gecrawlt – zurzeit nicht indexiert“ und „Gefunden – zurzeit nicht indexiert“ sind die beiden Zustände, die am häufigsten verwechselt werden, obwohl sie unterschiedliche Ursachen haben, wie im Diagnoseabschnitt beschrieben.

Beim Auswerten lohnt sich ein Blick auf die Entwicklung über Zeit, nicht nur auf die Momentaufnahme. Ein plötzlicher Sprung in einer Ausschlusskategorie, etwa ein deutlicher Anstieg der URLs, deutet fast immer auf eine technische Änderung hin, etwa ein Deployment, eine neue robots.txt oder eine CMS-Vorlagenänderung. Ein langsamer, stetiger Anstieg deutet eher auf ein strukturelles Problem wie wachsenden Duplicate Content hin. Diese zeitliche Einordnung entscheidet oft darüber, ob man nach einem einzelnen Fehler oder nach einem systematischen Muster suchen sollte.

Häufige Ursachen für Indexierungsprobleme bei der Mobile-First-Indexierung

Seit der vollständigen Umstellung auf Mobile-First-Indexierung bewertet Google primär die mobile Version einer Seite, nicht mehr die Desktop-Version. Das verschiebt auch die typischen Fehlerquellen: Eine Seite, die auf dem Desktop einwandfrei indexierbar wäre, kann trotzdem Probleme bekommen, wenn die mobile Variante andere Signale sendet.

Ein klassischer Fall ist eine mobile Vorlage, die ein noindex-Tag enthält, das in der Desktop-Version fehlt, oft ein Überbleibsel aus separaten m-dot-Domains oder alten responsive-Umstellungen. Ebenso kritisch sind Unterschiede im Hauptinhalt: Wird auf Mobilgeräten Content ausgeblendet oder per Lazy-Loading erst spät nachgeladen, sieht Googlebot bei der mobilen Bewertung möglicherweise weniger Inhalt als ein menschlicher Desktop-Besucher.

Auch strukturierte Daten und Canonical-Tags müssen auf der mobilen Seite identisch zur Desktop-Version vorhanden sein, fehlen sie dort, zählt für die Indexierung die unvollständige mobile Fassung. Wer Indexierungsprobleme untersucht, sollte deshalb im URL-Prüftool gezielt die mobile Darstellung testen und nicht automatisch von der Desktop-Ansicht auf den tatsächlichen Indexierungszustand schließen.

Einfluss von strukturierten Daten und Schema-Markup auf die Indexierbarkeit

Strukturierte Daten entscheiden nicht direkt darüber, ob eine Seite indexiert wird, sie beeinflussen aber, wie Google den Inhalt einordnet und ob er für bestimmte Suchergebnis-Darstellungen infrage kommt. Fehlerhaftes Schema-Markup blockiert eine Indexierung also normalerweise nicht, kann aber ein Symptom größerer technischer Probleme sein.

Problematisch wird es, wenn strukturierte Daten im Widerspruch zum sichtbaren Seiteninhalt stehen, etwa wenn ein Schema-Markup einen Produktpreis oder eine Bewertung nennt, die im Text nicht vorkommt. Das führt nicht zwingend zu einem Indexierungsausschluss, kann aber Qualitätsbewertungen negativ beeinflussen und damit indirekt den Zustand „gecrawlt, aber nicht indexiert“ begünstigen.

Wichtiger für die reine Indexierbarkeit ist, ob das Schema-Markup technisch korrekt eingebunden ist und ob ein fehlerhaft konfiguriertes CMS-Plugin zusätzlich zum Schema-Markup versehentlich noindex- oder Canonical-Tags ausgibt. Eine saubere Trennung zwischen struktureller Auszeichnung und Indexierungssteuerung ist deshalb Teil jeder gründlichen technischen Prüfung, auch wenn Schema-Markup selten die Hauptursache für eine blockierte Indexierung ist.

Technische Ursache oder Content-Qualitätsproblem: Wie Sie unterscheiden

Nicht jede fehlende Indexierung hat eine technische Ursache. Google indexiert aus Qualitäts- oder Relevanzgründen bewusst nicht jede crawlbare Seite, besonders bei dünnen, stark duplizierten oder wenig differenzierten Inhalten. Diese Unterscheidung ist entscheidend, weil die Behebung völlig unterschiedlich aussieht.

Ein verlässliches Indiz ist der bereits erwähnte Status „Gecrawlt – zurzeit nicht indexiert“. Zeigt das URL-Prüftool diesen Zustand, und sind robots.txt, noindex, Statuscodes und Canonical-Tag nachweislich korrekt, liegt die Ursache meist beim Inhalt selbst. Häufige Muster sind nahezu identische Seiten zu ähnlichen Themen, sehr kurze Texte ohne eigenständigen Mehrwert oder automatisiert generierte Seiten in großer Zahl.

Der entscheidende Praxistipp: Bei technischen Ursachen hilft eine erneute Indexierungsanfrage nach der Korrektur zuverlässig. Bei Qualitätsproblemen bringt dieselbe Anfrage ohne inhaltliche Überarbeitung in der Regel nichts, wie Beobachtungen zu Crawling-Entscheidungen bei Qualitätsfragen zeigen. Wer wiederholt Indexierungsanfragen für dieselbe URL stellt, ohne den Inhalt zu verändern, verschwendet damit eher Zeit, als das Problem zu lösen.

Häufige Fallstricke aus langjähriger Sichtbarkeitsarbeit

In unserer forensischen Praxis beobachten wir immer wieder denselben Fall: Eine einzige, unbeabsichtigte Änderung an der robots.txt im Rahmen eines Relaunchs sperrt plötzlich ganze Verzeichnisse, und niemand bemerkt es, bis Rankings und Sichtbarkeit sichtbar einbrechen. Verschwinden viele URLs gleichzeitig aus dem Index, lohnt sich deshalb immer eine forensische Betrachtung statt einer isolierten Einzelseitenprüfung, denn die Ursache liegt fast nie bei einer einzelnen Seite. Genau diese Erfahrung fließt in unsere eigenen Prüfstandards nach DIN SPEC 33461 ein.

Wann sich externe Unterstützung bei Indexierungsproblemen lohnt

Nicht jede Indexierungsprüfung lässt sich nebenbei erledigen, besonders wenn viele URLs gleichzeitig betroffen sind oder die Ursache trotz Checkliste unklar bleibt. Für solche Fälle bieten wir gezielte Leistungen an:

• Ein Technisches Audit deckt robots.txt-, Header- und Canonical-Fehler systematisch auf.
• Ein Forensisches Audit eignet sich, wenn viele Seiten plötzlich und ohne erkennbaren Auslöser aus dem Index fallen.
• Unser Monitoring über mehrere Antwortsysteme unterstützt Sie dabei, die Sichtbarkeit im Blick zu behalten.

Wenn interne Ressourcen fehlen oder der Verlust zu groß ist, um ihn allein durch eine Checkliste zu lösen, lohnt sich ein Blick auf unsere Leistungen rund um technisches SEO.

FAQ

Quellen

• Bericht zur Seitenindexierung - Search Console-Hilfe
• X-Robots-Tag header - HTTP | MDN

Empfehlungen

• Indexierung - Begriffe aus SEO einfach erklärt
• IndexNow - Begriffe aus SEO einfach erklärt
• 8 typische Fehler bei der Suchmaschinenoptimierung
• Tipps für Google Mobile First Mobile Only Index