Who-Is Domain-Abfrage: So finden Sie Daten zur Domain-Inhaberschaft

„Who-Is Domain-Abfrage“ ist die gängige Umschreibung dafür, nachzuschlagen, wer einen Domainnamen registriert hat. Dahinter stehen WHOIS und sein strukturierter Nachfolger RDAP. Dieser Artikel erklärt, was diese Protokolle im Jahr 2026 tatsächlich zurückliefern, warum die Kontaktfelder des Inhabers fast immer geschwärzt sind und welche Domain-Daten sich weiterhin in großem Umfang beziehen lassen — einschließlich dessen, was WebTrackly veröffentlicht und, mindestens ebenso wichtig, was nicht.

TL;DR / DIE WICHTIGSTEN PUNKTE

• WHOIS beantwortet genau eine eng gefasste Frage: was Registry und Registrar zur Registrierung einer Domain festhalten — Anlage- und Ablaufdatum, Registrar, Statuscodes und Nameserver.
• Die Kontaktfelder des Inhabers sind geschwärzt. Seit dem Wirksamwerden der DSGVO im Jahr 2018 verlangen die Temporary Specification von ICANN und die daraus hervorgegangene Richtlinie, dass die meisten gTLD-Antworten aus WHOIS/RDAP Name, Anschrift, Telefonnummer und Postfach des Inhabers verbergen. Es gibt keinen legitimen Weg, diese Felder in großem Umfang zu beziehen.
• RDAP hat WHOIS als Standardprotokoll abgelöst. Es liefert JSON über HTTPS statt unstrukturiertem Text und bietet einen dokumentierten Bootstrap-Mechanismus, um den richtigen Server zu finden.
• Was sich dagegen gut skalieren lässt, sind Infrastrukturdaten: welche Domains in einer TLD existieren, ihre Nameserver, Mailserver, aufgelösten IP-Adressen sowie das auf der Live-Website erkannte CMS oder Web-Framework.
• WebTrackly veröffentlicht genau diese Infrastrukturdaten als herunterladbare Dateien — Das Downloadformat hängt vom Paket ab und wird auf der Produktseite angegeben.
• Die Dateien enthalten keine persönlichen Kontaktdaten. Keine Inhabernamen, keine Postfachadressen, keine Telefonnummern, keine Intent-Daten. Wer das braucht, ist mit diesem Datensatz falsch beraten.

INHALTSVERZEICHNIS

• Was „Who-Is Domain-Abfrage“ tatsächlich bedeutet
• Was ein WHOIS-Eintrag enthält, Feld für Feld
• Warum Inhaberkontakte seit der DSGVO geschwärzt sind
• RDAP: der strukturierte Nachfolger von WHOIS
• Die Grenzen von Einzelabfragen pro Domain
• Was WebTrackly tatsächlich veröffentlicht
  • Aufbau des Katalogs
  • Abdeckung in Zahlen
  • Das Dateischema
  • Was die Dateien nicht enthalten
• Der reale Ablauf: kaufen, herunterladen, lokal verarbeiten
• Die API: ein Katalog, keine Domainsuche
• Preise und Auslieferung
• Häufige Fehler im Umgang mit Domain-Daten
• Häufig gestellte Fragen
• WEITERFÜHRENDE RESSOURCEN

Was „Who-Is Domain-Abfrage“ tatsächlich bedeutet

Jeder Domainname wird über einen Registrar registriert, der die Registrierung wiederum an die Registry meldet, die die jeweilige Top-Level-Domain betreibt. Beide Seiten führen einen Eintrag zu dieser Registrierung, und beide stellen der Öffentlichkeit eine Abfrageschnittstelle bereit. WHOIS, definiert in RFC 3912, ist die älteste davon: ein einfacher TCP-Dienst auf Port 43, der einen Domainnamen entgegennimmt und Freitext zurückgibt.

Dieser Text ist das, was Menschen mit einer „Who-Is Domain-Abfrage“ meinen. Es handelt sich um einen Registrierungseintrag, nicht um ein Unternehmensprofil. Er beschreibt das Verwaltungsverhältnis zwischen Inhaber, Registrar und Registry. Er sagt nichts darüber aus, was die Website tut, wer dort arbeitet oder womit das Unternehmen sein Geld verdient — dafür war er nie gedacht.

