Two of the twenty most cited hosts in our citation data were not sources at all
From 19,793 citation URLs collected on 22 October 2026 across 3,307 hosts. One host with 233 citations and another with 171 are the data provider fetch infrastructure, and a third with 447 is a real Google hostname that must not be merged into another. Here is how to tell them apart.
Published by AI Knows Us · Updated 22 October 2026
Anybody who publishes a table of the websites AI assistants cite has first had to decide what counts as a host. We collected 19,793 citation URLs on 22 October 2026 across 635 readings of ChatGPT and Gemini, every one with a parseable host, landing on 3,307 distinct hostnames. Three rows in the top twenty needed a decision before the table could be published, and the decisions are the point of this page.
The two hostnames that are not sources
- ccn.web.tr, 233 citations. Not a publisher. It is part of the fetch infrastructure of the data provider the readings came through.
- developers-google-com.hckseu1-xqad.com, 171 citations. The same thing in a more obvious costume. The real source sits in the subdomain string and the registrable domain belongs to the fetch layer.
Between them that is 404 citations which, left alone, would have put two pieces of plumbing above github.com at 171 and alongside searchengineland.com at 237 in a table purporting to show what AI assistants cite. A reader using that table to decide where to publish would have been pointed at nothing.
The hostname that looks like a duplicate and is not
developers.google.cn took 447 citations in the same run. developers.google.com took 1,360. The tempting move is to add them, call it 1,807 and report one row for Google developer documentation.
We did not, and the rule is worth stating plainly. developers.google.cn is a real Google hostname serving real documentation, so it is a source and keeps its own row and its own count. Merging two real hosts produces a number that was never observed, which is a different failure from leaving a proxy in the table but the same kind of failure: the published figure stops being a count of anything.
The three rules we used, in order
- Label, do not delete. A proxy row stays in the dataset with its raw count and a label saying what it is. Deleting it changes the denominator silently and nobody downstream can tell.
- Never merge two hosts. Not regional variants, not a help subdomain into its parent. help.openai.com took 467 and developers.openai.com 191 and openai.com 116 in this run, and those are three answers to three different publishing questions. help.otterly.ai took 143 while otterly.ai took 255, and the split is the interesting part.
- Publish the rule next to the table. Ours is printed with the citation host study so a reader can disagree with the classification and recount.
Why this matters if you are buying a citation dataset
Every tool in this category reads the engines through something, and a fetch layer that leaves its own hostnames in the citation stream will put them in your report. Three questions find out whether yours does.
- Show me the raw citation URLs for one answer. Not the host summary. The URLs. A proxy hostname is obvious in a URL and invisible in a tidy chart.
- Which hosts did you merge, and on what rule. If the answer is that none were merged, ask what happened to the regional variants, because a large run will have them.
- What is in the denominator. A host share is a fraction, and in this run the bottom of it is 19,793.
The same discipline applies to the headline most often quoted out of a dataset like ours. Half of every citation in this run arrived from 51 hosts of 3,307. That figure survives the classification decisions above because the proxies sit inside the 51 rather than outside, which is itself worth knowing: a concentration claim can be made to look stronger by leaving plumbing in and weaker by deleting it, so the rule has to be printed before the number.
What a clean top of the table looked like on 22 October 2026
Sources only, labelled by us, counts exactly as observed. developers.google.com 1,360. semrush.com 744. support.google.com 695. help.openai.com 467. developers.google.cn 447. blog.google 394. ahrefs.com 354. peec.ai 328. techradar.com 286. reddit.com 277. otterly.ai 255. bing.com 241. searchengineland.com 237. tryprofound.com 227. developers.openai.com 191. github.com 171. blogs.bing.com 158. help.otterly.ai 143. g2.com 125. hubspot.com 119. business.google.com 119. openai.com 116. learn.microsoft.com 112.
Our own domain appears in none of the 19,793, and that zero is the reason we hold this dataset at all rather than a result we are pleased with. The publishing experiment behind it is in the 507 page null result.
Two more additions nobody should make, from the same run
Do not add the two arms together
This audit had two arms. The measurement arm collected the 19,793 citations above. A separate in conversation arm, 19 batches run by hand in the products, collected 2,583 citations of its own. Those two totals describe different collection methods on different question counts, so 19,793 plus 2,583 is not a number that was ever observed. A dataset reporting 22,376 citations from this run would be reporting an addition rather than a count, and the only way a reader could tell is if the arms are named, which is why they are.
Do not carry a brand count across two rosters
The same discipline applies on the naming side. The main audit scored against a roster of 24 names and produced 1,053 namings across 635 readings. A consistency run on the same morning scored against a roster of 26 names across 132 readings. The rosters differ, so a brand total from one is not a brand total from the other, and the two must not be stacked into a trend. A brand outside whichever roster was fixed in advance is invisible to that scoring, which makes every such total a floor rather than a census. Both runs are published with their rosters attached, in the naming table and in the consistency measurement.
The general rule under all four cases on this page is the same. A published figure should be an observation plus a labelled rule, and every operation that combines two observations has to be printed where a reader can undo it. Deletion, merging, cross arm addition and cross roster stacking all produce tidier tables and none of them produce counts.
What this page does not establish
One run, one data provider, two engines, 22 October 2026. A different provider may not leak its own hostnames and a cleaner stream would produce a different top twenty. The classification is ours and a reader is entitled to recount from the published rule. We sell measurement software, so a page about dataset hygiene from us is a seller describing the hygiene of its own product, and the checkable part is the raw URL list rather than our conclusion about it.
Questions about citation dataset hygiene
How do I spot a proxy hostname
Read the registrable domain, not the whole string. A real source name sitting in a subdomain under an unrelated domain is the clearest case, and a host you cannot find a website for is the next clearest.
Should regional hostnames be combined
Not in a count. Report them separately and let a reader add them if they want a brand level view, because an addition a reader can do is recoverable and one you did for them is not.
Does leaving the proxies in change the headline
In our run the concentration finding held either way, because both proxy hosts sit inside the 51 hosts that carry half of all citations. That is why the rule goes next to the number.
Where can I check your classification
The labelled host table and the full question set are published with the citation host study.
Once the table is clean it says something about where to publish, which is in documentation outranked every vendor blog in our citation data, and what a B2B company does about it. The briefs we refused to write from the same run, and the gaps they named, are in three pages the AI engines told us to publish, and why we did not publish them.