`_parse_ld_json` walks `itemListElement` once and buckets each entry into a deque keyed by its `name`, and the DOM walk then pops from that bucket as it hits each static row in document order [6][18]. Two identical postings of the same phone get their JSON-LD entries handed out in the order they appear in the list [6]. That is the correct behaviour for the common case and it is not a guarantee [6].
When a title's queue runs dry, because more static rows carry that title than JSON-LD has entries for, the row still ships [9]. Title, price and location come from the static HTML; `currency`, `latitude`, `longitude` and `images` come back null or empty [9]. Fault isolation is at the field level, not the row level.
That is what the 89% is measuring. Of 325 listings, 290 joined [7], so 35 rows [1], or 10.8% [3], arrive with the four JSON-LD-sourced fields empty. No listing is lost. A row count that looks complete and a map view that quietly loses one pin in nine are the same run.
The denominator deserves a note. The dev.to write-up reports 290 of 325 recovered end-to-end on a captured 298-item page [7], and 325 is 27 more than 298 [4]. Those two figures do not reconcile as stated, and the post does not explain which capture the denominator came from. Treat 89% as one measurement on one page shape, which is how the post itself frames it when it calls the number the ceiling of a title-only join and tells you to plan field completeness around it rather than assuming 100% [8].
For the figure to transfer you need two things to hold on your query: the same fraction of static rows covered by the JSON-LD block at all, and the same duplicate-title density. Those are different failure sources. Some static rows have no JSON-LD counterpart whatsoever [5], and that share is a property of how far the block extends down the page, not of the join key. Duplicate titles are the part the queue is actually arbitrating. A high-duplicate query in a large metro stresses the second; a short result page barely stresses either.
`position` is in every entry and looks like it solves this [4]. It holds for about the first 18 rows, enough to pass a smoke test, before the numbering drifts out of alignment with the static list [5].
Missing this second finding costs more: Craigslist has moved off per-subdomain numeric IDs onto a unified `/view/d/<slug>/<id>` shape, and fixture capture found opaque alphanumeric IDs such as `39wYA6wpdyRS7ynm63QsKf` [10]. A post-ID regex written against the numeric-only assumption drops every listing on the new scheme without erroring [11]. The pattern in the Actor accepts any alphanumeric run: `r"/view/d/[^/]+/([A-Za-z0-9]+)"` [12]. Craigslist's help pages do not mention the migration, so a spec written from documentation keeps the old assumption intact [13].
The robots.txt handling is the cleanest part of the design. The reply flow is disallowed, and the client refuses `/reply/`, `/fb/`, `/suggest`, `/flag`, `/mf`, `/mailflag` and `/eaf` before any network call is made [14][15]. `reply_url` still ships as a field, captured exactly as rendered and never opened, with no email de-obfuscation on top [16].
For anyone consuming this output, the practical consequence is that latitude, longitude, currency and images should not be marked non-null in your schema. On a normal page they will be missing on roughly a tenth of rows [3][9].
