Google Search Console: Indexierungsprobleme selbst prüfen – Checkliste vor dem Support-Ticket

Die Google Search Console (GSC) meldet „nicht indexiert“, „durch noindex ausgeschlossen“ oder „Sitemap konnte nicht abgerufen werden“? Diese Meldungen sehen dramatisch aus, haben aber meistens nichts mit dem Hosting zu tun. Ob und wann Google eine Seite in den Index aufnimmt, entscheidet allein Google. Dafür spielen Inhalt, interne Verlinkung, Duplikate und Einstellungen in WordPress bzw. im SEO-Plugin die größte Rolle.

Unsere Aufgabe als Hoster ist eine andere: Wir sorgen dafür, dass der Googlebot deine Seiten technisch einwandfrei abrufen kann. Genau dabei helfen wir dir, wenn unser Server-Setup (z. B. Firewall, Bot-Schutz oder Server-Konfiguration) legitime Abrufe des Googlebots fälschlich blockiert. Mit der folgenden Checkliste findest du in wenigen Minuten heraus, ob das bei dir der Fall ist oder ob die Ursache woanders liegt.

Das Wichtigste vorab: Nur deine eingereichten Seiten zählen

Im Bericht Indexierung → Seiten zeigt dir die GSC standardmäßig „Alle bekannten Seiten“. Das sind alle URLs, die Google irgendwo gefunden hat: Feed-URLs, Filter- und Parameter-URLs, Anhangseiten, alte URLs, Tag-Archive, ?add-to-cart=-Links und vieles mehr. Dass viele davon „nicht indexiert“ sind, ist normal und gewollt. Diese URLs sollen gar nicht in den Index.

Relevant sind nur die URLs, die du Google über deine Sitemap ausdrücklich zur Indexierung vorschlägst. Du siehst sie, wenn du oben im Bericht den Filter auf „Alle eingereichten Seiten“ umstellst.

• Eingereichte Seiten müssen vom Server problemlos ausgeliefert werden: Statuscode 200, kein noindex, keine Sperre, keine Warteseite. Das prüfst du mit dieser Checkliste.
• Alle anderen URLs sind für die Bewertung deines Hostings irrelevant. Meldungen zu nicht eingereichten URLs sind kein Grund für ein Support-Ticket.
• Ob Google eine eingereichte, technisch einwandfreie Seite am Ende indexiert, ist eine Entscheidung von Google. Darauf haben weder du noch wir als Hoster direkten Einfluss.

Voraussetzungen

• Deine Website ist in der Google Search Console als Property eingerichtet und bestätigt (siehe Abschnitt „Häufige Frage: TXT-Eintrag zur Bestätigung“ weiter unten).
• Deine Website hat eine erreichbare XML-Sitemap (z. B. /sitemap_index.xml bei Yoast oder Rank Math, /wp-sitemap.xml bei WordPress ohne SEO-Plugin).
• Deine Website hat eine erreichbare robots.txt unter https://deinedomain.de/robots.txt. Ohne eigene Datei erzeugt WordPress automatisch eine virtuelle robots.txt.
• Du hast Zugriff auf das WordPress-Backend und auf Plesk (für die Access-Logs).

Schritt-für-Schritt-Checkliste

Arbeite die Schritte der Reihe nach ab. Sobald du in einem Schritt die Ursache findest, kannst du dort aufhören.

Schritt 1: robots.txt prüfen

1. Ruf https://deinedomain.de/robots.txt im Browser auf.
2. Es muss reiner Text erscheinen, keine HTML-Seite, keine Warteseite („One moment, please…“), keine Fehlermeldung.
3. Prüf, dass dort kein Disallow: / steht und keine Pfade gesperrt sind, unter denen deine eingereichten Seiten liegen (z. B. Disallow: /blog/).
4. Ein Verweis auf deine Sitemap ist empfehlenswert, z. B. Sitemap: https://deinedomain.de/sitemap_index.xml.

Ergebnis: Steht dort eine Sperre, liegt die Ursache in deiner Konfiguration (robots.txt-Datei oder SEO-Plugin). Mehr dazu im Artikel „Funktion der robots.txt“.

Alternativ kannst du auch ein externes Robots.txt Checker-Tool nutzen.

