Stop Reciting Mechanisms From Memory: A Blogger's Three Cognitive Failures

A blogger had seven consecutive articles flagged as noindex by search engines. He initially assumed the problem was writing quality, so he revised the articles repeatedly. Three weeks later he opened the platform's source code and discovered the problem was in the code itself: all three of his core beliefs about how the platform works were fabricated from thin air, and he had written them into his notes as facts.

This experience comes from a retrospective he published on the Forem platform, with a blunt title: "3 False Beliefs About My Own Blog That I Never Once Verified." The original contains no data charts—only snippets of code and a blogger settling accounts with his own cognitive habits. For anyone doing AI content, writing technical blogs, or even just relying on platform algorithms for distribution, its value lies not in platform details but at the methodological level: how easily we mistake "I remember" for "I checked."

Belief One: Reader Likes Boost Account Score—Wrong, That's a Report Penalty

The account score is the gate the platform uses to decide whether an author's historical articles are worth indexing. This blogger always assumed that reader likes on an article equal points for the account, because "a reader pressed a button on my work, so they're rewarding my account."

The code logic he read was the exact opposite: that block aggregating "reactions received by the author" filters for a reaction category indicating a user has been reported, and its target is the user record rather than the article. In other words, this number is a penalty deducted after being reported, not a bonus added after being liked. Reader likes never touch it at all.

This means that for the past three weeks he repeatedly told readers "likes help the account," and the actual effect was zero. A piece of operational advice that got widely repeated traced back to nothing but his own speculation.

noindex is a page-level directive provided by search engines, telling crawlers via the <meta name="robots" content="noindex"> tag or the HTTP response header X-Robots-Tag: you may crawl this page, but do not include it in the search index. It differs from robots.txt's Disallow—the latter blocks crawling, while the former allows crawling but refuses indexing. Pages marked noindex can still be accessed and shared, but they won't appear as normal results in search engines, which for a blog relying on search traffic means traffic drops to zero. Platform products often use noindex as a quality gate, dynamically deciding whether to output the tag based on account score or article score.

Belief Two: The Newsletter Checkbox Is the Index Switch—Wrong, the Experiment Never Actually Ran

Forem has a setting that, if truthy, sets every article's score to exactly the minimum required for indexing. Note: every article, not just the next one.

The blogger found it, wrote a script to parse the notification settings form, and compared field by field before and after submission so as not to accidentally modify the other nine items. He flipped that field, got an HTTP 200, confirmed the field had indeed changed, and rechecked the articles three minutes later—eleven indexable, zero change.

At the time he recorded it as "a lever that was tested but doesn't work." But the truth is: this wasn't a failed experiment, but an experiment that never actually ran. The code checks whether the user holds a certain role, and a role is not a notification preference. He toggled an unrelated setting, confirmed it changed, and then drew a conclusion about something entirely different.

More ironically, that role has no public acquisition path at all. The site's newsletter is just a form that submits to an external email service—the subscribe action never touches the site database. The code that grants that role exists only in the admin area.

User roles and notification preferences are two completely different data models. Roles are typically stored in a user table or a separate role-association table, granted by administrators, and control permissions and feature access; notification preferences are fields users can toggle themselves, determining whether they receive certain kinds of alerts. The two may appear on the same page at the form level, but after submission they write to different database columns and are read by different code paths. The typical consequence of confusing them: you modify a visible switch, confirm it changed, yet it has no effect whatsoever on the role that actually matters—leading to the wrong conclusion that "the experiment doesn't work."

Belief Three: Comments Directly Affect Whether an Article Is Indexed—Wrong, It Takes a Months-Long Detour

Comments are the only interaction data the blogger has seen that can move certain metrics, so he naturally assumed comments also drive the indexing gate.

The scoring function does not include comments. Comment scores are calculated separately, stored in a separate column, and never added to the score that determines indexing. Comments do matter here, but through a completely different path: meeting comment thresholds for several consecutive weeks earns a badge, the badge raises the account score, and the account score is the indirect entry point to indexing.

In other words, comments affect indexing, but through an indirect path measured in months, and he compressed it into a single step. This kind of compression is everywhere in word-of-mouth operational experience, but every compression loses causality.

Indirect causal chains are common in platform operations: A affects B, B affects C, but there's no direct edge between A and C. Meeting comment thresholds consecutively triggers a badge, the badge raises the account score, and the account score determines the indexing gate—every step in this chain has time delays and conditional constraints. Compressing three steps into "comments affect indexing" loses the intermediate variables and causes predictions to fail—for example, if the index status doesn't change shortly after increasing comments, it's misjudged as having no causality. The way to identify indirect chains is to trace the data flow: look at which columns the scoring function actually reads, rather than inferring backward from visible interaction metrics.

The Truly Useful Numbers Aren't in the Platform Code

After reading the code, his historical article list was no longer mysterious. Over three weeks of daily measurements, only two articles' verdicts had changed, and always in the same direction: from indexable to non-indexable. Not a single one had ever gone the other way.

This is not what a slow ranking decline looks like. A slow decline is a ranking sliding down across a score threshold, whereas this was a door closing.

And the most useful number in the entire retrospective came from his own archive. Before writing down these three beliefs, he went back and broke down the records of all thirty scans, counting something he'd never counted before: whether each article had ever been indexable, rather than whether it was indexable at this moment.

The result: sixteen had never been indexed, nine were currently indexable, and two had once been indexable but lost eligibility. All four situations had collapsed into two states across every dashboard he'd built, and he'd read it for three weeks without noticing.

This distinction is the key. A page that was never indexed and a page that was once indexed and then removed have identical metadata and identical verdicts, but completely different causes: the former has not yet been judged, the latter has been judged and failed. In his table there was a column called "indexable" with values True, False, or ?, where ? meant not checked. He never wrote down that False could mean two entirely different things, and so he completely lost the ability to distinguish them.

Two Rules You Can Take Away

The blogger left two rules at the end.

First: never state a mechanism from memory; if you must say it, write down which file it came from. Not "account score counts likes," but "calculate_score in app/models/user.rb, a certain line, and the scope it aggregates over." The difference is that a file can be verified; a memory cannot. He admits that if he'd actually taken a look at the time, all three errors could have been caught within ten minutes.

Second, smaller but costlier: a check that returns nothing is not the same as a check that discovered "nothing." He almost wrote down "unable to compare because the data is insufficient." In fact the data was sufficient—it was just that the table he queried is no longer written to in the current software version, and the query returned zero rows without error, and he took that zero as a fact about the world rather than a fact about his query.

Zero rows and no output look the same, and the only way to tell them apart is to compare against a case whose answer you already know.

For creators building AI tools, writing technical content, or even just relying on platform distribution, this article offers no operational tips whatsoever. What it offers is a cognitive calibration: in an environment where code and algorithms dominate distribution, "I remember" is the most dangerous input, and "I checked and recorded the source" is the reusable knowledge.

An empty result query and a negative result are indistinguishable at the database level: a SELECT returning zero rows could mean there really is no matching record in the table, or it could mean the table is deprecated, the field has been migrated, or the query condition was written wrong. The former is a conclusion about the world; the latter is a conclusion about the query. The reliable approach is to introduce a positive control: run the same query against a record you're certain exists—if the control also returns zero rows, the query itself is broken; if the control returns a result while the target query is empty, only then can you tentatively conclude the target doesn't exist. This principle applies equally to log analysis, metric monitoring, and reading A/B experiment results.