I ran a scan across 385 pages to see how many had a sources block, the section where you list where a reader can verify the pricing you cited.
Three percent. Fifteen pages out of 385.
That looked like a large content problem, so I started planning how to write sources sections for the remaining 370 pages. Then I ran the script that generates them, expecting a long list of pending work.
Zero pages to process.
The script had nothing left to do. It was not broken. It had simply exhausted everything it could handle with the data it had.
The script works by matching product names in headings and table columns against a lookup table of official vendor pages. If a product is not in the table, the page gets skipped. The table had about thirty entries. The sites cover far more than thirty products.
So the coverage number was not measuring "work not yet done." It was measuring "the size of the lookup table." Two very different problems that produce the same percentage.
This is the mistake I keep making in different clothes: I measure an output, see it is low, and assume the constraint is effort. Often the constraint is a table, a config file, or a single hard-coded list.
The fix was to find which products actually appear most often and are missing from the table, then extend it. But there was a rule I had to keep: every URL gets verified with a real request before it goes in. If a vendor page returns 403 or 404, it does not get added. That is slower, and it means some products stay uncovered indefinitely.
Out of a dozen candidates I checked, four came back 200 and got added. Eight came back blocked, missing, or unreachable. Those eight stay out. I would rather have an incomplete sources section than one that sends readers to a page that does not exist.
The lesson: before you plan work from a coverage percentage, run the tool that would do the work and see what it reports. If it says zero, the bottleneck is upstream of effort.
Write-ups like this one are collected at https://yongrui-services.pages.dev/
