DEV Community: Nan

My Unattended Job Ran on Time and Did Nothing

Nan — Fri, 23 Oct 2026 07:54:46 +0000

This post describes the behavior of specific tool versions on my machine — macOS with bash 3.2 and the Claude Code CLI as of October 2026. Argument-parsing details change; verify against your own versions before copying any of this.

For two nights in a row, my nightly automation fired exactly on schedule and exited one second later, having done nothing. The scheduler was never the problem. The prompt I fed to the agent CLI happened to start with a line of three dashes — the YAML frontmatter of my runbook file — and the CLI parsed the entire 12-kilobyte prompt as one long command-line option, rejected it, and quit with exit code 1. Here is the failure, the one-line fix, and the check I now run on every unattended job.

The job fired on time and failed in one second

I run a small unattended pipeline on my Mac. Every night at 21:00, a launchd agent executes a shell script. The script checks that a logged-in browser is reachable, then hands a runbook file to an AI coding agent in print mode, which executes the night's tasks: a few community replies, a read-only check of one account, and a blog post for this site.

On the morning of the third day I opened the logs. Both nights looked like this (the two Chinese lines translated — the script logs in Chinese, everything else verbatim):

===== nightly-yanghao start 2026-10-16 21:00:05 =====
[Fri Oct 16 21:00:05 CST 2026] CDP preflight OK (localhost:9223)
error: unknown option '---
created: 2026-10-15
type: runbook
...
[Fri Oct 16 21:00:05 CST 2026] claude exit rc=1
===== nightly-yanghao end 2026-10-16 21:00:06 rc=1 =====

The timeline table, both nights:

Night	launchd fired	Preflight	Agent runtime	Work done
Oct 15	21:00:05	Passed	1 second	Zero
Oct 16	21:00:05	Passed	1 second	Zero

The scheduler did its job perfectly. The script did its preflight correctly. The agent CLI then rejected its instructions as a malformed flag, and the whole run was over before a human heartbeat's worth of time had passed. Two nights, six tasks per night, twelve missed executions, and the system was green on every dashboard I had — because I had no dashboard, only a log file nobody read.

One thing worth crediting: macOS itself kept receipts I never looked at. launchd records the last exit status of every job it manages — launchctl list shows it in the Status column, where a 1 had been sitting since the first night. And the plist format has native StandardOutPath and StandardErrorPath keys that persist a job's output to files without any wrapper script. My wrapper did capture stderr into its own log, so nothing was lost — but between launchd's exit-status table and my log, the failure was recorded twice and read zero times. The observability was there. The observing was not.

The prompt was valid Markdown and an invalid command line

My runbook is a Markdown file, and like most of my Markdown files it starts with YAML frontmatter:

---
created: 2026-10-15
type: runbook
---

My script passed the file's contents to the CLI as a positional argument, roughly like this:

claude -p "$(cat runbook.md)"

The CLI's own help text describes print mode plainly: use -p/--print for non-interactive output. What the help text does not need to say — because it is a convention every CLI follows — is that argument parsing happens before your positional argument is interpreted. A positional argument that begins with a dash is not a positional argument at all. It is an option, by definition, at the layer where the shell's words meet the program's parser.

This convention has a name and a number. POSIX.1's Utility Syntax Guidelines define -- as the delimiter that ends option parsing (Guideline 10): everything after it is an operand, even if it begins with a dash. Every mainstream argument parser — glibc's getopt, Python's argparse, the Node and Go flag libraries — implements some flavor of this rule. That means two things. First, my failure was not a quirk of one particular CLI; any standards-following parser would have rejected the input the same way. Second, there was always an escape hatch I did not know I needed:

claude -p -- "$(cat runbook.md)"   # parses fine — everything after -- is an operand

So the parser saw ---\ncreated: 2026-10-15\ntype: runbook\n..., tried to match it against its known flags, failed, and printed error: unknown option '---...' with the entire runbook echoed back as the offending "option". Every layer of my pipeline was working as designed. The design was wrong.

My preflight checked everything except the thing that runs

This is the part that stung, because I had been careful. The script has a --check mode. Before I loaded the launchd job, I ran the preflight and watched it print PREFLIGHT-OK. I verified the schedule, the working directory, the browser probe, the log directory.

What the preflight validated: the environment around the task. What it never validated: the task itself. The one line that actually invoked the agent was exercised for the first time at 21:00 on the first night, in production, unattended. Loading a schedule is not running a job. A green preflight means the runway is clear; it says nothing about whether the plane can fly.

There is a subtler version of this trap worth naming. Even if my preflight had invoked the CLI, it would have invoked it with a fixed, known-good test string — while the real run reads its input from an external file. A preflight with hardcoded inputs proves the binary starts; it says nothing about the contract between the binary and the data you feed it at runtime. The honest fix is a smoke test with the real inputs, end to end: after enabling any unattended job, run it once by hand, exactly as the scheduler will. If that is too expensive, read the first real run's log the next morning before you assume the system exists.

A notification is not monitoring

One detail deserves honesty, and a harsher framing than I first gave it. My script did not stay silent: on a non-zero exit it fired a macOS desktop notification — something went wrong, see the log. It fired on both nights. I never saw either one, because notifications on this machine are where focus-mode banners go to die.

My first draft of this section asked "why did the notification fail?" The better question is why a desktop banner was the observability layer of an unattended job in the first place. A banner is volatile, silenced by Do Not Disturb, and requires a human to be looking at the screen within seconds. Rob Ewaschuk's classic essay My Philosophy on Alerting (reprinted in Google’s Site Reliability Engineering) argues that passive channels like email are of very limited value precisely because they get buried; an alert that does not demand immediate human action is noise. A transient GUI banner on an unattended machine is worse than email — it pages no one, ever. That is not a notification problem. It is an architectural anti-pattern: a desktop UI component carrying a production observability responsibility.

The deeper issue is the direction of the signal. Mine was push-on-failure: the system tries to announce its own death. But anything announced by the dying component shares a failure domain with that component — if the Mac loses power, hangs, or the process is killed before the trap runs, the announcement dies with it. Absolute silence, indistinguishable from success. The robust pattern inverts the direction: the job sends a success heartbeat to an external service when it completes, and the service — not the job — raises the alarm when the heartbeat stops arriving. This is the dead man's switch, or inverted heartbeat, and it is the entire business model of services like Healthchecks.io, Cronitor, and Dead Man's Snitch. Google's SRE book devotes a chapter of its cron discussion to exactly this: for periodic batch jobs, "the expected output did not appear" is the symptom worth alerting on, not any signal the job itself emits.

Every mature scheduler has some version of this lesson built in. Classic cron's MAILTO captures whatever the job printed and mails it — which is why > /dev/null 2>&1 in a crontab silently disarms it. systemd has OnFailure=, which activates a separate diagnostic unit when a service fails, so the reporting path is a different process from the failing one. macOS gave me the exit-status table I never read. My cheap version, until I build a real external heartbeat, is a rule instead of a tool: the first morning after any new unattended job goes live, reading its log is a scheduled task, not a vibe.

The fix was one pipe, with three caveats

The corrected invocation strips the frontmatter and feeds the prompt through standard input, where no option parsing applies:

awk '/^---$/{c++; next} c>=2' runbook.md | claude -p

stdin beats the positional argument here for two reasons, and only one of them is option parsing. The other is size: positional arguments live in the fixed-size buffer execve copies into the new process, capped by ARG_MAX (1 MB on macOS). A prompt that grows past that ceiling fails with E2BIG before the program starts at all. A pipe is a stream with no such ceiling, so the fix removes the parsing ambiguity and the size limit in one move.

Three caveats make this production-grade rather than a snippet:

