Website nicht erreichbar: Fehlersuche Schritt für Schritt

Wenn eine Website nicht lädt, kann der Fehler an vielen Stellen liegen: im eigenen Netz, beim DNS, beim Zertifikat, auf dem Server oder bei einem vorgeschalteten Dienst wie einem CDN. Ein Aufruf durchläuft diese Stationen immer in derselben Reihenfolge. Der Browser fragt zuerst das DNS nach der IP-Adresse, baut dann eine Verbindung auf, prüft das Zertifikat und bekommt zuletzt die Antwort des Webservers. Wer die Kette in dieser Reihenfolge prüft, findet die Ursache schneller als mit Raten. Diese Seite geht die Schritte der Reihe nach durch und nennt zu jedem das passende Werkzeug.

Schritt 1: Liegt es an dir oder an der Website?

Google empfiehlt in der Chrome-Hilfe als Erstes, die Adresse auf Tippfehler zu prüfen, die Seite neu zu laden und zu schauen, ob nur eine oder mehrere Websites betroffen sind. Gehen mehrere Seiten nicht, liegt das Problem meist an der eigenen Internetverbindung, an Router oder Modem ^[2]. Weitere Ursachen auf deiner Seite sind Erweiterungen im Browser, eine Firewall oder ein Virenschutz, der Verbindungen blockiert ^[2]. Ob eine Erweiterung schuld ist, testest du zuerst in einem Inkognitofenster. Lädt die Seite dort, deaktivierst du alle Erweiterungen und schaltest sie einzeln wieder ein, bis der Fehler zurückkommt ^[2]. In öffentlichen WLANs, etwa im Café oder am Flughafen, musst du dich oft erst auf einer Anmeldeseite des Netzes anmelden, bevor überhaupt eine Website lädt ^{[1, 2]}.

Ein schneller Gegentest: Ruf die Seite auf dem Handy über das Mobilfunknetz auf, mit ausgeschaltetem WLAN. Lädt sie dort, liegt der Fehler wahrscheinlich in deinem Netz oder auf deinem Rechner. Lädt sie auch dort nicht, liegt er wahrscheinlich bei der Website. Erst dann lohnen sich die nächsten Schritte.

Schritt 2: Die Fehlermeldung lesen

Der Browser sagt mit seiner Fehlermeldung oft schon, an welcher Station es hakt. Chrome nennt dazu Fehlercodes, eine vollständige Liste zeigt die interne Seite chrome://network-errors/ ^[1]. Die häufigsten lassen sich so zuordnen:

Die Angaben stammen aus der Chrome-Hilfe ^[1], bei den Zertifikatsmeldungen ergänzt um die Prüfpunkte aus Schritt 4 ^[6]. Andere Browser formulieren die Meldungen anders, die Stationen sind dieselben. Zeigt der Browser dagegen eine Seite mit einer Zahl wie 500, 502 oder 503, ist die Verbindung zum Server zustande gekommen, und der Server selbst meldet einen Fehler. Dann kannst du Schritt 3 und 4 überspringen und direkt zu Schritt 5 gehen.

Schritt 3: DNS prüfen

Ohne funktionierendes DNS findet kein Browser den Server. Frag mit dem DNS-Check die A- und AAAA-Einträge der Domain ab, auch für die Variante mit www. Drei Fragen helfen beim Einordnen:

• Gibt es überhaupt einen Eintrag? Fehlt er, wurde er gelöscht oder nie angelegt, oder die Domain ist abgelaufen. Ob sie noch registriert ist, zeigt eine Whois-Abfrage oder das Kundenkonto beim Registrar.
• Zeigt der Eintrag auf die richtige IP-Adresse? Nach einem Hosterwechsel steht dort oft noch der alte Server.
• Stimmen die NS-Einträge, also die zuständigen Nameserver? Ein Tippfehler beim Registrar legt die ganze Domain lahm.

Hast du kürzlich etwas geändert, sehen manche Nutzer noch die alte Antwort, bis die TTL des alten Eintrags abgelaufen ist. Bei einem Tag TTL kann das bis zu 24 Stunden dauern.

