Crawling-Fehler: Ursachen erkennen und beheben

Ein Crawling-Fehler bedeutet, dass ein Suchmaschinen-Crawler wie der Googlebot eine URL deiner Website nicht laden konnte. Nicht „nicht bevorzugt“, nicht „nicht gut genug“ – schlicht nicht geladen. Der Server hat nicht rechtzeitig geantwortet, der DNS-Eintrag war im Moment des Zugriffs nicht auflösbar, robots.txt hat den Zugriff verboten, oder die Antwort kam mit einem Statuscode zurück, der sagt: Hier ist nichts zu holen.

Das ist nicht dasselbe wie ein Indexierungsproblem, auch wenn beide im selben Search-Console-Bericht auftauchen. Eine Seite kann technisch fehlerfrei crawlbar sein und trotzdem nicht im Index landen, weil Google sie für Duplicate Content hält oder ein Canonical-Tag auf eine andere URL zeigt – der Crawl war erfolgreich, die Entscheidung danach fiel nur gegen die Seite. Umgekehrt bleibt eine Seite, die seit Wochen nicht neu gecrawlt wurde, trotzdem im Index sichtbar, mit dem letzten bekannten Stand. Wer beide Fälle mit derselben Checkliste abarbeitet, sucht am falschen Ende.

Wo Crawling-Fehler sichtbar werden

Zwei Quellen liefern belastbare Daten. Die erste ist der Bericht Seitenindexierung in der Google Search Console: Er listet URLs nach Status, darunter „Serverfehler (5xx)“, „Nicht gefunden (404)“, „Weiterleitungsfehler“, „Durch robots.txt blockiert“ und „Soft 404“. Jede Kategorie lässt sich aufklappen und zeigt Beispiel-URLs samt dem Datum des letzten Crawl-Versuchs.

Die zweite ist der Bericht Crawling-Statistiken unter den Einstellungen der Property. Er zeigt, wie viele Anfragen Google pro Tag stellt, aufgeschlüsselt nach Antwortcode, nach Dateityp und nach Zweck – Entdeckung neuer URLs gegenüber Aktualisierung bekannter. Ein plötzlicher Ausschlag bei 5xx-Antworten oder ein Einbruch bei den Gesamtanfragen ist hier oft der erste sichtbare Hinweis, bevor einzelne URLs im Seitenindexierungs-Bericht auftauchen.

Server-Logs ergänzen beide Berichte, weil sie in Echtzeit zeigen, was tatsächlich passiert – nicht die aggregierte, leicht verzögerte Sicht von Search Console. Im Rohlog siehst du jede Anfrage mit User-Agent, Statuscode, Antwortzeit und IP, kannst also einen echten Googlebot per Reverse-DNS-Abgleich von einem gefälschten User-Agent unterscheiden und siehst Fehler auf URLs, die Search Console noch gar nicht erfasst hat, weil sie erst kürzlich verlinkt wurden.

Serverfehler (5xx): Wenn dein Server nicht antwortet

Ein 5xx-Fehler heißt: Der Server hat die Anfrage erhalten, aber keine gültige Antwort geliefert. Typische Ursachen sind Überlastung bei Crawl-Spitzen, ein Timeout im Backend, eine Datenbank, die keine weiteren Verbindungen mehr annimmt, ein fehlerhaftes Deployment oder eine Firewall beziehungsweise ein Rate-Limiter, der den Bot fälschlich für einen Angreifer hält.

Die Diagnose beginnt im Server-Log: Korreliere die Zeitstempel der Fehler mit Crawl-Bursts, prüfe Antwortzeiten unmittelbar davor und schau in die Hosting-Metriken – CPU, Arbeitsspeicher, Anzahl offener Datenbankverbindungen. Tritt der Fehler konstant auf, liegt meist ein Code- oder Konfigurationsfehler vor; tritt er nur bei Lastspitzen auf, ist es ein Kapazitätsproblem.

Wichtig zu wissen: Anhaltende 5xx-Fehler beeinflussen nicht nur die betroffene URL. Wenn Google über einen längeren Zeitraum viele fehlgeschlagene Anfragen an eine Domain sieht, reduziert es die Crawl-Rate für diese Domain insgesamt, um den Server nicht weiter zu belasten – das trifft dann auch Seiten, die eigentlich fehlerfrei wären. Deshalb sind 5xx-Fehler fast immer dringend: Sie kosten nicht nur die eine URL, sie bremsen den gesamten Crawl-Zugriff.

• Kapazität erhöhen oder Lastspitzen abfedern, wenn der Fehler mit Crawl-Bursts korreliert
• Timeouts im Backend beheben, statt sie durch längere Wartezeiten zu kaschieren
• Verifizierten Googlebot-Traffic in WAF und Rate-Limiter ausdrücklich zulassen

