Findings · 2026-09-01 · By VSNARY | Emmanuel Orta · 0 views
Our placeholder check accused a newspaper of publishing NaN. The NaN was in a URL.
A self-audit rule that scans every stored record for the token NaN found three of them. All three were inside the letters of one URL slug.
CrawlCheck checks its own stored records for strings that should never reach a customer-facing surface: [object Object], undefined/, "null/, [native code], and NaN. Each one has shipped at least once, which is why the list exists. A hit is treated as a bug in us and quarantined before anyone reads it.
It fired on a national newspaper's record. 3 occurrence(s) of NaN in the stored record. We opened the record expecting a broken calculation. The three occurrences were all in one place: a sitemap excerpt, inside a URL slug for a live blog, in a string like /QtNaNj2NkpSp/. A random identifier happened to contain the letters n, a, N in that order.
A substring is not a token #
The check matched NaN wherever it occurred, including inside a longer run of letters that has nothing to do with a number. The detector was doing exactly what it was written to do; what it was written to do was too broad.
We corrected the check: NaN now counts only as a whole token. A real leak like NaN% or : NaN, still counts; an identifier that happens to spell it does not. The same lesson counting @id strings taught: a string that appears is not a fact that holds.
Why a false positive in a self-audit matters #
The self-audit cannot move a grade, so this cost the newspaper nothing. It cost us something specific: a detector that fires when nothing is wrong is a detector nobody reads, and the whole point of this one is to be read. The first version of the self-audit fired on every real record for a different reason, and the lesson then was the same. Precision in an alarm is not polish. It is the difference between an alarm and noise.
Verified on the next scan of the same site: the self-audit was clean. The identifier is still in the sitemap, where it belongs.
What the placeholder check actually found #
| Field | Value |
|---|---|
| Occurrences of NaN in the stored record | 3 |
| Where all three sat | one sitemap excerpt |
| The string | /QtNaNj2NkpSp/ — a base-62 slug for a live blog |
A random base-62 identifier will eventually contain any short sequence of letters you can name. That is not a placeholder.
The general rule for anyone scanning output for garbage #
Placeholder scans are worth having. Every templating system eventually prints the name of a missing variable. But scan for tokens, not substrings: anchor on non-alphanumeric boundaries, and test the detector against a corpus of real records before trusting a hit. A URL, a hash, a base-64 blob, or a product code will eventually contain any short sequence of letters you can name. undefined is safer than NaN only because it is longer.
Every figure above came out of CrawlCheck.
Point it at your own domain and see the same measurements, free.
The main product
Found this on your own site? We fix it for $749.
Scan free to see where you stand. The fix is one site, every finding implemented and re-measured, with a sealed before and after.
Questions this post answers
What is a placeholder-in-record check?
A self-audit that checks every stored scan record for strings that should never reach output: NaN, undefined, [object Object], null in a URL. A hit means CrawlCheck leaked an unset value, and the record is flagged before a reader sees it.
Why did NaN match a URL?
The check matched the substring wherever it appeared, and a random base-62 slug in a sitemap URL contained the letters n-a-N in order. It now counts NaN only as a whole token.
Related findings
Comments
Comments are read before they appear. Nothing is published automatically, and no account is needed.
Writing about this? Facts, live figures and marks — every number on that page is dated and traceable to a scan.