How to find out who owns a website: programmatic owner identification

Who owns this website? People ask some version of that question millions of times a month. Who is behind this site. Who owns this domain. Is this company even real. The person asking might be a journalist confirming who funds an outlet, a buyer checking if a domain is parked, a security team tracing a phishing page, or a founder vetting a partner. Different motives, same question, same wall: WHOIS says REDACTED, and the IP says Cloudflare.

So we did the obvious thing. We took 26 real domains, including the awkward ones, and asked the WhoisGenius API who owns each of them. Everything below is a real result from those runs. The whole experiment cost 65 credits, and every command is included so you can rerun it.

The warmup: the question takes one API call

curl -X POST "https://api.whoisgeni.us/analyze" \
  -H "X-API-Key: wg_YOUR_KEY" -H "Content-Type: application/json" \
  -d '{"domain": "stripe.com", "depth": "quick"}'

depth=quick runs the fast collectors (DNS, WHOIS, HTTP probe, ASN, reverse DNS) synchronously and answers in about ten seconds. Stripe came back confirmed at 1.0 confidence. Dropbox the same, legal entity “Dropbox, Inc.” attached. Boring, which is the point: most real businesses answer cleanly.

The headline of every response is data.scoring_result.attribution:

{
  "verdict": "confirmed",
  "operator": "Dropbox",
  "entity_name": "dropbox",
  "confidence": 1.0,
  "ownership_signals": 3,
  "corroborating_correlations": 2,
  "content_protected": false,
  "rationale": "Multiple independent ownership signals agree on Dropbox, corroborated, with no serious rival candidate."
}

Two shape details worth learning now, because they bite everyone:

• ownership_signals is a count, not a list. The per-signal evidence (which collector saw what, whether it was redacted) lives at GET /jobs/{job_id}/signals.
• parent_company, legal_entity, and impersonation_suspected live on scoring_result.entities[], not on the attribution block. Code that reads them from attribution silently gets nothing.

For full depth (certificate history, vision analysis, Wikidata parent resolution), drop the depth field. Deep runs async: you get a 202 and a job_id, and you poll GET /jobs/{job_id} for a minute or two. Adding ?wait=true holds the request for up to 20 seconds and answers inline if the run finishes in time, but deep runs usually outlast the hold, so expect to poll.

The redaction wall: spiegel.de says nothing, and answers anyway

Look up spiegel.de in WHOIS and you get nothing at all. DENIC does not publish .de registrant data. No name, no organization, no country. This is the case that kills every WHOIS-lookup tool.

We ran three German news sites through the API:

Domain	Verdict	Operator	Confidence
spiegel.de	likely	DER SPIEGEL	0.925
heise.de	likely	Heise Medien	0.83
sueddeutsche.de	possible	Sueddeutsche	0.7

Spiegel was recovered from the JSON-LD organization on the page itself. Heise came through the site’s copyright line, and here’s what real data looks like: the raw string came back as “Heise MedienVertrag widerrufen”, because the imprint page’s text bled into the parse. The normalized entity still resolved to the right company. Production data is messy. Grade on the verdict and confidence, not on perfect strings.

The brick wall: when the honest answer is “no idea”

downloadpage.xyz sits behind Dynadot’s privacy proxy. WHOIS lists “Super Privacy Service LTD c/o Dynadot”. No imprint, no certificate organization, nothing on the page that names anyone.

The API’s answer: inconclusive, 0.4. The only surviving signal was the domain name itself, and the rationale says so in plain words: only the domain name suggests Downloadpage, no independent ownership signal corroborates it.

This is what a tool that doesn’t bluff looks like. A privacy proxy plus a content-free site is a genuine dead end, and the right answer is a low number and a shrug, not a confident guess.

Who owns Instagram? (The answer is not Instagram)

Three famous subsidiaries, run at full depth so the corporate hierarchy resolver engages:

Domain	Verdict	Operator	Parent
whatsapp.com	confirmed	WhatsApp LLC	Meta
instagram.com	possible	Instagram LLC	Meta
twitch.tv	likely	Twitch Interactive, Inc.	Amazon

The parent rollup rides on the entity, at entities[0].parent_company. If you’re asking “who owns this site” for a deal, a lawsuit, or a sales account, the parent is usually the answer you actually wanted.

Notice instagram.com is only possible despite 1.0 confidence. Verdict and confidence are not the same axis: confidence says how strongly the evidence points at Instagram LLC, the verdict says the structure of that evidence is contested by a comparable rival (the Facebook network signal, in this case). Read both.

The main event: which of these sites are the same company?

Single lookups name owners. The question people usually mean is bigger: who is behind all of these? That takes correlation, and it needs a different endpoint.

We picked seven well-known sites: theverge.com, vox.com, sbnation.com, eater.com, thrillist.com, thedodo.com, popsugar.com. Individually, every one of them self-attributes to the same place: VM Publishing, LLC or Vox Media, LLC, pulled from each site’s own copyright line. Already a hint.

curl -X POST https://api.whoisgeni.us/correlate \
  -H "X-API-Key: wg_YOUR_KEY" -H "Content-Type: application/json" \
  -d '{"domains": ["theverge.com", "vox.com", "sbnation.com", "..."]}'

The completed result nests under result (poll the poll_url from the submit response, not /jobs/{id}). One cluster came back:

{
  "cluster_id": "clst_1",
  "confidence": 0.72,
  "domains": ["eater.com", "popsugar.com", "sbnation.com", "thedodo.com",
              "theverge.com", "thrillist.com", "vox.com"],
  "shared_signals": [
    {"signal_type": "ads_txt_seller", "value": "0013300001kQj2HAAS", "domains_sharing": 7, "all_domains": true, "relation": "owner"},
    {"signal_type": "analytics_id", "value": "G-C3QZPB4GVE", "domains_sharing": 4, "all_domains": false, "relation": "owner"}
  ]
}