Die Verwirrung rührt daher, dass der Eintrag früher Name, Postanschrift, Telefonnummer und Postfach des Inhabers enthielt. Rund zwei Jahrzehnte lang war WHOIS damit faktisch ein öffentliches Verzeichnis. Diese Ära endete 2018, und die Enttäuschung, die viele bei einer heutigen Abfrage empfinden, geht größtenteils auf diese Änderung zurück.

Was ein WHOIS-Eintrag enthält, Feld für Feld

Eine typische gTLD-Antwort enthält, ob aus WHOIS oder RDAP, folgende Informationskategorien:

• Domainname und seine internationalisierte Form, dazu die registryinterne Domain-ID.
• Registrar — Name, IANA-ID, Missbrauchskontakt und der eigene WHOIS-Server des Registrars.
• Datumsangaben — Anlage, letzte Aktualisierung und Ablauf. Das sind die zuverlässigsten Felder im gesamten Eintrag und der Grund, warum sich Registrierungsdaten überhaupt auswerten lassen.
• Statuscodes — EPP-Status wie clientTransferProhibited, serverHold, pendingDelete oder redemptionPeriod. Sie beschreiben den Lebenszyklus der Registrierung und sind wirklich aussagekräftig: Eine Domain im Status redemptionPeriod ist abgelaufen und befindet sich in der Wiederherstellungsfrist.
• Nameserver — die für die Domain delegierten autoritativen DNS-Server. Dieses Feld ist per Richtlinie öffentlich und eines der wenigen, das vollständig bleibt.
• DNSSEC — ob die Delegation signiert ist.
• Kontaktobjekte — Inhaber, Admin, Tech und Billing. In der überwiegenden Mehrheit der gTLD-Einträge sind das heute geschwärzte Platzhalter.

Die Abdeckung variiert je nach TLD. ccTLD-Registries legen ihre eigene Richtlinie fest: Manche veröffentlichen einen vollständigeren Eintrag als gTLDs, viele deutlich weniger, und einige begrenzen ihren WHOIS-Dienst per Rate-Limit oder sperren ihn hinter einem CAPTCHA. Es gibt keinen globalen Standard dafür, was eine „Who-Is Domain-Abfrage“ enthalten muss, abgesehen vom ICANN-Vertrag, der nur gTLDs bindet.

Warum Inhaberkontakte seit der DSGVO geschwärzt sind

Als die Datenschutz-Grundverordnung im Mai 2018 durchsetzbar wurde, war es nicht länger haltbar, die persönlichen Daten sämtlicher in der EU ansässiger Domaininhaber in einem anonym abfragbaren Verzeichnis zu veröffentlichen. ICANN verabschiedete eine Temporary Specification, die Vertragspartner verpflichtete, die meisten Kontaktfelder des Inhabers aus der öffentlichen Ausgabe herauszuhalten; später wurde dies in der Registration Data Policy festgeschrieben. In der Praxis wendeten Registrare die Schwärzung weltweit an, statt zu ermitteln, welche Inhaber überhaupt dem EU-Recht unterliegen.

Die praktischen Folgen für alle, die auf diesen Daten aufbauen:

• Name, Organisation, Straße, Ort, Postleitzahl, Telefonnummer und Postfach des Inhabers werden durch Zeichenfolgen wie REDACTED FOR PRIVACY oder Data Protected ersetzt.
• Land und teils Bundesland oder Provinz bleiben in vielen Einträgen erhalten — deshalb lassen sich Länderverteilungen aus Registrierungsdaten weiterhin teilweise ableiten.
• Registrare stellen in der Regel ein anonymisiertes Relay bereit — ein Webformular oder eine domainspezifische Weiterleitungsadresse —, über das man den Inhaber erreichen kann, ohne dessen Identität offenzulegen. Solche Relays sind keine extrahierbaren Kontaktdaten und von vornherein rate-limitiert.
• Zugang zu ungeschwärzten Daten besteht nur über kontrollierte, antragsbasierte Kanäle für Parteien mit nachgewiesener Rechtsgrundlage, die im Einzelfall geprüft werden. Das ist kein Massendatenstrom, und kein kommerzieller Datensatz kann ihn rechtmäßig ersetzen.

Privacy- und Proxy-Dienste gab es schon vor der DSGVO; sie fügen eine zweite Ebene hinzu: Selbst dort, wo eine Registry Kontaktdaten veröffentlichen würde, kann der Inhaber für einen Proxy bezahlt haben, der als nomineller Halter auftritt. Zwischen Schwärzung und Proxy-Nutzung ist WHOIS als Quelle für Kontaktinformationen in keiner Größenordnung mehr eine tragfähige Strategie.

