Indexierbarkeitskonflikte: Wenn Ihre eigene Website Google aussperrt

Jede Prüfung, die wir durchführen, stellt eine scharfe Frage zu den Seiten, die eine Site als wichtig erklärt — die Startseite plus die URLs, die ihre eigene Sitemap auflistet: können Suchmaschinen sie wie angegeben indexieren? Zwischen Mai 5 und August 15, 2026, 21 von 49 geprüften Sites haben diese Frage nicht bestanden. Das ist 42.9% der Stichprobe, die Crawlern sagt, Seiten zu überspringen, die jemand mit Aufwand veröffentlicht, verlinkt und gelistet hat. Die Fehler teilen ein gemeinsames Merkmal: jede dieser Sites funktioniert perfekt für Menschen. Seiten werden gerendert, Links werden aufgelöst, nichts im Browser deutet darauf hin, dass eine Direktive darunter Suchmaschinen wegschickt. Indexierbarkeitskonflikte sind die selbstverschuldeteste Kategorie in unseren Daten — kein Konkurrent hat sie verursacht, kein Algorithmus-Update hat sie ausgelöst, und niemand im Team kann sie sehen, ohne die Site wie ein Bot abzurufen.

Der Datensatz

Methodik: aktueller abgeschlossener Audit-Snapshot pro Domain aus unserem aktuellen Checkset, Mai 5 – August 15, 2026 — 49 geprüfte Seiten, anonymisiert. Die Check-Denominator variieren von 46 bis 49, weil ein Check nur ausgeführt wird, wenn seine Eingaben vorhanden sind — eine Seite ohne erreichbaren Sitemap liefert keine Sitemap-Seiten-Verteidigungen. Die Stichprobe ist selbstausgewählt — Eigentümer, die ein Audit durchgeführt haben — und verzerrt sich auf kleine bis mittelgroße, daher sollten die Raten als richtungsweisend für diesen Abschnitt betrachtet werden.

Weiterleitungen und Canonicals verursachen mehr Fehler als noindex

Die Lücke zwischen den ersten 2 Zeilen ist die Feststellung. Der Indexierbarkeit-Check schlägt eine Seite aus 4 Gründen fehl: blockiert durch robots.txt, trägt eine noindex-Direktive, leitet zu einer anderen URL weiter, oder deklariert einen Canonical, der woanders hinweist. Der noindex-spezifische Check schlug 7 Seiten fehl — was bedeutet, dass auf den meisten der 21 fehlerhaften Seiten die nicht-indexierbaren Seiten überhaupt kein noindex tragen. Sie leiten von dem URL ab, den die Sitemap versprochen hat, oder sie sagen Google ihr Canonical befindet sich an einer anderen Adresse. Diese Verteilung ist wichtig, weil Teams nach dem falschen Schuldigen suchen. Das Wort, das jeder kennt, ist noindex, also wird genau das nachgeschlagen — und es kommt sauber zurück. Der eigentliche Konflikt ist meist strukturell: eine Sitemap, die aus der CMS-Datenbank generiert wurde, während die Live-URLs zu einem neuen Pfadschema migriert wurden, oder ein Canonical-Tag, der auf eine URL Variante zeigt, die keine Seite tatsächlich bedient. Der Check ist vorsichtig bei dem, was zählt. Er entschuldigt die Weiterleitung, die richtige Infrastruktur ist — ein nacktes Domain-Hopping zu seiner www-Variante — und überspringt Utility-Pfade wie /login und /signup, die kein noindex tragen sollten. Die 21 Fehler sind das, was übrig bleibt, nachdem die harmlosen Fälle entfernt wurden.

Die 4 Konfliktmuster in den Daten

Die Staging-noindex, die ausgeliefert wurde. 7 Seiten listen Seiten in ihrer Sitemap auf, die eine noindex-Direktive tragen — im Meta-Robots-Tag oder im X-Robots-Tag-Antwortheader. Das ist der klassische Launch-Überrest: die Direktive, die die Staging-Umgebung korrekt versteckte, gelangt in die Produktion innerhalb einer Vorlage, einer Plugin-Einstellung oder eines Plattform-Toggles. WordPress' „Suchmaschinen davon abhalten, diese Seite zu indexieren“ Kontrollkästchen ist das kanonische Beispiel — 1 Einstellung, sitewide noindex, nichts Sichtbares anderes. robots.txt schreit über alles. 3 Seiten liefern ein robots.txt mit Disallow: / für alle Bots — das sitewide Go-Away-Signal — und 5 scheitern am breiteren Konsistenz-Check, bei dem robots.txt-Blockierung oder ein Homepage-noindex dem offensichtlichen Ziel, zu ranken, widerspricht. Die subtile Falle in diesem Muster: robots.txt und noindex erledigen gegensätzliche Aufgaben, und ihre Kombination hebt die stärkere auf. Eine Seite, die durch robots.txt blockiert ist, kann nicht gecrawlt werden, daher wird ein noindex, das darauf gesetzt wurde, nie gelesen — was dazu führt, dass URLs im Zustand „Indexiert, obwohl durch robots.txt blockiert“ enden, vorhanden in den Ergebnissen als ein roher Link Google war verboten zu holen. Canonical-Kontraste. Ein Canonical-Tag, der auf ein Ziel zeigt, das selbst noindex trägt, gibt Google 2 Anweisungen, die nicht beide erfüllt werden können: Signale in diese Seite konsolidieren und diese Seite aus dem Index ausschließen. Unser Engine löst jedes Canonical-Ziel auf und schlägt das Audit fehl, wenn das Ziel noindexiert, weitergeleitet oder sich weigert, sich selbst als Canonical zu deklarieren. Die gleiche Widersprüchlichkeit erscheint in 1-Seiten-Form, wenn eine Seite sowohl noindex als auch ein Canonical zu woanders trägt — fordert Google auf, Autorität durch eine Seite zu übertragen, die sie vergessen soll. Die Sitemap, die das fördert, was Direktiven verbieten. Eine Sitemap ist eine maschinenlesbare Behauptung, dass jeder URL darin eine Indexierung verdient. Das Auflisten eines URL, den robots.txt blockiert oder eine Direktive noindexiert, lässt die Seite mit sich selbst streiten, und der Streit kostet Crawl-Budget bei jedem Zyklus. Wir haben dieses Muster selbst in unserem Sitemap-Hygiene-Bericht gemessen [/articles/xml-sitemap-hygiene-audit-data].

