The Features Page Had 327 Visible Words and No Headings

Sep 5, 2026 · 3 min read

Updated Oct 13, 2026

Cover image for: The Features Page Had 327 Visible Words and No Headings

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

<tr onclick="featurePopUpShow('/popups/feature-info?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.

The change

We wrapped the feature name in a real anchor pointing at the same popup URL and left the row’s own click behavior untouched. The anchor’s click handler cancels the default navigation and stops the click from also reaching the row underneath it. A person sees no difference, and a crawler gets a real link to walk. The core of 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 first session said it couldn’t check

The session that wrote this had no browser automation, only Bash and file tools. 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, the page had zero heading tags, zero real links to the popup content, 63 onclick-only rows and 327 visible words. After, against the working branch on a local dev host, it had one <h1>, seven <h2> group headers, 63 real href attributes pointing at the 61 individually reachable detail pages, and 390 visible words.

Every one of those numbers was a real, checked fact. None of them said 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 so in its own report and named the one test still missing: a live click-test on the branch before shipping. It stopped there. It did not round “the markup is right” up to “this works.”

What the second session ran

A separate session picked up that recommendation and ran it in a real browser against the local dev copy. It made eight checks, each against an observed value:

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, and no 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 only a pre-existing, unrelated deprecation notice that fired identically before the change. The feature name rendered as plain gray text with 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 values did the change move toward shipping.

The compile step

Before anything 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 and get repointed at a dated, minified bundle. Then we checked again with the same curl counts as before: one heading, seven group headers, sixty-three real links. A compile step changes bytes, and the only way to know it didn’t change behavior is to check again.

The fix shipped the same day and was confirmed live with the same numbers it had in review. What made it trustworthy was that the session without a browser reported what it couldn’t check, and a clean set of curl numbers never stood in for a click nobody had made.

Clean measurements show what the markup contains. Whether the page still behaves for a person using it takes someone clicking.

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 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/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 right 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? Start an assessment or talk to us.

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 Talk to us

The Features Page Had 327 Visible Words and No Headings

The change

What the first session said it couldn’t check

What the second session ran

The compile step

Use this lesson with the AI assistant you already use

Related in Trusting AI output

The Morning Digest Said Three Things Needed a Person. None Did, and Passing Tests Were Not the Proof.

Verify the Agent Actually Showed It: Building Honest Tools for Agentic Workflows

The 38 Hour Session That Closed Without Opening the Deployed Page

What Our Coding Agent Announced After Editing JScript and Reloading Nothing

A Legacy max-width Rule Clipped the Right Column at Mid Width

Want the practical version?

Follow the Build