RDAP: der strukturierte Nachfolger von WHOIS

RDAP — das Registration Data Access Protocol, spezifiziert in RFC 7480 bis RFC 7484 sowie RFC 9082/9083 — wurde entworfen, um die strukturellen Schwächen von WHOIS zu beheben. Es läuft über HTTPS, liefert JSON, unterstützt Internationalisierung sauber und definiert eine von IANA veröffentlichte Bootstrap-Datei, mit der ein Client ermitteln kann, welcher Server für eine gegebene TLD oder einen IP-Bereich autoritativ ist. Alle gTLD-Registries und -Registrare müssen seit 2019 RDAP-Dienste betreiben; die Pflicht zum WHOIS-Dienst auf Port 43 wurde anschließend ausgesetzt.

Eine minimale Abfrage sieht so aus:

# Find the authoritative RDAP base URL for the TLD
curl -s https://data.iana.org/rdap/dns.json | jq '.services[] | select(.[0][] == "com")'

# Query a domain
curl -s https://rdap.verisign.com/com/v1/domain/example.com | jq '{
  ldhName,
  status,
  events: [.events[] | {eventAction, eventDate}],
  nameservers: [.nameservers[].ldhName]
}'

Entscheidend an dieser Ausgabe ist ihre Struktur. Events, Status und Nameserver sind strukturiert und gefüllt. Das Array entities — dort stehen Inhaber-, Admin- und Tech-Kontakte — enthält eine Registrar-Entität mit Missbrauchskontakt sowie eine Inhaber-Entität, deren vCard-Felder geschwärzt sind. RDAP hat die Kodierung verändert, nicht die Offenlegungsrichtlinie.

RDAP ist zudem rate-limitiert, pro Abfrage und pro Domain. Es ist das richtige Werkzeug, um eine einzelne Domain zu prüfen, ein Ablaufdatum zu verifizieren oder vor einem Transfer einen Statuscode zu kontrollieren. Es ist das falsche Werkzeug, um einen Datensatz mit einer Million Domains aufzubauen.

Die Grenzen von Einzelabfragen pro Domain

Angenommen, Sie wollen eine Frage beantworten wie „Wie viele Domains dieser TLD laufen auf WordPress?“ oder „Welche Nameserver sind in .de am häufigsten?“. Ein Protokoll, das nur einzelne Domains kennt, kann das nicht leisten. Sie müssten zuerst die Grundgesamtheit der Domains kennen, dann jede einzeln abfragen und anschließend jede Website separat abrufen, weil WHOIS und RDAP nichts darüber aussagen, welche Software eine Site betreibt.

Dafür sind drei getrennte Datenquellen nötig:

1. Die Grundgesamtheit — welche Domains in einer Zone überhaupt existieren. Sie stammt aus Zonendateien oder gleichwertigen, von der Registry abgeleiteten Listen, nicht aus WHOIS.
2. DNS-Auflösung — Nameserver, Mailserver und A-Records jeder Domain, ermittelt durch Auflösung.
3. Plattformerkennung — was die Live-Website zurückgibt, ermittelt durch Abruf und Abgleich von Signaturen in HTML, Headern und Asset-Pfaden.

Das selbst zu bauen, ist ein echtes Engineering-Projekt: Zugangsvereinbarungen für Zonendateien oder gleichwertige Quellen, eine Resolver-Farm, die nicht sofort ins Rate-Limit läuft, ein höflicher Crawler und Speicher für Hunderte Millionen Zeilen. Das Ergebnis einer solchen Pipeline als Datei zu kaufen, ist meist günstiger als der Nachbau.

Was WebTrackly tatsächlich veröffentlicht

Aufbau des Katalogs

Der Katalog von WebTrackly umfasst 1.538 Pakete in vier Ausprägungen:

Zonenpakete lassen sich unter /zones/ durchsehen, kuratierte Zusammenstellungen unter /datasets/ und der vollständige Katalog unter /packages/.

Abdeckung in Zahlen

• 285.582.781 Domains über alle Zonen hinweg.
• 163.422.083 Domains allein in .com.
• 21.639.326 Domains mit erkanntem WordPress.
• 567.680 Domains mit erkanntem Joomla.
• 272.614.863 Zeilen im Datensatz aller registrierten Domains.

Diese Zahlen sollte man genau lesen. Der WordPress-Wert zählt Domains, auf deren Live-Website WordPress erkannt wurde — er ist weder eine Zählung aller existierenden WordPress-Installationen noch die Behauptung, jede Domain im Katalog sei abgerufen worden. Erkennung setzt eine antwortende Website voraus; geparkte, weitergeleitete und nicht auflösende Domains stehen zwar in den Zonenlisten, tragen aber keinen Plattformwert.

