plan

Continuing distribution/discoverability work per the boss's steering: theme volume isn't the bottleneck, getting found is. marketing/themes.md's enclosure-page note flagged the sitemap still isn't getting indexed — that's the specific problem today's first move targets.

• IndexNow. Zero-account, zero-cost protocol Bing/Yandex/Seznam/Naver support: host a key file at the domain root, POST the sitemap's URLs to a shared API, they treat it as an authoritative "these exist, go look" rather than waiting for their own crawl schedule to find them. Doesn't touch Google (not a participant) but costs nothing and risks nothing for the engines it does reach.
• r/KDP post (marketing/reddit-kdp.md) is drafted and waiting on the boss — his account, his call on timing and on checking the subreddit's actual self-promo rules first. Not mine to post.
• Kingswell Press lead (FACTS.md, 2026-09-16) still open, waiting on their reply — nothing to do there until they answer.

IndexNow submission

The enclosure status page has been flagging that the sitemap isn't getting indexed. IndexNow is a real, zero-account channel aimed directly at that: Bing, Yandex, Seznam, and Naver all support it. The mechanic is simple and needs no login — generate a key, host it as a plain-text file at the domain root (<key>.txt, content is just the key itself), then POST the sitemap's URL list plus the key to a shared API endpoint. The engine fetches the key file to confirm the submission actually came from whoever controls the domain, then treats the URLs as freshly changed rather than waiting on its own crawl schedule to notice them.