404 – Nicht gefunden: Wann es ein Problem ist und wann nicht

Ein 404 sagt: Diese URL existiert hier nicht. Das ist oft völlig richtig. Ein Produkt wurde dauerhaft eingestellt, eine Kampagnenseite lief aus, ein alter Blogpost wurde bewusst entfernt – in all diesen Fällen ist 404 die ehrliche Antwort, und Zeit in „alle 404 auf null bringen“ zu stecken, ist Zeit an der falschen Stelle.

Problematisch wird ein 404 erst, wenn er nicht beabsichtigt ist: ein interner Link mit Tippfehler, eine Seite, die beim letzten Relaunch ohne Weiterleitung verschwand, eine URL in der XML-Sitemap, die längst nicht mehr existiert, oder eine fehlerhafte JavaScript-Route, die willkürliche URL-Fragmente erzeugt. Der Unterschied entscheidet sich an einer Frage: Verlinkst du selbst noch auf diese URL, intern oder in der Sitemap?

Prüfe im Seitenindexierungs-Bericht, welche Seite die 404-URL referenziert – Search Console zeigt bei jedem Eintrag eine Beispielquelle. Ein Crawler wie Screaming Frog findet zusätzlich alle internen Links auf die betroffene URL im gesamten Projekt. Steht die URL noch in der Sitemap, gehört sie dort entfernt, unabhängig davon, ob der 404 sonst ein Problem ist.

Für absichtlich entfernte Inhalte mit noch bestehenden Backlinks oder messbarem Resttraffic lohnt sich eine 301-Weiterleitung auf eine wirklich verwandte Seite – nicht pauschal auf die Startseite. Für alles andere ist 404, oder bei dauerhaft entfernten Inhalten 410, technisch korrekt und braucht keine weitere Aktion.

Weiterleitungsprobleme: Ketten, Loops und falsche Weiterleitungscodes

Eine Weiterleitungskette liegt vor, wenn URL A auf B verweist, B wiederum auf C, und erst C den finalen Inhalt liefert. Jeder zusätzliche Sprung kostet Crawl-Budget und Ladezeit für echte Besucher, und mit jedem Hop wird es unklarer, ob Google die Signale der Ursprungs-URL noch vollständig der Zielseite zuordnet.

Ein Redirect-Loop ist der Extremfall: A verweist auf B, B wieder zurück auf A. Der Crawler bricht nach einer bestimmten Anzahl Sprünge ab und meldet einen Weiterleitungsfehler – für echte Nutzer bedeutet das denselben Effekt, nur sichtbar als endlos ladende Seite oder eine Browserfehlermeldung.

Ein weiterer, seltener genannter Fehler: alle 404-URLs pauschal per Weiterleitung auf die Startseite zu schicken. Das verschleiert echte Fehler, statt sie zu lösen, und erzeugt aus Sicht von Google Hunderte URLs, die alle auf denselben irrelevanten Inhalt zeigen – im schlechtesten Fall als Soft 404 markiert, weil die Zielseite thematisch nichts mit der ursprünglichen Anfrage zu tun hat.

• Weiterleitungen direkt auf das Endziel setzen, nicht über Zwischenstationen
• 301 für dauerhafte Verschiebungen, 302 nur für tatsächlich temporäre
• Nach jedem Relaunch oder Domain-Umzug die Kette mit einem Crawler-Tool prüfen

Blockiert durch robots.txt

Ein Disallow in der robots.txt verhindert, dass ein Crawler die Seite überhaupt abruft. Das ist nicht dasselbe wie noindex: Eine blockierte URL kann trotzdem mit Titel und URL in den Suchergebnissen erscheinen, wenn andere Seiten darauf verlinken – Google weiß dann, dass die URL existiert, kann den Inhalt aber nicht lesen, um über die Darstellung zu entscheiden.

Der häufigste Unfall: eine für die Staging-Umgebung gedachte robots.txt mit „Disallow: /“ landet versehentlich auf der Live-Domain, meist nach einem Deployment ohne Umgebungstrennung. Fast genauso häufig sind zu breite Regeln, die mehr blockieren als beabsichtigt – etwa eine Regel für /wp-admin, die durch fehlendes Trailing-Slash auch /wp-admin-hilfe erfasst, oder ein Wildcard-Ausschluss, der versehentlich CSS- und JS-Dateien mitblockiert, die für das Rendering der Seite nötig sind.

Zur Diagnose dient das URL-Prüftool in der Search Console: Es zeigt live, ob eine bestimmte URL durch robots.txt blockiert wird; der robots.txt-Bericht in den Einstellungen zeigt zusätzlich, welche Version der Datei Google zuletzt abgerufen hat. Nach einer Korrektur der robots.txt dauert es, bis Google die Datei erneut abruft und die Sperre aufhebt – der geänderte Zugriff ist also nicht sofort wirksam, sondern erst nach dem nächsten robots.txt-Fetch des Crawlers.