Pipeline exit codes lie by default. A pipeline's exit status is its last command's. If awk crashed mid-stream and the CLI treated empty input as success, the failure would vanish. set -o pipefail makes the pipeline report any stage's failure.
launchd does not load your shell's locale. A job started by launchd runs without the locale environment your terminal has; byte-oriented tools like awk can misparse multi-byte UTF-8 content unless you set LC_CTYPE explicitly in the script. My runbooks contain Chinese — this one is not theoretical.
--- is also Markdown syntax. In CommonMark, three dashes are a thematic break — a horizontal rule. My one-liner counts every line of three dashes, so a horizontal rule in the runbook body would be silently deleted from the prompt: a parsing crash traded for silent data corruption. The hardened filter only strips a frontmatter block at line 1 and stops at its first closing delimiter:

awk 'NR==1 && /^---$/ {f=1; next} f && /^---$/ {f=0; next} !f' runbook.md

I tested the pipe with a two-word prompt before trusting it, which is what I should have done on day one. The next scheduled run executed all six tasks end to end.

The total cost of the bug was two quiet nights. The total cost of not noticing could have been weeks — nothing in the system would ever have gotten louder on its own. That asymmetry is the real lesson, and it is why the incident earned a permanent entry in the family's incident log rather than a quick fix and a shrug: unattended automation fails silently by default, and silence only breaks where you have built a place for it to break.

What I changed after the incident

Strip metadata before handing files to a CLI. Any file that might carry frontmatter gets filtered before its content becomes an argument; stdin beats positional arguments for anything that can start with a dash; and where an argument is unavoidable, -- ends option parsing before it begins.
Smoke-test the invocation with real inputs, not just the environment. A preflight proves the surroundings are ready; only a real run with real data proves the pipeline runs.
Check the first-run log the next morning. New unattended jobs get a scheduled human review of their first execution, before trust is granted.
Treat silence as the alarm. Until a real external heartbeat exists, the interim rule is explicit: no news is bad news, and something — eventually an external service, for now a calendar entry — is responsible for noticing.
Write the incident down where future runs will read it. My nightly agent now greps the incident log before starting and appends new entries before finishing, so a mistake is expensive exactly once.

None of this is clever. That is the point. Unattended systems do not need cleverness; they need the dull discipline of checking that the thing you built is the thing that ran.

Originally published on my blog: https://javaeye.dev/blog/silent-failure-unattended-automation/

Keeping New Sites Visible to AI Search Crawlers

Nan — Wed, 21 Oct 2026 00:35:34 +0000

AI crawler policies, bot lists, and platform defaults change quickly. This is a snapshot from October 2026, based on what I run on my own sites today. Re-check the official lists before you copy any of it.

Since July 2025, Cloudflare blocks AI crawlers on newly onboarded domains by default. If you do nothing, a new site on Cloudflare is simply absent from ChatGPT, Claude, and Perplexity — and nothing errors, nothing warns you, and your analytics stay silent because the traffic never arrives. Here is the four-step checklist I now run on every new static site before I consider it launched.

New Cloudflare domains hide from AI crawlers by default

This is the trap, and it is silent. Cloudflare turned on default AI-crawler blocking for new domains on 2025-07-01 (Cloudflare, 2025). An existing site keeps its settings; a new domain inherits the block. Your pages render fine, Google Search Console shows nothing unusual, and the first symptom is that AI assistants simply never mention your site — a symptom with no dashboard.

The crawl access layer is worth treating as launch infrastructure, same as DNS and SSL. I missed this on exactly zero sites only because the family SOP caught it before launch — the checklist below is that SOP.

Step 1: Explicitly allow search-class crawlers in Cloudflare AI Crawl Control

Cloudflare's AI Crawl Control is the switch that matters most. Go in and explicitly allow the search-class crawlers — the bots that fetch pages to answer user queries: OAI-SearchBot (ChatGPT search), ClaudeBot (Claude), and PerplexityBot (Perplexity). These are the ones that make your content quotable inside AI answers.

Also allow the user-triggered fetchers — bots that fetch a page because a user explicitly asked an AI to read it. Google's list (updated 2025-10/11) includes Google-NotebookLM, Google-CWS (Chrome's AI features), and Google-Pinpoint. Being read on demand is the same value as being read by search bots; block it and "summarize this page for me" fails for your domain.

Crawler class	Examples	Why it fetches	My setting
Search-class AI bots	OAI-SearchBot, ClaudeBot, PerplexityBot	Answer user queries with your content	Allow
User-triggered fetchers	Google-NotebookLM, Google-CWS, Google-Pinpoint	A user asked an AI to read this page	Allow
Training-class crawlers	GPTBot, Google-Extended	Model training corpora	Allow (optional — I allow them)

Step 2: Name the bots in robots.txt — and skip invented fields

robots.txt still works, but only for documented fields. Google has said since 2024-10 that it ignores undocumented self-invented directives like NoAI (Google, 2024). Writing NoAI: false or similar into robots.txt controls nothing anywhere. Control goes through the official mechanisms: Cloudflare AI Crawl Control for the edge, and named user-agent groups in robots.txt for everything else.

On my own sites the robots file names the AI crawlers explicitly — ten user-agent groups, every one of them allowed — and a contract test fails the build if any group gains a Disallow. Named groups beat wildcards here: you can see exactly who you admitted, and a diff on the file is a readable audit trail.

Step 3: Keep llms.txt, but do not count it as a Google lever

Google's official guidance across three documents (2025-05 generative AI content guidance, 2025-12 AI features documentation, and the 2026-05 AI optimization guide) settles two questions: there is no separate AI index to optimize for, and llms.txt is not counted by Google Search. GEO, in Google's own framing, is traditional SEO done well — crawlable pages with citable, quotable content.

I still ship /llms.txt on every site, with this blog's own copy covering the hub and main pages. It costs almost nothing and non-Google consumers use it. But I keep it out of the ROI story: for Google, its expected value is zero, and pretending otherwise would distort what I measure.

Step 4: Reconcile with the GSC Generative AI report every month

Since 2026-06, Search Console has a Generative AI report showing how often your content appears in AI experiences (Google, 2026). Two things to know before you read it: it reports impressions, not clicks, and it has no query dimension. You can see that AI surfaces showed your page, not which question triggered it.

This report is now part of my monthly inspection routine, next to classic queries and pages. One related setting worth leaving alone: the "Search generative AI" participation control (opened globally 2026-08-31) is not a ranking lever in either direction — opting out does not protect rankings and opting in does not boost them. I keep participation on, because for a content site AI visibility is the point.

What I verified on my own sites, and what I did not

On this blog the full stack went live on 2026-09-29: robots.txt with ten named AI-crawler groups all allowed, /llms.txt covering the hub and main pages, a Cloudflare zone audit showing no AI blocking, and curl checks confirming every rule served what I intended. Contract tests lock the robots file so a regression fails the build instead of slipping out. The same SOP now runs across my family of static tool sites — the newest of them went through the same checklist on launch day.

The honest boundary: all of this verifies crawl access, not outcomes. I can prove the bots are admitted; I cannot yet point at traffic and say the checklist caused it. That part needs months of the GSC Generative AI report before anyone — including me — should claim it works.

The one-line version

Allow search-class and user-triggered AI crawlers in Cloudflare AI Crawl Control, name them in robots.txt with no invented fields, keep llms.txt as a free extra with zero Google ROI, and reconcile against the GSC Generative AI report monthly.

Originally published on my blog: https://javaeye.dev/blog/ai-crawler-governance-checklist/

Google's Request Indexing Quota: What I Measured

Nan — Sun, 18 Oct 2026 13:42:03 +0000

Search Console limits, labels, and quotas change without notice — the quota here is not documented at all. Every number below is a snapshot from early October 2026, measured on my own Google account. Re-measure on yours before you plan around it.

Google Search Console's "Request Indexing" has a daily quota. The help documentation confirms that a limit exists and never says how large it is; the number people repeat in forums — ten URLs a day — has no official source I could find. I spent three days measuring mine. The short version: the quota is shared by every property under one Google account rather than counted per site, the daily number floats, and it recovers hours before Pacific midnight. Here is what I actually logged.

The quota belongs to the account, not to the site

