WordPress „Suchmaschinen davon abraten“: Was die Einstellung ändert

Die Checkbox „Suchmaschinen davon abraten, diese Website zu indexieren“ (im englischen WordPress „Discourage search engines from indexing this site“) setzt auf jeder öffentlichen Seite der Website ein Robots-Meta-Tag mit noindex, nofollow. Google hält sich an dieses Tag: Jede Seite, die Google mit dem Tag erneut crawlt, verschwindet aus den Suchergebnissen, und neue Seiten kommen nicht hinzu. Auf einer privaten Staging-Kopie ist das genau das gewünschte Ergebnis. Auf einer Live-Website, die bei Google gefunden werden soll, entfernen Sie das Häkchen sofort: Es nimmt die ganze Website Crawl für Crawl aus Google heraus, während sich für Besucher nichts sichtbar ändert.

Was die Einstellung im aktuellen WordPress ausgibt

Die Checkbox finden Sie unter Einstellungen → Lesen in der Zeile „Sichtbarkeit für Suchmaschinen“, und der WordPress-Installer bietet dieselbe Checkbox auf seinem Einrichtungsbildschirm an. Sie speichert einen einzigen Wert in der Datenbank: die Option blog_public, 0 bei gesetztem Häkchen und 1 ohne Häkchen. Was dieser Wert verändert, haben wir im Oktober 2026 am Quellcode des WordPress-Cores geprüft, als die aktuelle Version 7.1.3 war:

• Jede Frontend-Seite erhält ein Robots-Meta-Tag. Die Standardausgabe des Themes im Head enthält diese Zeile:

<meta name='robots' content='noindex, nofollow' />

• Die eingebaute XML-Sitemap wird abgeschaltet. Die Core-Sitemap unter /wp-sitemap.xml liefert einen 404, und die Zeile Sitemap: verschwindet aus der robots.txt, die WordPress erzeugt.
• Die robots.txt sperrt nichts Neues. Die erzeugte Datei behält ihr übliches Disallow für den Admin-Bereich und Allow für admin-ajax.php.
• Es wird kein HTTP-Header hinzugefügt. Der Core sendet für diese Einstellung keinen X-Robots-Tag-Header; das Signal steht also nur im HTML.
• Die Website bleibt öffentlich. Unter der Checkbox steht: „Es ist Sache der Suchmaschinen, dieser Bitte nachzukommen.“ Besucher und jeder Crawler, der Robots-Meta-Tags ignoriert, können weiterhin jede Seite lesen.
• Administratoren erhalten einen einzigen Hinweis. Das Dashboard-Widget „Auf einen Blick“ zeigt die Zeile „Suchmaschinen abgewiesen“, solange das Häkchen gesetzt ist.

Ist Ihr Dashboard auf Spanisch eingestellt, hängt der Wortlaut vom Gebietsschema ab. Das WordPress-Übersetzungsprojekt, geprüft im Oktober 2026, übersetzt die Beschriftung für Mexiko, Argentinien, Kolumbien und mehrere andere lateinamerikanische Gebietsschemata mit „Disuade a los motores de búsqueda de indexar este sitio“ und für das Spanisch Spaniens mit „Pedir a los motores de búsqueda que no indexen este sitio“. In den meisten spanischen Gebietsschemata heißt die Zeile „Visibilidad en los motores de búsqueda“ auf dem Bildschirm „Ajustes de lectura“, und in allen lautet die Dashboard-Zeile „Motores de búsqueda disuadidos“.

Wie sich das Verhalten der Einstellung über die WordPress-Versionen verändert hat

Ratschläge für ältere Versionen kursieren weiterhin und beschreiben einen anderen Mechanismus. Der Core-Quellcode zeigt 3 Phasen:

Die Änderung in 5.3 ist die wichtigste. Davor wies die erzeugte robots.txt jeden Crawler an, die ganze Website zu meiden, sodass Google die Seiten nicht abrief und ihr noindex-Tag nie sah. URLs, auf die andere Websites verlinkten, konnten im Google-Index bleiben, ohne gecrawlt zu werden; die Search Console meldet das als „Indexiert, obwohl durch robots.txt-Datei blockiert“, und die Seite zu diesem Status erklärt den Konflikt. Seit 5.3 lässt die Checkbox die robots.txt unangetastet und stützt sich allein auf das Meta-Tag. Auf einer aktuellen Website stammt ein Disallow: / aus einer physischen robots.txt-Datei, einem Plugin oder vom Hoster, nie von dieser Checkbox.

