Erreichen alle Besucher Ihre Website zuverlässig?

„Bei mir geht’s“ ist nicht dasselbe wie „es geht bei allen“. Dass die Startseite in Ihrem eigenen Browser einmal lädt, beweist fast nichts – und „erreichbar“ sind eigentlich drei getrennte Fragen:

• DNS-Erreichbarkeit – löst der Name korrekt auf, auch auf Resolvern (den Servern, die Domainnamen in Adressen übersetzen), die Sie nicht kontrollieren?
• Verbindungs-Erreichbarkeit – schafft ein Besucher DNS, Verbindung und TLS? Ein Server, der mit einem abgelaufenen oder falschen Zertifikat antwortet, ist für viele Besucher praktisch down.
• Funktionale Erreichbarkeit – funktioniert auch der richtige Inhalt? Ein Server kann 200 OK melden und trotzdem eine Wartungsseite, einen Fehler oder eine halb geladene Anwendung zeigen.

Ein echter Erreichbarkeitstest prüft alle drei – so, wie echte Besucher sie erleben.

Warum ein Ladevorgang nichts beweist

• Ihr Browser und Ihr Netz sind ein Sonderfall. Lokale DNS-Caches, ein „warmer“ CDN-Server in Ihrer Nähe und Ihr eigener Resolver können eine kaputte Website von Ihrem Schreibtisch aus heil aussehen lassen.
• Die Startseite ist nicht die ganze Website. Eine funktionierende Startseite sagt nichts über ein Stylesheet, ein Skript, einen Login oder einen Checkout auf einem anderen Pfad oder einer anderen Subdomain.
• IPv4 und IPv6 können sich unterschiedlich verhalten. Viele reine IPv6-Netze erreichen IPv4-only-Websites über DNS64/NAT64 – aber diese Übersetzung gibt es nicht überall. Ein fehlender AAAA-Eintrag (die IPv6-Adresse im DNS) lässt die Website einfach IPv4-only; ein falscher oder unerreichbarer AAAA-Eintrag beschert Besuchern, deren Geräte zuerst IPv6 probieren, Verzögerungen oder Ausfälle. Wenn Sie also einen veröffentlichen: Testen Sie den kompletten IPv6-Weg (siehe DNS-Einträge erklärt).
• Sicherheitsschichten können echte Menschen aussperren. Ein CDN, eine Web Application Firewall, eine Bot-Regel oder eine Ländersperre kann eine gesunde Website aus bestimmten Ländern, bei bestimmten Anbietern oder für bestimmte IP-Bereiche unerreichbar machen. Umgekehrt gilt das auch: Testdienste werden selbst gern als Bots geblockt – nehmen Sie eine einzelne fehlgeschlagene Messung also als Anlass zum Nachschauen, nicht als Beweis für einen öffentlichen Ausfall.
• DNS hinkt nach. Nach einer Änderung liefern Resolver die alte Antwort, bis ihre Cache-Kopie abläuft – und manche halten Antworten länger fest, als sie sollten. Fragen Sie mehrere unabhängige Resolver ab und lassen Sie das alte Ziel weiterlaufen, bis die Prüfungen durchgängig den neuen Wert zeigen.

Testen wie ein echter Besucher

1. Jeder öffentliche Einstiegspunkt: die nackte Domain (der „Apex“), www, die Weiterleitung von HTTP auf HTTPS und wichtige Subdomains – jeder landet auf der beabsichtigten kanonischen URL, ohne Schleifen und ohne Zertifikatswarnung.
2. Status und Inhalt: Prüfen Sie bei wichtigen Seiten und Assets den erwarteten HTTP-Status, die End-URL nach den Weiterleitungen und ein unverwechselbares Stück Seiteninhalt – nicht nur, dass irgendetwas geantwortet hat.
3. Ein echter Browser, der etwas Echtes tut: Laden Sie die Seite mit Skripten und Styles und führen Sie eine Aktion aus, die zählt – bei einer reinen Präsentations-Website die Kontaktseite; bei einer Anwendung Login, Suche oder Checkout.
4. Verschiedene Regionen und verschiedene Netze: Mehrere Teststandorte können trotzdem beim selben Cloud-Anbieter liegen – variieren Sie also auch das Netz: Festnetz, Mobilfunk, und IPv4 und IPv6 getrennt, wo veröffentlicht.
5. Frisch, aber realistisch: Nehmen Sie eine neue Browsersitzung oder schalten Sie den Cache ab – testen Sie aber weiter über den normalen öffentlichen CDN-Weg, denn genau den bekommen Ihre Besucher.

Das ist eine Momentaufnahme: Sie sagt, dass die Website jetzt erreichbar ist, von dort, wo Sie getestet haben. Dass das rund um die Uhr so bleibt, ist Aufgabe des laufenden Monitorings.

Fazit: Belegen Sie alle drei Ebenen – Auflösung, Verbindung, Funktion – von vielen Orten und aus vielen Netzen, gegen Ihre echten Einstiegspunkte. Ein einzelner Ladevorgang der Startseite im eigenen Browser beantwortet keine davon.

Was zu tun ist

1. Testen Sie die nackte Domain, www, die HTTPS-Weiterleitungen und wichtige Subdomains auf die beabsichtigte kanonische URL – ohne Schleifen, ohne Zertifikatsfehler.
2. Rufen Sie die kritischen Seiten, CSS/JS, Bilder, Downloads und API-Endpunkte ab und prüfen Sie Status und erwarteten Inhalt.
3. Prüfen Sie aus mehreren Regionen und über mehrere Netzanbieter, auch mobil – und IPv4/IPv6 getrennt.
4. Veröffentlichen Sie einen AAAA-Eintrag erst, wenn der komplette IPv6-Weg getestet ist – ein kaputter ist schlimmer als keiner.
5. Lassen Sie nach DNS-Änderungen das alte Ziel laufen, bis unabhängige Resolver durchgängig die neue Antwort geben.
6. Beheben Sie, was bei anderen scheitert und bei Ihnen nicht – und richten Sie dann laufendes Monitoring ein, damit Sie von Ausfällen erfahren, bevor Ihre Besucher es tun.