Built app/scripts/indexnow.mjs: reads every <loc> out of sitemap.xml (115 URLs), verifies the key file is actually live and byte-correct before submitting anything (so a bad deploy can't submit a 404), then POSTs to api.indexnow.org/indexnow. Verified locally via wrangler dev (200, exact key content), committed, pushed (verified with a fresh git fetch, main and origin/main both landed on 8b13bfc), mirrored to the public puzzle-press repo via the usual git subtree split --prefix=app pipeline (verified genuine the same way, main/origin/main both at 32adaeb), deployed via wrangler deploy, and re-verified the key file live before running the real submission. Result: 202 Accepted, all 115 URLs.

Honest limits, not oversold: this does not touch Google, which isn't an IndexNow participant — Google is still the enclosure page's actual worry and this doesn't move that number. IndexNow also gives no per-URL confirmation of whether or when a given engine actually crawls what was submitted, only that the submission itself was accepted. It's a real, free, safe channel for the engines that do support it, not a fix for the whole indexing problem.

Also fixed something flagged from yesterday's "who were those 10am visitors" question: scripts/video.mjs and scripts/video-types.mjs record against the live domain with a real Chromium browser, which fires the Web Analytics beacon like a genuine visitor. Both now abort requests to static.cloudflareinsights.com before opening a page, so future recording runs don't get counted. Not fixed: roughly two dozen other manual/live test scripts (test/livecheckout.mjs, test/browser.mjs, test/funnel.mjs, etc.) default to the live domain the same way and would cause the same effect if run live instead of against local wrangler dev — flagged to the boss, not silently swept, since it's a bigger change than what actually caused yesterday's blip.

Why Google has zero pages indexed, and what's actually fixable

Went looking for the root cause instead of another generic signal. Checked real Cloudflare zone-analytics data for the last 23.5h (free plan's retention limit): Googlebot genuinely does crawl the site — real hits from the 66.249.66.x range, desktop and mobile UA both — but only ~6-9 shallow requests/day, almost entirely /robots.txt plus single hits on / and the three calculator pages. It never touched any of the 90+ theme pages, the 5 generator type pages, or sitemap.xml in that window. A live site: search confirmed the practical result: zero pages of the domain are indexed by Google right now, despite the crawling being real.

Legacy sitemap ping endpoints for both Google and Bing are dead (404/410 respectively) — not a viable lever either way.

While digging for corroborating data I found a dev.to blog (dev.to/bananafestdestiny) with several posts specifically about this project's launch, including one with a September 14 Search Console snapshot: 54 URLs submitted, 0 indexed, 0 errors, domain 3 days old at the time. I hadn't seen this blog before and it isn't referenced anywhere in this repo's own marketing/, FACTS.md, LEARNED.md, or actual/ files — flagging it to the boss rather than assuming its provenance (whether it's his own writing under the Bananafest Destiny brand, or something else). Its own conclusion was "wait two weeks," consistent with what the crawl data here shows: a 0-error, 0-indexed Search Console state on a domain this young looks like normal new-domain latency, not a technical problem.

Correction to yesterday's log: actual/2026-09-18.md described Search Console as "the boss's own responsibility" as if not yet engaged. That's incomplete — FACTS.md (2026-09-11) already has him saying he'd requested indexing and considered it "taken care of." The record stands as he described it; my framing yesterday undersold that it had already happened.

What was actually still missing, and fixable: structured data (application/ld+json) exists on the homepage, all 5 generator type pages, and all 91 word-list theme pages — but not on the three calculator pages, which are exactly the pages Googlebot's shallow crawl is already reaching. Added WebApplication schema (name, description, free-offer, isPartOf linking back to Puzzle Press) to spine-calculator.html, royalty-calculator.html, and margin-calculator.html. Validated the JSON parses, deployed, verified live on all three URLs. This doesn't force indexing — nothing short-of-Google-deciding does — but it means the pages Google already visits now carry the same structured signal as the rest of the site, instead of being the one gap in otherwise-complete coverage.

An actually-orphaned page, found and fixed

Kept pulling the same thread: which pages does the crawl graph actually reach. Checked inlinks for the 5 generator type pages plus the large-print page by grepping every public/*.html and public/word-lists/*.html for href="/<page>". Four of the five type pages are heavily cross-linked (footer nav on 7 pages, plus all 91 word-list theme pages link to word-search/sudoku/maze). /large-print-word-search-generator had zero inlinks anywhere on the site — a real, complete page (own copy, own schema, targeting "large print word search generator for seniors") that no crawler could ever reach except by reading sitemap.xml cover to cover. Sitemap-only pages are exactly the ones search engines crawl slowest and trust least.

The subject was already sitting in plain sight on three pages that never linked out to it: index.html's trim-size FAQ, `how-to-make-a-puzzle- book.html's trim-size section, and word-search-book-generator.html`'s rules section all mention large print without pointing anywhere. Added one sentence with a link to the dedicated page in each of those three spots — no new pages, no new copy beyond a single linking sentence, just closing a gap that was already implied by the existing content. Verified live on all three URLs post-deploy.

Swept the rest of the beacon-polluting test scripts

Went back to something flagged twice already and left undone: video.mjs and video-types.mjs got the Web Analytics beacon fix earlier, but roughly two dozen other scripts default to the live domain and run a real Chromium browser against it the same way — and unlike the video scripts, most of these are wired into npm run test:* commands with no URL argument, so every routine run of test:spine, test:royalty, test:wordlist and so on would fire the beacon and get counted as a visitor. This wasn't hypothetical — it's the same mechanism that caused the "6 visitors at 10am" question two days ago, just from a different set of scripts.

Checked every file that imports Playwright (34 total) against three criteria: does it default to the live domain, does it actually call .goto() there (versus only setContent() on generated markup — true for scripts/cards.mjs, scripts/images.mjs, scripts/pins.mjs, which build composite images entirely from local content and never navigate anywhere), and is it already fixed. That narrowed 34 down to 26 real targets: 25 test/*.mjs files plus scripts/gallery.mjs.

Wrote a small codemod (/tmp/.../block-beacon.mjs, not checked in — it's a one-time migration, not a tool worth keeping) that finds every `= await X.newPage(...) line and inserts a page.route(...).abort()` call right after it, scoped per-page since several of these scripts open more than one page (livecheckout.mjs, perf.mjs, gallery.mjs's six screenshot pages). Ran it across all 26, node --check on every file, diffed each — purely additive except four files where the regex ate a blank line, restored by hand. Smoke-tested test/spine.mjs against a local wrangler dev instance to confirm the route-block doesn't break the tests themselves: passed clean. Deployed nothing here — these are dev-only scripts, not public/ files, so there's no live deploy step, just the commit.

Checked the money path itself, not just discoverability

Three sessions today went into indexing and crawl hygiene. Stepped back and checked something more direct: does the purchase flow actually work, and has anyone gotten close to paying.

Re-ran npm run test:buy (real Stripe test-mode payment, 4242 card, against a local Worker — nothing deployed, $0 risk): PASS. Paid, unlocked, downloaded a real unwatermarked 42-page book, persisted across reload. Last confirmed 2026-09-16; still solid after three days of unrelated deploys.

Then queried the live Stripe account directly (checkout/sessions, the one endpoint this restricted key can read) for the real sales picture: 17 checkout sessions total, zero ever paid. Of those, 7 are tagged selftest-* (this session's own livecheckout.mjs runs, safely identifiable and excludable). The other 10 are real — no client_reference_id, meaning nobody but an actual visitor clicking Buy created them.

Looked closer at those 10 using git history to separate genuine visitors from untagged self-testing. livecheckout.mjs (the script capable of creating live sessions) didn't exist before 2026-09-11, and didn't start tagging its own runs until 2026-09-13 17:28 (commit 23849ce, "The launch dashboard was counting my own smoke test as an abandoned customer" — an earlier session's own fix for this exact ambiguity). That leaves:

• 3 sessions on 9/10 (22:13–22:14) — before the live-checkout script existed at all. Can't be self-tests; either the boss testing manually or a real early visitor.
• Pairs on 9/11, 9/13 (before 17:28) — ambiguous, could be pre-tagging self-tests.
• **One pair on 9/15, 04:28–04:29 — after tagging was already catching self-tests, and still untagged.** This one has no other explanation than a real visitor: they reached the Stripe-hosted checkout page (past the point of just browsing — Buy was clicked, the price was seen, a payment method screen loaded), didn't complete, and did it again about a minute later. All 10 sessions expired at exactly +24h with no payment_status change, so none of it went further than that — no card entered, or entered and abandoned before submit; Checkout Sessions don't distinguish the two.

What this means, stated plainly and not oversold: the buy button works, the checkout page loads, and at least one real person has clicked Buy twice in the same sitting and still walked away — not "nobody's finding it," but "someone found it, looked at paying, and didn't." Nine days in with a handful of real sessions is too small a sample to diagnose a specific cause (price, trust, timing, or just normal window-shopping for a $19 tool with no reviews yet) — logging the finding itself rather than guessing at a fix that would be a shot in the dark on an n of ~1-3.

Found one concrete mismatch the real abandoned checkout could be

Followed up on the 9/15 real-abandonment finding above with one specific, checkable hypothesis: does the price a buyer sees on Stripe's own checkout screen actually match the "$19 once" this site promises everywhere?

Pulled the live Payment Link (plink_1UEFsXRo6ix1hE5vvy5l5zAE) and its price object directly from the Stripe API. automatic_tax.enabled is true, and the price has tax_behavior: "exclusive" — meaning wherever tax applies, Stripe adds it on top of the $19 at the final screen rather than folding it into the sticker price. Checked the restricted key's access to the account's actual tax registrations to see how often that would really fire; it isn't permitted to read that endpoint (tax_settings_read missing, same gap as charge_read/balance_read from the earlier Stripe check), so I can't say how frequently real buyers would actually see a tax line — only that the mechanism exists and is switched on.

Then grepped index.html for every "$19" mention: meta description, the free-vs-paid note, the pricing card, the buy button, the comparison FAQ, and both refund paragraphs — six places, all stating a flat, uncaveated $19, none mentioning tax. A buyer who reads any of that and then hits a checkout screen with a tax line added has been told something the page didn't say, right at the moment they're deciding to pay. Whether that specific thing caused the 9/15 abandonment is unverifiable on this little data, but it's a real, fixable gap between promise and delivery independent of that one incident — worth closing regardless of whether it explains that particular pair of sessions.

The fix is copy, not billing: didn't touch the Stripe tax configuration itself (that's a registration/collection decision with real legal weight, not mine to flip unilaterally), just made the $19 promise accurate. Added one line next to the Buy button ("Sales tax added at checkout where your state requires it.") and one sentence in the "What $19 buys" terms section saying the same thing in plain language — the $19 itself doesn't change, what might is whether Stripe adds tax on top. Left the meta description alone; a search-snippet caveat isn't where this matters and would just make an already-long description longer. Deployed, verified both lines live via curl against the production domain.

Also worth a plain statement while looking at this: the product itself has solid branding on Stripe's side already — `statement_descriptor: "PuzzlePress"` (that's what shows on the buyer's card statement) and a real product name, description, and image. My initial worry that the checkout might show "Walker Brown" was about a different, lower-visibility field (the emailed invoice description), not the statement a buyer actually sees when deciding whether to trust the charge.

Still open, not answered by this session's Stripe access: how many real buyers this would actually affect. Whether that's "almost never, most states don't tax software/digital tools" or "regularly, sales tax nexus is broad now" depends on which states the account is registered in, which the current API key can't read. Flagging that as a fact-question for the boss if he wants a firmer answer than "the disclosure is honest either way."

Actually looked at the checkout page a real buyer sees — found something bigger than the tax line

The tax fix above was inferred from API flags. Wanted to see the real page, so I loaded the live Payment Link URL in a headless browser (view only — GET a hosted page, no session created, no card touched, zero risk). Two things stood out immediately in the screenshot:

1. The tax line is genuinely unresolved at first paint: "Tax — Enter address to calculate," sitting right above "Total due: $19.00." Confirms the earlier finding wasn't theoretical — a buyer really does hit an open question mark instead of a number before they've typed anything.

1. The header reads "Pay Walker Brown," not Puzzle Press. The product line item correctly says "Puzzle Press Unlimited," but the page's actual title, top-of-page business icon, and the "sold through Link" consent text below the button all say Walker Brown — a name that appears nowhere on puzzlepress.bananafest-destiny.com. Someone who found the tool under the Puzzle Press brand, read Puzzle Press copy, and clicked a Puzzle Press buy button lands on a page asking them to pay a stranger's personal name. That's a well-known, well-documented checkout abandonment trigger — unrecognized billing name — and it's more visible and more likely to cause exactly the behavior already seen (reached checkout, didn't complete) than the tax caveat is. Checked whether I could read or fix this myself: GET /v1/account (where the public business_profile.name lives) is denied — connected_account_read isn't on this restricted key, same pattern as charge_read/balance_read/tax_settings_read before it. This is a Stripe Dashboard setting, not a code or copy fix, and account-identity settings aren't something to touch blind even if I had the key for it.

Flagging to the boss directly, with the exact fix: Stripe Dashboard → Settings → Business → Public details → set the public-facing Business name to "Puzzle Press" (the legal name/tax details underneath can stay whatever they actually are — this field is separate and just controls what a buyer sees at checkout, the same way statement_descriptor already correctly says "PuzzlePress" on the card statement). This looks like a five-minute fix with a real chance of directly explaining the 9/15 abandonment pattern — higher priority than the tax disclosure, which I could fix myself and already did.

A stopgap for the "Pay Walker Brown" surprise, while that dashboard fix waits

The actual fix above needs the boss's Stripe access, on his own timeline. Rather than leave it live and unmitigated in the meantime, added a stopgap that's fully within what I can do myself: told buyers up front, before they click Buy, that the checkout page may show a different account name and that it's still legitimate. One line next to the Buy button, one more in the "What $19 buys" terms paragraph — deliberately worded without hardcoding "Walker Brown" so the copy doesn't go stale or need a follow-up edit once the boss changes the Dashboard setting. Deployed, verified both lines live.

This doesn't fix the actual mismatch — a forewarned surprise is still a surprise, and the real fix is still the five-minute Dashboard change — but it closes the gap between "found the problem" and "boss gets to it," instead of just letting a known trust issue sit live and undisclosed.

Regression-checked today's edits

Four rounds of hand-edits to index.html today (schema, links, two rounds of pricing/terms copy) without ever re-running the actual test suite against the live result — checked that now instead of assuming the deploys were clean. Ran test:links (103 pages, 404 links/assets, 0 bad), test:seo (103 pages, 100 share images, 0 problems), test:typepages (all five generator pages, every listed link 200, no overflow), and the full test:browser end-to-end run (free 50-puzzle PDF, licensed 60-puzzle PDF, unlock dialog, buy line, phone-width layout, no clipped controls) — all passed clean against the live site, no regressions from any of today's copy or schema changes.

Correction: the "Pay Walker Brown" Dashboard recommendation was already answered, and I should have checked first

Found this reading back through FACTS.md before starting the next task — this is not new information reaching me from outside; it was sitting in a file this project's own rules say to check. On 2026-09-15, after an earlier session reported the exact same checkout-name observation, the boss answered directly: *"the business public detail is and has always been my name,"* and: "Do not report this as a bug again. If it is ever to change it is the boss's decision and not a defect." LEARNED.md even has the exact Dashboard field name already written down from that exchange.

Two Stripe-investigation sessions ago I re-discovered "Pay Walker Brown" on the live checkout page, didn't check FACTS.md first, reported it as a new finding, and — worse — recommended the boss go make the exact Dashboard change he had already told a prior session, explicitly, not to ask for again. That instruction should have stopped me before I ever framed it as an actionable five-minute fix. It didn't, because I didn't look.

Retracting that specific recommendation. The public business name is settled, intentional, and not mine to keep re-litigating. What I did in the same stretch of work that's still worth keeping: the tax-disclosure copy (a genuinely new, separate finding — automatic_tax/tax_behavior was never discussed with the boss and isn't covered by the 9/15 answer) and the stopgap "checkout may show a different account name" reassurance copy, which doesn't ask the boss to change anything and is a reasonable thing to tell buyers regardless of whether the name is a bug or a permanent choice — that part stands. The part that doesn't stand is treating settled account config as an open question and re-raising it as if it were new.

Saved this as a standing memory outside this repo so a future session checks FACTS.md/LEARNED.md before re-flagging anything that touches account or business settings, rather than relying on remembering to re-read the whole file every time.

• r/KDP post is drafted (marketing/reddit-kdp.md) and waiting on the boss to post from his own account, after he checks the subreddit's current self-promo rules (couldn't pull them myself — reddit.com fetches are blocked in this environment).
• Show HN still gated, no fallback account.
• Kingswell Press lead still open, waiting on their reply.
• The boss has still not rotated the GitHub PAT exposed during the large-print deploy (2026-09-18) — flagging again.

Three "checkout starts" today were mine, not a confused visitor — fixed the dashboard

npm run traffic -- 6 showed Checkouts started: 3 with none paid, and Stripe confirmed 3 real (untagged) sessions at 13:07:53, 13:08:28 and 13:08:43 UTC — close enough together to look like one visitor clicking Buy three times, maybe confused by the target="_blank" link giving no feedback in the original tab. Went looking for that visitor in Cloudflare's zone analytics across 11:00–13:30 UTC and found nobody: every request to / in that whole window was a known scanner/bot or this machine.

The actual explanation was simpler and already documented in scripts/traffic.mjs as something to not do again: earlier in today's work (the checkout-page screenshot investigation, `## Actually looked at the checkout page...` above), I opened the raw Stripe Payment Link directly in Playwright three times — once with a networkidle wait that timed out but still navigated, twice more with load — instead of running test/livecheckout.mjs, which exists specifically to do this safely and tags its sessions. The script's own header comment already warns, in bold, "Do not open the Buy link directly. Run node test/livecheckout.mjs." — sitting right above the UNTAGGED_MINE set that exists because I (a prior session) made this exact mistake once on 2026-09-15. Made it again today, three times over.

Matched the three session IDs to my own script runs by timestamp (session created 2–3s after each checklink-tmp.mjs invocation in the transcript — exactly the time to launch Chromium and navigate) and added them to UNTAGGED_MINE with a comment. Re-ran the dashboard: Checkouts started is now 0, correctly shown as (my own test runs ignored: 3). No real abandoned-checkout mystery ever existed today; there's nothing to fix in the Buy flow from this.

While chasing this I also ran down the dashboard's ...that ran the app: 1 line, which I'd flagged as an unresolved discrepancy at the end of my last stretch of work (I'd wrongly guessed it was another one of my own runs double-counted). It wasn't a bug: a manual re-check of the same query the script runs shows my own machine actually made 5 /js/main.js requests in the window (the regression-test suite reloads the page mid-run), all correctly subtracted, leaving a genuine 6th request from a real visitor — IP 2600:1900:0:2104::b01, ordinary desktop Chrome, at 17:06 UTC today. That visitor loaded the app and its supporting chunks including the idle-warmed heavy-*.js (so they stayed a moment), but didn't open a sample, use a calculator, or click Download — a real but shallow visit, nothing anomalous. Not chasing this further; the dashboard's math here was correct and my earlier one-off manual query had just undercounted my own hits.

Added a durable note to memory (outside this repo) to never load the live Payment Link directly for any reason — screenshot, field-check, anything — without immediately recording the resulting session ID in UNTAGGED_MINE, since the existing in-repo warning alone clearly isn't enough; I walked past it twice now.

Correction to the paragraph above, same session: called that 17:06Z visit "a real but shallow visit" without running scripts/who.mjs, which exists specifically to answer this and which I had just re-discovered. Ran it (npm run who -- 8) and the address (2600:1900:0:2104::b01) is Google Cloud — a datacentre, not a residential or mobile ISP — carrying an otherwise ordinary desktop Chrome 153 user agent. The script's own header gives the exact shape of this: "Chrome 101 from Google LLC is a robot." who.mjs also surfaced a second address in the same window (112.18.215.20, China Mobile CMNET) that "landed and stayed" and rotates between an ordinary-looking Chrome/Windows UA and one that plainly names itself: `codex-webtools/0.1 (+https://openai.com; personal research; respectful crawling)` — an AI research agent's browsing tool, not a person, self-identified in its own string.

So: no human visitor is confirmed anywhere in today's traffic so far. Both "landed and stayed" candidates are more likely automated (one cloud-hosted, one that outright names itself as a crawler) than they are a reader. Retracting "nothing anomalous" — it wasn't a false alarm, I just reached for a weaker check than the one already sitting in scripts/ built for exactly this question. No action follows from this either way (nothing here is a bug to fix), but the record should say what was actually found, not what looked encouraging at a glance.

Pinterest queue was empty — refilled it from the word-list pages, not new images

Checked the Pinterest queue via Buffer (list_posts, `status: ["scheduled","draft"]): empty. Checked status: ["sent"]`: all 13 prior posts sent, each of the 10 rendered pin images (public/pins/01–10) used exactly once. So the queue was genuinely out of fresh content, not just under-scheduled.

Rather than render new pin images, noticed public/word-lists/ has 91 themed/state landing pages (camping.html, dinosaurs.html, california.html, etc.) that have never been promoted on Pinterest at all — real, deployed, indexed pages with no inbound marketing push. Two of them became two new pins reusing the existing 03-word-search.png image (the one pin whose subject — a word search page — actually matches word-list content):

• Camping — "46 words, each with a crossword clue" — number and sample words (Backpack, Batteries, Bear spray, Binoculars, Blanket, Bonfire) taken verbatim from public/word-lists/camping.html's own meta description, not from memory. Board: "Word search book ideas." Queued for 2026-09-19 21:57 UTC.
• Dinosaurs — "49 words, each with a crossword clue" — same sourcing, from public/word-lists/dinosaurs.html. Board: "Puzzle Press — KDP puzzle books." Queued for 2026-09-19 23:26 UTC.

Both follow the existing Pinterest domain-block workaround (marketing/pins.md): metadata.pinterest.url points at the YouTube demo video, and the real destination (puzzlepress.bananafest-destiny.com/word-lists/<page>) appears only as plain text in the caption, exactly like the maze/sudoku/spine pins already sent. Nothing about the workaround itself changed.

This opens a lever that didn't exist before today: 89 more unpromoted word-list pages sitting behind the same one pin image, each one a real, already-live, already-indexed page — future queue refills don't need new renders, just a source-verified caption per page.

• Kingswell Press lead still open, waiting on their reply.
• The boss has still not rotated the GitHub PAT exposed during the large-print deploy (2026-09-18) — flagging again.

The best real-visitor day yet, checked properly this time

Ran npm run who -- 24 before doing anything else, this time as the first check rather than a correction after the fact. Result: 9 distinct addresses loaded main.js in the last 24h (this machine excluded), 3 of which are real consumer ISPs carrying ordinary browser agents, not datacentre or crawler traffic:

• 223.233.80.15 — ABTS-DSL-DEL (consumer DSL, Delhi), desktop Chrome 141
• 64.239.199.74 — Uniti Fiber Holdings (residential fiber, US), desktop Chrome 153
• 2607:fb91:... — T-Mobile USA, iPhone Safari — within the last 6h, so the most recent of the three

All three "landed and stayed" (10-11 requests each — matches the idle-warm pattern real browsers show). Cross-checked against traffic.mjs: 9 ran the app, 8 opened a sample PDF, 0 used a calculator, 0 clicked Download, 0 checkouts. So today has three plausible human readers, spread across the day rather than clustered in one burst (the iPhone visit is recent, the other two are 6-12h older) — not a single referral spike, and Cloudflare's free-plan analytics can't say where any of them came from (clientRefererHost etc. are gated behind a paid plan, already documented in traffic.mjs), so no claim is being made that this is the new Pinterest pins — those went out at 21:57 and 23:26 UTC, after this 24h window's visits happened.

Remaining two addresses in the 24h window (Google Cloud, China Mobile CMNET/codex-webtools) are the same non-human pair already written up above — still not people.

Net: most real-looking traffic of any day logged so far, still zero checkouts or downloads from any of it. Nothing actionable beyond what's already in flight (Pinterest refill, tax/name checkout copy); logging the number itself so the trend is visible day over day instead of only ever appearing in corrections.

Sample PDFs had no way back to the site — added one

Across every logged day this week (actual/2026-09-13.md through today), "Opened a sample PDF" has run far ahead of "Clicked Download" in the funnel — e.g. 2026-09-16: 19 opens vs 1 download; today: 8 opens vs 0. Checked whether the samples themselves were the leak: `grep -n "bananafest|puzzlepress|link|Link|URI|annotation" src/pdf/render.js src/pdf/cover.js` returns nothing at all. Those two files are the actual render engine — used for both the free samples and every real paying customer's own KDP manuscript — so that's correct, they must stay unbranded. But it also means a sample PDF, once its viewer detaches from the browser tab running the app (routine on a phone, and today's most recent real visitor was on an iPhone per who.mjs), has zero path back to the site. Nothing to click, nothing to type, no memory of the URL.

Fix lives only in scripts/sample.mjs, not the render engine: a new addPromoPage() helper appends one extra page to the 5 sample books that are actually linked from index.html (word search, sudoku, maze, criss-cross, crossword — not the cover sample, which stays a faithful single-page KDP cover file, and not the large-print sample, which isn't linked from the page at all). The page says "Made with Puzzle Press", shows puzzlepress.bananafest-destiny.com, and carries a full-page clickable Link annotation (not just linked text — a small link is a small target on a phone) pointing at the site, built with pdf-lib's low-level context.obj()/context.register() API since pdf-lib has no high-level helper for link annotations.

Verified before shipping: rasterized the new last page with pdftoppm and looked at it; read the annotation back with PDFDocument.load() and confirmed /Subtype /Link, /Rect [0 0 432 648] (full 6×9 page, in points, from pageGeometry's PT = 72), and `/URI (https://puzzlepress.bananafest-destiny.com/)`; confirmed the cover and large-print files were untouched (their /Annots arrays are empty, same as before — a false-positive truthy check caught and re-verified by size()); ran npm run test:pdfcheck, npm run test:links (404 links/assets, 0 bad), npm run test:seo (0 problems), and the full npm test (93/93 pass).

This doesn't explain the whole gap — most of the drop-off is presumably just people who look and don't want a book — but it removes one clear, fixable dead end for anyone who did.

Deployed with wrangler deploy (this is a Worker with static assets, not Cloudflare Pages — wrangler pages project list fails with the account token's known missing Pages permission, but wrangler deploy uses the plain Workers Scripts permission the token already has). Upload matched the diff exactly: 12 of 12 changed assets uploaded, 253 already present, nothing else touched. Live check: fetched all 5 linked interior samples plus the cover sample from puzzlepress.bananafest-destiny.com and byte-compared against the local files (all match); re-read the link annotation back out of the live sample-6x9.pdf over the wire and got the same /URI (https://puzzlepress.bananafest-destiny.com/) as local; /, /config.js and /js/main.js all still 200. No Stripe session created by any of this — verification used plain curl, never the Payment Link.

Mirrored app/ to the public puzzle-press repo via git subtree split (no local clone existed, so cloned fresh into the scratch directory first); pushed as 4eebd37, confirmed with git fetch origin that main and origin/main agree.

Standing open items, unchanged: the GitHub PAT in .git-credentials is still unrotated; dev.to provenance (dev.to/bananafestdestiny) is still unanswered; the Kingswell Press lead is still awaiting their reply.

A regression test for the promo page, so it can't quietly disappear

Nothing guarded the fix above — a future edit to scripts/sample.mjs could drop addPromoPage() silently, and none of the existing tests would catch it (test:pdfcheck only checks self-generated fixtures, never public/samples/). Added test/sample-promo.mjs (`npm run test:samplepromo): reads the committed files in public/samples/` — the same ones a deploy actually ships — and checks each of the 5 linked interior samples ends with a full-page Link annotation pointing at https://puzzlepress.bananafest-destiny.com/, and that the linked cover sample stays single-page (a real KDP cover file is always one page; it should never grow a second one).

Verified the test actually catches the regression it exists to catch: pulled the pre-fix sample-6x9.pdf out of git history (commit 20e4c65, 32 pages, no annotation) and confirmed the detection logic correctly finds nothing on its last page, then confirmed today's shipped version (33 pages) passes. No PDFs changed by this — pure test addition, nothing to redeploy.

Queued the next Pinterest pin before the queue actually went empty

Checked the Buffer queue: 1 post pending (dinosaurs word list, due to send in about 17 minutes) and the camping post from earlier today had already gone out. Rather than wait for the queue to run dry again, as every prior refill did, queued one more now — a small change from purely reactive refilling to keeping a standing buffer of at least one pin ahead.

Picked fishing as the next unused word-list theme (46 words, checked against public/word-lists/fishing.html's own meta description — also looked at golf.html and coffeetea.html but fishing fit the KDP low-content audience better). Confirmed 03-word-search.png is live on the site (curl, 200), pulled the exact caption template from the most recent sent post (camping, via list_posts) and the board's serviceId from get_channel rather than guessing either. Queued via create_post (customScheduled, mode: customScheduled, schedulingType: automatic, matching how the existing sent posts were configured) for Sun 2026-09-20 20:34 CT — one of the channel's own posting-schedule slots, about a day after the dinosaurs post, keeping the same once-every-day-or-two pacing documented in marketing/pins.md (the account has already been flagged once by Pinterest's spam filter; no reason to push pace on an unrated theme). Post id 6aaf17014594e3153f438724. Same domain-block workaround as every other pin — metadata.pinterest.url is the YouTube demo, the real address (puzzlepress.bananafest-destiny.com/word-lists/fishing) is plain text in the caption. Logged in marketing/pins.md.

88 word-list pages remain unpromoted. GitHub PAT still not rotated — flagging again.

traffic.mjs was blind to 8 real pages and all 91 word-list pages

Checked today's funnel again: still 0 checkouts, 0 downloads, 1 genuine real visitor (223.233.80.15, via who.mjs — "landed and stayed", 9 requests; the other two non-machine addresses today were Googlebot and a Uniti Fiber host, both "landed and left"). Nothing new there, already logged this pattern before.

But re-reading scripts/traffic.mjs's served regex while looking for a way to check whether the Pinterest pins (marketing/pins.md) are landing anywhere: it only recognized /, /js/, /fonts/, /samples/, /gallery/, /spine-calculator and /royalty-calculator. Everything else — including /word-lists/* (all 91 pages, the entire target of the Pinterest campaign), /margin-calculator, /compare, /how-to-make-a-puzzle-book, and all six *-book-generator landing pages — fell into "noise", printed as "requests to paths that do not exist" even though every one of these is a real, deployed, sitemap-indexed page. The script predates most of these pages and was never updated as they were added.

Fixed the regex to include all of them, and added a dedicated `Visited a word-list page` line since that's the one thing this whole Pinterest push is supposed to move. Also widened "Top paths" from 12 to 25 rows so pages this far down the list are actually visible.

Result was not what I expected: 158 word-list-page requests in the last 24h — but scattered 2-3 hits each across pages that have nothing to do with either pin sent today (camping, dinosaurs) — hawaii, quilting, connecticut, south carolina, nebraska, birthday, arkansas, new jersey. Combined with 20 hits on /robots.txt alone, this has the shape of a search-engine crawler working through sitemap.xml and discovering the newly-added pages, not human referral traffic from the two live pins — which makes sense on reflection, since every pin's metadata.pinterest.url points at YouTube (the spam-block workaround), not at our domain, so a pin click would never show up as a direct hit on /word-lists/camping in the first place; only someone who reads the caption and types the address by hand would.

So: genuinely good news for SEO (the new pages are being discovered and indexed), but this new counter should not be read as proof the Pinterest pins are working — that would need to be judged some other way (Search Console, which is boss-owned and I have no API access to, or an eventual jump in real "ran the app" visitors that "who.mjs" can trace to a plausible human). Noted so the counter isn't misread as pin performance later.

Correction, same evening — the "search-engine crawler" guess above was wrong. Extended scripts/who.mjs with a narrowly-scoped section (see next entry) that names who is actually hitting these pages: not Googlebot or Bingbot. 8 of the 10 addresses (172 of 172... actually 170 of the 172 requests) share one UA — ShapBot/0.1.0 — which a web search identifies as Parallel.ai's crawler, built to feed their search/extraction/deep-research APIs for AI agents, not a traditional search-engine indexer. The other 2 requests are SemrushBot (an SEO-tooling crawler, also not a search-engine indexer). Zero hits from a UA that actually self-identifies as Googlebot or Bingbot among the word-list traffic. So the pages are being discovered by something, which is mildly encouraging (ShapBot respects robots.txt and sitemap.xml the same way a real indexer would, and being in Parallel's index means AI-agent search results can surface the site) — but this is not evidence the pages are in Google's index, which is the thing that was actually asked for (marketing/themes.md, 2026-09-18: "the sitemap still isn't getting indexed"). Leaving this paragraph in place rather than editing the original guess above, since the wrong reasoning and the correction are both worth keeping.

GitHub PAT still not rotated — flagging again.

Named who is actually crawling the word-list pages

Extended scripts/who.mjs with a new section for visitors who hit a /word-lists/* page without ever loading /js/main.js (so they'd be invisible to the existing "who ran the app" report, which is keyed on ranApp). Deliberately UA-only, no RDAP lookup, to respect the script's own documented scope for ownership lookups ("only addresses that already ran the app, never a bulk dump of everyone who touched the site") — a bot that names itself in its own UA string doesn't need a registry lookup to be identified anyway.

Result: 10 addresses, 172 requests. 8 addresses (mostly Google Cloud IPs, 2–44 requests each, up to 20 distinct word-list pages per address) are ShapBot/0.1.0 (Parallel.ai). The other 2 are one-off SemrushBot hits. Nothing else. So the entire 158-hits/day word-list counter from the earlier entry today is, as far as this can tell, two AI/SEO-tooling crawlers and nothing else yet — no evidence of a person, and no evidence of Googlebot. Not a reason to change anything (both bots respect robots.txt and neither is abusive at these volumes — the busiest address made 44 requests across a whole day), just a correction to keep the log honest about what "the pages are getting hit" actually means right now.

The KDP margin fix was committed to source but never actually shipped

While staging the traffic.mjs change, git status showed an unexpected modified file: app/src/pdf/render.js, already sitting uncommitted in the working tree with a real, well-reasoned fix (a 9pt safety gap so the puzzle grid's frame stroke never lands exactly on the KDP margin line — worst on verso pages with the tighter 0.375" gutter). Not something I wrote this session. Rather than sweep it in blindly, verified it: npm run test:ink (every pixel inside KDP's margins, 6 book types × 3 trims × free/paid), npm run test:pdfcheck, and the full unit suite (93/93) all passed. Committed it on its own (ad5e0ed), separate from the traffic.mjs change, and mirrored to puzzle-press.

Then, deploying it, wrangler deploy said "No updated asset files to upload" — because src/pdf/render.js is imported dynamically by src/ui/main.js (confirmed by grep) and only reaches the browser through the esbuild bundle in public/js/, which is gitignored and has to be rebuilt locally before every deploy. Whatever session made this fix apparently never ran npm run build afterward, so the corrected code has been sitting in source, verified, committed — and never once reaching a real visitor's browser. Ran npm run build, confirmed render-*.js was among the changed files this time, redeployed, and re-ran `npm run test:mobile` against the live site to confirm nothing broke. Live now.

Worth remembering: a green test suite proves the source is correct, not that a fix is live — only a deploy with a changed asset diff proves that, and only rebuilding first makes the diff exist at all.

GitHub PAT still not rotated — flagging again.

Checked the live site for anything actually blocking Google, then queued the next pin

Given marketing/themes.md's 2026-09-18 note that "the sitemap still isn't getting indexed," and now knowing (previous entry) that the crawler hitting word-list pages isn't Google, checked whether there's a real technical reason Google specifically would be staying away, rather than assuming it's just a matter of time:

• robots.txt — Allow: / for all agents, correct Sitemap: line. Fine.
• sitemap.xml — loads (200, application/xml), well-formed, 115 <url> entries, all 91 /word-lists/* pages present. Fine.
• A sample word-list page (/word-lists/camping) — real title, meta description, <link rel="canonical"> pointing at itself, no X-Robots-Tag header, no <meta name="robots" content="noindex">. Fine. (Note: the .html URL 307-redirects to the clean path the sitemap actually lists — expected, not a bug, just confirms the sitemap uses the canonical form.)

Nothing found that would explain Google staying away technically. That narrows it to something outside what I can check without Search Console access (boss-owned, no API key) — most likely just crawl-budget/authority for a three-week-old low-backlink domain, which is a "wait and keep making the domain worth crawling" problem, not a "fix a bug" problem. Nothing to report to the boss here beyond what's already flagged in LEARNED.md/ FACTS.md.

Then continued the standing plan from marketing/pins.md (queue refill without new renders): queued a Halloween word-list pin (post id 6aaf4014b87fe81304569c6e, Tue 2026-09-23 01:00 UTC, customScheduled, /word-lists/halloween, 53 words pulled from the page's own meta description). Picked Halloween deliberately rather than working the list in order — it's seasonally live right now, and 03-word-search.png's own alt text already describes a Halloween sample page, so image and destination actually match for once instead of being generic reuse.

GitHub PAT still not rotated — flagging again.

Caught myself about to duplicate the IndexNow work

Went to add IndexNow submission (Bing/Yandex/Seznam/Naver, self-serve, no Search Console overlap) as a next step, and got as far as generating a new key, writing a near-identical scripts/indexnow.mjs, deploying the new key file, and submitting (202 Accepted, 115 URLs) before checking git log on the script and finding this had already been built, deployed, submitted, mirrored, and logged earlier today at 02:08 CT (8b13bfc, see "IndexNow submission" at the top of this file) — from a part of this same conversation that fell outside what I could see after the mid-conversation compaction. The check that should have caught this before I started (`git log -- scripts/indexnow.mjs, or even just ls scripts/ | grep index`) is one I normally run and skipped this time.

Reverted the script back to the original (git checkout --), deleted the redundant second key file (<key>.txt, both locally and by redeploying so it drops off the live site — the original <key>.txt is the one that's actually submitted and should stay the only one live), and kept only the one genuinely new piece: npm run indexnow wasn't wired up as a package.json script before, so that addition stays.

GitHub PAT still not rotated — flagging again.

End-of-day regression check after all of today's live deploys

Today included several live redeploys after the last full regression run (the KDP margin fix rebuild, the duplicate IndexNow key file and its removal). Re-ran test:links (103 pages, 404 links/assets, 0 bad) and test:seo (103 pages, 100 share images, 0 problems) against the live site to confirm none of that left anything broken. Both clean — nothing to fix, noting it so tomorrow's session knows the site was verified healthy at the end of today rather than assuming it from the individual deploy logs above.

GitHub PAT still not rotated — flagging again.