Das Dateischema

Ein angereichertes Zonenpaket ist eine CSV-Datei mit ungefähr dieser Struktur:

domain,created,ns,mx,ip,cms
example.com,2011-04-17,ns1.example-dns.net;ns2.example-dns.net,mx1.mailhost.net,203.0.113.14,WordPress
sample.com,,ns1.hoster.io;ns2.hoster.io,,198.51.100.7,

Anmerkungen zu den Feldern, denn die Einschränkungen wiegen schwerer als die Kopfzeile:

• domain — immer vorhanden. Das ist der Primärschlüssel.
• created — das Registrierungsdatum, nur dort gefüllt, wo die Registry es veröffentlicht. Viele ccTLDs tun das nicht, außerhalb der großen gTLDs ist diese Spalte also dünn besetzt.
• ns — die delegierten Nameserver. Nützlich für Hosting- und DNS-Provider-Analysen und eine der vollständigsten Spalten der Datei.
• mx — die Mail-Exchange-Records der Domain: die Hostnamen der Server, die Mail für sie annehmen, etwa ein Endpunkt von Google Workspace oder Microsoft 365. Das sind Servernamen, keine Postfachadressen.
• ip — die zum Erhebungszeitpunkt aufgelöste Adresse. Sites hinter einem CDN lösen auf dessen Edge auf — eine Aussage über das CDN, nicht darüber, wo der Origin steht.
• cms — die auf der Live-Website erkannte Plattform; leer, wenn nichts erkannt wurde oder die Site nicht geantwortet hat.

Was die Dateien nicht enthalten

Klar benannt, damit vor dem Kauf keine Unklarheit bleibt:

• Keine persönlichen Kontaktdaten. Keine Inhabernamen, keine Postfachadressen, keine Telefonnummern, keine namentlich genannten Personen in irgendeinem Unternehmen. Das ist eine bewusste Designentscheidung und eine Folge der oben beschriebenen Schwärzung — diese Daten sind in dieser Größenordnung nicht rechtmäßig verfügbar, und jeder Anbieter, der sie in Masse anbietet, gehört kritisch hinterfragt.
• Keine Intent- oder Kaufsignale. Nichts darüber, ob eine Organisation gerade eine Anschaffung prüft.
• Keine Schätzungen zu Traffic, Umsatz oder Mitarbeiterzahl.
• Kein Abfragedienst für einzelne Domains. Das Produkt sind Massendateien, keine Abfrage-API für einzelne Domains. Für eine einzelne Domain nutzen Sie RDAP direkt, wie oben gezeigt.
• Keine Technologiesuche in der Oberfläche. Die Gruppierung nach Technologie existiert als Satz vorbereiteter Pakete; sie ist kein interaktiver Query-Builder.

Der reale Ablauf: kaufen, herunterladen, lokal verarbeiten

Der Ablauf ist bewusst schlicht, und alles nach dem Download passiert auf Ihrem eigenen Rechner:

1. Paket auswählen unter /packages/, /zones/ oder /datasets/, je nach Zone oder Plattform, die Sie interessiert.
2. Kaufen. Der Export wird im Moment des Kaufs frisch erzeugt statt aus einem veralteten, vorgefertigten Archiv ausgeliefert.
3. ZIP sofort herunterladen — die Auslieferung erfolgt als direkter Download, mit CSV im Archiv.
4. Entpacken und lokal auswerten. Keine API-Roundtrips, keine Abrechnung pro Zeile.

unzip com-enriched.zip
wc -l com-enriched.csv

# Quick filtering with standard tools
grep -c ',WordPress$' com-enriched.csv
awk -F, '$6 == "Joomla" { print $1 }' com-enriched.csv > joomla-domains.txt

Bei mehr als ein paar Millionen Zeilen ist eine spaltenorientierte Engine deutlich angenehmer als Shell-Werkzeuge. DuckDB liest CSV direkt, ganz ohne Importschritt:

-- DuckDB: top name server providers in a zone
SELECT
    regexp_extract(split_part(ns, ';', 1), '([^.]+\.[^.]+)$', 1) AS ns_domain,
    count(*) AS domains
FROM read_csv_auto('com-enriched.csv')
WHERE ns IS NOT NULL AND ns <> ''
GROUP BY 1
ORDER BY domains DESC
LIMIT 25;