This is the finding that changed how I work, and it is the one I got wrong first. My earliest notes said the limit was counted per account, per property, per day — I assumed each site had its own budget. Cross-property testing disproved it. A small family of free tool sites is what I actually run — the eight of them are listed on my /tools page, and WordRoost is the newest — plus this blog, and when one site under my account had spent the day's quota, a different site under the same account could not submit either.

The clearest single day is 2026-10-09. Sixteen requests succeeded that day, and they were spread across four different properties under one account: one site took one, another took six, this blog took eight, and a fourth took one. Property boundaries reset nothing. The pool was the account's.

Two things that do not change the pool, which I tested specifically because both are common advice: the IP address you submit from, and whether you use an incognito window. Neither made any difference. The only action that gets you a different pool is a different Google account.

The daily number floats, so plan for a range

I have two clean samples of a full day's capacity: 11 and 13. On a third day, 16 requests went through and the 17th was rejected. So "the quota" is not a fixed number you can memorise. Treat it as a range somewhere in the low teens, and stop guessing at an exact figure.

The shape of a batch tells you which end of that range you are on. On 2026-10-07 my blog's batch submitted four URLs and the fifth was rejected — the account had already been used that day, so four was what remained rather than the day's total. The next full batch, on 2026-10-09, submitted eight URLs with nothing left over. Same account, same tool, very different amounts available, because the pool depends on whatever else the account did that day.

Recovery happens before Pacific midnight

The advice I kept reading was to wait for midnight in Pacific time. My logs disagree. After one morning cap, the next day's first submissions at 13:19 Beijing time went straight through. That is hours earlier than Pacific midnight, so I moved my working window to "any time after 13:00 Beijing" and stopped waiting until the evening.

I also tested the other popular claim, that the quota resets at 15:00 Beijing. It does not. On one day the first request at 14:31 was already rejected, a re-test at 15:00:54 was still rejected, and the pool only came back at 17:05. Recovery is not always generous either: one recovery gave exactly one submission before the cap returned.

The first click is a usable signal for how much is left

This is the small observation I rely on most now. When the quota is nearly gone, the first click on a URL returns a transient error — a generic message that there was a problem submitting the indexing request — and the second click succeeds. When the pool is fresh, the first click succeeds and there is no error at all.

Both batches fit the pattern exactly. The 2026-10-07 batch, running against a partly used pool, had a first-click error on all four URLs. The 2026-10-09 batch, running against a fresh pool, had zero errors across eight.

So if you are working through a batch and every first attempt fails, that is not a broken tool. It is the quota telling you it is nearly empty — and it is a good moment to write down where you stopped.

What I do now: stop at the cap, roll the rest, keep the screenshots

Three rules, all of them forced by these runs:

Stop the moment the quota is hit. The remaining URLs go to the next day. Switching accounts to keep going is not worth it, for the reason in the next section.
Screenshot every confirmation. The success state is the line saying the URL has been added to the priority crawl queue. A line you typed into your own log is not evidence; a screenshot is.
Re-check read-only. After a batch, checking whether a URL is already indexed does not consume quota. Only the submit action does.

For cost: a four-URL batch ran about five minutes end to end, and an eight-URL batch about eight minutes. The clicking is not the bottleneck. The queue is.

A second account is not a second full quota

The obvious workaround is to keep a spare Google account and switch when the first one runs dry. I tried it, and it mostly does not work. Quota is attached to the account, and my spare accounts already carried properties of their own — so their budget for the day was partly spent before I arrived. On the worst day, a spare account's very first request was rejected.

Keep a spare if you want one, but look at what else that account does before you count on it. An account with several properties under it is not a fresh account.

What I would tell anyone batching indexing requests

The quota is real, it is smaller than the folklore suggests, and it is not the thing worth optimising. What matters is knowing which pool you are drawing from and stopping cleanly when it is empty. Everything above is one account's behaviour in one week of October 2026, not a documented Google promise — so measure your own before you build a schedule on it.

Originally published on my blog: https://javaeye.dev/blog/google-request-indexing-quota/

This article was created with the help of AI. AI was not used to write the content; it assisted only with translation and grammar checks.

Niche Research: My Go/No-Go Validation Workflow

Nan — Fri, 16 Oct 2026 23:50:58 +0000

I run a small family of free, no-login tool sites — eight of them are listed on my /tools page — and every one of them lives or dies on search traffic. Somewhere around the fifth site I figured out the expensive truth: the real cost of a new site isn't the build, it's committing to the idea before the build. Register a domain on a guess and you're quietly betting three months of work on a hunch. This post is my full validation workflow — every gate a candidate idea has to pass between "interesting word" and "domain registered" — plus the trap that nearly sank one of my sites anyway.

Keyword tools and search behavior change fast. Every number here is a snapshot from early October 2026 — treat this as a workflow demo, not a forever-true dataset.

Gate one: combine word roots into a candidate pool before you have an "idea"

The starting point is never a flash of inspiration. It's a collision of words. My fixed routine: put together a pool of roots — tool words, scenario words, audience words, roughly fifty of them — and combine them into a few hundred candidate phrases. This stage is deliberately unfiltered. The only goal is to build a pool large enough that the next stage, the data, has something real to vote on.

Gate two: the data checks three things — competition, volume, and whether anyone pays

Every candidate phrase goes into a keyword database (I use Semrush). I look at exactly three numbers:

Keyword difficulty low enough. A new domain has no authority. A word with high KD isn't an opportunity, it's a headstone.
Volume large enough. Too small and it can't carry a standalone site — at best it earns one page on a site I already run.
CPC above zero. This one gets ignored a lot, and it's the most honest signal in the set. Cost-per-click is direct evidence that somebody pays for that traffic. Advertisers spending money means real demand with a real business behind it; a candidate where every CPC reads zero is usually people searching for fun.

A candidate that fails any of the three is deleted. No appeal.

For a live example, the phrase-match probe I ran for this very topic this morning returned eight keywords in the "niche research" family: 110 to 720 monthly searches each, difficulties between 18 and 33, mostly zero CPC — a topic people clearly read about, but one nobody advertises on. Fine for a blog post. Useless as a business.

Gate three: zero competitors is a graveyard, not an opening

Candidates that clear the data gate get a manual look at the actual search results. This judgment is counterintuitive:

No competitors at all? Be afraid, not happy. The likely story isn't that nobody thought of it — it's that everyone who did is dead. Demand that weak doesn't support a business.
One or two competitors whose pages haven't been touched in years? That's the green light. Demand is proven — someone is alive serving it — and the reigning champion has stopped trying. A new site with a better page can pry the position loose.

An old, unmaintained number-one ranking is my favorite signal in this whole workflow.

Gate four: communities hold pain that has no search volume yet

Keyword tools can only see demand that already shows up as searches. So I also hang out where the target audience complains — Reddit boards, niche forums — and read how people describe their problems and advise each other. Plenty of real pain is too small or too new to appear in any tool, but you can watch it happen in threads. Those complaints are free research, and they double as a side check that the audience I'm targeting is genuinely annoyed by the thing I want to build.

Gate five: the domain is the last gate, never the first

Only after a candidate passes word pool, data, competitor shape, and community pain do I register a domain. The order is the whole point. Once a domain exists, sunk cost kicks in and I start rationalizing. Keeping registration last keeps abandoning a candidate free — any failed gate means delete the row and move on, at zero cost.

The trap that got me anyway: change the keywords, and the competitors vanish

This workflow wasn't born complete. When I built my seating-chart tool, SortaSeat, the competitor check on the words we'd chosen came back clean, and we green-lit the project. Later we found out the space already had several popular, heavyweight solutions. They simply ranked under a different set of keywords — the words we'd validated with weren't the words normal people searched, so the incumbents were invisible in our results.

The lesson is now written into the workflow in bold: never run the competitor check with only your own chosen words. Search again from different audience perspectives with different phrasing, and read who actually sits on the first page, how old their sites are, and whether anything still gets updated. Search-word bias is the easiest way to fool yourself in this entire process — I know, because it fooled me.

One more habit: every site gets its own blog