Lösen Sie Konflikte in dieser Reihenfolge: Absicht, dann 1 Mechanismus, dann Beweis

Indexierbarkeitskonflikte bleiben bestehen, weil Korrekturen Signal für Signal angewendet werden — jemand patcht hier ein noindex, bearbeitet dort robots.txt — ohne dass jemand entscheidet, wofür jede Seitenklasse tatsächlich ist. Die dauerhafte Lösung läuft in 1 Richtung.

Rangierbarer Inhalt, doppelte Varianten, private Hilfeseiten und unendliche Parameterbereiche erhalten jeweils 1 Absicht — bevor jemand eine Konfigurationsdatei bearbeitet. 1. Absicht pro Seitenklasse entscheiden. 2. Jede Absicht durch genau 1 Mechanismus ausdrücken.

• Rang: in der Sitemap aufgeführt, kanonisch auf sich selbst verweisend, keine robots-Direktiven überhaupt.
• Duplikate konsolidieren: <link rel="canonical" href="https://example.com/primary/" /> auf der Variante, die crawlbar bleibt und die Sitemap verlässt. Kanonische Seiten sind ein Hinweis — Googles eigene Dokumentation sagt, dass sie einen anderen kanonischen Link wählen kann, wenn andere Signale widersprechen, was genau der Grund ist, warum das Ziel sauber sein muss: indexierbar, 200, selbst-kanonisch.
• Aus den Ergebnissen ausschließen: ein noindex meta robots Tag in der Seite, oder der X-Robots-Tag: noindex Response-Header für PDFs und andere nicht-HTML Antworten. Die Seite muss crawlbar bleiben — eine Direktive hinter einem robots.txt-Block ist eine Direktive, die nicht existiert.
• Speichere Crawl-Budget: Disallow: /search/ unter User-agent: * in robots.txt, reserviert für Bereiche mit unbegrenzten URLs. robots.txt steuert das Crawlen, niemals das Indexieren — es entfernt nichts, was bereits indexiert ist.

Pro Plattform ist die Noindex-Absicht 1 Zeile: robots: { index: false } im Metadata-Export einer Next.js-Route, das „Suchmaschinen-Visibility“-Toggle in WordPress – absichtlich pro Umgebung aktiviert, niemals von Staging geerbt – oder add_header X-Robots-Tag "noindex" always; auf einen Standortblock in nginx beschränkt. Der Browser beweist hier nichts; hole die Daten so, wie es Crawler tun: 3. Verifiziere als Bot, pro Seitentyp.

curl -sI -A "Googlebot" https://example.com/page/ | grep -i "x-robots-tag\|location"
curl -s -A "Googlebot" https://example.com/page/ | grep -i "robots\|canonical"

1 Vertreter URL pro Seitentyp reicht aus, geprüft gegen die Absicht, die du in Schritt 1 festgelegt hast. Die Inspektion von Search Console URL liefert die autoritative zweite Meinung, einschließlich welcher kanonische Google tatsächlich gewählt wurde. Unser Audit führt die komplette Schleife bei jedem Bericht aus — robots.txt gegen Sitemap-Mitgliedschaft, Direktiven gegen Kanonische, kanonische Ziele aufgelöst und verifiziert — und der kostenlose Bericht listet jedes widersprüchliche Paar mit der Seite, auf der es gefunden wurde. Die 42.9%-Fehlerrate setzt Indexierbarkeitskonflikte unter die häufigsten schwerwiegenden Befunde in unseren Daten, im selben Rang wie die Header-Lücken aus unserer Rangliste der am häufigsten fehlgeschlagenen Prüfungen — mit einer härteren Konsequenz, da eine blockierte Seite nichts verdient, egal wie gut sie ist. Die Seiten, die bestehen, sind die, bei denen die Indexierungsabsicht einmal entschieden, in 1-Mechanismus pro Seitentyp festgehalten und wie ein Crawler geprüft wurde. Alles über diese Fehlkategorie steht unter der Kontrolle des Seiteninhabers — was sie zur am leichtesten zu behebenden 42.9% im Datensatz macht.