Ein Sonderfall ist DNSSEC. Ein Resolver, der Signaturen prüft, antwortet bei einer gescheiterten Prüfung mit dem Fehlercode SERVFAIL, auf Deutsch Serverfehler, und liefert die Adresse nicht aus ^[3]. Für Nutzer solcher Resolver ist die Domain dann nicht erreichbar, für andere schon. Dazu kann es kommen, wenn nach einem Nameserverwechsel beim Registrar noch ein alter DS-Eintrag hinterlegt ist, der zu keinem Schlüssel mehr passt.

Schritt 4: Das Zertifikat prüfen

Liefert das DNS die richtige Adresse, kommt als Nächstes das Zertifikat. Mit dem SSL-Check siehst du, wann es ausläuft, für welche Namen es gilt und wer es ausgestellt hat. Die Prüfpunkte, die Cloudflare für ungültige Zertifikate nennt, passen auch ohne CDN ^[6]:

• Das Zertifikat ist nicht abgelaufen und nicht widerrufen.
• Eine anerkannte Zertifizierungsstelle hat es signiert, es ist also nicht selbst signiert.
• Der aufgerufene Name steht im Zertifikat, als Common Name oder als Subject Alternative Name.
• Der Server liefert die vollständige Kette mit allen Zwischenzertifikaten aus.

Ein abgelaufenes Zertifikat ist eine typische Ursache in dieser Station. Let's-Encrypt-Zertifikate gelten 90 Tage und müssen deshalb automatisch erneuert werden ^[7]. Bricht die Erneuerung still ab, etwa weil der Server über Port 80 nicht mehr erreichbar ist, fällt das erst auf, wenn das Zertifikat abläuft. Tritt die Datumsmeldung nur auf einem Gerät auf, liegt es oft an dessen falsch eingestellter Uhr ^[1]. Mehr zu den einzelnen Meldungen steht unter Zertifikatsfehler im Browser verstehen und beheben.

Schritt 5: Den Server prüfen

Kommt eine Verbindung zustande, verrät der HTTP-Statuscode, was auf dem Server los ist. 500 heißt, dass der Server auf einen unerwarteten Zustand gestoßen ist. 503 steht für Überlastung oder Wartung. 502 und 504 bedeuten, dass ein vorgeschalteter Server vom eigentlichen Webserver eine ungültige oder keine rechtzeitige Antwort bekommen hat ^[8]. Die genaue Ursache steht im Fehlerprotokoll des Webservers, das du bei vielen Hostern in der Verwaltungsoberfläche findest. Was die einzelnen Codes bedeuten, erklärt HTTP-Statuscodes von 200 bis 503.

Lehnt der Server die Verbindung ab oder antwortet er gar nicht, kann der Webserver nicht laufen, nicht auf dem richtigen Port hören oder von einer Firewall blockiert werden. Ein Blick auf die Statusseite des Hosters zeigt, ob dort gerade eine Störung bekannt ist.

Liegt ein CDN wie Cloudflare vor dem Server, kommen eigene Codes dazu. Bei 521 lehnt der Ursprungsserver die Verbindungen von Cloudflare ab, häufig weil der Webserver nicht läuft oder Cloudflare-Adressen gesperrt sind ^[4]. Bei 522 hat Cloudflare innerhalb von 19 Sekunden keine Antwort auf den Verbindungsaufbau bekommen, oder nach dem Aufbau 90 Sekunden lang keine Bestätigung für die Anfrage. Als häufigste Ursache nennt Cloudflare gesperrte oder gedrosselte Cloudflare-Adressen beim Hoster ^[5]. 526 meldet, dass Cloudflare im Modus Full (strict) das Zertifikat auf dem Ursprungsserver nicht prüfen kann ^[6].

Schritt 6: Weiterleitungsschleifen und Subdomains

