Your AI Landing Page Gets Traffic — But Where Do the Leads Go?

You got the page live. Claude wrote it, you deployed it to a static host, the domain resolves, the SSL padlock shows up. You even turned on some paid traffic. The form fills are coming in.

Or — you're pretty sure they're coming in, because you filled out the form yourself during testing and nothing appeared anywhere. No email, no CRM record, no spreadsheet row. The lead went into a void.

That void is the post-submit half of the landing page, and it's the part every AI-site tutorial skips. Getting the page built and published is genuinely the easy part now — we've covered that ground before, including the path from code to live domain and how to point a domain you bought elsewhere at a Claude-built site. This post is about the moment after someone clicks Submit: where the data lands, why the default form behavior silently fails on static hosting, and three ways to wire submissions into a CRM without hiring a developer.

Why your form is broken and you don't know it yet

Here's the failure mode: Claude (or ChatGPT, or any code model) writes you a <form> element. A bare HTML form with no action attribute, or one pointed at a placeholder like action="/submit". When you preview that page in a chat window or in a local dev server, submitting looks fine — the browser at least does something.

But a static host — Netlify, Vercel, GitHub Pages, Cloudflare Pages, an S3 bucket — doesn't run any server-side code. There is no /submit endpoint. The form either 404s, does nothing, or worse: appears to succeed while the data evaporates. That last one is the dangerous one, because from the visitor's side the page looks like it worked. They think they submitted. You never got anything. If that page is running paid traffic, you're paying for leads and destroying them at the last step.

Three things worth knowing about this gap:

