WordPress-Seite nicht bei Google: Ein Haken, der die ganze Website unsichtbar macht

Wenn eine WordPress-Seite nicht mehr bei Google zu finden ist, gehört eine Prüfung an den Anfang: Steht die ganze Website auf noindex? Genau das war bei einer Seite der Fall, die wir uns ansehen sollten — jahrelang zuverlässig gefunden, dann weg. Kein Hack, kein Google-Update, keine Abstrafung. Die Ursache war ein einziges Kontrollkästchen in den WordPress-Einstellungen, gesetzt von jemandem, der nicht ahnen konnte, was es anrichtet. WordPress fragt nicht nach, warnt nicht und erwähnt mit keinem Wort, dass damit die Sichtbarkeit bei Google endet.

Kurz zusammengefasst:

• Ein Haken unter Einstellungen → Lesen nimmt die gesamte Website aus dem Google-Index — nicht eine Seite, alle.
• Der Absturz kommt verzögert und über Wochen verteilt, weil Google jede URL einzeln neu besuchen muss. Genau deshalb verbindet ihn niemand mit der Änderung.
• Im echten Fall: von rund 135 Keywords auf zwei, von 13 rankenden URLs auf eine — vier Jahre Aufbau in rund drei Monaten weg.
• Die Prüfung dauert zwei Minuten und braucht kein Werkzeug außer dem Browser.
• Das Zurückholen dauert länger als das Kaputtmachen — mit Rückenwind Wochen, nicht Tage.

Der Fall: aus 135 Keywords wurden zwei

Wir sollten uns eine Website anschauen, die „bei Google nicht mehr auftaucht“. Solche Sätze bedeuten meistens: ein paar Positionen verloren, ein Wettbewerber vorbeigezogen, eine Kernaktualisierung von Google. Hier war es anders. Der Sichtbarkeitsverlauf über fünf Jahre zeigt sofort, dass das kein Ranking-Thema ist:

Vier Jahre lang geht es aufwärts, mit den üblichen Dellen. Dann fällt die Kurve senkrecht. Ein solcher Verlauf hat keine inhaltliche Ursache. Wenn Wettbewerber besser werden, sieht das anders aus: Dann bröckelt es an den Rändern, einzelne Begriffe rutschen ab, die Kurve franst aus. Fällt dagegen alles gleichzeitig — auch die Begriffe, bei denen es gar keinen Wettbewerb gibt, etwa der eigene Firmenname —, dann ist die Seite nicht schlechter geworden. Dann ist sie weg.

Warum der Absturz nicht an einem Tag passiert

Der Blick auf die letzten zwölf Monate erklärt, warum so ein Fehler oft wochenlang unentdeckt bleibt:

Der Haken war zu einem Zeitpunkt gesetzt worden — der Effekt verteilt sich über rund zwölf Wochen. Das liegt daran, wie Google arbeitet: Die Anweisung „nimm diese Seite nicht in den Index“ steht im Quelltext jeder einzelnen Seite. Google erfährt davon erst, wenn der Crawler diese Seite das nächste Mal besucht. Häufig besuchte Seiten fliegen früh raus, selten besuchte Wochen später. Deshalb gibt es keinen Tag, an dem etwas passiert — und deshalb fällt der Verdacht nie auf die Änderung, die Wochen zurückliegt.

Auffällig ist außerdem die Reihenfolge: Zuerst dünnt die Breite aus (rote Kurve), die guten Positionen halten sich noch. Erst Ende März kippt auch die blaue Kurve. Wer nur auf die Top-10-Platzierungen schaut, hält den Vorgang die ersten sechs Wochen für ein Rauschen.

Der Beweis liegt nicht in den Positionen, sondern in den URLs

Endgültig klar wird die Sache bei der Frage, wie viele Seiten überhaupt noch ranken:

Das ist der entscheidende Unterschied, und er trennt die beiden möglichen Diagnosen sauber:

Beobachtung	Bedeutung
Positionen fallen, Anzahl der URLs bleibt	Ranking-Problem: Wettbewerb, Inhalte, Aktualität
Anzahl der URLs fällt, Positionen brechen mit	Indexierungsproblem: Die Seiten sind nicht schlechter, sie sind nicht mehr da