DNS-Fehler, Verbindungsabbrüche und Soft 404

DNS-Fehler und Verbindungsabbrüche treten auf, bevor der Server überhaupt antworten kann. Der Domainname lässt sich im Moment des Crawl-Versuchs nicht auflösen – wegen eines Ausfalls beim DNS-Provider, eines fehlerhaft gesetzten Eintrags oder eines Nameserver-Wechsels ohne ausreichende Übergangszeit. Verbindungsfehler haben ähnliche Ursachen auf einer anderen Ebene: eine Firewall blockiert die IP-Bereiche des Crawlers, ein abgelaufenes oder falsch konfiguriertes TLS-Zertifikat lässt den Handshake scheitern, oder der Server braucht schlicht zu lange, um die Verbindung überhaupt anzunehmen.

Beide Fehlertypen sind meist zeitlich begrenzt und zeigen sich in den Crawling-Statistiken als Ausschlag beim Hoststatus. Sind sie einmalig und kurz, ist selten eine Aktion nötig. Wiederholen sie sich über Tage, ist es fast immer eine Infrastrukturfrage – DNS-Konfiguration, Zertifikatserneuerung oder eine Firewall-Regel – und keine Frage von Inhalt oder Struktur.

Ein Soft 404 ist der unauffälligste dieser Fehler, weil der Server technisch mit Status 200 antwortet, obwohl die Seite inhaltlich „nicht gefunden“ bedeutet: ein leerer Filterzustand ohne Treffer, eine ausverkaufte Produktseite mit generischem Platzhaltertext, eine abgelaufene Anzeige, die nur noch eine Standardmeldung zeigt. Google bewertet den Inhalt, nicht nur den Statuscode, und stuft solche Seiten trotz 200 als Soft 404 ein.

Für Seiten, die dauerhaft nichts mehr zu bieten haben, ist ein echter 404- oder 410-Statuscode die korrektere Antwort. Für Seiten, die eigentlich indexiert bleiben sollen – etwa eine Kategorie ohne aktuelle Treffer –, hilft es, echten Inhalt zu zeigen: verwandte Produkte, eine Erklärung, warum die Auswahl leer ist, oder ähnliche Alternativen, statt einer reinen Platzhalterzeile.

Priorisieren statt auf null bringen – und den Fix bestätigen

Eine lange Liste an Crawling-Fehlern ist der Normalzustand größerer Websites, kein Alarmsignal für sich. Der Fehler liegt nicht in der Länge der Liste, sondern darin, sie ohne Priorisierung abzuarbeiten. Drei Kriterien helfen bei der Reihenfolge: der Wert der betroffenen URL – Traffic, Backlinks, Umsatz –, die Dringlichkeit der Fehlerklasse, und ob die Zahl gerade steigt oder seit Monaten flach verläuft.

Bei der Dringlichkeit gilt grob: verbreitete 5xx-Fehler zuerst, weil sie die Crawl-Rate der gesamten Domain drücken. Danach Weiterleitungsfehler und robots.txt-Blockaden auf Seiten, die eigentlich ranken sollen. 404-Fehler auf einzelnen, bewusst entfernten alten Seiten stehen am Ende der Liste – und manche davon gehören dort für immer, weil du sie nie auf null bringen wirst und solltest. Externe Seiten verlinken weiterhin auf Tippfehler-URLs, die du nicht kontrollierst, und das ist kein Zustand, den du reparieren kannst.

Ein Trend ist aussagekräftiger als eine Momentaufnahme: Steigt die Zahl eines bestimmten Fehlertyps sichtbar an, ist gerade etwas neu kaputtgegangen und verdient sofortige Prüfung. Bleibt die Zahl über Wochen konstant und betrifft dieselben, bekannten URLs, ist es Hintergrundrauschen.

Ob ein Fix wirklich gewirkt hat, bestätigst du nicht per Browseraufruf, sondern über den Crawler selbst. Im Seitenindexierungs-Bericht löst die Schaltfläche „Beheben validieren“ einen erneuten Crawl der betroffenen URLs aus; das Ergebnis läuft über mehrere Crawl-Durchgänge und braucht üblicherweise ein bis zwei Wochen, bis Search Console den Status aktualisiert. Für eine schnellere Einzelprüfung zeigt das URL-Prüftool mit „Live-Test durchführen“ den aktuellen Abruf sofort. Und im Server-Log lässt sich Tage später gegenprüfen, ob der verifizierte Googlebot die URL erneut mit Status 200 abgerufen hat – erst diese drei zusammen, nicht der eigene Browser, bestätigen, dass die Reparatur beim Crawler angekommen ist.