Finding Baidu Doesn't Mean Finding the Domain You Care About

Nineteen domains, four categories

The sample splits into four groups, each with an answer that can be checked independently: ten obscure domains holding valid filings (filing number and registrant verifiable against the MIIT system), one domain that was filed but no longer is, five large Chinese sites (baidu, taobao, qq, zhihu, bilibili, whose filing numbers are public), and three domains that definitely have no filing (google.com, github.com, and our own kineticlinks.net).

Those last three are the reverse controls, and their job is to catch guessing — if a tool reports them as filed, what it is returning isn't a lookup result. For comparison we used a public, free ICP lookup API, called with the demo key from its own documentation. Both tools saw the same 19 domains.

Category	Kineticlinks	Comparison (free public API)
Obscure domains, all validly filed (10)	10 / 10	1 correct; 8 reported "lookup failed or no filing"; 1 reported success with "lookup failed" as the field value
Previously filed, now lapsed (1)	1 / 1	1 correct
Large Chinese sites (5)	5 / 5	5 correct, with matching filing numbers and registrants
Definitely unfiled (3, reverse control)	3 / 3	1 correct; 1 returned a retryable error; 1 reported as filed

Start with the bottom row. Most people test a lookup tool by feeding it domains that do have filings, but the category that exposes problems is usually the reverse control — the one where the correct answer is "no".

Three findings

Three things in this data are worth separating out.

1. The failures cluster in the only category that discriminates The comparison API got all five large Chinese sites right, filing numbers and registrant names included — and got one out of ten obscure filed domains. That distribution isn't random. It points at coverage: popular domains get indexed and maintained, obscure ones may never have entered the dataset at all. Obscure domains are exactly what people look up.
2. Reports success, but every field says "lookup failed" Some queries came back with HTTP 200 and a code field of 200, while icp, unit, domain and time were each set to the string 查询失败 — "lookup failed". To calling code that is a successful query, and those two characters get stored as the filing number and the registrant name. It is much harder to notice than an outright error.
3. The same domain gives different answers at different times We ran the set twice. In the first run kineticlinks.net came back with the success-but-garbage response described above; in the second it was correct, and google.com and 0592tk.com drew the bad response instead. The behaviour is intermittent, so passing a test once says nothing about the next call.

Why "success" is more dangerous than failure

Ask the comparison API about google.com and this comes back — HTTP 200, code 200, a syntactically perfect success: {"code": 200, "icp": "查询失败", "unit": "查询失败", "domain": "查询失败", "time": "查询失败"}

google.com obviously has no ICP filing. But nothing in that response says the lookup failed: the status is success and the filing-number field has a value. Calling code written as if resp["icp"]: mark_as_filed() — the most natural way to write it — marks google.com as filed and stores "lookup failed" as its filing number.

The same response shape appeared for 0592tk.com — a domain that does hold a valid filing. So the value in that field proves neither presence nor absence of a filing; it is simply an error message occupying a data field. From the outside, two opposite situations look identical. This isn't a question of accuracy rates, it's a question of response design: the error has no way to express itself. Any lookup API should make "definitely yes", "definitely no" and "couldn't tell you this time" structurally distinguishable, or the caller has nothing to work with.

What this test does not prove

The sample is 19 domains, one comparison tool, one point in time (September 29, 2026). That is not enough to infer any tool's overall accuracy, and it shouldn't be read as a general rule — it is what happened in this test, not an industry conclusion. Some specific limits: the obscure domains all came from one source rather than a random sample, and the comparison used a free endpoint with a published demo key, so a paid tier may draw on entirely different data. We also deliberately left speed out of the comparison — that demo key permits roughly one query every 20 seconds, and we slowed our calls to respect it, so presenting the elapsed time as a performance result would be dishonest.

One more thing that needs saying plainly: one of the tools under test is ours, and we designed and ran the test. Our own tool has had the same class of problem — in earlier testing it returned unknown for every large Chinese site, and a run before that failed in bulk under rate limiting; both were found and fixed during this testing. Our first comparison run also hammered the free endpoint hard enough to trigger its rate limiter, which made that run our fault, so we discarded it and re-ran. We are writing this down because a comparison that only shows the author scoring full marks is not worth reading. The method is the part worth taking away, not the score.

Three steps to check a lookup tool yourself

Whichever tool you end up with, these three steps filter out the unusable ones before you wire anything in:

1. Put obscure domains and reverse controls in the sample

Testing only with well-known sites is not testing. Find a handful of domains whose status you already know but that nobody has heard of, and add two or three that definitely have no filing. The second group catches guessing — a lot of problems only surface when the correct answer is negative.

2. Check that "lookup failed" and "no filing" are distinguishable

Those two mean opposite things, yet plenty of APIs collapse them into one response. Deliberately send a nonexistent domain, a malformed string, or a call while rate-limited, and look at what comes back. If error text can appear inside a data field, that API cannot be wired directly into anything that writes to a database.

3. Run the same set twice

Intermittent bad responses don't show up in a single pass. Re-run the same domains after a gap and compare the two sets of results. Wherever they disagree is a problem you will hit in production and struggle to reproduce.

Three questions to ask before buying a lookup API

If you are wiring filing lookups into your own system, these three determine whether you can trust it:

1. Is the data live or a snapshot Ask directly, and ask for the snapshot's refresh interval and coverage. This determines whether obscure domains resolve at all, and how long a lapsed filing takes to show up.
2. How are failures distinguished from "no filing" Look at the actual response structure, not the prose in the documentation. Confirm that errors get their own status code or field instead of being packed into the filing-number field.
3. Rate limits, quotas and timeout behaviour What are the per-second and daily ceilings, what comes back when you exceed them, and on an upstream timeout does it return an error or "no filing". That last one is the easiest to discover only after you go live.

In summary

The part of this test worth remembering isn't the score, it's the shape of the failure: reports success, field has a value, the value is wrong. It doesn't raise an exception, so nobody notices, and it quietly records "lookup failed" as some domain's filing number. Finding Baidu proves very little; testing with domains that definitely have no filing tells you far more about whether a tool is usable.

Filing status isn't fixed once you've looked it up, either — a hosting provider withdrawing access, or a compliance review cancelling the record, can make it disappear with no warning at all. If you are evaluating a pre-filed domain, or wiring filing lookups into your own workflow, tell us what you are working with and we will look at it with you.