SEO-Tools
DNS-Checker: alle Einträge einer Domain abfragen
Fragt das DNS der eingegebenen Domain live ab und zeigt die veröffentlichten Einträge: auf welche Adressen sie auflöst, wohin die Post geht und ob die TXT-Einträge vorhanden sind, von denen die E-Mail-Authentifizierung abhängt.
Was dieser DNS-Checker meldet
Gelesen wird live und nicht aus einem Cache. Ein soeben geänderter Eintrag kann deshalb noch seinen alten Wert zeigen, wenn die Resolver dazwischen ihn gemäß TTL noch nicht verworfen haben.
- A- und AAAA-Einträge — die IPv4- und IPv6-Adressen, auf die der Host auflöst.
- MX-Einträge — die für die Domain zuständigen Mailserver.
- SPF als TXT-Eintrag — welche Server im Namen der Domain senden dürfen.
- DMARC als TXT-Eintrag auf der Subdomain _dmarc — wie mit Mails zu verfahren ist, die die Prüfung nicht bestehen.
Was DNS mit SEO zu tun hat
DNS liegt vor allem anderen. Löst ein Host nicht auf, erreicht kein Crawler die Site, und jedes weitere Signal ist gegenstandslos. Deshalb gehört DNS an den Anfang, wenn eine Site vollständig verschwindet statt nur in den Rankings nachzugeben.
DNS entscheidet außerdem, welcher Hostname real ist. Ein fehlender Eintrag für die www- oder die Nicht-www-Variante ist die häufigste Ursache dafür, dass eine Version funktioniert und die andere komplett scheitert — was danach wie ein Canonical- oder Weiterleitungsproblem aussieht, obwohl schlicht ein Eintrag fehlt.
| Eintrag | Beantwortet | Typischer Fehler |
|---|---|---|
| A / AAAA | Welcher Server diesen Host ausliefert | Nur www oder nur ohne www definiert |
| MX | Wohin die Post der Domain geht | Zeigt auf einen Host, den es nicht mehr gibt |
| TXT (SPF) | Wer im Namen der Domain senden darf | Zwei SPF-Einträge, wodurch beide ungültig werden |
| TXT (DMARC) | Was mit fehlgeschlagener Post geschieht | Fehlt, also wird nichts durchgesetzt |
Das Ergebnis lesen
Ein leeres Ergebnis für einen Eintragstyp ist nicht automatisch ein Fehler: Viele Domains veröffentlichen berechtigterweise keinen MX-Eintrag, weil sie keine Post versenden. Entscheidend ist, ob die Einträge zu dem passen, wofür die Domain tatsächlich genutzt wird. Löst der Host nicht auf, ist die Site überhaupt nicht indexierbar — beginnen Sie mit kann Google Ihre Site indexieren , und sehen Sie die Registrierungsdaten über die WHOIS-Abfrage .
- Warum wird ein alter Eintrag angezeigt, den ich bereits geändert habe?
- Resolver cachen Einträge für die Dauer ihrer TTL. Bis diese abgelaufen ist, kann eine Abfrage berechtigterweise den alten Wert liefern, obwohl der autoritative Server bereits den neuen hat.
- Schadet ein fehlender AAAA-Eintrag dem SEO?
- Nein. IPv6 ist optional, und Googlebot erreicht reine IPv4-Sites problemlos. Veröffentlichen Sie AAAA, wenn Ihr Hosting es unterstützt, aber sein Fehlen ist kein Mangel.
Was dieses Tool nicht leistet
„DNS prüfen“ meint mehrere verschiedene Aufgaben; dieses Tool deckt einen bestimmten Ausschnitt ab. Das offen zu sagen ist billiger als ein irreführendes Ergebnis.
| Gesucht | Dieses Tool | Stattdessen |
|---|---|---|
| A, AAAA, MX, SPF, DMARC einer Domain | Ja | — |
| Reverse DNS zu einer IP | Nein | dig -x oder der Hoster |
| Propagation über weltweite Resolver | Nein — ein Resolver, ein Moment | Ein Multi-Resolver-Propagationstool |
| Wem eine IP-Adresse gehört | Nein — nur Domains | Ein regionales Register (RIPE, ARIN) |
| DNS-Leak bei einem VPN | Nein | Ein VPN-Leak-Test |
- Ist das dasselbe wie nslookup oder dig?
- Gleiche Quelle, engere Frage. Mit nslookup und dig lässt sich jeder Record-Typ bei jedem Resolver abfragen; hier stehen die Einträge, die darüber entscheiden, ob eine Site erreichbar ist und ob ihre Mail authentifiziert wird — samt Bedeutung.
- Warum kein NS und kein CNAME?
- Sie ändern selten die Antwort auf „ist die Site erreichbar und kann sie Mail versenden“. Ein CNAME führt zu demselben A-Record, der bereits angezeigt wird, und ein Nameserver-Problem zeigt sich als gar kein A-Record.
Weitere Tools
Ruft die robots.txt des eingegebenen Hosts ab, meldet, ob sie existiert und ob sie alle Crawler blockiert, und liest parallel die Robots-Direktiven auf Seitenebene.
Sucht die Sitemap so, wie ein Crawler es tut — zuerst die Deklaration in der robots.txt, dann die üblichen Orte — und prüft anschließend, ob das Dokument als XML parst, und zählt die enthaltenen URLs.
Liest die von der Seite deklarierte kanonische URL und ruft diese Adresse anschließend ab, um zu bestätigen, dass sie erreichbar ist, nicht weiterleitet und kein noindex trägt — die drei Wege, auf denen ein Canonical still wirkungslos wird.
Analysiert die strukturierten Daten der eingegebenen Seite, listet die gefundenen schema.org-Typen auf und markiert Blöcke, die nicht parsen oder denen die von ihrem Typ verlangten Eigenschaften fehlen.
Folgt der eingegebenen URL über jeden Schritt und meldet den Statuscode jeder Station sowie das endgültige Ziel — genau das Detail, das der Browser verbirgt, sobald die Adresszeile zur Ruhe kommt.
Lädt die angegebene Seite, nimmt eine Stichprobe ihrer internen Links und ruft jeden davon ab — und meldet den zurückgegebenen Statuscode statt der Farbe des Links.
Prüft jedes Signal, das darüber entscheidet, ob eine Seite in den Index darf: Statuscode, Zugriff laut robots.txt, Meta-Robots, den X-Robots-Tag-Header und das Canonical.
Fragt das Registry über RDAP ab — den strukturierten Nachfolger des klassischen WHOIS — und meldet, wann die Domain registriert wurde, wie alt sie ist, wer der Registrar ist und wann die Registrierung endet.
Geben Sie eine Domain ein, um Registrierung, Alter, Ablaufdatum und Registrar zu sehen. Das Domain-Alter liefert Kontext, ist aber kein Google-Rankingfaktor.
Öffnet eine TLS-Verbindung zum eingegebenen Host und meldet das präsentierte Zertifikat: Aussteller, Gültigkeitszeitraum, verbleibende Tage und die ausgehandelte Protokollversion.
Fordert die eingegebene URL an und meldet, was der Server in seinen Headern zurückgibt: welche Sicherheits-Header gesetzt sind, welche Caching-Richtlinie gilt, ob komprimiert wird und welche HTTP-Version ausgehandelt wurde.