Forms need a receiver. HTML forms are just a POST request to a URL. On a dynamic site, that URL is a server endpoint someone wrote. On a static site, there is no server — so the URL has to point at a third-party service whose whole job is receiving form posts.
Some static hosts have native form handling. Netlify, for example, has built-in form detection: add the data-netlify="true" attribute (or add netlify to the form's hidden input list) and Netlify will intercept submissions, store them in its dashboard, and notify you by email. Vercel and GitHub Pages do not have an equivalent — you bring your own receiver there.
JavaScript handlers just move the problem. Claude will often write a fetch() call that POSTs to an API endpoint it invented. That endpoint doesn't exist unless you create it or point the fetch at a real service. A form that "works" in the browser console and produces zero leads is worse than a form that visibly errors.

So the honest framing is: on a static host, lead capture is not a code problem anymore. It's a routing problem. The question is not "how do I make the form work" but "what URL should the form POST to, and what should that URL do with the data." The rest of this post is three answers, ordered roughly by how much volume and complexity you expect.

Route 1: Webhook direct to CRM — the low-volume default

Most CRMs and form services expose a webhook URL: a special endpoint that accepts a POST and turns it into a record. HubSpot has form endpoints; Zapier's own webhooks module is the universal adapter; many CRMs (Pipedrive, HighLevel, Insightly) accept submissions through built-in form tools or webhook triggers. The wiring looks like this:

<form action="https://hooks.your-service.com/your-id" method="POST">
  <input name="email" type="email" required />
  <input name="company" />
  <button type="submit">Request a demo</button>
</form>

You ask Claude to swap the placeholder action for your real webhook URL and add a hidden success page or inline thank-you state so the visitor gets feedback. Done. No backend, no server, no monthly infrastructure decision beyond whatever your CRM already costs.

Tradeoffs for paid-traffic volume:

At low volume (tens of leads a month), this is unbeatable on simplicity. It's two edits to the page.
Spam is your main enemy. An open webhook gets scraped and abused; add a honeypot field (a hidden input bots fill but humans can't see — ask Claude to add one, it's a five-line change) and let the receiving service's spam filtering do the rest.
You get no retry logic worth trusting. If the CRM hiccups at the exact moment a lead submits, that lead may be gone. At low volume, you can live with checking the form service's log manually. At high volume, you can't — which is the argument for Route 3.
Analytics granularity is thin. You know a lead arrived; you don't get server-side event data unless your receiver tracks it.

Route 2: Claude as the router — the automation-native route

If you're already running automations against your live site — the territory we covered in the MCP and scheduled-LLM wiring post — there's a more interesting option: let an LLM sit in the middle of your lead pipeline.

The shape of it: form submissions hit a webhook receiver (Zapier's webhooks, Make's webhook module, or a simple catch-all form service). That receiver triggers a flow where Claude does routing work — classifying the lead ("is this a demo request, a support question, or a recruiter?"), enriching the submission with inferred context (company size, likely intent, urgency), drafting a personalized first-touch reply, and then routing the record to the right place in your CRM with tags attached.

What this buys you that Route 1 doesn't:

Qualification before a human sees it. If your landing page serves two offers, Claude can triage submissions and drop each into the correct pipeline stage.
Zero-response-time follow-up. A drafted, contextual reply can be queued seconds after submission. Speed-to-lead is one of the few things most teams consistently under-invest in, and this is the cheapest way to fix it.
The router is promptable. Change your offer or your CRM structure, and you edit a prompt, not a codebase.

Tradeoffs:

Latency and cost scale with volume. Every submission is an API call. At tens of leads a day that's trivial; at thousands, you're paying for LLM reasoning on every form fill whether it needs it or not.
You've introduced a failure point that's harder to debug. When the pipeline silently drops a lead, is it the webhook, the LLM call, the CRM connector, or your prompt? Route 3's structured tools make this much more visible — which is why at serious volume you probably want the router inside a platform rather than as a loose chain.
Guardrails matter. You're letting a model decide what happens to a real person's inquiry. Keep a human approval step for anything that sends email directly, at least until you've watched it run for a few weeks.

Route 3: Zapier (or Make) as the bridge — the scale-it-later route

The third route is the one that grows with you: put an automation platform between the form and the CRM and let it handle everything the naive webhook path can't — retries, deduplication, spam filtering, multi-step routing, and visible logs of every submission.

The pipeline: form → automation platform trigger → (optional) filter steps that drop spam and junk submissions → (optional) a Claude step for classification or reply drafting → CRM record creation → notification to the team (email, Slack) → logging row in a spreadsheet as a belt-and-suspenders backup.

Why bother with the middleman when Route 1 is simpler? Because the middleman is where the paid-traffic problems get solved:

Retries. If your CRM's API times out during a traffic spike, Zapier replays the task. Route 1 just loses the lead.
Deduplication. The same person submitting twice (they always do) becomes one CRM record instead of two, if you set up a lookup step.
Visibility. Every task run is logged with success/failure status. When your cost-per-lead spikes and you suspect lead loss, you can actually check instead of guessing.
Modularity. Swap CRMs next quarter and you rewire one connection, not your form's action URL and everything downstream of it.

Tradeoffs: per-task pricing means high volume costs real money — check the task math against your lead volume before committing, since every filter step consumes tasks too. And there's a mild learning curve to the filter/lookup steps that Route 1 completely avoids.

Which route for which volume

No precise thresholds here, because pricing and CRM behavior vary — but the shape of the decision is:

Testing or low spend (a few leads a week): Route 1. Direct webhook, honeypot for spam, done in an afternoon. Don't build infrastructure for traffic you don't have.
Growing spend, multiple offers, want fast follow-up: Route 2, ideally with the router living inside Route 3's platform so failures are visible and retries exist.
Serious paid traffic, can't afford to lose leads: Route 3 as the backbone, Claude as a step inside it rather than a separate fragile link. The platform absorbs the spikes; the model adds judgment where it's worth paying for.

One last thing: test it like a visitor, not a developer

Whatever route you pick, do the one test that catches everything: fill out your live form from your phone, on the deployed site, with the domain loaded — not the preview, not localhost. Then check that the lead actually arrived at its destination and that you received the notification you'd want to see at 11pm when a real lead shows up. The void at the end of the form only exists if you never look into it.

The build-to-publish pipeline is solved — Claude handles that, and we've documented it here. The submit-to-CRM pipeline is the half that decides whether your landing page is a business or a brochure. Wire it once, test it honestly, and the leads stop falling through the gap between "deploy" and "live."