Wenn eine Website nicht erreichbar ist, hilft ein geordneter Anfrageweg. Der Browser muss zuerst den Domainnamen auflösen, danach eine Verbindung zur richtigen Adresse herstellen und schließlich eine passende Website erhalten. Ein Fehler an einer frühen Station kann verhindern, dass WordPress überhaupt beteiligt ist. DNS, Verbindung und Anwendung werden deshalb getrennt geprüft.
Dieser Ratgeber beschreibt einen praktischen Diagnoseablauf. Er behauptet keine durchgeführte Prüfung einer bestimmten Domain. Das Beispiel ist eine Website, die nach einem Hostingwechsel teils noch den alten Stand zeigt.
Die Beobachtung zuerst genau festhalten
Notieren Sie die vollständige Adresse mit Protokoll und gegebenenfalls www. Ergänzen Sie Uhrzeit, Browsermeldung und den sichtbaren Inhalt. Zeigt die Website eine alte Seite, eine Standardseite oder gar keine Antwort? Diese Zustände können unterschiedliche Ursachen haben. Ein Screenshot der Meldung ist hilfreich, enthält aber keine Zugangswerte.
Prüfen Sie auch, ob alle Nutzer denselben Fehler sehen. Ein einzelnes Gerät kann andere zwischengespeicherte DNS-Antworten verwenden als ein unabhängiger Anschluss. Das macht die Beobachtung wertvoll, beweist aber noch keine fehlerhafte DNS-Konfiguration. Die nächsten Schritte sollen die beteiligten Stationen voneinander trennen.
Den autoritativen DNS-Stand abfragen
Die autoritativen Nameserver liefern die veröffentlichte Antwort für die Zone. Zunächst wird geprüft, welche Server tatsächlich zuständig sind. Danach werden die relevanten Namen direkt dort abgefragt. Hauptdomain und www sind eigene Namen und können unterschiedlich konfiguriert sein. Eine richtige Antwort für einen Namen bestätigt den anderen nicht.
A-Records enthalten IPv4-Adressen, AAAA-Records IPv6-Adressen. Ihre Werte müssen zum vorgesehenen Hosting passen. Prüfen Sie beide autoritativen Server, wenn mehrere vorhanden sind. Eine Abweichung wird mit Zeitpunkt und Antwort dokumentiert. Erst anhand dieses Bestands wird entschieden, ob ein Record verändert werden muss. Raten oder Kopieren aus einem fremden Projekt ist dafür keine Grundlage.
- Autoritative Antwort → veröffentlichte Adresse
- Normaler Resolver → vom Anschluss verwendete Antwort
- Verbindung → tatsächliches Ziel erreichen
- HTTPS und Website → Namen und Anwendung prüfen
Textalternative: Ein veröffentlichter DNS-Wert, eine zwischengespeicherte Resolverantwort und eine erfolgreiche Websiteverbindung sind drei unterschiedliche Nachweise. Keiner ersetzt die beiden anderen.
Den normalen Resolver mit dem Bestand vergleichen
Ein normaler DNS-Resolver kann Antworten für die vorgesehene TTL zwischenspeichern. Nach einer Änderung sieht er deshalb möglicherweise noch den alten Wert. Erfassen Sie seine Antwort und vergleichen Sie sie mit dem autoritativen Stand. Dabei zählt die tatsächliche Abfrage, nicht nur die Aussage, dass DNS irgendwann aktualisiert wurde.
Ein lokaler Cache-Reset kann eine Gerätebeobachtung verbessern, ändert aber keine autoritativen Records. Wenn mehrere Anschlüsse unterschiedliche Antworten sehen, wird der weitere Verlauf geprüft. Die pauschale Aufforderung, immer zwei Tage zu warten, ist keine Diagnose. Eine falsche autoritative Antwort wird durch Warten nicht richtig.
IPv4 und IPv6 unabhängig verbinden
Ein öffentlicher AAAA-Record ist sinnvoll, wenn das zugehörige Ziel die Website über echtes IPv6 korrekt bedient. Die bloße IPv4-Erreichbarkeit bestätigt diesen Weg nicht. Umgekehrt kann ein direkter Test einer IPv6-Adresse erfolgreich sein, obwohl öffentlich kein AAAA veröffentlicht wurde. Dann besteht ein technischer Testnachweis, aber noch kein öffentliches Dualstack-Angebot.
Prüfen Sie die Verbindungen deshalb getrennt und mit Hostnamenprüfung. IPv4-gemappte Schreibweisen wie ::ffff: mit einer IPv4-Adresse sind kein Nachweis für einen nativen öffentlichen IPv6-Pfad. Falls ein veröffentlichter Weg scheitert, wird seine Zuweisung, Erreichbarkeit und TLS-Konfiguration untersucht. Die erforderliche Serveradresse stammt aus dem tatsächlichen Hostingbestand.
Die Websitezuweisung vor WordPress prüfen
Eine Standardseite kann darauf hindeuten, dass der richtige Server erreicht wurde, aber die Domain noch falsch zugeordnet ist. Prüfen Sie im Hostingbestand die konkrete Domain, das eigene Abonnement und das Dokumentenverzeichnis. Die sichtbare Standardseite beweist nicht, dass noch kein Abonnement existiert.
Erst wenn Verbindung und Zuweisung passen, wird die Anwendung untersucht. WordPress-Adressen, Weiterleitungen und Cache können dann relevant sein. Der Beitrag TLS und Weiterleitungen erklärt die nächste Station. Bei einem Umzug ergänzt Hostingwechsel die Prüfung von Datenstand und Umschaltzeitpunkt.
Ein kurzes Prüfprotokoll schließen
Das Protokoll enthält Namen, autoritative Antworten, normalen Resolverstand, Verbindungen über IPv4 und IPv6 sowie das Ergebnis der Websitezuweisung. Jeder Punkt erhält Datum und tatsächliche Beobachtung. Ungeprüfte Stationen bleiben offen. Damit kann eine andere Person sehen, was bereits belegt ist und wo die Diagnose fortgesetzt werden muss.
Nach einer Veränderung werden genau die betroffenen Stationen erneut geprüft. Eine erfolgreiche Startseite am eigenen Gerät reicht als Abschluss nur dann, wenn das Ziel tatsächlich auf diesen einen Weg begrenzt war. Für eine öffentlich angebotene Website sollten die vorgesehenen Namen und Adressfamilien nachvollziehbar funktionieren. So entsteht eine belastbare Prüfung ohne pauschale Aussagen über alle Netze.
Quellen und Prüfstand
- Cloudflare: DNS-Record-Typen — geprüft 2026-10-07
Produktinformationen können sich ändern. Beispielarchitekturen sind redaktionelle Modelle. Unsere Methode und Grenzen