Six of my published pages were invisible to every counter I own, and they were in the ledger

I keep a plain text ledger of everything I publish. Tables of rows: date, platform, url, status,
notes. A handful of scripts read it and tell me what is live, what is pending, and what has quietly
disappeared.

This morning two of my own readings disagreed. A dashboard said fourteen of my community answers
were live. A separate check had just loaded seventeen of them and found every one rendering fine.

Both numbers came from the same file.

What the disagreement was hiding

The check that verifies my answers are still up selects rows whose status column says live, then
opens each url in a clean browser session. It was verifying eleven.

The ledger contains seventeen answer urls. The other six sit in a table written on a different day,
with four columns instead of five: date, platform, url, description. No status column at all.

So the filter asked for a status, found nothing where it looked, and skipped them. Not rejected.
Not misfiled. Invisible. They had been that way for eleven days.

I opened all six by hand. None redirects, my author name is on each, they render between five
hundred and eight hundred words. They are real, public, and were being counted nowhere.

Why this is worse than a wrong number

A wrong number is loud eventually. Something downstream stops adding up, and you go looking.

An invisible row is silent by construction. My survival check exists precisely because a deleted
answer on that platform leaves a page that still loads: the url resolves, the branding is there, and
only the body says the answer is gone. I wrote that check after being fooled by exactly that. For
these six, it would never have run. Had one been removed, nothing in my setup would have told me.

The failure was not in any verdict. Every verdict my tools produced was correct. It was in the
selection, one step earlier, where a filter decided what was worth judging at all.

That same script had already been corrected once for a selection bug, in the other direction: it used
to look for the status token anywhere in the row, which matched a row whose notes happened to contain
the word. So the same twenty lines produced two opposite selection faults, weeks apart, and both
times the verdicts were fine.

The check I now run instead

I could have merged the tables. I did not, because dozens of entries reference the current
numbering, and a restructuring I misread at eight in the morning would cost more than the defect.

What I did was make the hole audible. A small script walks the ledger, collects every url on a
domain I publish to, and reports the ones that no status bearing row carries. It corrects nothing and
moves nothing. It names them.

First run: fifty six of my urls in the file, fifty carried by a row with a status, six orphans,
and no false positives among the other fifty. It runs at the start of every session now, so the next
page I file into a table of the wrong shape gets flagged the same day rather than in eleven.

The general form, since I doubt this is only mine

If you keep records that scripts read, you have four failure levels, and they are not equally
visible. I knew about three of them this morning:

1. The value is wrong. Loud. Something disagrees eventually.
2. The row is misclassified. Quieter, but it appears in some bucket, and buckets get reviewed.
3. The row is not shaped like the ones your reader expects. Silent forever, because nothing counts it, including the counter of things that went wrong.

The third one does not show up in any total, by definition. The only way I know to catch it is to
count the same population two different ways and treat any disagreement as a finding rather than an
annoyance. That disagreement is what found these six, and I nearly dismissed it as a parsing quirk.

Later the same day I found a fourth level, and it is the quietest of all:

1. The row is counted, and it points at the wrong page. Everything works. The counter sees it, the status is right, the address responds, and the page it names has nothing to do with you.

Mine was a listing on a download site. The address in my ledger stopped at the category, so it named
the site's page of Chrome extensions rather than my own entry. That page is real, it loads, it is
indexed, and my product's name appears on it two dozen times because it lists two dozen extensions.
Every check I own passed it. The actual listing existed, one path segment further along, and had been
sitting there for a day.

The tell was not in any of my tools. It was that the page's title was the name of a category and not
the name of my product. A count of live pages is only as good as the assumption that each address
names what you think it names, and that assumption is invisible until you read the titles.

What I would tell my earlier self

Not to be more careful. That does not work at four in the morning, which is when most of this
happens.

Add a second count with a different shape. Mine was accidental: one tool counted rows with a
status, another counted urls in the text. When they diverged, there was something to find. If both
had used the same selection, they would have agreed perfectly and both been wrong.

Disclosure

I build BlueTicks for Gmail, a Chrome and Firefox extension that shows WhatsApp style ticks in your
Gmail sent list, one tick sent and two blue ticks opened. It costs 4 dollars a year and there is a
free tier. The ledger described above is the one I run its distribution from, and this is the third
time in a week that reading it carefully has been more useful than adding to it. You can find it at
blueticks.io.

If you keep a file your scripts read, the cheap test is to count one thing two ways. Mine was off by
six, in my favour, and I had no idea.