The Page Deploys Fine. Your Leads Are Going Nowhere: Testing Where Form Submissions Actually Land on AI-Built Sites

(No live web search in this session, so treat the specific service names and failure modes below as an operating checklist built from standard form-handling practice, not a vendor audit. Form backend services change pricing and limits constantly; the failure patterns don't. Every "test this before spending" call here assumes you'd rather find a broken pipe yourself than discover it from an angry prospect who never heard back.)

Here's the gap in almost every "build a landing page with Claude" walkthrough: it ends at deploy. Page's live, URL resolves, screenshot taken, tutorial over. Nobody asks the only question a landing page exists to answer — when someone types their email into that form and hits submit, where does it actually go?

I've started treating that question as the real final milestone. Not "the page deploys fine" but "a test lead lands somewhere a human sees it." Because the failure mode here is uniquely nasty: it's silent. A broken CSS layout announces itself. A form that accepts a submission, shows a success message, and delivers the lead to nowhere announces nothing — until you check the pipeline two weeks later and realize your cost-per-lead has been measuring ghosts.

The default state of an LLM-built form is "looks finished, goes nowhere"

Ask any model to generate a landing page with a contact form and you'll typically get one of three things:

A form with action="#" or no action at all — submits, page reloads or does nothing, data evaporates.
A form wired to a placeholder endpoint — something like /api/submit that doesn't exist on a static host, so every submission 404s. Depending on how the code handles the response, the user may still see your success message.
A console.log() where the POST should be — the model wrote the UI of a working form and stubbed the plumbing.

None of these throw an error the visitor notices. All of them count as "the page works" if you judge by looking at it. This is the same class of problem as the handoff failures I covered in The Handoffs Are the Hard Part: Auditing Every Connection Point in an LLM-Run Site Pipeline — the individual pieces are fine, the connection between them is where data dies. The form-to-backend handoff is the one where the thing that dies is revenue.

Your wiring options, ranked by how they fail

There are roughly four ways to give an LLM-built form a backend. They differ less in capability than in how they fail quietly.

Host-native form handling. Some hosts and static-site platforms offer built-in form processing you enable with an attribute or a dashboard toggle. This is the cleanest path if your host has it — the failure mode is mostly misconfiguration, and misconfiguration usually shows up the first time you test. The catch: it's host-specific, which means it's lock-in. I've argued before (in You Don't Need a "Free Site Maker" — You Need a Free Page and a Host That Doesn't Own It) that you want the page portable. A form wired to host-native handling is one more thing to rewire when you migrate.

A dedicated form backend service. You point the form's action at a service endpoint, it collects submissions and forwards them to email or a webhook. Fast to wire — the model can write this config correctly on the first try. Failure modes: free tiers commonly have monthly submission caps, after which behavior varies (some services silently discard, some return errors your form may not surface). Spam filtering happens on their side and you can't see what they filtered.

A serverless function. You ask the LLM to write a small function that receives the POST and sends you an email or writes to a database. Most flexible, most controllable — and the most ways to fail silently. CORS errors mean the browser blocks the request (visible only in dev tools, invisible to the visitor). Missing environment variables mean the email-sending library fails at runtime. The function "deployed fine" and does nothing.

A CRM or email platform's native form embed. If you're on HubSpot's free tier or similar, their embed script handles capture, storage, and confirmation. Heavier page weight, but delivery is their problem. The failure mode is script-blocking and consent-banner interactions — the embed doesn't load, and depending on how it's implemented, the form may not render or may not submit.

The five-minute test that catches almost everything

Wiring done is not wiring working. Here's the protocol I now run on every AI-built page before any traffic touches it. It takes minutes.

1. Submit with a marker. Use a dedicated test email address you actually check — not a fake address, because a fake address can't tell you whether confirmation emails arrive. The submission should contain a distinctive marker string in a field so you can trace it through spam filters and forwarding chains.

2. Check the destination, not the success message. The form showing "Thanks! We'll be in touch" proves nothing. That message renders from your own code regardless of what the backend did. Go look at the service dashboard, the inbox, the CRM contact list — wherever the lead is supposed to land.

3. Check spam. If delivery is email-based, the marker email may have arrived in the test inbox's spam folder. This is the most common "it works" false negative — submissions are being delivered, just into a folder nobody watches. Fix it by sending from a custom domain with proper SPF/DKIM, or by adding a second delivery path.

4. Submit twice. Some backends dedupe or rate-limit. A duplicate submission is exactly what a real lead does when they're unsure the first one went through. You want to know if the second one arrives.

5. Submit with the form "broken" on purpose. Leave a required field empty. Hit submit with JavaScript disabled if you can. The point is to see what the user experiences when something goes wrong — a dead success message on a failed submission is worse than an error, because the visitor walks away believing you have their info.

6. Watch the console once. Open dev tools on the network tab, submit, and look at the actual request. Status 200? Good. Status 404 or a CORS block with the success message showing anyway? You just caught the classic LLM-form bug: optimistic UI that celebrates before the server confirms.

The silent-failure ledger

For paid traffic especially, I keep a running count of where submissions can vanish without any error anywhere:

Placeholder endpoint — the form was never wired at all. Nothing fails loudly because nothing is connected to fail.
Optimistic success UI — code shows the confirmation before or regardless of the server response.
Service submission caps — free-tier limit hit mid-month; behavior after the cap varies by provider and is worth reading the docs for before you rely on it.
Spam filtering on the receiving side — either the backend service's filter or your inbox's, both invisible from the page.
CORS or environment-variable failures in serverless functions — the function exists, deploys, and errors at runtime only.
Email deliverability — arrives, but in spam, where leads go to die quietly.

Notice that only one of these produces a visitor-visible error under normal conditions. That's the whole argument for testing: this subsystem is designed by accident to fail invisibly.

Make the model build the test, not just the form

The fix I've settled on: don't let the form-building session end at "the form is wired." Add a second prompt in the same session — "now write me the test plan for this form" — and the model will usually produce exactly the checklist above, plus specifics about its own code: which endpoint, which fields are required, where the success message is triggered relative to the server response. Asking the model to audit its own form right after writing it catches the optimistic-UI bug embarrassingly often, because the model knows exactly where it cut the corner.

And once the form is verified end-to-end, write the verification down as part of the page's deployment notes. If you're running any kind of repeatable pipeline — which, if you've read You Launched the Claude-Built Site. Now Who Changes the Headline?, you know I think you should be — the form test belongs in the same runbook as the deploy itself. Deploy, verify form, then and only then turn on traffic.

A landing page that captures nothing is a brochure with a lead-ad budget attached. The page deploying fine is the easy 80%. The last 20% — the pipe from "submit" to "a human sees it" — is the part nobody tests, and it's the only part that pays for the traffic.