Wenn die zweite Zeile zutrifft, ist die Suche nach besseren Texten Zeitverschwendung. Was Sichtbarkeit überhaupt misst und warum sie mit Besucherzahlen nicht gleichzusetzen ist, haben wir in Sichtbarkeit bei Google erhöhen auseinandergenommen.

Die Ursache: ein Kontrollkästchen ohne Warnung

Gefunden war sie nach einem Blick ins Backend, unter Einstellungen → Lesen, ganz unten:

Zwischen der Anzahl der Beiträge pro Blogseite und dem Speichern-Knopf steht die folgenreichste Einstellung, die WordPress zu bieten hat — optisch gleichrangig mit der Frage, ob im Feed der ganze Text oder ein Auszug erscheint. Es gibt keinen Bestätigungsdialog, keine rote Markierung, keinen Hinweis, dass hier gerade das Marketingbudget von vier Jahren stillgelegt wird. Nach dem Speichern erscheint auch später nichts, was daran erinnert.

Der einzige Kommentar, den WordPress dazu abgibt, ist der Satz „Es ist Sache der Suchmaschinen, dieser Bitte nachzukommen.“ Das klingt nach Unverbindlichkeit und liest sich beruhigend. Google kommt dieser Bitte nach — zuverlässig. Auch die offizielle WordPress-Dokumentation zur Lesen-Seite erwähnt die Tragweite nur beiläufig.

Was der Haken technisch auslöst

WordPress speichert die Einstellung als Option blog_public = 0 und zieht daraus zwei Konsequenzen:

• In den Kopfbereich jeder Seite wandert <meta name="robots" content="noindex, nofollow">. Das ist die eindeutige Anweisung, die Seite nicht in den Index aufzunehmen — und den Links darauf nicht zu folgen.
• Die von WordPress erzeugte robots.txt wird auf Disallow: / umgestellt, sperrt also zusätzlich das Crawlen.

Beides wird gern verwechselt, obwohl es zwei verschiedene Dinge tut:

	noindex (Meta-Tag)	Disallow (robots.txt)
Verhindert	die Aufnahme in den Index	das Crawlen der Seite
Steht in	dem <head> jeder einzelnen Seite	einer zentralen Datei im Wurzelverzeichnis
Seite kann trotzdem in der Suche erscheinen	nein	ja — ohne Beschreibung, wenn andere darauf verlinken
Wirkt, sobald	Google die Seite abruft	Google das Abrufen plant

Die Kombination aus beidem ist schlimmer als jedes für sich. Was nicht gecrawlt werden darf, kann auch nicht erneut gelesen werden — Google erfährt also gar nicht, dass du den noindex-Hinweis inzwischen entfernt hast. Google beschreibt das in der Dokumentation zu noindex und zur robots.txt ausdrücklich als Fehlerquelle. Die Grundlagen stehen auch in unseren Glossareinträgen zu Indexierung und robots.txt.

Ein dritter Weg wird dabei gern übersehen: Die Anweisung kann auch als HTTP-Header X-Robots-Tag vom Server kommen. Dann steht sie nicht im Quelltext und ist nur in den Antwort-Headern sichtbar — ein Grund, warum manche Suche nach der Ursache ins Leere läuft.

noindex prüfen: in zwei Minuten zur Diagnose

Der Reihe nach, ohne Werkzeug:

1. Backend: Einstellungen → Lesen öffnen. Ist der Haken bei „Suchmaschinen davon abhalten…“ gesetzt? Dann bist du fertig mit der Fehlersuche.
2. Quelltext: Startseite aufrufen, Quelltext anzeigen (Strg+U), mit Strg+F nach noindex suchen. Ein Treffer im <head> genügt.
3. robots.txt: deine-domain.de/robots.txt aufrufen. Steht dort Disallow: /, ist die ganze Seite gesperrt.
4. Google fragen: site:deine-domain.de in die Suche eingeben. Kommen null oder auffällig wenige Ergebnisse, fehlen die Seiten tatsächlich im Index.
5. Search Console: unter Seiten → Warum Seiten nicht indexiert werden nach dem Eintrag „Durch ‚noindex‘-Tag ausgeschlossen“ sehen. Das ist der Nachweis mit Datum — und zeigt, wie viele URLs betroffen sind.

Punkt 5 ist der wertvollste, weil er nicht nur das Ob, sondern das Wann liefert. Wer keine Search Console eingerichtet hat, hat bei so einem Vorfall keine Chance, ihn früh zu bemerken — sie ist kostenlos und in zehn Minuten verbunden.