Schritt 2: WordPress-Einstellung „Suchmaschinen abhalten“ prüfen

1. Öffne im WordPress-Backend Einstellungen → Lesen.
2. Der Haken bei „Suchmaschinen davon abhalten, diese Website zu indexieren“ darf auf der Live-Website nicht gesetzt sein.
3. Gerade nach einer Migration von einer Staging- auf die Live-Umgebung ist dieser Haken oft noch aktiv.

Schritt 3: Sitemap prüfen und einreichen

1. Ruf deine Sitemap im Browser auf. Es muss eine XML-Ansicht bzw. eine Liste von Teil-Sitemaps erscheinen, keine HTML-Seite und keine Warteseite. Alternativ kannst du auch ein externes Sitemap.xml Checker-Tool nutzen.
2. Öffne in der GSC Indexierung → Sitemaps und reich genau eine aktuelle Sitemap-URL ein. Entferne alte oder doppelte Sitemaps (z. B. aus einem früheren SEO-Plugin).
3. Der Status sollte nach einiger Zeit auf „Erfolgreich“ wechseln.
4. Prüf stichprobenartig, ob in der Sitemap wirklich nur Seiten stehen, die indexiert werden sollen. Weiterleitungen, noindex-Seiten oder 404-Seiten gehören nicht in die Sitemap. Welche Inhaltstypen in der Sitemap landen, steuerst du im SEO-Plugin.

Gut zu wissen: Direkt nach dem Einreichen zeigt die GSC manchmal für einige Stunden „Konnte nicht abgerufen werden“, obwohl die Sitemap erreichbar ist. Ist sie im Browser und im Live-Test (Schritt 5) einwandfrei abrufbar, warte bis zu 24 Stunden und reich sie dann bei Bedarf erneut ein.

Schritt 4: Filter „Alle eingereichten Seiten“ setzen und Gründe einordnen

1. Öffne Indexierung → Seiten.
2. Stell den Filter oben von „Alle bekannten Seiten“ auf „Alle eingereichten Seiten“ um.
3. Sieh dir unter „Warum Seiten nicht indexiert werden“ die Gründe an und ordne sie mit der folgenden Liste ein.

In der Regel keine Server-Ursache (selbst prüfen bzw. abwarten):

• „Gefunden – zurzeit nicht indexiert“ und „Gecrawlt – zurzeit nicht indexiert“: Das ist eine Entscheidung von Google, meist wegen Qualität, Relevanz, Duplikaten oder schwacher interner Verlinkung. Hier hilft Geduld bzw. eine Verbesserung der Inhalte.
• „Seite mit Weiterleitung“, „Alternative Seite mit richtigem kanonischen Tag“, „Duplikat – …“: Das sind Einstellungen von Website, SEO-Plugin oder Canonical. Solche URLs sollten nicht in der Sitemap stehen.
• „Nicht gefunden (404)“ und „Soft 404“: Die Seite existiert nicht (mehr) oder hat kaum Inhalt. Sitemap bereinigen oder Weiterleitung einrichten.
• „Durch robots.txt-Datei blockiert“: siehe Schritt 1.

Mögliche Server-Ursache (weiter mit Schritt 5):

• „Serverfehler (5xx)“
• „Blockiert aufgrund von Zugriffsverbot (403)“ oder „Blockiert aufgrund eines anderen 4xx-Problems“ (z. B. 429 Too Many Requests)
• „Durch ‚noindex‘-Tag ausgeschlossen“, wenn du in WordPress und im SEO-Plugin sicher kein noindex gesetzt hast

Schritt 5: Live-Test mit der URL-Prüfung (der entscheidende Test)

Die URL-Prüfung ist der zuverlässigste Test, ob unser Server den Googlebot durchlässt, denn hier ruft der echte Googlebot deine Seite jetzt ab. Die übrigen Berichte zeigen dagegen oft einen Stand von vor Tagen oder Wochen.

1. Kopier eine betroffene URL aus der Liste der eingereichten Seiten.
2. Füg sie oben in der GSC in das Suchfeld „URL prüfen“ ein.
3. Klick auf „Live-URL testen“.
4. Öffne anschließend „Getestete Seite ansehen“ und prüf die Reiter HTML, Screenshot und Weitere Informationen → HTTP-Antwort.

