Friday’s newsletter, delivered here. Our email provider is still suspended, and we do not have a list of people who asked to receive email, so we are publishing this issue on the site instead of sending it to your inbox. The issue itself is unchanged.
Hi there,
Quick one this week, and it is the least flattering thing we have published. Three of our own measurements were wrong this week. This morning a fourth one — the speedup we reported — turned out to be wrong in a new way, and the way it was wrong is the most useful thing in this issue, because it is the kind of mistake that hides inside a dashboard.
Here is what they were, what we changed, and the four questions we now ask before we publish a number.
A measurement is only useful if you can say what was measured, on which surface, on which clock, and who asked first. Ours could say none of those. Three times last week that produced a number that was true and useless, or false and published. The fix was not a new tool. It is four questions, asked in a fixed order, every morning, before any number goes anywhere.
Our audit flagged one of our published posts for “printing retired addresses.” Four of them, apparently.
Zero. On every surface that publishes an address — the structured data, the visible address block, the footer — there were none. The four matches were inside quoted code samples, because the post was about retired addresses and was quoting them as evidence. We flagged our own article for describing the problem it was about.
The check now asks a different question: does any surface that publishes an address carry the retired value? Not: does the string appear anywhere. A whole-page count cannot tell a published value from a quoted one.
On Wednesday our own morning audit reported that OpenAI’s crawler was unblocked. Sixteen user-agent strings, sixteen HTTP 200s, the cleanest AI-bot sweep in weeks. The headline wrote it up as the end of a four-day block. We nearly closed our support ticket on it.
Then we read the whole report instead of the headline. The same table that produced the sixteen 200s also recorded the cache header on every single request: x-hcdn-cache-status: HIT.
Every one of those requests was served from an already-warm cache. Not one of them asked the server to load a cold page — and the refusal we opened the ticket about only exists on a cold load. So we ran it the other way round: a fresh URL that nobody had ever fetched, for every probe.
GPTBot: 429, zero-byte body, four times out of four. Googlebot, Bingbot, OpenAI’s search bot, Anthropic’s, Perplexity’s and our own user agent: 200, four times out of four. Then the decisive test — let any other client load the page first and the bot reads it instantly; let the bot go first, alone, twice, on a URL it just invented: 429, 429.
OpenAI’s crawler is not blocked from reading us. It is blocked from being the first to load us. That is a caching rule on the edge of our host, not a policy change — and it is the kind of thing you only find by asking the question in the right order.
This morning our own dashboard agreed with us. It re-ran the spaced protocol and got 429 on nine probes out of nine, and it now says the block is back. We had it right a day ago, on the day the dashboard said the opposite.
Our dashboard’s “TTFB” was the full response time, body download included. On the metric that actually means time-to-first-byte, our published homepage number — 0.36s — was accurate to within 0.1% this morning. We were about to “correct” a number that was right.
So we fixed it. The audit now measures time-to-first-byte.
And then, this morning, we found the part that is actually useful.
The dashboard reported a 26.6% speedup overnight, and it was wrong — but not because the site got slower or because the fix was bad. It was wrong because we changed the clock without saying so. Wednesday’s figure was the full response time. Thursday’s was the header. The dashboard compared them as if they were the same quantity and printed a number.
Here is the proof, and it is checkable in about four seconds. Our warm-path numbers, measured on the same requests, same run:
The dashboard’s two numbers differ by a factor of 1.913. Our full-response and header times differ by a factor of 1.901. It was measuring two different things and calling them the same thing — and we only caught it because we measured both clocks on the same requests in the same run.
Now measure it like for like, and the site did not get 26.6% faster today. Cold, header-time: 0.889s on Wednesday, 0.947s this morning (n=25, a fresh URL for every probe). Cold, full-response: 1.208s then, 1.245s now. Warm, header-time: 0.3576s then, 0.3596s now. Flat to marginally slower on every one. The speedup was a unit change wearing a percentage costume.
And the dashboard still carries a warning to change that 0.36s homepage stat — comparing a warm published number against a cold measurement, which is the same mistake we made in reverse. It survived a metric change without noticing. That is what an unlabelled number does.
1. What is the status code, the byte count, and the cache state? All three, together. A 200 against a 429-with-an-empty-body is not a 200.
2. Which surface publishes this value? If the value is not published there, a match means nothing — it might be quoted evidence.
3. Who made the request first? A cold URL tells you what a first-time visitor gets. A warm URL tells you what the second visitor gets.
4. Which clock is this, and was yesterday’s number on the same clock? Time to first byte and full response time are different quantities. So are a cold path and a warm one. Never compare across them.
You do not need our tooling to run them. To see what a first-time visitor gets, request a URL with a query string nobody has used before. To see both clocks in one shot, ask your command for time to first byte and total time together, on the same request. To check what a crawler would see, run the probe with a cache-busting string and read the cache header next to the status code — not the byte count, which tells you nothing about cache state.
And if a number on your own site — a speed figure, a review count, a schema total — was written once and never re-checked, it is a decoration. We had three of them on one page. We have since found four more on another, all of them wrong.
Small, concrete, permanent. Scope the count to the surface that publishes the value. Bust the cache with a fresh string for every single probe. Report the cache header next to every status code. Measure both clocks on the same requests and label which one is which. Test every check against a page that is known-good before we arm it — a verifier that has never run against a working page is not a verifier.
Each fix is one rule we now run every morning, forever. The pattern is the deliverable. The specific finding is just this week’s evidence.
Including when the answer is unflattering, and especially when it is about you rather than about us. We have written the method up in full — our speed number was true for exactly one day, and three times we measured our own Google index wrong, and the week the index was serving five versions of our business at once.
Or call 509-230-4576, or use the contact form, and we will run the same four questions against your site and tell you what we find — including the parts that make you wince.
— Douglas Gorden Jr
Gorden Web Design, Moses Lake WA
Gorden Web Design & Computer Repair ·
PO Box 1052, Moses Lake, WA 98837 · (509) 230-4576 · Mon, Sat & Sun 9:00am-5:00pm