robots.txt und noindex: Widersprüche erkennen und richtig auflösen

Zuerst festlegen, was mit der URL geschehen soll

Beginnen Sie mit einer konkreten Entscheidung: Soll die Seite öffentlich auffindbar sein, öffentlich erreichbar bleiben und aus Google verschwinden oder ausschließlich berechtigten Personen zugänglich sein? Schreiben Sie dieses Ziel vor der technischen Prüfung auf. Sonst wird eine absichtliche Ausschlussregel schnell als Fehler behandelt oder ein echter Fehler vorschnell als Schutzmaßnahme verteidigt.

Google erklärt in seiner Einführung zu robots.txt, dass eine gesperrte Webseiten-URL über andere Verweise bekannt werden und weiterhin als Treffer erscheinen kann. Ein Disallow-Eintrag ist daher kein Beleg für eine erfolgreiche Entfernung. Er ersetzt auch keinen Zugriffsschutz: Ein Mensch oder ein Client, der die Datei nicht beachtet, kann eine ungeschützte Seite weiterhin abrufen.

Ein mögliches Arbeitsregister unterscheidet beispielsweise eine öffentliche Produktseite, eine öffentlich nutzbare Bestätigungsseite nach einer Anfrage und einen vertraulichen Kundenbereich. Das sind redaktionelle Beispielsituationen, keine festgestellten Probleme bei Transparion. Für jede Situation benötigen Sie eine verantwortliche Person und ein prüfbares Soll-Ergebnis; ein einziges „Bots erlaubt“-Feld reicht dafür nicht.

Drei Fundstellen prüfen, bevor Sie eine Regel ändern

Erfassen Sie die genaue URL mit Protokoll, Host, Pfad und gegebenenfalls Parametern. Notieren Sie bei Weiterleitungen auch das endgültige Ziel. Speichern Sie anschließend die zugehörige robots.txt, die vollständigen Antwort-Header einer GET-Anfrage und das ausgelieferte HTML. Eine CMS-Einstellung oder ein Blick in den sichtbaren Seitentext ersetzt diese Antwortbelege nicht.

Für robots.txt zählt der passende Geltungsbereich: Eine Datei auf einem anderen Host, Port oder Protokoll ist nicht automatisch zuständig. Googles Spezifikation unterscheidet außerdem die Auswahl der passenden User-Agent-Gruppe von der Auswahl einer Pfadregel. Prüfen Sie deshalb nicht nur, ob irgendwo „Allow“ steht, sondern welche Gruppe und welcher Pfad tatsächlich passen.

Im HTML suchen Sie sämtliche einschlägigen Meta-Tags, insbesondere name="robots" und name="googlebot". In den Antwort-Headern erfassen Sie alle X-Robots-Tag-Werte. Halten Sie die Fundstellen getrennt fest. So bleibt sichtbar, ob die Anweisung aus einer Seitenvorlage, einem Plugin, dem Webserver oder einer vorgeschalteten Auslieferungsschicht stammen könnte; eine bloße Vermutung über die Herkunft ist noch kein Befund.

Prüfen Sie eine öffentlich gedachte Seite zunächst ohne Anmeldung. Weichen ausgeliefertes HTML und gerenderter Zustand voneinander ab, gehört dieser Unterschied ins Protokoll. Der verlinkte Rendering-Leitfaden erklärt die nächste Prüfung. Ein selbst eingetragener Googlebot-Name in einem Testclient macht den Abruf nicht zu einem echten Google-Abruf.

Die Fallmatrix: Sechs Konfigurationen mit unterschiedlichen Folgen

Die folgenden Fälle beziehen sich auf erfolgreiche HTML-Antworten, ohne zusätzliche Sperren oder Sonderregeln wie indexifembedded. „Erlaubt“ meint hier ausschließlich die robots.txt-Konfiguration. Die tatsächliche Erreichbarkeit muss gesondert stimmen. Die Einordnung folgt Googles Dokumentation; andere Anbieter können Regeln anders behandeln.

Nutzen Sie die Fälle als Diagnosehilfe: Zuerst den beobachteten Zustand zuordnen, dann mit dem aufgeschriebenen Seitenziel vergleichen. Derselbe Zustand kann für eine Bestätigungsseite beabsichtigt und für eine Produktseite ein Fehler sein.