So bewertest du das Ergebnis:

• „URL ist für Google verfügbar“ und Statuscode 200: Der Server liefert die Seite einwandfrei aus. Eine Server-Blockade liegt nicht vor. Du kannst über „Indexierung beantragen“ ein neues Crawling anstoßen. Der Rest liegt bei Google.
• Statuscode 403, 429 oder 5xx im Live-Test, während die Seite im Browser normal lädt: Hinweis auf eine Server-Blockade. Weiter mit Schritt 8.
• Im Screenshot oder HTML steht „One moment, please…“ bzw. „Please wait while your request is being verified“: Die Bot-Prüfung unseres Servers hat den Googlebot abgefangen. Server-Ursache, weiter mit Schritt 8.
• In der HTTP-Antwort steht X-Robots-Tag: noindex, obwohl dein SEO-Plugin die Seite auf „index“ stellt: Das noindex kommt sehr wahrscheinlich aus der Server-Konfiguration. Prüf noch Schritt 6, dann weiter mit Schritt 8.
• Im HTML steht ein <meta name="robots" content="noindex">: Das kommt aus WordPress, deinem Theme oder dem SEO-Plugin. Weiter mit Schritt 6.

Mach denselben Live-Test zusätzlich für deine robots.txt- und deine Sitemap-URL.

Schritt 6: Woher kommt das noindex?

1. Öffne die betroffene Seite in WordPress und prüf im SEO-Plugin (z. B. Yoast: Reiter „Erweitert“, Rank Math: „Erweitert“ bzw. „Robots-Meta“), ob die Seite auf „indexieren“ steht.
2. Prüf in den SEO-Plugin-Einstellungen, ob für den gesamten Inhaltstyp (z. B. Produkte, Beiträge, Kategorien) „nicht in Suchergebnissen anzeigen“ aktiv ist.
3. Leer danach alle Caches (Caching-Plugin und ggf. Server-Cache) und wiederhol den Live-Test aus Schritt 5.

Ergebnis: Bleibt ein noindex im HTTP-Header (X-Robots-Tag) bestehen, obwohl in WordPress alles auf „index“ steht, ist das ein Fall für unseren Support. Weiter mit Schritt 8.

Schritt 7: Optional – Crawling-Statistiken und Access-Logs ansehen

1. Öffne in der GSC Einstellungen → Crawling-Statistiken → Bericht öffnen.
   • Unter Hoststatus siehst du, ob es Probleme beim Abruf der robots.txt, bei der DNS-Auflösung oder bei der Serververbindung gab.
   • Unter Nach Antwort siehst du, wie viele Googlebot-Abrufe mit 200, 403, 429 oder 5xx beantwortet wurden.
2. Öffne in Plesk bei deiner Domain die Logs und filter nach Googlebot. Notier dir für betroffene eingereichte URLs die Zeilen mit Uhrzeit und Statuscode.
3. Öffne im WordPress-Backend Imunify Security → Bot Traffic (oder im Dashboard-Widget „Imunify Security“ den Link „View full bot traffic report“). Der Bericht zeigt dir für die letzten 24 Stunden, welche Bots wie oft zugegriffen haben und ob sie durchgelassen (Allowed), gebremst (Rate-limited, 429) oder blockiert (Blocked, 403) wurden. Klapp unter „By classification“ die Kategorie „Verified search engines“ auf. Dort sollte der Googlebot mit der Aktion Allowed stehen.

Was bedeutet ein 429 durch den Bot-Schutz?

Auf unseren Servern läuft im WordPress-Plugin „Imunify Security“ die Funktion AI Bot Management (im Widget „Bot Protection“). Sie ordnet jeden Zugriff einer Kategorie zu und erlaubt jeder Kategorie eine bestimmte Anzahl an Anfragen pro Minute. Wer darüber liegt, bekommt vorübergehend ein 429 Too Many Requests. Das schützt deine Website davor, dass aggressive Crawler und Scraper die Ressourcen deines Hostings aufbrauchen.