Seven sites, one ad stack. The four Vox-flagship properties share a GA4 property, the three acquired brands share an older UA property, and the ads.txt seller graph (340 owner-relation shared signals in the full response) ties all seven into a single cluster at 0.72. No single domain proves this. The proof only exists between the domains.

Here’s the part that makes the engine trustworthy: it refuses the easy version of this answer. We put instagram.com and whatsapp.com in the same correlation run. Same parent company, same ASN, same registrar. They did not cluster, because shared infrastructure is not shared ownership. Only two signal types count as owner-relation: analytics_id and ads_txt_seller, the account-scoped IDs that only an operator controls. Everything else (registrar, nameservers, IPs, cert issuers, registration timing) is labeled relation: "host" and can corroborate but never convict. When we tested google.com and youtube.com earlier, same story: 0.50, unclustered. If the engine won’t merge Google with YouTube on infrastructure, it won’t merge your list on a shared CDN either.

The false friends: three sites, one Cloudflare

To prove that point with strangers, we correlated medium.com, discord.com, and producthunt.com. All three sit behind Cloudflare’s edge. The result: zero clusters, all three in unclustered_domains, max pairwise score 0.5, every shared signal host-relation (ASN 13335, the cloudflare CDN tag, a CAA policy). Co-hosting is not co-ownership, and the response says so explicitly.

The typosquat: who owns twtter.com? A person, it turns out

twtter.com is a classic lookalike, one letter short of a site you’ve heard of. The API’s brand-similarity check scores it 0.96 against twitter.com and tags the technique: typosquat.

But the ownership answer is the interesting part. WHOIS privacy isn’t universal, and this registration is open: the operator candidate came back as a personal name from the registrant field, verdict possible at 0.21. Thin, contested, and flagged as exactly that. When the record is public, “who owns this sketchy domain” can have a very concrete answer.

The parked premium: atlas.com is for sale, not operated

atlas.com resolves to a for-sale lander from a premium domain brokerage. The loudest signal is the reverse DNS pointing at the broker’s infrastructure. Verdict: inconclusive, 0.1, with a rationale that translates to “nobody operates this, a broker is holding it.”

If you’re the buyer asking “who owns this domain,” this is still the answer you needed: there is no operating business to reach, there’s a sales page to negotiate with.

The zombie: tuaw.com and why confidence is the product

tuaw.com was AOL’s Apple blog. It shut down in 2015, the domain dropped, and someone re-registered it. Today it’s a content site wrapped in Apple imagery, and the archive shows a first capture 7,934 days ago.

The API’s answer: possible, Apple, 0.9, with a rationale that says the evidence is thin and contested. That’s the correct reading of a trap. The site’s look says Apple. The ownership evidence does not, and the verdict refuses to upgrade past “possible” on imagery alone. If you’re evaluating an expired domain for its reputation, this row is the whole lesson: the brand on the page and the owner behind it are different questions, and only one of them is answered by looking.

The quick hits

• IDN: münchen.de goes in as-is, the API converts to xn--mnchen-3ya.de automatically, and comes back with the City of Munich’s IT department at 0.9.
• Partial runs: taz.de finished with status: "partial" (7 of 11 collectors, WHOIS timed out) and still answered: likely taz, 1.0, on 19 corroborating correlations. Partial means part of the evidence came from cache or surviving collectors, and the confidence already reflects that.
• Genuine coin flip: golem.de came back inconclusive at 0.4. Real site, thin conflicting signals, no winner. Reported, not guessed.

Run your own list

One domain is a party trick. The reason to do this programmatically is that the question usually arrives as a list: a backlink export, a vendor spreadsheet, a dataset of outlets whose ownership you’re mapping.

POST /analyze/batch takes up to 50 domains per call (one credit each, invalid entries rejected before charging, failed analyses refunded). POST /analyze/bulk takes 500 and emails you CSV and JSON when it’s done. The batch-and-poll script we use is bulk_analyze.py, and the correlation runner is correlate_networks.py. Rate limits are 200 requests/hour free, 500/hour pro, with X-RateLimit-* headers on every response. The 26-domain dataset behind this post, plus the full correlation output, is in /blog/find-website-owner/, with raw API responses archived for provenance.

Prefer not to code? The MCP server puts the same two capabilities inside Claude:

claude mcp add --transport http whoisgenius https://api.whoisgeni.us/mcp \
  --header "X-API-Key: wg_YOUR_KEY"

Then it’s one sentence: “Here are 12 domains. Find out who owns each, and tell me which ones are secretly the same operator.” Claude calls analyze_domain per site, then correlate_domains on the set (capped at 15 via MCP, use REST for 100), and hands you the clusters in prose. No key works too, at anonymous free-tier limits.

The honest part

None of this is magic, and the 26 runs show the seams as clearly as the wins. A privacy proxy on a content-free site is a dead end (downloadpage.xyz). Evidence moves: ecosia.org, which we attributed at 96.5% in an earlier post, now returns unattributable because the site sits behind a WAF that blocks automated readers. Correlation errs toward silence, so disciplined operators who separate their analytics accounts stay unclustered. And possible is a lead for a human, not a name to act on.

The reverse-lookup endpoints round out the toolkit: GET /entities/search?q=... finds domains belonging to an entity, and GET /domains/{domain}/history shows the ownership timeline with per-run diffs. The reverse-WHOIS portfolio endpoint depends on an upstream provider and returned 503 during our runs, so treat it as best-effort.

Get an API key (75 free credits, no card) and run the domain that made you search this question. The whole dataset above cost 65 credits. Yours will cost less than the hour you just spent on WHOIS sites.