-- Registration cohorts, where the registry publishes creation dates
SELECT date_trunc('year', created) AS cohort, count(*) AS domains
FROM read_csv_auto('com-enriched.csv')
WHERE created IS NOT NULL
GROUP BY 1
ORDER BY 1;

ClickHouse ist die bessere Wahl, wenn Sie mehrere Zonen dauerhaft geladen halten und wiederholt abfragen wollen:

CREATE TABLE domains
(
    domain  String,
    created Nullable(Date),
    ns      String,
    mx      String,
    ip      String,
    cms     LowCardinality(String)
)
ENGINE = MergeTree
ORDER BY domain;

INSERT INTO domains
SELECT * FROM file('com-enriched.csv', 'CSVWithNames');

Typische Auswertungen auf dieser Basis: Hosting- und DNS-Marktanteile je Zone, CMS-Verteilung über TLDs hinweg, Konzentration der Mail-Provider, Registrierungskohorten für Zonen, die Anlagedaten veröffentlichen, sowie Clustering von IP-Bereichen, um Infrastruktur eines einzelnen Anbieters zu identifizieren.

Die API: ein Katalog, keine Domainsuche

Die API stellt den Paketkatalog bereit. Sie können damit erkunden und prüfen, was verfügbar ist, und Kaufentscheidungen automatisieren; einzelne Domains durchsucht sie nicht, denn Domain-Daten werden als Dateien ausgeliefert.

# List zone packages
curl -s "https://webtrackly.com/api/v1/packages/?type=zone" \
  -H "Authorization: Bearer YOUR_API_KEY"

# Find technology packages matching a term
curl -s "https://webtrackly.com/api/v1/packages/?type=technology&q=wordpress" \
  -H "Authorization: Bearer YOUR_API_KEY"

# Inspect a single package
curl -s "https://webtrackly.com/api/v1/packages/{slug}/" \
  -H "Authorization: Bearer YOUR_API_KEY"

Ein minimaler Python-Client für dieselben Endpunkte:

import requests

BASE = "https://webtrackly.com/api/v1"
HEADERS = {"Authorization": "Bearer YOUR_API_KEY"}

zones = requests.get(f"{BASE}/packages/", headers=HEADERS,
                     params={"type": "zone"}).json()

for pkg in zones.get("results", []):
    print(pkg["slug"], pkg.get("domains_count"))

detail = requests.get(f"{BASE}/packages/com/", headers=HEADERS).json()
print(detail)

Die vollständige Endpunkt-Dokumentation finden Sie unter /api/.

Preise und Auslieferung

Einzelne Pakete sind Einmalkäufe ab $3.50: Das Downloadformat hängt vom Paket ab und wird auf der Produktseite angegeben. Zwei Abo-Pläne decken die wiederholte Nutzung ab:

Aktuelle Details stehen unter /pricing/.

Häufige Fehler im Umgang mit Domain-Daten

1. Von WHOIS erwarten, dass es ein Unternehmen identifiziert. Es identifiziert eine Registrierung. Schon vor der Schwärzung war der Inhaber häufig ein Hoster, eine Agentur oder ein Proxy-Dienst statt der Organisation hinter der Website. Nutzen Sie Registrierungsdaten für Fragen zu Lebenszyklus und Delegation und Infrastrukturdaten für Fragen zur Site selbst.

2. Eine aufgelöste IP für den Origin-Server halten. Jede Domain hinter einem CDN oder Reverse Proxy löst auf die Edge auf. Wer IPs ohne Berücksichtigung dessen aggregiert, erzeugt ein Diagramm über CDN-Verbreitung, das aussieht wie eines über Hosting.

3. Eine leere CMS-Spalte als „kein CMS“ deuten. Leer heißt, dass nichts erkannt wurde — das schließt Sites ein, die nicht geantwortet haben, weitergeleitet wurden, den Abruf blockiert haben oder etwas ohne verlässliche Signatur betreiben. Weisen Sie Erkennungsraten zusammen mit Erkennungszahlen aus, sonst lügt der Nenner stillschweigend.

4. Fehlende Anlagedaten als neue Registrierungen lesen. Viele ccTLD-Registries veröffentlichen Anlagedaten überhaupt nicht. Eine dünn besetzte Spalte ist ein Artefakt der Richtlinie, kein Signal über das Alter einer Domain.