The newest addition to the routine: for every tool site, I spin up a separate blog dedicated to that brand's topic. The tool site catches search traffic; the blog tells the brand's story and advertises the tool in long form — each feeding the other. How that plays out in practice is a post of its own, coming next.

What I'd tell a past me

None of these gates is glamorous, and every one of them is two orders of magnitude cheaper than writing code. Word pool, three data checks, competitor shape, community pain, domain last — any single gate can kill a candidate, and a killed candidate is not a failure, it's three months saved. The tool numbers are snapshots; the workflow is the asset.

I wrote about the demand side of this system in my post on finding keyword gaps across my existing sites — the matrix finds where my current family can grow. This workflow decides which new directions get to exist at all.

Originally published on my blog: https://javaeye.dev/blog/niche-research-validation-workflow/

This article was created with the help of AI. AI was not used to write the content; it assisted only with translation and grammar checks.

The 662-Page Indexing Report: Two New States

Nan — Wed, 14 Oct 2026 01:42:41 +0000

Search Console labels and behavior change over time. Every figure here is a snapshot from October 4–5, 2026 — verify against current Google documentation before acting on it.

Last week I published the week-one post on a 662-page static site: one indexed homepage, everything else "URL is unknown to Google", and a promise to run the full-batch inspection in week two. I ran it a day early, on day 7. Here are the final week-one numbers: all 662 URLs inspected, zero state flips on the big site — and the indexing states I was waiting for showed up the same week, on the family's smallest site instead. Plus the first search data worth reading: 92 impressions and a position-21 head term.

The full batch: 662 inspected, and the queue did not move

The full inspection I deferred from launch day happened on day 7 (October 4, 2026), once the results could rank pages against each other. Here is the complete distribution:

State	Count	Share
Submitted and indexed	1	0.2%
Discovered – currently not indexed	0	0
Crawled – currently not indexed	0	0
URL is unknown to Google	661	99.8%

The one indexed page is still the homepage, last crawled October 1, and its referring URLs are still a link from my blog's tools page plus the site itself. Meanwhile the sitemap grew from 568 to 662 URLs during the week and processed with zero errors. Six days after my first post, the queue looks exactly the same at full resolution as it did in a 12-page sample: this is what a healthy week one on a new programmatic site looks like, and the honest headline is that there is no headline yet.

One practical note for anyone running the same play: 662 individual URL Inspection calls took about 80 minutes at a polite per-request delay, and roughly one in four requests failed with a transient SSL error and needed retrying. Batch with resume support, or you will re-spend that quota every time something interrupts the run.

The states showed up — on the 48-page site, not the 662-page one

The week's most informative data came from the smallest site in the family, a 48-page work-hours calculator site called TallyPunch that is three weeks older than the word-list site. A seven-URL scan there captured the family's first two non-terminal indexing states:

URL	State (Oct 4)
/	Indexed
/about/	Indexed
/biweekly-time-card/	Indexed
/what-is-time-and-a-half/	Indexed
/time-card-calculator/	Indexed
/how-many-hours-is-12pm-to-8pm/	Discovered – currently not indexed
/how-many-hours-is-9am-to-5pm/	Crawled – currently not indexed

Same family, same infrastructure, same sitemap-and-internal-links launch pattern — opposite trajectories. My working hypothesis, and it is only a hypothesis: a 662-page sitemap lands in Google's queue as one big batch that gets paced, while a 48-page site gets crawled to completion in days. Small sites get depth first; big small sites wait in line longer. If the week-two rerun on the big site shows the first flips, I will take that as support.

The checklist-driven responses are deliberately boring. The Discovered page gets an internal-link priority check (it currently has no referring URLs) and then patience. The Crawled page — Google fetched it on September 28 and declined to index it — gets two weeks of observation with zero changes, until October 18, before any attribution. Changing a page during its observation window destroys the experiment.

The first query data worth reading

Indexing states tell you what Google did. Query data tells you what searchers did. Until this week, every site in the family sat under my 20-impression floor: below that, I write "insufficient sample" and touch nothing. This week the smallest site crossed it.

