All 461 eligible records in OnlyDetect's 30 September 2026 audit had distinct normalized handles and distinct normalized canonical URLs. Each stored canonical URL matched the expected platform URL plus the record's handle. These checks found no exact handle or canonical-URL collisions in this sample.
They do not prove that every record belongs to a different person, that every destination is active, or that the directory contains no mistaken identity matches. Those require different evidence.
The exact checks
We selected active, indexable, unsuppressed records validated within 180 days. We compared lowercased handles, lowercased canonical URLs, and the expected URL constructed from each stored handle. The aggregate data and SQL preserve those definitions.
Scroll across the table on smaller screens.
| Check | Result |
|---|---|
| Eligible rows | 461 |
| Distinct normalized handles | 461 |
| Distinct normalized canonical URLs | 461 |
| URLs matching the stored handle | 461 |
Because the counts match, there are no duplicate values under these exact normalization rules. We did not strip or equate meaningful punctuation, substitute similar-looking characters, or assume that two similar names identify the same person.
What a passing check establishes
Consistent handle-to-URL construction prevents one simple data error: a record showing one handle while its canonical URL encodes another. Distinct keys also prevent exact duplicate rows from inflating this eligible-record count.
The database's unique-handle constraint contributes to that result. This is therefore a structural data-quality check, not independent evidence that the directory has solved every identity problem.
What it leaves unresolved
A creator may maintain several public accounts. An old handle may be replaced. Two people may share a display name. A public link can become unavailable after an earlier observation. None of those situations is settled by comparing strings within a current table.
Our username guide separates an exact public identifier from a display-name match. For a changed or uncertain account, the creator's own current public links provide more useful evidence than collapsing similar names into one record.
Why we did not deduplicate by photograph
This audit did not compare faces, infer private identities, or merge accounts based on appearance. Similar artwork or a reused promotional image is not enough to establish that two records belong to the same person. Identity resolution should rely on explicit, relevant public evidence and a reviewable correction process.
A useful correction report
If a public record points to the wrong destination, report the affected OnlyDetect URL, the specific mismatch, and a relevant public source. Avoid including private documents or account credentials. The correction policy explains the site's review process.
The present result remains bounded: zero exact collisions under three documented checks across 461 eligible records on one date. It is not a claim of a zero-error directory.