Website auf Fehler prüfen: Links, 404, 5xx, JS-Fehler, Formulare

Website auf Fehler prüfen in der Praxis: defekte Links, echte und Soft-404, 5xx-Antworten, JavaScript-Fehler, kaputte Formulare und Mixed Content finden.

Links · Veröffentlicht: 12. Oktober 2026 · 5 Min. Lesezeit · Марк Лебедев

Besucher melden Fehler so gut wie nie. Sie landen auf einem toten Link, einem Formular, das stillschweigend nichts abschickt, oder einer halb zerfallenen Seite – und gehen. Suchmaschinen sind weniger höflich: Sie registrieren den Fehler und crawlen seltener. Wer die Website auf Fehler prüfen will, bevor es eine dieser Gruppen tut, braucht eine Routine. Dieser Beitrag ist ein Praxisleitfaden zu den sieben häufigsten Fehlerarten: wo sie sich verstecken und wie Sie sie bestätigen.

1. Defekte Links

Ein Link auf 404 oder 410 ist der häufigste Fehler auf jeder Website, die älter als ein Jahr ist. Seiten werden umbenannt, Produkte ausgelistet, ein Menüpunkt zeigt noch auf den Sale vom letzten Jahr. Defekte interne Links haben Sie vollständig selbst in der Hand, und sie schaden doppelt: Sackgasse für Besucher, verschwendeter Abruf für den Crawler. Externe Links verrotten nach eigenem Zeitplan.

Die Lösung ist, den Link zu korrigieren, nicht dauerhaft weiterzuleiten: Verweisen Sie direkt auf die Zieladresse. Sonderfälle behandelt der Beitrag über defekte Links, und die Hilfeseite erklärt, wie der Scanner internen Links folgt und prüft, wo sie landen.

2. 404-Seiten und Soft 404

Ein echter 404 ist in Ordnung – die ehrliche Antwort auf eine fehlende Seite. Der Fehler beginnt, wenn eine fehlende Seite mit 200 OK antwortet und „nicht gefunden“ nur im Text steht. Das ist ein Soft 404: Das Monitoring hält die Seite für gesund, die Suchmaschine indexiert Müll. Prüfen lässt sich das mit einer Zeile:

curl -s -o /dev/null -w "%{http_code}\n" https://example.com/no-such-page-7c1/

Alles außer 404 oder 410 muss behoben werden. Der Scanner führt genau diesen Test aus – siehe, wie die 404-Behandlung geprüft wird.

3. Serverfehler (5xx)

500, 502 oder 503 bedeuten, dass der Server versagt hat, nicht der Besucher. Sporadische 5xx sind am schwersten zu fassen: Die Seite funktioniert, wenn Sie sie öffnen, und fällt unter Last, bei kaltem Cache oder bei bestimmten URL-Parametern aus. Suchen Sie in den Server-Logs und in jedem Crawl, der viele Seiten nacheinander abruft. Eine Seite, die mit einem Fehler antwortet, ist einer der wenigen Befunde, die immer kritisch sind: Sie ist für alle kaputt, und zwar jetzt.

4. JavaScript-Fehler in der Konsole

Eine geworfene Exception kann den Rest des Skripts stoppen: Das Menü öffnet sich nicht, der Warenkorb aktualisiert sich nicht, das Analytics-Tag feuert nie. Optisch kann die Seite dabei tadellos aussehen. Öffnen Sie DevTools → Console und laden Sie neu: Rote Zeilen sind Fehler, nicht abgefangene Exceptions die schlimmsten. Typische Ursachen sind ein Drittanbieter-Skript, das nicht geladen wurde, ein fehlendes Element, mit dem der Code rechnet, und ein 404 auf einem JS-Chunk nach einem Deployment. Wie Sie sie einordnen, erklärt der Beitrag zu Konsolenfehlern.

5. Formulare, die nicht funktionieren

Kontakt- und Bestellformulare sind die Stellen, an denen ein Fehler direkt Geld kostet. Typische Ausfälle: Das Formular hat kein action oder sendet an einen entfernten Endpunkt, die Validierung lehnt korrekte Eingaben ab (Telefonnummer mit Pluszeichen, Umlaute im Namen), der Absenden-Button reagiert wegen eines JS-Fehlers nicht, die Danke-Seite liefert 404. Schicken Sie nach jedem Release jedes Formular selbst ab; was Sie ausprobieren sollten, listet der Leitfaden zum Formular-Testing.

6. Mixed Content und defekte Bilder

Jede Ressource, die auf einer HTTPS-Seite über http:// geladen wird, ist gemischter Inhalt. Aktiven Mixed Content (Skripte, iframes) blockieren Browser sofort, passiven markieren sie – eine einzige alte Bild-URL kann Sie das Schloss in der Adressleiste kosten. Details im Beitrag zu Mixed Content. Defekte Bilder sind der visuelle Zwilling defekter Links: Die Bildadresse antwortet mit 404, auf der Seite bleibt ein leerer Rahmen.

Website auf Fehler prüfen mit SiteScan

1. Geben Sie die Adresse auf der Startseite ein. Ein kostenloser Scan öffnet bis zu zehn Seiten in einem echten Browser und sieht damit dasselbe wie ein Besucher, einschließlich JavaScript.
2. Sehen Sie sich im Bericht den HTTP-Status jeder Seite in der Tabelle „Seiten“ an sowie „Website-Prüfungen“ → „Interne Links“: Jeder interne Link der gelesenen Seiten wird abgerufen, tote Links stehen dort zusammen mit der Seite, auf der sie gefunden wurden.
3. Prüfen Sie die „404-Behandlung“ auf Soft 404, den Block „Browser-Konsole“ auf Fehler und Exceptions je Seite und die Bildprüfung auf Dateien, die nicht laden.
4. Beheben Sie die Fehler und klicken Sie auf „Neu scannen“. Angemeldet setzt die Schaltfläche „Diese Website überwachen“ die Domain auf einen Zeitplan, und der nächste Bericht zeigt, was neu, was behoben und was geblieben ist.

Beginnt ein Problem mit einem Symptom statt mit einem Fehlercode – „die Website ist langsam geworden“, „E-Mails landen im Spam“ –, geht es mit der Website-Diagnose weiter.