Your Landing Page Should Never Freeze: Building a Weekly AI Iteration Loop From Campaign Data Back to Claude
Michael Sacca•Every "AI landing page" tutorial ends at the same place: the page deploys, the confetti emoji fires, the tutorial signs off. Which is exactly backwards. A landing page isn't a deliverable — it's a hypothesis. "This headline, this hero image, this form length will convert this traffic" is a guess you made in thirty seconds inside a chat window, and the entire rest of the campaign is the experiment that proves you right or wrong.
If you never feed the results back in, you built a very fast way to freeze a bad page. The generation half is covered elsewhere on this blog — including how to keep Claude editing your site after launch — but that post stops at "the pipe works." This one is about what flows through it: a weekly rhythm where campaign data becomes prompt input, and Claude's rewrite becomes next week's page.
The loop, in one paragraph
Every week, you collect four things: what the traffic did (analytics), what visitors said without saying it (session recordings), what they typed into your form, and what changed on your side (new offer, new audience, new ad copy). You compress those into a brief, hand it to Claude with the current page code, and ask for a specific set of changes. You deploy, you tag the version, and next week's data tells you whether the rewrite helped. That's it. Everything below is just making each step cheap enough that you actually do it weekly instead of "when things quiet down," which is never.
Step 1: Decide what data actually gets fed in
The trap here is dumping a raw analytics export into a chat window and asking Claude to "improve the page." A 40-row CSV of every metric makes the model average everything and change nothing. What works is a deliberately narrow brief with four ingredients:
- Conversion counts by segment. Not "1,200 visits, 34 conversions" — that's a report. "Visits from the Google Ads campaign convert at a third the rate of direct traffic, and almost all Google Ads traffic bounces on mobile" — that's a signal Claude can act on.
- Session recording patterns, summarized by you. Tools like Hotjar, Clarity, or FullStory will show you rage clicks, dead-scroll zones, and visitors who read the whole page and then leave without touching the form. Don't export recordings — watch ten of them, write three sentences about what you saw, and feed those sentences in. You are the pattern-recognition layer for anything that isn't a number.
- Actual form submissions, verbatim. This is the most underused asset in landing page optimization. If people write "does this work for teams?" in the message field, that's a headline. If they write "I expected pricing on this page," that's a section you're missing. Ten real submissions beat any amount of generic CRO advice.
- What changed upstream. New ad angle, new audience, price change, competitor launch. Claude can't see your campaign manager; if the traffic mix shifted, the model will otherwise misread the week's numbers as a page problem when it's an audience problem.
A useful rule: if a piece of data wouldn't change a sentence on the page, leave it out of the prompt.
Step 2: The prompt that produces a diff, not a rewrite
The biggest failure mode of AI iteration is the model regenerating the whole page every week — new headline, new layout, new everything — so you can never tell which change moved the number. The fix is mechanical, not clever: always give Claude the current page code, always frame the task as a bounded edit, and always ask it to justify each change against a specific piece of your data.
A prompt shape that holds up week after week:
Here is the current landing page code and last week's data brief.
Make the smallest set of changes likely to fix the mobile
conversion drop described in the brief. For every change,
cite the specific data point that justifies it. Do not
restructure the page, do not change the offer, do not touch
the form fields. Output: (1) a summary of each change and
its justification, (2) the full updated file.
The constraints matter more than the phrasing. "Smallest set of changes" fights the model's enthusiasm for reinvention. "Cite the data point" makes weak ideas visible — if Claude can't point to a reason, the change is decoration and you should cut it. And keeping the form fields fixed preserves the one part of your funnel you actually collect data through.
Step 3: Version control is your experiment log
This is the unglamorous half that makes the whole loop work. If you're deploying via git — which any of the static hosts recommended in our hosting coverage for AI-built sites support natively — then every week's rewrite is a commit, and your commit history becomes a readable experiment log:
week-6: shorten hero headline, add pricing section (mobile bounce data)
week-7: move CTA above fold on mobile (session recordings)
week-8: revert week-6 headline (conversions down 20% week-over-week)
Three practices that turn this from clutter into an asset:
- Tag the version with the week number, so the page you showed traffic in week 6 is always recoverable.
- Write the justification in the commit message. Six months from now, "updated headline" tells you nothing; "replaced 'AI-powered growth' with 'Does this work for teams?' — top form submission, week 5" tells you exactly what you learned.
- Keep a one-line log outside the repo — a note in your task manager is fine — recording the conversion rate each week went to. Claude's changes are only an experiment if you record the before and after.
Step 4: Automate the boring connective tissue
Once the manual loop has run three or four weeks, you'll notice most of it is plumbing: pull the analytics number, pull the form submissions, paste the brief, paste the code, deploy. Each of those is a place where the tools covered in the automation posts on this blog apply:
- Scheduled jobs. A weekly scheduled run — a cron-triggered script or a platform like Make or Zapier on a weekly schedule — can pull form submissions from your form handler and dump them into a document Claude reads.
- MCP connectors. If you've wired Claude to your site with MCPs (the setup described in the post-launch automation post), the same connectors can read from your analytics or form tool, so the "gather the data" step shrinks to reviewing what the system collected.
- One-way automation only, at first. A strong recommendation: keep the human in the loop for approving the rewrite for the first month. Let the pipeline assemble the brief automatically, but read the diff and hit deploy yourself. Fully autonomous page rewrites based on weekly noise — especially at low conversion volumes, where one lucky week looks like a trend — will eventually ship something embarrassing to your whole traffic source. Once you've seen Claude's weekly judgment hold up for a month, you can loosen the leash on cosmetic changes while keeping human sign-off on headlines and offers.
What the loop actually fixes
The payoff isn't a prettier page — it's that your landing page becomes the one asset in your marketing that compounds. Week 5's form submissions wrote week 6's headline. Week 7's session recordings moved week 8's CTA. By week 12, the page encodes twelve weeks of evidence about what your specific audience responds to, which no competitor can copy by viewing your source.
Compare that to the standard alternative: you launch the AI-built page, run your campaign, get mediocre numbers, shrug, and either rebuild from scratch next quarter or keep paying for traffic into a page nobody tested. The generation tools made building nearly free; the iteration loop is what makes the building worth anything.
And the cost of running it is small — thirty minutes of data review, one well-constrained prompt, one commit. The only real requirement is the decision that the page is never done. Freeze it the week you stop feeding it, and it starts quietly decaying the moment your ads, audience, or offer drift.