• Echte Besucher werden nie gebremst.
• Der echte Googlebot wird per Reverse-DNS-Prüfung als „Verified search engine“ erkannt. Er darf in der Standardeinstellung 300 Anfragen pro Minute stellen. Ein 429 für den verifizierten Googlebot entsteht also nur bei einer außergewöhnlich hohen Crawl-Last und ist in der Praxis sehr selten.
• SEO-Tools, KI-Crawler und unbekannte Bots haben deutlich niedrigere Limits (z. B. 60, 10 bzw. 5 Anfragen pro Minute). Ein 429 für diese Bots ist gewollt und hat keinen Einfluss auf deine Google-Indexierung.
• Bots, die sich nur als Googlebot ausgeben, die Reverse-DNS-Prüfung aber nicht bestehen, gelten als „Unverified bots“ und dürfen nur 2 Anfragen pro Minute stellen.

Wichtig: Teste den Googlebot deshalb nicht selbst nach, indem du in einem Tool oder per curl den Googlebot-User-Agent von deinem eigenen Rechner aus vortäuschst. Deine Anfrage fällt dann in die Kategorie „Unverified bots“ und bekommt schon nach der zweiten Anfrage ein 429. Das ist ein Fehlalarm, der nichts über den echten Googlebot aussagt. Verlass dich stattdessen auf den Live-Test aus Schritt 5 und den Bot-Traffic-Bericht.

Tipp zur Eingrenzung: Vermutest du, dass der Bot-Schutz die Ursache ist, kannst du im Widget unter „Bot Protection“ → „change“ testweise das Preset „Monitor only“ wählen. Dann wird der Datenverkehr nur noch protokolliert, nicht mehr gebremst. Wiederhol anschließend den Live-Test aus Schritt 5. Stell danach unbedingt wieder „Balanced“ ein, damit deine Website geschützt bleibt.

Mehr Details findest du in der offiziellen Imunify-Dokumentation zum WordPress-Plugin (englisch).

Schritt 8: Prüfen, ob ein Fall für unseren Support vorliegt

Ein Support-Ticket ist sinnvoll, wenn mindestens einer der folgenden Punkte für eingereichte Seiten, die robots.txt oder die Sitemap zutrifft:

• Der Live-Test liefert 403, 429 oder 5xx, während die Seite im Browser normal lädt.
• Der Live-Test zeigt die Warteseite („One moment, please…“) statt deines Inhalts.
• robots.txt oder Sitemap werden mit Status 200, aber als HTML statt als Text bzw. XML ausgeliefert.
• Der Server sendet X-Robots-Tag: noindex, obwohl WordPress und dein SEO-Plugin auf „index“ stehen.
• Die robots.txt liefert einen Serverfehler (5xx), auch wenn dein SEO-Plugin deaktiviert ist.
• Die Access-Logs, die Crawling-Statistiken oder der Bot-Traffic-Bericht zeigen wiederholt 403 oder 429 für den verifizierten Googlebot („Verified search engines“) auf eingereichte URLs. Ein 429 für SEO-Tools, KI-Crawler oder unbekannte Bots ist dagegen kein Grund für ein Ticket.

Gut zu wissen: Unsere Standard-Serverkonfiguration setzt weder ein noindex noch einen zusätzlichen Bot-Schutz in nginx. Hast du mit uns eine Sonderkonfiguration vereinbart, zum Beispiel einen verschärften Bot-Schutz während einer Bot-Attacke, ist das der häufigste Grund für die oben genannten Punkte. Erwähne eine solche Vereinbarung bitte direkt in deiner Anfrage.

Trifft keiner dieser Punkte zu, liefert unser Server deine Seiten korrekt an Google aus. Die Ursache liegt dann sehr wahrscheinlich in der Website-Konfiguration, im Inhalt oder bei Google. Am schnellsten hilft dir dann deine Agentur oder eine:n SEO-Expert:in. Du kannst dich trotzdem an uns wenden. Wir prüfen dann individuell, ob und wie wir dir helfen können. Plane dafür bitte ein, dass die Bearbeitung nach Eingang deines Tickets 5 Tage oder länger dauern kann.

Schritt 9: Support-Anfrage mit den richtigen Angaben stellen

Damit wir schnell helfen können, schick uns bitte:

• die betroffene Domain,
• 3–5 Beispiel-URLs aus „Alle eingereichten Seiten“ (keine Filter-, Feed- oder Parameter-URLs),
• einen Screenshot des Live-Tests mit Statuscode bzw. HTTP-Antwort,
• den Grund, den die GSC für diese URLs anzeigt (z. B. „Blockiert aufgrund von Zugriffsverbot (403)“),
• falls vorhanden: passende Zeilen aus den Access-Logs mit Uhrzeit und Statuscode.