• Fall A – Abruf erlaubt, kein noindex: Damit stehen diese beiden Mechanismen dem Abruf und der Verarbeitung des Seiteninhalts nicht entgegen; eine Indexaufnahme ist damit nicht zugesagt.
• Fall B – Abruf erlaubt, noindex im HTML: Google kann die Ausschlussanweisung beim Crawlen lesen. Das passt zu öffentlich erreichbaren Inhalten, die nicht als Google-Treffer erscheinen sollen.
• Fall C – Abruf gesperrt, kein noindex: Die robots.txt steuert den Abruf. Daraus lässt sich keine sichere Entfernung einer bereits bekannten URL ableiten.
• Fall D – Abruf gesperrt, noindex im HTML: Der Ausschluss liegt hinter der Abrufsperre. Mehr Regeln ergeben hier keine stärkere Absicherung; das noindex ist bei einem verhinderten Abruf nicht neu lesbar.
• Fall E – Abruf erlaubt, index im HTML und noindex im HTTP-Header: Das freigebende HTML hebt die anwendbare restriktivere Header-Regel bei Google nicht auf. Wer nur den Seitenquelltext kontrolliert, übersieht die Ursache.
• Fall F – Abruf erlaubt, allgemeines index und Googlebot-spezifisches noindex im HTML: Für Googlebot bleibt die Ausschlussanweisung wirksam. Daraus folgt kein gleiches Ergebnis für sämtliche Suchmaschinen.

Warum „die strengste Regel gewinnt“ nicht überall passt

Google wendet bei widersprüchlichen anwendbaren Meta- und X-Robots-Tag-Anweisungen die restriktivere Regel an. Innerhalb der robots.txt gilt eine andere Auswahl: maßgeblich ist die spezifischste passende Pfadregel; bei gleich spezifischem Konflikt gewinnt die weniger einschränkende Regel. Auch die User-Agent-Gruppen werden nicht pauschal addiert: Die passendste Gruppe zählt, gleich spezifische Gruppen für denselben Crawler werden zusammengeführt.

Ein ausgedachtes Beispiel verdeutlicht die Pfadauswahl: Unter User-agent: * stehen Disallow: /archiv/ und Allow: /archiv/handbuch.html. Die längere passende Freigabe lässt den Abruf dieser Adresse nach Googles Regeln zu. Ob das Handbuch anschließend noindex sendet, ist eine zweite Prüfung. Behalten Sie diese beiden Entscheidungsschritte getrennt; sonst kann eine technisch korrekte Pfadausnahme irrtümlich als Indexfreigabe dokumentiert werden.

Praktisch hilft eine einfache Zuständigkeitsnotiz: „Pfadregel geprüft von …; HTML-Anweisungen geprüft von …; Header geprüft von …“. Sind mehrere Teams beteiligt, ergänzen Sie die jeweilige Konfigurationsquelle. Eine Änderung ist erst nachvollziehbar, wenn die verantwortliche Person zeigen kann, welche ausgelieferte Antwort sich dadurch verändert hat.

Wenn eine öffentliche Seite wieder auffindbar werden soll

Angenommen, eine neue Produktseite fällt in Fall E. Die Redaktion sieht im HTML index, im tatsächlichen HTTP-Header steht aber noch noindex. Sichern Sie beide Belege und prüfen Sie mit dem zuständigen Team, welche Konfiguration den Header setzt. Ein zusätzliches index-Tag würde den Widerspruch lediglich stehen lassen.

Unsere empfohlene Reihenfolge: Erst die unerwünschte Ausschlussquelle eingrenzen, dann die Änderung für genau den betroffenen Bereich vorbereiten und nach Freigabe ausliefern. Kontrollieren Sie anschließend dieselbe URL erneut einschließlich Headern, HTML und Weiterleitungen. Prüfen Sie außerdem eine benachbarte Seite, die bewusst ausgeschlossen bleiben soll. So wird aus dem Einzelfix keine unbeabsichtigte Freigabe eines ganzen Bereichs.

Ergänzen Sie im Änderungsprotokoll Zeitpunkt, verantwortliche Person, betroffene Vorlage oder Regel und die vorherige Fassung. Falls Zwischenspeicher beteiligt sind, dokumentieren Sie die tatsächlich erhaltene Antwort nach der Änderung. Maßgeblich für Ihre lokale Abnahme ist die beobachtete Auslieferung, nicht nur die Meldung „Konfiguration gespeichert“.

Widersprüche in internen Links, Sitemap oder Canonical-Zielen prüfen Sie anschließend passend zum Seitenziel. Der vorhandene Relaunch-Leitfaden behandelt diese URL-Zuordnung ausführlicher. Eine Korrektur an robots.txt oder noindex allein erklärt noch nicht jede fehlende Indexierung.

Wenn eine öffentliche Seite aus Google verschwinden soll

Für eine weiterhin öffentlich erreichbare HTML-Seite beschreibt Google noindex im Meta-Tag oder im X-Robots-Tag als unterstützten Weg. Eine noindex-Zeile in robots.txt wird von Google dagegen nicht unterstützt. Das Signal muss in der abrufbaren Antwort stehen; erst ein erneuter Abruf und die Verarbeitung können den geänderten Zustand berücksichtigen.