Meldet der Browser zu viele Weiterleitungen, leiten sich zwei Regeln gegenseitig weiter. Ein bekanntes Beispiel beschreibt Cloudflare: Steht der Verschlüsselungsmodus auf Flexible, fragt Cloudflare den Server über HTTP an. Leitet der Server jede HTTP-Anfrage auf HTTPS um, entsteht eine Schleife. Abhilfe ist, die Umleitung auf dem Server zu entfernen oder den Modus auf Full oder höher zu stellen, was ein Zertifikat auf dem Server voraussetzt ^[9]. Ohne CDN suchst du die Ursache in den Weiterleitungsregeln des Servers, etwa in der .htaccess, und in den Adresseinstellungen des CMS.

Ist nur eine Subdomain betroffen, prüfst du sie wie oben einzeln: DNS-Eintrag, Zertifikat, Server. Welche Subdomains für deine Domain öffentlich bekannt sind, zeigt der Subdomain-Finder. Er liest die öffentlichen Protokolle der Zertifikate aus. Taucht dort eine Subdomain auf, die du nicht mehr nutzt, solltest du ihren DNS-Eintrag entfernen.

Nach der Reparatur

Ein kurzer Ausfall muss für die Suche nicht folgenreich sein, eine genaue Frist nennt Google aber nicht. Google bremst das Crawlen, sobald viele Adressen Serverfehler liefern. Bereits aufgenommene Seiten bleiben zunächst im Index und verschwinden erst, wenn die Fehler anhalten. Antwortet der Server wieder normal, steigt die Crawlrate nach und nach an ^[10]. Ob einzelne Seiten aus dem Index gefallen sind, findest du mit Seite wird nicht indexiert: Ursachen finden heraus.

Damit derselbe Fehler nicht wiederkommt, lohnt sich eine einfache Überwachung. Let's Encrypt rät ausdrücklich dazu, die Erneuerung der Zertifikate zu überwachen und sich warnen zu lassen, wenn ein Zertifikat nicht rechtzeitig erneuert wird. Das wird wichtiger, weil die Laufzeit bis 2028 auf 45 Tage sinkt ^[11]. Überwachungsdienste können Ablaufwarnungen für Zertifikate schicken ^[12] und zusätzlich in festen Abständen prüfen, ob die Startseite antwortet. Bei der Domain schützt eine automatische Verlängerung, sofern der Registrar sie anbietet, vor einem versehentlichen Ablauf. Eine aktuelle Mailadresse im Kundenkonto sorgt dafür, dass Rechnungen und Hinweise ankommen.

1. Organisation Hilfe bei häufigen Fehlermeldungen in Chrome. Google. Stand ohne Datum. abgerufen am 29.10.2026
2. Organisation Verbindungs- und Ladefehler in Chrome beheben. Google. Stand ohne Datum. abgerufen am 29.10.2026
3. Gesetz RFC 4035: Protocol Modifications for the DNS Security Extensions, Abschnitt 5.5. IETF. Stand März 2005. abgerufen am 29.10.2026
4. Organisation Error 521. Cloudflare. Stand 23.04.2026. abgerufen am 29.10.2026
5. Organisation Error 522. Cloudflare. Stand 31.07.2026. abgerufen am 29.10.2026
6. Organisation Error 526. Cloudflare. Stand 12.10.2026. abgerufen am 29.10.2026
7. Organisation FAQ. Let's Encrypt (ISRG). Stand 28.04.2025. abgerufen am 29.10.2026
8. Gesetz RFC 9110: HTTP Semantics, Abschnitt 15.6. IETF. Stand Juni 2022. abgerufen am 29.10.2026
9. Organisation ERR_TOO_MANY_REDIRECTS. Cloudflare. Stand 01.09.2026. abgerufen am 29.10.2026
10. Organisation How HTTP status codes, and network and DNS errors affect Google Search. Google Search Central. Stand 04.02.2026. abgerufen am 29.10.2026
11. Organisation Decreasing Certificate Lifetimes to 45 Days. Let's Encrypt (ISRG). Stand 02.12.2025. abgerufen am 29.10.2026
12. Organisation Monitoring Service Options. Let's Encrypt (ISRG). Stand 13.07.2026. abgerufen am 29.10.2026

Zuletzt geprüft am 29.10.2026, nächste Prüfung spätestens im Oktober 2027. Fehler entdeckt? Schreib uns.