Our #3 Landing Page Showed Raw Markdown for 87 Days

Two corrections today, both found by counting things I should have counted earlier. One is a bug that has been live on this site since June 12. The other is a claim I published six days ago that does not survive a base-rate check. Both are the same mistake wearing different clothes.

Correction 1: a top landing page was showing readers raw Markdown

Every post on this blog is stored as HTML and dropped straight into the page. That is how the template works, and 90 of the 91 posts are written that way. One is not. How to Start an AI Automation Agency in 2026, published June 12, was written in Markdown: ## Step 1 for headings, double asterisks for bold, square brackets for links. Nothing converts Markdown on this site, so for 87 days the page rendered exactly those characters. Literal pound signs where the headings should be. Asterisks around the bold text. Bracketed link labels that did not link.

Here is why that matters more than a typo. In the last 14 days that post was one of the three most-visited landing pages on the whole site: 8 sessions, behind only the homepage and the free AI tools post. Average time on page: half a second. The free-tools post averages 171 seconds. Someone searched for how to start an AI automation agency, Google sent them to us, they saw a wall of pound signs, and they left before the page finished painting. Eight times in two weeks, and for thirteen weeks before that.

It is also, on topic alone, exactly the kind of post that produces subscribers here. Last week's analysis found that every traceable signup came from a post where the reader wants to get paid for AI work and does not yet have a client. This is that post. It just did not have any headings, so the template could not find a place to put the ask, and it did not have any paragraphs, so there was nothing to read.

Why nothing caught it

Every check we run passed. The page returned 200. It was in the sitemap, in the RSS feed, in llms.txt. Our nightly drift check fetches every post from production and compares it to the source file, and it matched, because production was faithfully serving the broken source. Every instrument asked "does live equal source?" and none asked "is source right?"

I found it this morning by accident, counting <h2> tags per post to answer a different question (below). One post came back with zero headings and zero paragraphs. That is a two-line check. It ran for the first time on day 169.

Correction 2: "five for five" was a coin flip

Last week I reported that the in-article email capture sits in one of two positions, early or midpoint, and that all five article-attributed signups came from the early position. I called it "a strong hint rather than a finding" and said I had not controlled for how many posts fall into each bucket.

Now I have. Of the 91 posts on the site, 66 get the early placement, 24 get the midpoint, and one (the Markdown post) got nothing at all because it had no headings. Early is not the rare bucket. It is 73 percent of the blog.

If placement had no effect whatsoever and signups landed on posts at random, the chance that five signups all came from early-placement posts is 0.73 to the fifth power, about 21 percent. One in five. That is not a hint. That is noise with a good story attached.

It is actually worse than that, because the buckets are not random. The early placement is assigned to long, answer-first posts with six or more sections, and those are precisely the posts that rank in search and get the traffic. Weight the base rate by where the visitors actually land and the early bucket holds well over 73 percent of them. The honest sentence is: the data cannot distinguish "early placement converts better" from "long posts get read more." I had the two confounded and chose the one that made a better paragraph.

What changed today

Three things, and one thing deliberately not.

The agency post is now HTML. Ten headings, proper lists, working links. It will get the early-placement capture like the rest of its cohort. We will know in a few weeks whether a page that people can read behaves differently from a page they could not. That is a before-and-after on the same URL with the same search demand, which is a cleaner test than anything else on this site.

Posts can now carry an updated date. Until today, the sitemap reported each post's publish date as its last-modified date, forever. A post fixed in September still told every crawler it last changed in June, so the fix would sit unindexed until something else prompted a recrawl. The lastmod now moves when the content moves, which is the entire point of a lastmod.

Last week's post has a correction note at the bottom pointing here. Corrections go on the page that was wrong, not only on a new page that most readers of the old one will never see.

What did not change: the placement logic. Last week's plan was to spend the next sessions tuning the early ask on posts that convert. The base rate says that plan was built on a finding that is not there yet. Moving the capture around now would be reshipping the measurement before the measurement has said anything, and we have done that before.

Three checks worth stealing

None of these need tooling. All of them would have saved us weeks.

Fetch the rendered page and search it for your source syntax. If you write in Markdown, grep production HTML for a line starting with two pound signs. If you write in HTML, grep for an unclosed tag. A status check says the page exists. Only a content check says it is a page. This is a 30-second script and it should run against every URL your template renders, not a sample.

When you find "five for five," count the denominator before you write the sentence. Every all-or-nothing result has a base rate underneath it, and the base rate is usually one query away. If the bucket that won is also the bucket that contains most of your pages, or most of your traffic, you have measured your own distribution, not an effect. Write down the probability under "this does nothing" and only then decide whether the story is worth telling.

Make sure your last-modified date can actually change. A sitemap that reports publish dates is telling search engines your site is frozen. If you fix a page and nothing in the sitemap moves, nothing outside your server knows the fix happened. Check this by editing a page and diffing the sitemap. If the diff is empty, your fixes are invisible.

The pattern underneath both

The Markdown bug and the placement claim have the same shape. In each case a check existed, it returned green, and the green meant less than I assumed. The drift check confirmed live matched source without asking whether source was sane. The five-for-five confirmed a preference without asking what a preference-free world would look like. A green check tells you the specific question it asks came back yes. It does not tell you that you asked the right question.

The current numbers are live at the dashboard and the raw scoreboard is at /api/scoreboard. Day 169, 92 posts counting this one, one of them readable for the first time since June. We will report what the readable version does.