Wo der Haken herkommt — und warum niemand schuld sein muss

In unserem Fall ließ sich nicht mehr klären, wer ihn gesetzt hat. Das ist typisch. Die üblichen Wege:

Situation	Warum es passiert
Relaunch oder Neuaufbau	Während der Bauphase soll die halbfertige Seite nicht gefunden werden — völlig richtig. Beim Livegang wird der Haken vergessen. Der mit Abstand häufigste Fall.
Kopie einer Staging-Umgebung	Die Entwicklungsseite steht zu Recht auf noindex. Wird sie auf die Live-Domain kopiert, wandert die Einstellung mit.
Umzug oder Wiederherstellung	Ein Backup wird eingespielt, das aus einer Phase stammt, in der die Seite nicht öffentlich war.
Aufräumarbeiten im Backend	Jemand geht die Einstellungen durch, versteht die Formulierung als „Datenschutz“ und hakt sie in bester Absicht an.
SEO-Plugin statt Kernoption	Yoast, Rank Math und All in One SEO haben eigene noindex-Schalter — pro Seite, pro Beitragstyp, pro Archiv. Der Kern-Haken ist dann sauber und die Seite trotzdem ausgesperrt.

Beim Relaunch gehört die Kontrolle deshalb fest in die Startliste nach dem Livegang — sie steht bei uns in der Relaunch-Checkliste aus genau diesem Grund weit oben.

noindex entfernen — und dann?

Das Entfernen ist die Arbeit von Sekunden, die Erholung nicht. Sinnvolle Reihenfolge:

1. Haken entfernen und speichern. Danach im Quelltext gegenprüfen, dass noindex verschwunden ist — manche Caching-Plugins liefern noch minutenlang die alte Fassung aus.
2. robots.txt prüfen. Ist sie durch ein Plugin oder eine statische Datei überschrieben, muss das Disallow: / dort separat weg.
3. Sitemap neu einreichen in der Search Console. Das ist der schnellste Weg, Google die wichtigsten URLs wieder anzubieten.
4. Einzelne Schlüsselseiten manuell prüfen lassen („URL prüfen“ → „Indexierung beantragen“). Für Startseite und die drei bis fünf wichtigsten Seiten sinnvoll, für hundert Seiten nicht praktikabel.
5. Wöchentlich beobachten, statt täglich. Die Rückkehr verläuft so ungleichmäßig wie der Absturz.

Einzelne Seiten statt der ganzen Website

Der Haken unter Lesen ist der Holzhammer: alles oder nichts. Für einzelne Seiten gibt es den feineren Weg über das SEO-Plugin — bei Rank Math und Yoast pro Beitrag unter „Erweitert“ mit der Option, die Seite aus dem Index zu nehmen. Das ist auch der Grund, warum der Kern-Haken sauber sein kann und die Seite trotzdem nicht erscheint: Der Ausschluss steckt dann eine Ebene tiefer. Wer die Ursache sucht, muss beide Orte prüfen — und zusätzlich Wartungsmodus-, Staging- und Coming-Soon-Plugins, die ebenfalls noindex setzen.

Realistische Erwartung: Die Startseite ist oft nach Tagen zurück, die Breite braucht Wochen. Und sie kommt nicht garantiert vollständig zurück — Positionen, die in der Zwischenzeit ein Wettbewerber besetzt hat, sind erst einmal besetzt. Was in dieser Phase hilft und was nur beschäftigt, ist Teil unserer Arbeit im technischen SEO für WordPress.

Damit es nicht wieder passiert

Der Fehler ist nicht das Problem — dass er drei Monate unbemerkt blieb, ist das Problem. Drei Maßnahmen, die genau das verhindern:

• Search Console einrichten und die Benachrichtigungen anlassen. Google meldet einen Einbruch der indexierten Seiten von selbst — man muss die Mail nur bekommen und lesen.
• Nach jedem Livegang, Umzug und Backup-Einspielen dieselben zwei Minuten prüfen, die oben stehen. Kein Werkzeug nötig, keine Ausrede möglich.
• Regelmäßiger Blick von außen. In der WordPress-Wartung gehört die Indexierbarkeit zum festen Prüfumfang — zusammen mit Updates, Backups und Erreichbarkeit. Genau dafür ist der Turnus da: damit ein stiller Fehler höchstens Wochen alt wird, nicht Monate.