Bei Fall D prüfen Sie deshalb zuerst, ob der Inhalt tatsächlich öffentlich bleiben darf. Nur dann planen Sie, das noindex zuverlässig auszuliefern und die widersprechende Crawl-Sperre für den nötigen Abruf aufzuheben. Sperren Sie den Pfad nicht direkt nach einem erfolgreichen eigenen Test wieder: Ihr Abruf beweist nicht, dass Google die Änderung bereits gesehen hat. Auch später muss Google den aktuellen Ausschluss erneut prüfen können.

Für vertrauliche Inhalte ist dieses Vorgehen ungeeignet. Schützen oder entfernen Sie die Inhalte an ihrer Quelle; machen Sie sie nicht eigens öffentlich, damit ein Bot eine Anweisung lesen kann. Googles Entfernungshilfe unterscheidet dauerhafte Maßnahmen von einer beschleunigten vorübergehenden Ausblendung. Eine Ausblendung in Suchergebnissen beseitigt den Inhalt auf Ihrer Website nicht.

Führen Sie zwei getrennte Abnahmestände: „gewünschte Antwort technisch ausgeliefert“ und „Ausschluss durch Google beobachtet“. Bleibt der zweite Stand unbekannt, bleibt er unbekannt. Versprechen Sie weder eine feste Bearbeitungszeit noch eine sofortige Entfernung aus anderen Such- oder KI-Systemen.

Was wir an sechs lokalen Beispielen tatsächlich geprüft haben

Am 24. September 2026 haben wir die sechs Fälle auf einem eigens angelegten lokalen HTTP-Server ausgeführt. Eine robots.txt sperrte /blocked/; vier HTML-Seiten lagen unter /public/, zwei unter /blocked/. Der Testclient fragte die robots.txt und jede der sechs Seiten per GET ab. Die Belege enthalten die ausgelieferten HTML-Dateien, rekonstruierten HTTP-Antworten, Zeitangaben und Prüfsummen.

Alle sechs Seiten antworteten mit HTTP 200. Bei Fall D war das noindex im direkt abgerufenen HTML vorhanden, obwohl die robots.txt den Pfad sperrte. Bei Fall E enthielt die Antwort zugleich index,follow im HTML und noindex im Header. Bei Fall F standen allgemeine und Googlebot-spezifische Anweisungen nebeneinander. Insgesamt bestanden 56 Prüfungen der vorgesehenen Konfiguration und Auslieferung; anschließend wurde der Testserver beendet.

Diese Beobachtungen sind bewusst eng begrenzt. Unser Client hieß TransparionLocalFixture/1.0 und befolgte robots.txt nicht automatisch. Deshalb ist ein erfolgreicher Direktabruf einer gesperrten Beispielseite kein Widerspruch und kein Beweis für einen Crawlerfehler. Wir haben weder Googlebot aufgerufen noch eine Indexaufnahme, Entfernung, Rankingänderung oder reale Firewall-Freigabe gemessen.

Das Textprotokoll und das vollständige reproduzierbare Beispielpaket stehen bei den Quellen bereit. Die Google-Einordnung ist dort ausdrücklich von den gemessenen HTTP-Antworten getrennt. Sie können die Beispiele lokal nachvollziehen, ohne Einstellungen einer produktiven Website zu verändern.

Die Nachprüfung braucht zwei Zeitstände

Mit autorisiertem Zugriff auf Ihre Search-Console-Property vergleichen Sie nach einer Änderung die gespeicherte Indexansicht mit einem aktuellen URL-Livetest. Google beschreibt diese als unterschiedliche Zeitstände: Der Livetest untersucht die jetzige Erreichbarkeit, die Indexansicht beruht auf dem zuletzt verarbeiteten Zustand. Ein positives Live-Ergebnis garantiert keine Aufnahme in den Suchindex.

Notieren Sie für jede Ansicht Datum, untersuchte URL und Befund. Falls Sie keinen Property-Zugriff haben, dokumentieren Sie ausschließlich Ihre eigenen HTTP-Belege und lassen die Google-Nachprüfung offen. Für diesen Artikel wurden keine Search-Console-Daten erhoben; die beschriebene Nachprüfung ist ein nächster Arbeitsschritt, kein vorliegendes Ergebnis.

Ein brauchbarer Abschlussvermerk lautet beispielsweise: „Produktseite soll auffindbar sein. Unbeabsichtigtes Header-noindex in der Auslieferungskonfiguration entfernt. Kontrollabruf dokumentiert; Ausschluss der benachbarten Bestätigungsseite erhalten. Google-Indexstand noch nicht bestätigt.“ Dieser ausdrücklich illustrative Vermerk ist hilfreicher als „SEO repariert“, weil er Entscheidung, Eingriff und verbleibende Unsicherheit voneinander trennt.