Am schnellsten geht es, wenn du uns Zugriff auf deine Search Console gibst:

1. Öffne in der GSC Einstellungen → Nutzer und Berechtigungen.
2. Klick auf „Nutzer hinzufügen“.
3. Trag die E-Mail-Adresse info@hostpress.de ein.
4. Wähl als Berechtigung „Uneingeschränkt“ und bestätige mit „Hinzufügen“.

So sehen wir die Meldungen direkt, können nach einer Korrektur die Indexierung neu beantragen und die Fehlerbehebung in der GSC selbst überprüfen lassen. Nach Abschluss deiner Anfrage kannst du den Zugriff jederzeit wieder entfernen.

Nachdem wir eine Server-Ursache behoben haben, wiederhol den Live-Test, beantrag die Indexierung erneut und klick im Bericht Seiten beim jeweiligen Grund auf „Fehlerbehebung überprüfen“. Google braucht für die erneute Prüfung oft einige Tage. Bis dahin zeigt die GSC weiterhin den alten Status an.

Häufige Frage: TXT-Eintrag zur Bestätigung der Search Console

Für eine Domain-Property verlangt Google einen TXT-Eintrag in den DNS-Einstellungen deiner Domain.

1. Kopier den Wert in der GSC über die Schaltfläche „Kopieren“, nicht abtippen. Ein vertauschtes Zeichen (l/1/I) reicht für einen Fehlschlag.
2. Der Eintrag lautet: Host @, Typ TXT, Wert google-site-verification=…. Achte darauf, dass google-site-verification= nur einmal am Anfang steht.
3. Trag den Eintrag selbst in der DNS-Verwaltung deiner Domain ein. Wird deine Domain bei HostPress verwaltet, findest du die DNS-Verwaltung im Kundencenter unter Domains → Meine Domains → drei Punkte → Domain verwalten → DNS-Verwaltung. Wähl dort den Eintragstyp „SPF (txt)“. Er gilt für alle TXT-Werte, auch wenn dein Wert kein SPF-Eintrag ist. Als Hostname nimmst du @ bzw. lässt das Feld leer. Die ausführliche Anleitung findest du im Artikel „DNS Einstellungen bei HostPress“.
4. Siehst du im Kundencenter keinen Menüpunkt „DNS-Verwaltung“, folg dem Abschnitt „Ich sehe keine DNS-Verwaltung in meinem Domain-Menü – was tun?“. Liegt deine Domain bei einem externen Anbieter, setzt du den Eintrag dort.
5. Plane Wartezeit ein: Bis Google den neuen Eintrag sieht, können einige Stunden (in Einzelfällen bis zu 24 Stunden) vergehen. Klick in dieser Zeit nicht ständig auf „Bestätigen“. Versuch es nach ein paar Stunden erneut.

Fazit & Support-Hinweis

Für die Indexierung zählen nur die Seiten, die du über deine Sitemap einreichst. Diese müssen für den Googlebot mit Status 200, ohne noindex und ohne Warteseite erreichbar sein. Das prüfst du am zuverlässigsten mit dem Live-Test der URL-Prüfung. Ist der Live-Test für deine eingereichten Seiten, die robots.txt und die Sitemap in Ordnung, funktioniert unser Server korrekt. Alles Weitere entscheidet Google.

Zeigt der Live-Test dagegen 403, 429, 5xx, eine Warteseite oder ein serverseitiges noindex, melde dich mit den Angaben aus Schritt 9 bei unserem Support. Wir prüfen dann gezielt, ob unsere Firewall, der Bot-Schutz oder eine mit dir vereinbarte Sonderkonfiguration den Googlebot fälschlich ausbremsen, und beheben das für dich.

Findest du mit der Checkliste keine Server-Ursache, kannst du uns trotzdem schreiben. Wir prüfen dann individuell, ob wir helfen können. Rechne in diesem Fall mit einer Bearbeitungszeit von 5 Tagen oder länger nach Ticketeingang. Mit den Angaben aus Schritt 9 geht es am schnellsten.