Und der vielleicht wirksamste Punkt: Wer im Backend arbeitet, sollte wissen, welche Schalter Folgen haben. Der Haken unter „Lesen“ ist das beste Beispiel dafür, dass WordPress harmlos aussehende Einstellungen ohne jede Rückfrage ausführt. In unseren WordPress-Schulungen ist das ein eigener Punkt — nicht als Verbotsliste, sondern damit die Leute, die täglich mit der Seite arbeiten, die kritischen Stellen erkennen.

Häufige Fragen

Wie sehe ich, ob meine Seite auf noindex steht?

Am schnellsten im Quelltext: Startseite aufrufen, Strg+U, mit Strg+F nach noindex suchen — ein Treffer im <head> genügt. Belastbarer ist die Google Search Console: Unter Seiten → Warum Seiten nicht indexiert werden steht der Grund „Durch ‚noindex‘-Tag ausgeschlossen“ mitsamt der Zahl betroffener URLs. Für eine einzelne Adresse liefert die URL-Prüfung dieselbe Auskunft.

Wo genau steht das noindex-Tag im Code?

Im <head> jeder einzelnen Seite, als <meta name="robots" content="noindex">. Es steht nicht in der robots.txt — das ist eine andere Datei mit einer anderen Aufgabe. Kommt die Anweisung als HTTP-Header X-Robots-Tag vom Server, ist sie im Quelltext gar nicht zu sehen.

Was ist der Unterschied zwischen noindex und einem Disallow in der robots.txt?

noindex verhindert die Aufnahme in den Index, Disallow das Crawlen. Eine per robots.txt gesperrte Seite kann trotzdem in den Ergebnissen auftauchen — ohne Beschreibung, wenn andere Seiten darauf verlinken. Beides gleichzeitig einzusetzen ist ein verbreiteter Fehler: Google darf die Seite dann nicht mehr abrufen und erfährt deshalb nie, dass der noindex-Hinweis entfernt wurde.

Wie lange dauert es, bis Google nach dem Entfernen wieder indexiert?

Die Startseite ist oft nach wenigen Tagen zurück, die Breite braucht Wochen — dieselbe Größenordnung, in der auch der Absturz verlaufen ist. Beschleunigen lässt sich das nicht erzwingen, nur einladen: Sitemap in der Search Console neu einreichen und die wichtigsten Adressen einzeln zur Indexierung anmelden. Ob alle Positionen zurückkommen, hängt davon ab, wer sie in der Zwischenzeit besetzt hat.

Kann ein Plugin das noindex-Tag gesetzt haben?

Ja, und das ist der zweithäufigste Fall nach dem vergessenen Haken. Yoast, Rank Math und All in One SEO bringen eigene Schalter mit — pro Seite, pro Beitragstyp, pro Archiv. Dazu kommen Wartungsmodus-, Staging- und Coming-Soon-Plugins. Der Haken unter Einstellungen → Lesen kann also sauber sein und die Seite trotzdem ausgesperrt.

Ist ein noindex-Tag schlecht für SEO?

Falsch gesetzt ist es fatal, richtig gesetzt ist es Handwerk. Dankeseiten, interne Suchergebnisse, Filterseiten und Testumgebungen haben im Index nichts verloren. Das Problem ist nie das Tag, sondern seine Reichweite: Eine Seite auszuschließen ist Pflege — die ganze Website auszuschließen ist ein Unfall.

Fazit auf einen Blick

Wenn eine Website nicht mehr gefunden wird, lohnt vor jeder inhaltlichen Überlegung die banale Frage, ob sie überhaupt noch im Index steht. Fällt die Zahl der rankenden URLs, hilft kein besserer Text — dann ist eine technische Tür zugefallen. Im geschilderten Fall war es ein Kontrollkästchen, das in zwei Sekunden gesetzt und in zwei Minuten gefunden war. Dazwischen lagen drei Monate und vier Jahre Aufbau.

Unsicher, ob deine Seite sauber indexiert ist? Unser kostenloser Website-Check prüft genau solche Punkte — Indexierbarkeit, Technik, Auffindbarkeit. Wenn daraus mehr werden soll, findest du auf unserer SEO-Leistungsseite, wie wir arbeiten.