The 48-page site recorded 92 impressions across 50 query rows in the measurement window (September 22 to October 1; the API's rolling window lags by a few days). Zero clicks, so click-through rate is still meaningless. What matters is position:

Head term: "30 minute lunch break calculator" — 4 impressions at position 21. A calculator page is one page away from page one of Google for its exact keyword, three weeks after launch.
Same cluster, hyphenated variant: "30-minute lunch break calculator" — 4 impressions at position 38.8, a reminder that near-duplicate queries rank independently.
Mid-tail: time-card and hours-to-decimal terms each show 1–2 impressions at positions 65–86 — normal new-site depth, nothing to act on.

One page at position 21 is not a trend. It is the family's first discriminating signal: proof that a brand-new domain with zero backlinks can get within sight of page one on a specific, answer-shaped query. The next checkpoint is whether it enters the top 10, and that is a week-two question, not a week-one one.

What I changed this week: nothing

The checklist I wrote on launch day said "unknown = normal, check again in two weeks", and the full-batch data says the same thing with 662 rows instead of 12. The complete action list from this inspection:

Put the Crawled-state page on a watchlist with a hard date — no edits before October 18.
Recheck the Discovered-state page at the next inspection; add an internal link entrance only if it stalls.
Rerun the 662-page batch next week, same caliber, and compare flips.
Keep interpreting nothing under 20 impressions.

Boring is the point. New-site indexing is a queue, and the data so far rewards the people who wait in it without fidgeting.

A meta footnote

The week-one post I promised this follow-up from is, as I write this on October 5, itself "Discovered – currently not indexed" — 38 hours after publication. The post about that state now lives in that state. Both are queue positions, not verdicts; that was the thesis, and apparently it applies to the thesis too.

This article was originally published on my blog: https://javaeye.dev/blog/week-one-full-indexing-report/

This article was created with the help of AI. AI was not used to write the content; it assisted only with translation and grammar checks.

Programmatic SEO Examples: 8 Sites, 946 Pages

Nan — Tue, 13 Oct 2026 01:32:35 +0000

Programmatic SEO advice and search volumes change fast. Page counts and keyword figures here are snapshots from October 3–4, 2026 — verify against current data before acting on them.

Search "programmatic SEO examples" and you get the same case studies every time: Zapier, Canva, Wise — companies with engineering teams and data budgets. Here is the other kind of example. I am one developer running eight small static tool sites: 946 pages total at last count (October 4, 2026), every page generated from a structured data source, no database, no CMS, no build pipeline beyond a script. This post is the full inventory — what each site generates pages from, the one matrix type the big-brand lists never mention, and the build-time gate that keeps thin pages from shipping.

What programmatic SEO actually means at this scale

Programmatic SEO = pages generated from structured data instead of written one at a time. At Zapier scale that means thousands of integration pages pulled from a live database. At my scale it means: one template, one data file, one script, and a folder of HTML files uploaded to a CDN. The sites are free tools, no login, no ads worth mentioning. Every page exists because a keyword said people want it.

The eight sites, in one table

Site	Pages	What generates them
WordRoost	662	Word-list matrix: words containing / starting / ending in letter combinations
SparkFont	78	Font style generators + printable alphabet pages
TallyPunch	48	Work-hours calculators: time cards, overtime, shift math
Bracketree	40	Tournament bracket templates by field size and format
GridRoster	36	Rotating shift schedule grids
StudCalc	33	Construction material calculators: concrete, gravel, lumber
TrueCubic	29	DIY material calculators for home projects
SortaSeat	20	Seating chart templates by layout

946 pages across eight domains. Notice what is not in the table: a database. Each site's "programmatic" layer is a JSON or CSV file checked into the repo, and the entire build runs in seconds on a laptop. That is a deliberate constraint, not a budget limit — the same constraint that lets me keep every page static and every tool no-login.

The matrix type big-brand case studies never show you

Every famous pSEO example is a lookup play: integrations, job postings, city pages — one entity, one page. My largest site runs a different shape I rarely see documented: a combinatorial constraint matrix. WordRoost's pages are not "words that start with Q". They are intersections — five-letter words containing both Q and X, words ending in ELN — generated by crossing word-length rows with letter-combination columns. The October 3 sitemap shows 662 such intersections, each backed by a real filtered word list.

The matrix has a property lookup pages do not: every cell is cheap to validate. A word list either contains matches or it does not. That enables the next section's gate.

The build-time gate that keeps thin pages from ever shipping

The dirty secret of pSEO at any scale is empty pages. A generator that blindly produces one page per matrix cell will happily ship "five-letter words ending in IUE" — a page with zero real words on it. Google has seen a billion of these and indexes none of them.

My build refuses to do this, twice over:

Zero-hit cells are deleted, not published. The latest WordRoost build killed 12 shape-valid keywords whose word lists came back empty. They never reach the sitemap; they never existed as far as Google is concerned.
Wrong-intent keywords are rejected before the matrix even runs. 155 collected keywords are sitting in a reject file with reasons attached: 55 were not list-shaped at all, 52 demanded word lengths the data does not cover, 26 needed a human-curated prefix list, 24 belonged to constraint families the generator cannot express, and a handful were tool-intent words (solver, unscrambler) that a previous CPC check had already falsified.

This is the part of pSEO nobody puts in a case study, and the part that decides whether a small site survives: the generator's most important output is the list of pages it refused to make.

What I would copy from the big names — and what I would skip

Copy the data-before-pages discipline. Zapier's integration pages work because each one answers a real query with real data. My keyword files go through the same filter: volume and difficulty thresholds (Semrush, October 2026 probe: the "programmatic SEO" cluster around this topic — examples, tools, strategy — totals roughly 530 US searches a month, with KD scores from 10 to 27) before any page earns a slot.

Skip the scale-as-goal mindset. The big cases measure pages in the hundreds of thousands; at that scale, thin pages are a rounding error and the domain's authority carries them. On a new domain with no backlinks, every page competes on its own merits. 946 honest pages beat 9,460 thin ones, because each honest page is a page a human would not bounce from.

What the numbers look like one week in

Honesty section, because the KPI section of a pSEO case study is where most of them lie. The eight-site family is young: the oldest pages have been crawlable for about two weeks, the newest site (WordRoost) launched September 28, 2026. Current state, measured through Google's URL Inspection API on October 3: of WordRoost's first 662 pages, the homepage is indexed and the rest are still "URL is unknown to Google" — a queue, not a verdict. On TallyPunch, three of seven sampled pages are indexed. Total search impressions across the family: under the 20-impression floor where I treat the data as insufficient sample and change nothing.

So this is an example collection, not a success story — yet. The infrastructure claim I can already stand behind: every published page answers a real query with real data, and the generator proved it before shipping. The traffic claim I will report in a follow-up post when the numbers deserve one.

Originally published on my blog: https://javaeye.dev/blog/programmatic-seo-examples-eight-sites/

This article was created with the help of AI. AI was not used to write the content; it assisted only with translation and grammar checks.

Discovered – Currently Not Indexed: Week One Data

Nan — Mon, 12 Oct 2026 12:54:48 +0000

Search Console labels and behavior change over time. Every figure here is a snapshot from late September / early October 2026 — verify against current Google documentation before acting on it.

Roughly 1,300 people a month search some form of "discovered currently not indexed" (Semrush, October 2026 snapshot), and almost every result they land on is a generic explainer. This post is the other kind: real numbers. I run nine small static tool sites — eight of them are listed on my tools page — and the newest one, a 662-page word-list site called WordRoost, went live on September 28, 2026. Six days in, here is what the indexing states actually look like: the homepage got indexed before the sitemap was even submitted, every inner page still reads "URL is unknown to Google", and the dreaded "Discovered – currently not indexed" has not appeared at all. The checks that told me anything useful were exactly three.

The three states are three different problems

Google's own Search Console help page says it plainly. "Discovered – currently not indexed: The page was found by Google, but not crawled yet. Typically, Google wanted to crawl the URL but this was expected to overload the site; therefore Google rescheduled the crawl." And right above it: "Crawled – currently not indexed: The page was crawled by Google but not indexed. It may or may not be indexed in the future; no need to resubmit this URL for crawling." (support.google.com/webmasters/answer/7440203)

Read those twice, because they are not the same problem. Discovered-but-not-indexed is a scheduling story — Google knows the page exists and simply has not fetched it yet. Crawled-but-not-indexed is a judgment story — Google fetched the page and declined to keep it. "URL is unknown to Google" is a third thing again: Google has not even seen the URL. Treating these as one blob called "indexing issues" sends you fixing the wrong thing with total confidence.

My data agrees with the official reading. On the new site, the state I actually live in is "unknown to Google" — a queue problem, not a quality problem. The day a page flips to "Discovered – currently not indexed", my first check will not be content. It will be internal links, because a page Google discovers but keeps postponing is usually a page Google considers low-priority — and priority is what links signal.

Week one, real numbers from a 662-page static site

Check	Day 0 (Sep 28)	Day 6 (Oct 3)
Sitemap status	Submitted 11:43 UTC, pending	Processed, 0 errors, 0 warnings
Sample URL inspection (12 → 9 URLs)	1 indexed, 11 unknown	1 indexed, 8 unknown
Indexed page	Homepage, found before sitemap submission	Homepage, last crawled Oct 1

Two details carry most of the information. First, the homepage was indexed before the sitemap went in — its referring URLs in Search Console include a link from my own blog's tools page, so plain discovery through links worked. Second, on day 6 the inner pages are still "unknown to Google" even though the sitemap has been processed with zero errors. That combination — sitemap read, homepage in, everything else unknown — is what a healthy week one looks like for a small new site. It is a queue, and the queue is long.

A sibling site three weeks further along shows the transition. Of seven pages I sampled there, three are indexed (an about page and two calculator pages, first crawled September 17) and one matrix page is still unknown. The states move unevenly across page types, and they move slowly.

Only three checks have discriminating power in week one

I wrote the inspection checklist before any data existed, on launch day, precisely so I would not improvise criteria after seeing numbers. In week one, three checks earn their place:

Sitemap processed with zero errors. This proves the submission channel works. If it errors here, nothing else matters yet.
The homepage is indexed. This proves discovery and crawling work — and if it got in via a plain text link before the sitemap, internal linking is doing its job.
URL Inspection returns states, not errors. This proves the API channel works and gives you the state distribution to watch over time.

Everything else — impressions, average position, click-through rate — is zero or noise in week one. My standing rule: under 20 impressions in a window, I write down "insufficient sample" and touch nothing.

The failure mode is fixing things when there is nothing to fix

The most dangerous moment in week one is seeing zero data and concluding something must be done. Chasing "indexing fixes" with no signal means guessing, and guesses cost real work: rewriting pages that were never the problem, resubmitting URLs Google already has, publishing content to impress a crawler that has not arrived.

Two traps nearly got me before the data did. The analytics script I use defaults to a rolling window whose upper bound is always three days in the past — on launch day, that window silently excluded launch day, and two runs on different dates were not comparable. Fixed by pinning explicit start and end dates. And a full 662-page URL inspection on day 0 would have returned 662 identical "unknown" results: zero discriminating power, real quota spent. I deferred the full batch to week two, when the results can actually rank pages against each other.

What I am watching next

Week two brings the first full-batch inspection of all 662 URLs. The distribution — how many flip from unknown to discovered, how many from discovered to indexed — is the first real signal. If "Discovered – currently not indexed" shows up at scale, the response is boring: strengthen internal links to those page types, confirm the site is not accidentally slowing crawlers down, and wait. If "Crawled – currently not indexed" shows up, that is the quality signal, and it gets two weeks of observation before any attribution. Boring is the point. Indexing a new small site is a queue, and the job in week one is to make sure you are in it — then let it move.

Originally published on my blog: https://javaeye.dev/blog/discovered-currently-not-indexed-real-data/

This article was created with the help of AI. AI was not used to write the content; it assisted only with translation and grammar checks.

Keyword Matrix: How I Find Gaps My Tool Sites Miss

Nan — Sat, 10 Oct 2026 11:19:53 +0000

I run a small family of free, no-login tool sites — eight of them are listed on my tools page — and each site lives or dies on search traffic. This morning I ran two keyword-matrix batches to find ranking gaps: clusters of keywords nobody in my family covers yet. One cluster, printable habit and savings trackers, died on the numbers. One came back from the dead: 79 legal-document keywords under KD 20, roughly 12,000 monthly searches combined, with cost-per-click figures up to $3.42. This post is the full run — the workflow, the real figures, and two decisions I would not have made by guessing.

SEO tooling and search behavior change fast. Every number in this post is a snapshot from early October 2026 — treat it as a workflow demo, not a forever-true dataset.

Guessing keywords failed me, so I stopped guessing

Last week's case study about my PageSpeed scores started with ten keyword phrases I invented by intuition — phrases like "defer third party scripts". All ten returned zero search volume. Not low volume. Zero. A keyword tool can only report how people actually search, and people do not search like me.

So the workflow changed. Instead of inventing phrases, I now mine three sources:

keywords that competitor sites already rank for
questions people ask in communities around my topics
word pools my own sites have not touched

Earlier this week I tore down timecalculator.net, the strongest competitor of my time card calculator site TallyPunch, layer by layer — page types, headings, FAQ schema. That teardown alone turned into 36 matrix pages. A competitor's keyword list is a map of proven demand: every word on it is a group of people already looking for something.

The matrix: topic rows, word-form columns, two probes per cell

The matrix is a grid. Rows are topics or audiences — printable trackers, legal documents, paycheck calculators. Columns are word forms — generator, template, printable, calculator, maker. A cell is one seed phrase, like "will template" or "habit tracker printable".

Each cell gets two probes through the Semrush keyword API, declared in a small seed file before every run:

{ "phrase": "will template", "filters": { "volumeMin": 100, "kdMax": 20 } }

Probe A keeps every phrase-matched keyword with at least 100 monthly searches and keyword difficulty (KD) at or under 20 — the range a small new site can realistically rank for. Probe B is the watchlist: volume at least 500, KD up to 40 — too hard today, worth re-checking as domain authority grows.

Both probes run on the US database, phrase match, in USD. Every batch ends with a six-dimension verdict: demand size, competitor presence, monetization, two standing rules of my own, and page format.

Decision one: printable trackers died on the money dimension

I wanted a new printable tracker site. Habit trackers, savings trackers, mood trackers — people search for these and print them, so the gap looked real. The run returned 13 keywords with a combined ~8,700 monthly searches, and the difficulties were gentle: savings tracker printable sits at 590 searches a month with KD 12; mood tracker printable is 110 with KD 18. The head word, habit tracker printable, carries 2,400 searches a month.

The monetization dimension killed the idea. All 13 keywords are informational intent — people want a free PDF, not software. The CPC range, $0.42 to $1.20, is what advertisers pay for that traffic, and it means ad revenue alone cannot carry a standalone site.

I almost built a whole site because I liked the words. The fix: the cluster moves into the word pool of WordRoost, my word-lists site, which already serves the same printable-and-list audience with the same ad infrastructure. No new site. Same keywords, different home.

Decision two: one word form returned zero rows, the other returned 79

I wanted legal document keywords — wills, leases, eviction notices. The first run used the "generator" word form: "will generator", "lease agreement generator", and so on. The result was six empty CSV files. Zero rows across the board. My first thought was that the collection script was broken. It was not. My word was.

So I moved one column sideways in the matrix — generator to template — and ran the cell again. "Will template" and its sibling seeds returned 79 keywords under KD 20 with a combined ~12,000 monthly searches, and this cluster is commercial: people want a document, and legal template services pay real money for that click.

Document row	Keywords under KD 20	Strongest example	CPC signal
Will template	38	Oregon and Pennsylvania at KD 7	—
Lease agreement template	26	Maryland: $3.42, KD 13	$2.80–3.42, the best in my whole project
Power of attorney	9	New Jersey: 480/mo, KD 16, $1.63
Eviction notice	3	Texas: 480/mo, KD 17, $1.55

The big head words stay on the watchlist for now: lease agreement template alone carries 14,800 monthly searches, but KD 40 is out of reach for a new domain. The realistic ceiling is a state matrix — 50 states times five document types, roughly 250 pages — each page a real template download for one state.

The lesson is now written in my playbook in bold: a falsified word form is not a falsified demand. Before killing a topic, move one column sideways.

A rescued cluster still has to pass the competitor gate

Numbers alone do not launch a site. The next steps for the legal cluster are manual: check the actual search results for ten state-level words to confirm small sites can rank, and verify that competitors in this niche make money. My standing rule is no competitor revenue, no build.

The rule has saved me before. In a four-direction verification round last week — timers, word-game helpers, recipe calculators, education worksheets — every direction turned out to have competitors with real revenue, from a $19.95-a-year ad-free membership at math-aids.com (taken from the site's own subscription code on 2026-09-26) to a stage timer SaaS reporting €20K MRR. Micro-clusters look small in a spreadsheet and still carry real businesses; a cluster with no revenue anywhere is usually a trap.

What I'd tell a past me

Keep the probes cheap, keep the verdict boring, and write down why a cluster died — printable trackers died on money, not demand, and that difference decides whether a cluster gets merged, parked, or built.

Third-party volumes and KD scores are estimates with snapshot dates; the workflow is the asset, the numbers are weather. The follow-up to this post will be the legal cluster's SERP check — ten state words, opened one by one, with what actually ranks.

Originally published on my blog: https://javaeye.dev/blog/keyword-matrix-gap-analysis/

This article was created with the help of AI. AI was not used to write the content; it assisted only with translation and grammar checks.

Mobile PageSpeed Insights: Why Scores Stall

Nan — Fri, 09 Oct 2026 08:40:47 +0000

PageSpeed tooling and lab scores shift with every Chrome release. Every score in this post is a snapshot from September–early October 2026 — re-run your own measurements before acting on it.

The main bottleneck on my static tool site was not my code. It was a single 177KB third-party analytics script, and moving its load out of the parse window took five pages from 83–96 to 99–100 on Google PageSpeed Insights (mobile), with LCP dropping from 3.5s to 1.5s. This post is the full case study: the measurement traps, the numbers, the code, and the second failure I did not see coming.

Quick numbers (TallyPunch, official PSI mobile, September 2026):

Page weight: mine ~14KB, third parties ~180KB — 93% was not mine
Worst page: 83 → 99, LCP 3.52s → 1.52s
Cost: one script-loading change. Zero changes to my own code

Measurement behavior at PSI changes over time; treat the caching quirks below as "verify against current docs," not eternal law.

Set your baseline on official PageSpeed Insights, not local Lighthouse

If you have ever wondered why your mobile PageSpeed Insights score is so hard to move while local Lighthouse says everything is fine — the two tools are measuring different worlds. The same page, at the same moment:

Measurement	Scores
Local Lighthouse (my network, mainland China)	39 / 63 / 57
Official PageSpeed Insights (Google's servers)	96 (three runs, identical)

Local Lighthouse is the open-source audit engine running on my machine over my network. PageSpeed Insights runs Lighthouse on Google's hardware over a simulated mobile network, blended with real-user data. On my restricted network, the third-party script's download and execution timing lands randomly inside or outside the measurement window, and the local variance becomes too large to optimize against. Google's official Core Web Vitals thresholds — LCP 2.5s, INP 200ms, CLS 0.1 — are the same numbers PSI scores against, so a baseline taken anywhere else is optimizing for the wrong target.

One more trap: PSI serves cached responses for identical URL + strategy requests. Three "consistent" reads may be one cached response. Break the cache before trusting the median, and compare against an untouched control page from the same session.

The failing resource is usually not your own code

My site's entire bill, from the PSI third-parties-insight audit, looked like this:

Item	My code	Third parties
Transfer bytes	HTML + CSS + favicon ≈ 14KB	gtag.js 177KB + CF beacon 10KB
Share of 194KB total	~7%	93%
Main-thread time	~90ms	gtag 171ms (786ms blocking, local)
CLS	0.000	—

Fourteen kilobytes of my own code, zero forced reflows, zero layout shift. Nothing to fix there — which was almost disappointing, because I had a profiler ready and no villain of my own to catch.

The diagnosis lives in three PSI audits, not in the headline score: third-parties-insight shows who eats the main thread, total-byte-weight shows who eats bytes, and long-tasks shows the causal chain — in my case a long task starting at 2429ms against an LCP of 2551ms, the task sitting exactly on top of the paint moment. That is causation, not correlation.

This also falsified, for this site shape, the common claim that TTFB is the upstream cause of LCP. My server-response-time was 1ms. On a small static site, the bottleneck is bytes and main-thread time, not the server. The TTFB chain holds or breaks depending on what kind of site you run — quantify before optimizing.

Local A/B tests prove the mechanism, never the magnitude

A controlled localhost A/B — same build, one variable, interleaved runs — cleanly isolated the mechanism. gtag static tag versus deferred load: TBT 343ms versus 0ms. Mechanism confirmed.

But two structural blind spots make local numbers non-portable. First, the RTT blind spot: localhost has effectively zero round-trip time, while PSI's simulation charges 150ms per request. Both local variants capped at 99 with unchanged LCP; the same page scored 83 on PSI, and the entire gap lived in the RTT chain. "No change locally" does not mean "no change on PSI." Second, my restricted network inflated the third-party cost about fivefold — 786ms of blocking locally versus 171ms in PSI's environment. Direction agreed, magnitude did not.

The rule I kept: local A/B answers "does the mechanism work," and official PSI answers "how much does it buy." Mixing the two wastes an afternoon, and I speak from experience.

Defer third-party scripts until first interaction — and pin the delay with a test

The fix keeps analytics semantics completely intact; it only moves the library's injection later:

<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}
  gtag('js', new Date());
  gtag('config', 'G-XXXXXXX');          // config stays inline — semantics unchanged
  (function () {
    var src = 'https://www.googletagmanager.com/gtag/js?id=G-XXXXXXX';
    var FALLBACK_MS = 10000;            // named constant, locked by a unit test
    var done = false;
    function load() { if (done) return; done = true;
      var s = document.createElement('script'); s.async = true; s.src = src;
      document.head.appendChild(s); }
    ['pointerdown','keydown','touchstart','scroll'].forEach(function (ev) {
      window.addEventListener(ev, load, { once: true, passive: true });   // real users: no data lost
    });
    window.addEventListener('load', function () {
      setTimeout(function () {                                            // passive visits: out of the window
        if (window.requestIdleCallback) requestIdleCallback(load, { timeout: 2000 });
        else load();
      }, FALLBACK_MS);
    }, { once: true });
  })();
</script>

Three load-bearing details. The dataLayer stub and config call stay inline in the document, so no tracking call site changes. Real users trigger the load on first interaction — click, key, touch, or scroll — so session data survives. The fallback fires 10 seconds after load for passive visitors, pushing the script out of the lab measurement window.

The honest cost: a visitor who reads passively and leaves within ten seconds is not counted. That trade was worth it for my content site, but it is a real trade, and I keep the books on it.

The second failure mode is subtler: setting FALLBACK_MS too low. A two-second delay drags the long task straight back into the TBT measurement window — the score collapses by points, and six months later nobody remembers why. My unit test asserts FALLBACK_MS >= 8000, bans any static <script async src=...> tag, and checks all four interaction triggers exist. The constant has a name because the number is a promise.

A site-wide fix patched into one page is debt, not optimization

Then I audited a second site — TypeOnSkin, an interactive tattoo-font editor — and the main cause was the opposite of everything above. Not third parties. My own first-screen CSS, linked externally, render-blocking: main.css wasted 151ms and fonts.css wasted 451ms, and the external stylesheet delayed the font requests until CSS finished parsing. The fix script that inlined critical CSS only served the homepage.

The homepage had already been cured of this exact disease one day earlier. The test that guards it even carried the diagnosis in its assertion message — "head must have no render-blocking external CSS (v1 externals caused mobile PSI 79)" — but that assertion only scanned index.html. The cause of death was written inside the guardrail, and the guardrail watched one page. Every new page type re-caught the disease, legally, with nobody remembering the original outbreak.

The general form, and the most valuable sentence in this post: a site-wide optimization implemented as a patch on one page is not an optimization — it is debt. Every new page type re-runs it, and the rerun never remembers why.

The repair had three parts, all required: inline critical CSS in the build script's shell itself rather than as a post-build injection step; one shared inlineStyleTag() constructor used by both baking and post-processing; and a whole-site invariant, asserted across every HTML file, that the head contains zero rel="stylesheet" links. Structure beats score for verifying recovery — scores get noisy, structure does not. All 24 pages now ship zero render-blocking stylesheets and zero CSS requests. (The font preload I almost added would have been negative value: the LCP element is system-ui body text, so preloading fonts only competes for bandwidth. Check what your LCP element actually is before optimizing for it.)

How to improve Core Web Vitals: the ten steps, in order

This is the checklist my next site will run from day one — a Core Web Vitals case study compressed into mechanics:

Take the baseline on official PSI. Break its cache first, run five or more passes, take the median, and judge against an untouched control page from the same session.
Open third-parties-insight and total-byte-weight. Identify who owns the bytes and the main thread before touching anything.
Compare long-tasks start times against LCP. A long task starting at the paint moment is the causal chain you are looking for.
Audit your own first-screen CSS too. Look for external rel="stylesheet" in the head and wasted milliseconds in render-blocking-resources — the second most likely villain.
Defer third-party scripts until first interaction, with an idle fallback well outside the measurement window.
Lock the deferral in tests: no static script tags, a named FALLBACK_MS constant with a floor assertion, all interaction triggers present.
Build site-wide invariants into the build itself, with one shared constructor and whole-site assertions — never a per-page patch.
Identify the LCP element before any font or image strategy. Preloading assets the LCP element does not use is negative value.
Re-measure on PSI after every change. Local numbers confirm mechanism only.
Collect the side findings — my pass also surfaced 16 color-contrast failures and security-header suggestions. The audit you ran anyway owes you the small print.

The results, before and after (official PSI, mobile)

Page	Score	LCP	TBT
Home	96 → 100	2.55s → 1.52s	100ms → 0ms
time-card	83 → 99	3.52s → 1.52s	0 → 0ms
biweekly	83 → 99	3.53s → 1.53s	0 → 0ms
double-time	90 → 99	3.49s → 1.55s	45ms → 0ms
decimal	90 → 100	3.51s → 1.53s	60ms → 0ms

The site is TallyPunch, a free no-login time-card calculator suite for US small businesses. The 93%-third-party pattern should generalize to any small static site running analytics; the render-blocking relapse warns anyone maintaining more than one page type.

Originally published on my blog: https://javaeye.dev/blog/pagespeed-insights-mobile-case-study/

This article was created with the help of AI. AI was not used to write the content; it assisted only with translation and grammar checks.

I Built a Few Products Nobody Used: Honest Lessons

Nan — Tue, 06 Oct 2026 07:09:50 +0000

I spent my first months as a full-time indie developer building small products that almost nobody used. Since October 2025 I have shipped a few tools, earned zero revenue from them, and learned four expensive lessons: building before validating demand, entering red oceans, over-engineering, and ignoring domains and search indexing. This post covers all four mistakes, plus why I am still not discouraged.

Why do beginner indie developers pick "safe" ideas?

At the beginning, I picked businesses I thought were easy to understand. A debugging tool, a relationship quiz — products with clear boundaries, where I did not even have to imagine the demand. Public cases already existed: other people had shipped similar things, and those products looked like they worked.

With AI-assisted development, cloning an existing idea and adding my own twist took very little time. From a product perspective, this felt like a low-risk path: the direction was proven, the build was fast, and the remaining steps seemed to be "ship it, tell people, wait for users."

What happens when you launch a product nobody wants?

The products went live, and then nothing happened. No users, no feedback, and almost nobody knew these products existed. I did promote them on social media, and the effect was very limited.

That silence was the part I had no plan for. I knew how to build; I had no idea how to be found.

What happens if you build before validating demand?

Looking back, the whole process may have been backwards from step one. My approach was: decide "I can build this", build it, and then hope someone needs it. The order I lean toward now is the reverse: search keywords first, see what people are actually searching for, and only then decide what to build.

"Build it and they will come" simply did not happen for me. This is my own experience, not a law — but it is the most expensive lesson of my first year.

What is a red ocean market?

A crowded market where many competitors already fight over the same customers. For a beginner it is usually a losing fight before you even enter, because promotion and features decide the outcome rather than effort alone. I only learned to check how crowded a topic is before entering it after paying the tuition — I had simply never known this check existed.

Is over-engineering your first MVP a mistake?

Yes, and I made exactly that mistake: I built the website "big" by default — login, payment, an admin panel, everything a real product should have. The problem was that I could not clearly explain what pain point the business actually solved. In hindsight, I was mostly using AI development to keep polishing something I wanted to build.

In the end, nobody even knew the core function existed, so the login and admin panel meant nothing. AI makes "just build it" so easy that thinking first actually gets harder — wrong ideas get implemented more efficiently too.

Domains and search indexing: the infrastructure detours

I picked cheap domains with no relation to the topic — they helped almost nothing. Search indexing was worse: I only knew "after launch, Google should find it", and I had no idea how to register a site with Google Search Console. I fumbled for months before I even found the door.

The server side was equally new. My first cloud server was Tencent Cloud — powerful, but configuration and maintenance felt tedious. Later I came across Cloudflare, and the comparison made the earlier experience feel even more troublesome.

Why I am still not discouraged

Even with no users and no product revenue, I genuinely enjoy this life. I take on some outsourcing work to cover living costs, and I would rather put that income back into indie experiments. Building itself is the reward, so the failures did not change that.

I have come to think this might be a hidden threshold of indie development: if only success can keep you going, the long silent beginning is very hard to survive.

My failure list and plan list (both still being validated)

Failed so far:

Building before validating demand, and having nobody show up
Entering a mature market without checking competition
Building login, payment, and admin for zero users
Using cheap unrelated domains, plus months of detour on search indexing

What I plan to try:

Keyword-first topic selection: check demand and competition before building
Treat social media as a long-term asset, while focusing on organic traffic
Make the core value discoverable and usable first; defer other infrastructure

Quick answers

How do you judge real demand? Search keywords: volume tells me demand exists, competition tells me how much room a beginner has. Works for me so far — not a law.

Should a first product include login and payments? My lesson says no. Ship the core value first; add the rest only when real usage asks for it.

Was the detour wasted time? Not entirely — the engineering ability and the intuition for "what is a useless feature" are real. But this tuition is cheaper paid in advance.

Originally published on my blog: https://javaeye.dev/blog/first-products-nobody-used/

This article was created with the help of AI. AI was not used to write the content; it assisted only with translation and grammar checks.

Generating Tournament Brackets in Vanilla JS: Seeding, Byes, and the Loser's Bracket

Nan — Sun, 04 Oct 2026 10:04:29 +0000

I run a small rec-league circuit, and every season someone redraws the playoff bracket by hand, gets a seed wrong, and quietly ruins the loser's bracket. So I sat down and wrote a bracket generator — plain JavaScript, no framework, no backend, no build step. The interesting part wasn't the UI. It was that three things everyone hand-waves in a bracket — seeding order, byes, and the loser's bracket — each hide an actual algorithmic decision.

Here's what I ended up with, with the real code.

1. Seeding is a recursion, not a shuffle

A seeded single-elimination bracket for s = 2^r teams has a fixed constraint: in every round, the sum of the two seeds playing each other should be 2^r + 1 (1 vs 16, 2 vs 15, ... 8 vs 9 in a 16-team bracket). If you just shuffle or sort naively, you break that invariant and the #1 and #2 seeds can meet in round one.

The standard fix is the "nested" construction: take the order for s/2, then for each seed x in it, emit x and s + 1 - x:

function seedOrder(s) {
  let order = [1, 2];
  while (order.length < s) {
    const size = order.length * 2;
    const next = [];
    for (const x of order) next.push(x, size + 1 - x);
    order = next;
  }
  return order;
}

seedOrder(8); // [1, 8, 4, 5, 2, 7, 3, 6]

Round one pairs are adjacent entries, and every pairing sums to s + 1. Four lines, and it's testable against a printed NCAA bracket forever.

2. Byes are slots, not special cases

Non-power-of-two team counts (5, 6, 7, 9...) mean byes. The tempting approach is a bunch of if (hasBye) branches scattered through the render code. That way lies pain, because a bye affects three things at once: who advances, which match doesn't exist, and what the "loser" of a bye is (nothing — there is no game, so nobody drops into the loser's bracket).

I made a bye just another slot:

if (a && b) {
  r1.push({ id: `W${gid}`, slots: [a, b], winner: `W${gid}`, loser: `L${gid}` });
} else {
  const adv = a ?? b;
  r1.push({ id: null, bye: true, slots: [adv, { kind: 'bye' }], winner: adv, loser: null });
}

A bye round has id: null, loser: null, and the advancing team's slot object is reused directly in the next round. The renderer treats it uniformly, and — this mattered more than I expected — the double-elimination logic stays correct for free, because "bye losers" simply never enter the losers pipeline. One representation, zero special cases downstream.

3. The loser's bracket is a two-stage pipeline, not a tree

This was the surprise. A winners bracket is a tree: every match feeds exactly one parent. A losers bracket is not any tree I could draw first and fill in later, because the set of teams arriving each round depends on who lost this round in the winners bracket.

What works is thinking of it as a pool with a two-stage pump, once per winners round:

Minor stage: the survivors currently in the losers pool play each other. If the count is odd, the last one gets a pass.
Major stage: the winners of those minor matches face the teams that just dropped out of the winners bracket this round. Pair them in order. If more teams dropped than survived, the extra drop-ins pass through to the next pool.

const pairUp = (xs) => {
  const matches = [];
  const rest = [...xs];
  while (rest.length >= 2) matches.push(lMatch(rest.shift(), rest.shift()));
  return { matches, survivors: [...matches.map((m) => m.winner), ...rest] };
};

// per winners round k:
const minor = pairUp(pool);
// survivors[i] vs drops[i] for i < min(survivors, drops);
// leftovers (either side) carry into the next pool unchanged
pool = [...majorWinners, ...minorSurvivors.slice(n), ...drops.slice(n)];

Run that loop once per winners round and the pool drains to exactly one team: your losers bracket champion. Two properties fall out of the construction and are worth asserting in tests: a team is never asked to play twice in the same "round", and the total game count for n teams is at most 2n - 1 (one fewer if your format skips the grand-final reset).

Byes from step 2 flow through here too — an odd-sized drop creates a carry-through, which is exactly the drops.slice(n) term.

Round robins are the easy one

For completeness: a round robin schedule is the circle method. Fix team 1, rotate the rest by one each round, pair mirror positions:

players = [players[0], players[size - 1], ...players.slice(1, size - 1)];

For an odd number of teams, append a dummy null to the ring; whoever pairs with the dummy has a bye that round. After trying to be clever with modular arithmetic twice, the rotate-and-mirror version is the one I could still read in six months.

Why all of this is pure functions

The whole engine — validation, the three builders, seed order, share-URL encode/decode — is pure functions over a config object. The same file runs in the browser, gets imported by the static-site baker, and is loaded directly by the Node test suite. No DOM, no fetch, no state. That one decision is why testing "5-team double elimination places byes correctly" is a one-liner instead of a browser automation job.

I packaged all of this into a free, print-first bracket generator (single/double/round robin, 3–128 teams, byes placed automatically, nothing stored) if you want to see the output or steal the code: bracketree.com

And if you draw yours on paper anyway: pencil in the loser's bracket. It will change.