Scenario · Something looks broken
We stopped getting leads
“We stopped getting leads.” Or: “The contact form isn't working.”
"We stopped getting leads" and "the form isn't working" are usually the same underlying problem, and it fails silently — the people who'd notice are exactly the ones who couldn't get through. This actually submits the form to prove it accepts a real entry, rather than just confirming it looks fine, and separately checks whether leads are still arriving but simply not being counted, which looks identical to leads stopping and sends the wrong kind of investigation entirely.
What to ask for
See it work
A real run of Form submittability:
Form submittability · form-submittability — https://toolkit-tests.pages.dev/forms/overlay-submit.html (devices: desktop,iphone-17)
FAIL — https://toolkit-tests.pages.dev/forms/overlay-submit.html
✗ the submit button is covered by a fixed element (div.banner) — clicks land on the overlay, the form cannot be sent
• field textarea [message] is covered by a fixed div.banner — a visitor may not be able to click it
• field button is covered by a fixed div.banner — a visitor may not be able to click it
report: ./out/form-submittability-form-submittability.html
text: ./out/form-submittability-form-submittability.txtThe captured report, exactly as a run hands it to a client —open the full report ↗
Seen in the wild
A public lead form with no spam protection at all.
Ticket #12672open · high priority
Junk and maliciously diverted leads coming through
The client is reporting junk enquiries and cannot explain where they come from. Rather than reasoning about it, the check drove the actual live form the way a visitor would, and reported what protection it found.
What the probe pulled back
| Form found | public lead form |
|---|---|
| Honeypot field | none |
| CAPTCHA / Turnstile | none detected |
| Submittable | yes |
| Verdict | REVIEW |
Why that explains the complaint
- Nothing to slow an automated botSpam gap
- No trap field to catch one eitherSpam gap
- A public form, openly submittableSpam gap
Two reports, one procedure. “The form isn’t working” is the cause; “we stopped getting leads” is the symptom, and it arrives without anyone having checked the form. Either way the failure is silent — the people who would have complained are the ones who could not reach you.
- Run the form-submittability check on the public page and record its form, destination, and protection findings. A form that renders and rejects every submission is the most common cause and it is invisible to a visual check.
- Check the links and images on the page. A form behind a broken button, or a page whose submit control never loaded, produces the same symptom.
- Fix any delivered-page issue it confirms before testing the actual lead route.
- [manual] Make a controlled internal submission and confirm receipt in the agreed internal destination. Never use a real patient or production lead as a test, and tell whoever watches the inbox that a test is coming so it is not chased as a real enquiry.
- Check whether the measurement stopped rather than the leads. The tag audit confirms whether form submissions are still being recorded as conversions — leads arriving but not counted looks identical to leads stopping, and it sends this ticket in entirely the wrong direction.
- Keep the check report and the receipt confirmation together. Until the end-to-end submission in step 4 exists, this is not verified — the automated check proves the form accepts input, not that anything was delivered.
What this does not cover
Whether a lead actually reaches a human. The form check tells you the form is submittable and what protection it has — not that the last enquiry landed in anyone’s inbox, and not that the practice is answering it. A decline in genuine enquiries is also outside it: a working form with fewer submissions is a marketing question, and no page check can tell the two apart.