Warum die Einstellung auf einer Live-Website landet

Der übliche Ablauf: eine Staging-Website, die korrekt verborgen war, und danach ein Launch, bei dem ihre Datenbank kopiert wird. Migrations-Plugins, die „Push to live“-Werkzeuge eines Hosters und ein manueller Export und Import übertragen alle die Optionstabelle, und blog_public reist mit. Die einzige sichtbare Änderung ist eine Zeile im Head der Seite, die kein Besucher liest.

sequenceDiagram
    participant S as Staging-Website
    participant P as Produktiv-Website
    participant G as Googlebot
    S->>S: Häkchen gesetzt, blog_public ist 0
    S->>P: Datenbank beim Launch kopiert
    P->>P: blog_public ist weiterhin 0
    G->>P: Crawlt Startseite und Beiträge erneut
    P-->>G: HTML mit noindex, nofollow
    G->>G: Entfernt jede erneut gecrawlte Seite aus den Ergebnissen

Von 45 externen Websites, die SEOReport zwischen Mai und Oktober 2026 geprüft hat, lieferte keine eine Startseite mit einer noindex-Anweisung aus, weder im HTML noch in einem X-Robots-Tag-Header. Eine Stichprobe dieser Größe kann nicht sagen, wie häufig der Fehler ist, nur dass er keine Routine ist. Wenn er auftritt, betrifft er alle öffentlichen Seiten auf einmal, und deshalb gehört er auf jede Launch-Checkliste.

So prüfen Sie die Einstellung von außerhalb des Dashboards

Entscheidend ist das HTML, das ein abgemeldeter Besucher nach jedem Seiten-Cache und CDN erhält, denn genau das ruft Google ab. Ersetzen Sie example.com durch Ihre Domain und wiederholen Sie die ersten 2 Befehle neben der Startseite auch für 2 oder 3 Beiträge. Die Option -L folgt Weiterleitungen, sodass eine Weiterleitung von der Domain ohne www auf www oder auf HTTPS die endgültige Seite nicht verdeckt.

# 1. The robots meta tag in the served HTML
curl -sL https://example.com/ | grep -io "<meta[^>]*name=.robots[^>]*>"

# 2. Any noindex sent as an HTTP header instead
curl -sL -o /dev/null -D - https://example.com/ | grep -i "x-robots-tag"

# 3. What robots.txt actually serves
curl -sL https://example.com/robots.txt

# 4. Whether the core sitemap is switched off
curl -sL -o /dev/null -w "%{http_code}\n" https://example.com/wp-sitemap.xml

Ein noindex im ersten Ergebnis zusammen mit einem 404 aus dem vierten passt zu der Einstellung. Ein SEO-Plugin kann die Core-Sitemap durch eine eigene ersetzen, ein 404 allein beweist also nichts. Ein noindex im zweiten Ergebnis ist eine Header-Regel von Server, Hoster, CDN oder einem Plugin, und die Checkbox kann sie nicht entfernen.

Innerhalb von WordPress ist die Zeile „Suchmaschinen abgewiesen“ im Dashboard die schnellste Bestätigung. Mit Kommandozeilenzugriff gibt wp option get blog_public bei gesetztem Häkchen 0 und ohne Häkchen 1 aus.

flowchart TD
    A["Enthält das Live-HTML ein Robots-Meta-noindex?"] -->|ja| B["Ist blog_public 0?"]
    A -->|nein| C["Enthält ein X-Robots-Tag-Header noindex?"]
    C -->|ja| D["Regel auf Server, beim Hoster oder im CDN entfernen"]
    C -->|nein| E["Live-Seite ist indexierbar: erneutes Crawling anfordern"]
    B -->|ja| F["Häkchen entfernen und Caches leeren"]
    B -->|nein| G["Ein Plugin oder Theme setzt noindex: dessen Einstellungen prüfen"]
    F --> H["Live-HTML auf Startseite und Beiträgen sauber?"]
    G --> H
    H -->|nein| I["Ein Cache liefert noch altes HTML: leeren"]
    I --> H
    H -->|ja| J["Live-Test in der URL-Prüfung, dann „Fehlerbehebung überprüfen“"]

Wie die Einstellung in der Search Console erscheint

