The Numbers Said It Worked. Only a Click Would Prove It.

Sep 5, 2026 · 3 min read

Our marketing features page had 63 rows. Every one opened its detail popup through a plain onclick. None of them had an href.

<tr onclick="featurePopUpShow('/marketing/popups/FeatureInfo.asp?section=Main&category=Features&pagename=Mobile%20Home%20Page', 650)" class="featureRow">

Sixty-one distinct feature detail pages sat behind those rows, and a crawler had no link to follow to any of them.

What the fix actually was

Wrap the feature name in a real anchor pointing at the same popup URL, keep the row’s own click behavior untouched, and make the new anchor’s own click handler cancel the default navigation and stop the click from also reaching the row underneath it, so a person sees no difference and a crawler gets a real link to walk. The core of the change on the first pass, with names simplified:

this.TagAdd("a", cell,
  {href: popupHref, cssclass: "featureNameLink",
   onclick: "event.preventDefault();event.stopPropagation();" + onclickParam + ";return false;"},
  featureName);

Both the prevented default and the stopped propagation were there from the first edit. There was no earlier version missing one of them.

What the session actually said it hadn’t done

The session that wrote this had no browser automation available to it, Bash and file tools only. So it verified the only way it could: curl requests, before and after, counting exactly what changed. Before, against production with a crawler’s user agent: zero heading tags anywhere on the page, zero real links to the popup content, 63 onclick-only rows, 327 visible words. After, against the working branch on a local dev host: one <h1>, seven <h2> group headers, 63 real href attributes pointing at the 61 individually reachable detail pages, 390 visible words.

Every one of those numbers was a real, checked fact. None of them said anything about whether a person clicking a feature name would still see the popup and nothing else. That question needs a browser actually clicking something, and this session didn’t have one. It said exactly that in its own report, named the one test still missing, a live click-test on the branch before shipping, and stopped there instead of rounding “the markup is right” up to “this works.”

What the second session actually checked

A separate session picked up that exact recommendation and ran it: a real browser, against the local dev copy, not production. Eight specific checks, each against an observed value, not an impression:

Click the feature name anchor. Record the URL before and after. It must not change.
Click elsewhere in the same row, off the anchor. Same popup, same content.
Repeat both on a row in a different feature group, to rule out a per-group difference.
Confirm the popup closes normally afterward.
Read the console for the entire sequence.
Screenshot the feature name: plain text, not a visible link.
Screenshot the seven group headers for layout defects now that they render as real headings.
Load a second page that shares the same underlying component and confirm it still renders correctly, with exactly one heading of its own.

The URL never changed across any click. The console carried nothing but a pre-existing, unrelated deprecation notice that fired identically before the change. The feature name rendered as plain gray text, no underline, matching its surroundings exactly. All seven headers rendered clean. The second page, sharing the same code, still worked. Only after all eight came back with real observed values, not assumptions, did the change move toward shipping.

The step neither session skipped

Before any of it went out, the styling reference still pointed at the uncompiled source file, since this codebase compiles CSS at release time only. That had to run through the repo’s own compile step, get repointed at a dated, minified bundle, and get checked again with the exact same curl counts as before, one heading, seven group headers, sixty-three real links, because a compile step changes bytes and the only honest way to know it didn’t change behavior is to check again, not to assume a routine step is a no-op.

The fix shipped the same day and was confirmed live with the same numbers it shipped with in review. What made it trustworthy wasn’t that every check passed. It’s that the session without a browser told the truth about what it couldn’t check, instead of letting a clean set of curl numbers stand in for a claim it never tested.

AI Skills

Use this lesson with the AI assistant you already use

A fix that adds real crawlable links to a page can be fully confirmed by curl (the right tag counts, the right href count, the right word count) while the one thing the fix actually promises, that a real visitor's click experience does not change, remains completely unverified.

Paste the prompt, share only the context needed to answer it, and treat the result as a draft for your review. Do not include confidential information or let an AI assistant make changes without your approval.

Optional: for a visual report and saved memory, run /dxdev first. Don’t have it? Get it at dxdev.com/skills/dxdev. The prompt works without it.

dxdev LESSON · paste into your AI coding agent
LESSON: A Structural Check and a Behavioral Check Answer Different Questions, and Neither One Substitutes for the Other
SOURCE: dxdev.com/blog/2026-09-05_the-numbers-said-it-worked-only-a-click-would-prove-it
WHAT HAPPENED: A marketing page had no heading tags and dozens of feature rows that opened detail content only through a JavaScript popup handler with no underlying link, making every one of those detail pages unreachable by a crawler. The fix added real anchors around each feature name, pointing at the same popup URL, with the anchor's own click handler set to prevent the default navigation and stop the click from also triggering the row's separate handler, so a person's experience was meant to stay identical while a crawler could now follow the link. The session that wrote the fix had no browser automation available, so it verified the change the only way it could: curl requests confirming the exact before-and-after counts of heading tags, real hrefs, and visible words. It explicitly reported what it had NOT done, click-testing the popup behavior in an actual browser, and recommended that step before shipping rather than asserting the fix worked. A second, separate session then did exactly that: opened a real browser against a local, non-production copy of the page and ran eight specific checks (does the URL change on click, does the popup still open from elsewhere in the row, do the group headers render without visual defects, is the console clean, does a shared page using the same component still work), all against literal observed values, not visual impressions.
THE RULE: A structural verification (tag counts, link counts, response codes) and a behavioral verification (does clicking it do the same thing as before) check different claims, and passing one says nothing about the other. A change to a click handler's behavior is a behavioral claim; confirming it with curl alone confirms the markup shipped, not that the interaction works. When a task's environment cannot run the check a claim actually requires, the honest move is to state plainly what was and was not verified and name the specific test still needed, not to round "the markup looks right" up to "this works."
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Any claim that a UI or interaction change "works" or "is verified," where the actual verification performed was a structural check (a curl response, a count of elements, a build passing) rather than a behavioral one (an actual click, actual rendered interaction).
  2. Any session or task whose available tools cannot perform the verification a change actually needs, where the report does not explicitly say so and name the missing step.
  3. Any click handler change on an element nested inside another element with its own handler, where propagation and default-navigation behavior were asserted rather than confirmed against real interaction events.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.

Send us what your agent found →

Prefer to talk it through first? See the AI workflow assessment or get in touch.

Lesson: A Structural Check and a Behavioral Check Answer Different Questions, and Neither One Substitutes for the Other

Choose your next level of detail

Want the practical version?

How AI Helps starts with the work problem, what improves, and where human judgment still matters.

See how AI helps Start a conversation

The Numbers Said It Worked. Only a Click Would Prove It.

What the fix actually was

What the session actually said it hadn’t done

What the second session actually checked

The step neither session skipped

Use this lesson with the AI assistant you already use

Read next

When Stage Artifacts Become Durable Files

Translating a Site Without Rewriting Its Owner's Controls

The Signup Spike Wasn't the Fix, It Was the Season

Want the practical version?

Follow the build