5. Ignorieren, wie schnell diese Daten altern. Domains laufen ab, Nameserver wechseln, Sites werden neu gebaut. Jeder Snapshot ist eine Momentaufnahme. Hängt eine Entscheidung vom aktuellen Zustand ab, laden Sie das betreffende Paket neu, statt eine Datei vom letzten Quartal wiederzuverwenden.

6. Hunderte Millionen Zeilen in eine Tabellenkalkulation laden. Tabellenkalkulationen stoßen weit vor diesen Dateien an ihre Grenzen. Eine spaltenorientierte Engine bewältigt die vollständige .com-Zone bequem auf einem Laptop; eine Tabellenkalkulation öffnet sie erst gar nicht.

Häufig gestellte Fragen

F: Bekomme ich über eine WHOIS-Abfrage Inhabernamen und Kontaktdaten?
A: Bei den meisten gTLD-Domains nein. Die Kontaktfelder des Inhabers sind geschwärzt, seit die Post-DSGVO-Richtlinie von ICANN 2018 in Kraft trat. Registrare bieten in der Regel ein anonymisiertes Relay an, um einen Inhaber ohne Offenlegung seiner Identität zu erreichen, und für Parteien mit nachgewiesener Rechtsgrundlage existiert ein kontrollierter, antragsbasierter Zugang. Beides ist keine Massenquelle, und die Dateien von WebTrackly enthalten keinerlei persönliche Kontaktdaten.

F: Was ist der Unterschied zwischen WHOIS und RDAP?
A: RDAP ist der standardisierte Ersatz. Es liefert JSON über HTTPS, unterstützt internationalisierten Text sauber und veröffentlicht eine IANA-Bootstrap-Datei, damit Clients den autoritativen Server für jede TLD finden. WHOIS gibt unstrukturierten Text über Port 43 zurück, dessen Format sich zwischen Registries unterscheidet. RDAP hat Kodierung und Transport verändert, nicht aber den Umfang der Offenlegung.

F: In welchem Format kommen die Pakete von WebTrackly?
A: Das Downloadformat hängt vom Paket ab und wird auf der Produktseite angegeben. Der Export wird im Moment des Kaufs erzeugt statt aus einem vorgefertigten Archiv ausgeliefert.

F: Wie viele Domains sind abgedeckt?
A: 285.582.781 über alle Zonen hinweg, davon 163.422.083 in .com. Der Datensatz aller registrierten Domains umfasst 272.614.863 Zeilen. Die Technologiepakete decken 21.639.326 Domains mit erkanntem WordPress und 567.680 mit Joomla ab.

F: Kann ich über WebTrackly eine einzelne Domain abfragen?
A: Nein. Das Produkt sind Massendateien, organisiert nach Zone, Technologie oder kuratiertem Datensatz. Für eine einzelne Domain fragen Sie RDAP direkt ab — das ist kostenlos, für Registrierungsdaten autoritativ und braucht genau einen HTTP-Request.

F: Kann ich mit der API Domains nach Technologie oder Land filtern?
A: Die API stellt den Paketkatalog bereit, keine Abfrage-Engine auf Domain-Ebene. Sie können Pakete nach Typ und Suchbegriff auflisten und filtern und anschließend die passenden kaufen und herunterladen. Das Filtern einzelner Zeilen passiert lokal, in DuckDB, ClickHouse oder dem Werkzeug Ihrer Wahl.

F: Wie aktuell sind die Daten?
A: Exporte werden zum Kaufzeitpunkt aus dem aktuellen Katalogstand erzeugt. Da sich das Web laufend verändert, behandeln Sie jeden Download als Snapshot und laden Sie ihn vor Entscheidungen, die vom heutigen Zustand abhängen, erneut.

F: Wie sehen die Plan-Limits aus?
A: Pro kostet $29/Monat für 50 Pakete, 10 Datensätze und 30.000 API-Aufrufe. Enterprise kostet $99/Monat für 200 Pakete, 50 Datensätze und 300.000 API-Aufrufe. Einzelne Pakete lassen sich zudem einmalig ab $3.50 kaufen. Siehe /pricing/.

WebTrackly veröffentlicht Daten zu Domain-Zonen, DNS und CMS-Erkennung als herunterladbare Dateien.
Domain-Daten ansehen → | Preise ansehen →

Weiterführende Ressourcen

• Paketkatalog — über 1.500 herunterladbare Domain-Datenbanken
• Zonendateien nach TLD — .com, .net, .de und 700+ weitere
• Kuratierte Datensätze — alle registrierten Domains, MX-Server, E-Commerce
• Preise — Einmalkäufe ab $3.50