Sobald Google Seiten erneut crawlt und das Tag findet, wandern sie im Bericht zur Seitenindexierung auf die Seite „Nicht indexiert“, mit dem Grund URL als „noindex“ markiert. Googles Dokumentation zum Bericht zur Seitenindexierung, geprüft im Oktober 2026, sagt, dass die Seite nicht indexiert wurde, weil Google beim Indexierungsversuch eine noindex-Anweisung gefunden hat. Die Verschiebung geschieht nach und nach, weil Google Seiten zu unterschiedlichen Zeiten erneut crawlt. Unser Leitfaden zum Status URL als „noindex“ markiert behandelt die anderen Ursachen dieses Status und wann er beabsichtigt ist.

Die URL-Prüfung zeigt beide Seiten. Die Standardansicht beschreibt die Version, die Google zuletzt indexiert hat, und ihr Feld „Indexierung zulässig?“ gibt an, ob diese Version die Indexierung untersagt hat. „Live-URL testen“ ruft die Seite in ihrem jetzigen Zustand ab. Nach einem Fix zählt der Live-Test; die indexierte Ansicht ändert sich erst, wenn Google erneut crawlt.

Eine Website, die von Tag 1 an mit gesetztem Häkchen gestartet ist, zeigt im Bericht unter Umständen nur sehr wenige URLs. Die Core-Sitemap ist abgeschaltet, und nofollow bittet Google, den Links auf jeder Seite nicht zu folgen, sodass Google kaum etwas hat, wovon aus es Seiten entdecken kann.

Plugins und Server-Regeln, die das Bild verändern

SEO-Plugins verwalten das Robots-Tag selbst. Wir haben im Oktober 2026 den Quellcode von 2 weit verbreiteten Plugins gelesen, Yoast SEO und Rank Math: Beide erzwingen weiterhin noindex, solange das Häkchen gesetzt ist, und beide zeigen im Admin-Bereich eine Warnung. Ist eines dieser Plugins aktiv, bleibt das Entfernen des Häkchens der Fix.

Dieselben Plugins können auch nach dem Entfernen des Häkchens ein noindex beibehalten, über ihre eigenen Einstellungen für einzelne Beiträge, Inhaltstypen oder Archive. Jedes andere Plugin und jedes Theme kann über denselben WordPress-Robots-Filter Anweisungen hinzufügen, etwa ein Coming-soon- oder Wartungsmodus-Plugin, das nach dem Launch aktiv geblieben ist. Zeigt das Live-HTML weiterhin noindex, obwohl blog_public auf 1 steht, sollten Sie dort nachsehen.

2 weitere Überbleibsel stammen aus dem Staging. Eine physische robots.txt-Datei mit Disallow: / hat Vorrang vor der erzeugten. Lesen Sie die Live-Datei nach dem Launch also erneut, besonders wenn Sie robots.txt-Regeln über ein Plugin gespeichert haben, während die Website verborgen war. Eine Header-Regel, die X-Robots-Tag: noindex hinzufügt, wirkt wie das Meta-Tag, erscheint aber nie im Seitenquelltext; deshalb liest die Prüfung von außen beides. Unser Leitfaden zu robots.txt und Crawl-Zugriff zeigt, wie Sie die Datei Zeile für Zeile lesen.

So erholt sich die Website, und wie lange es dauert

1. Entfernen Sie das Häkchen und speichern Sie, oder führen Sie wp option update blog_public 1 aus.
2. Leeren Sie jede Cache-Ebene: das Seiten-Cache-Plugin, den Cache des Hosters und das CDN. Eine zwischengespeicherte Seite liefert den alten Head aus, bis sie abläuft.
3. Wiederholen Sie die Prüfung von außen auf der Startseite und einigen Beiträgen und bestätigen Sie, dass /wp-sitemap.xml oder die Sitemap Ihres Plugins jetzt mit 200 antwortet.
4. Reichen Sie die Sitemap im Sitemaps-Bericht der Search Console ein, damit Google eine vollständige Liste der erneut zu crawlenden URLs hat. Unser Leitfaden zu XML-Sitemaps erklärt, was eine saubere Sitemap enthalten sollte.
5. Führen Sie in der URL-Prüfung einen Live-Test für die Startseite und Ihre wichtigsten Seiten aus und nutzen Sie dann „Indexierung beantragen“ für diese Handvoll. Das Tool hat ein Kontingent für einzelne URLs, und laut Googles Dokumentation beschleunigen wiederholte Anträge für dieselbe URL das Crawling nicht.
6. Öffnen Sie URL als „noindex“ markiert im Bericht zur Seitenindexierung und wählen Sie „Fehlerbehebung überprüfen“.

Dann heißt es warten. Googles Dokumentation zum erneuten Crawlen, geprüft im Oktober 2026, sagt, dass das Crawling zwischen einigen Tagen und einigen Wochen dauern kann, und die noindex-Dokumentation merkt an, dass ein erneuter Besuch bei manchen Seiten Monate dauern kann. Laut der Dokumentation zum Bericht zur Seitenindexierung dauert die Validierung in der Regel bis zu etwa 2 Wochen und in manchen Fällen deutlich länger. Die Indexierung selbst bleibt Googles Entscheidung: Die Dokumentation zur URL-Prüfung hält fest, dass ein Antrag nicht garantiert, dass eine Seite im Index erscheint.

So verhindern Sie es beim nächsten Launch

Schützen Sie das Staging mit einem Passwort, per HTTP-Authentifizierung auf dem Server oder beim Hoster, statt sich auf die Checkbox zu verlassen. Eine Anmeldung hält jeden Besucher und jeden Crawler fern. Lassen Sie die Checkbox auf der passwortgeschützten Kopie leer: Google kann eine Seite hinter einer Anmeldung nicht lesen, das Häkchen bringt dort also nichts, und eine in die Produktion kopierte Datenbank nimmt dann kein noindex mit. Ergänzen Sie anschließend Ihre Launch-Checkliste um eine Zeile: die Prüfung von außen auf der Produktivdomain nach dem Go-live und nach jeder Datenbankmigration oder -wiederherstellung.

Eine vollständige SEOReport-Diagnose liest das Robots-Meta-Tag und den X-Robots-Tag-Header Ihrer Startseite sowie das Robots-Meta-Tag der Seiten, die Ihre Sitemap listet, und nennt jede Seite, die Suchmaschinen anweist, sie nicht zu indexieren. Ein noindex auf der Startseite, das diese Einstellung immer erzeugt, wird als kritischer Befund gemeldet; die Einstellung wird also auch dann erkannt, wenn sie zusätzlich die Sitemap abgeschaltet hat. Für eine Website, die oft den Besitzer oder das Hosting wechselt, prüft das wöchentliche Monitoring, eingerichtet über die REST API, die Website erneut und benachrichtigt Sie per E-Mail, wenn ein neuer kritischer Befund auftaucht. Das größere Muster von Websites, die ihre eigenen Seiten verbergen, behandeln unsere Daten zu Indexierbarkeitskonflikten und der Leitfaden zur Indexierbarkeit von Seiten.

Häufige Fragen

Sperrt die Einstellung KI-Crawler aus?

Nein. Sie fügt keine robots.txt-Regeln hinzu, und in der robots.txt wird der Zugriff für KI-Crawler üblicherweise gesteuert. Googles eigene KI-Funktionen erreicht sie allerdings: Googles Dokumentation zu KI-Funktionen, geprüft im Oktober 2026, sagt, dass eine Seite indexiert sein muss, um als unterstützender Link in AI Overviews oder im KI-Modus zu erscheinen; eine Seite mit noindex fällt also auch dort heraus. Betrachten Sie die Checkbox als Bitte zur Suchindexierung, nicht als KI-Richtlinie. Unsere Entscheidungstabelle für KI-Crawler in der robots.txt zeigt, wie Sie eine solche Richtlinie bewusst festlegen.

Ich habe das Häkchen vor Wochen entfernt, und Seiten zeigen weiterhin URL als „noindex“ markiert. Warum?

Die Search Console meldet, was Google beim letzten Crawl jeder Seite gesehen hat. Führen Sie zuerst „Live-URL testen“ aus: Findet der Live-Test weiterhin ein noindex, liefert ein Cache, ein Plugin oder eine Header-Regel es aus. Ist der Live-Test sauber, wartet die Seite auf ein erneutes Crawling, und „Fehlerbehebung überprüfen“ zusammen mit einer eingereichten Sitemap ist der richtige nächste Schritt.

Kann ich das Häkchen gefahrlos setzen, während ich eine Live-Website neu gestalte?

Nein. Die Einstellung gilt für die Live-Website, und jede Seite, die Google während der Neugestaltung erneut crawlt, fällt aus den Ergebnissen. Bauen Sie die Neugestaltung stattdessen auf einer passwortgeschützten Staging-Kopie.