The Self-Updating Landing Page: When Claude Reads Your Ad Account and Ships the Variant

We've covered a lot of ground on this blog about building landing pages with Claude fast — the zero-to-live workflow, the pre-flight QA pass, feeding your search terms report into the draft before you write a word. All of that solves the build. What it doesn't solve is the part that kills most paid campaigns quietly: two months in, your ads have rotated three times, the winner from launch week is fatigued, and the landing page still says what it said on day one.

The fix isn't building faster. It's building a loop. This post is about that loop — wiring Claude to your ad account through MCP so the platform's own performance data triggers new page variants, and the pages ship themselves.

Why the one-off build runs out of road

Every workflow we've described so far — including <exact title> — has a human in the middle. You notice performance dipping, you pull the search terms report, you paste it into Claude, you review the draft, you deploy. That's a great Tuesday. It's a terrible system, because it depends on you noticing.

Ad fatigue doesn't announce itself. Frequency creeps up, CTR slides a few tenths a week, and by the time you've carved out an afternoon to refresh the creative, you've spent two weeks paying rising CPCs for a message that stopped working. The landing page is usually the last thing to catch up, even though it's the thing the click actually lands on.

A self-updating landing page inverts the trigger. The ad account isn't something you check — it's something that talks.

What MCP actually does here

MCP — the Model Context Protocol — is Anthropic's open standard for connecting Claude to external systems. Instead of copying numbers out of a dashboard and pasting them into a chat window, you run an MCP server that speaks to an API on Claude's behalf. Claude can then query data directly, and act on it.

For this loop you care about two connections:

The ad side. An MCP server that can read from Google Ads or Meta's marketing APIs — campaign performance, frequency metrics, ad copy currently live, search terms. Some community MCP servers already wrap these APIs; if one doesn't cover the fields you need, the APIs are documented and a purpose-built server is a weekend project, not a quarter.
The site side. Whatever deploys your pages — if you followed <exact title>, that's static hosting with an API you can hit. Claude needs a way to push a new page live, not just describe one.

Once both exist, the conversation changes shape. You stop saying "here's my data, write me a variant." You say "check the account, tell me what's fatiguing, and ship the fix."

The loop, end to end

Here's what the automation actually looks like when it's wired up.

Step 1: The ad account reports on a schedule. A scheduled prompt — run daily or a few times a week — asks Claude to pull performance for each active ad group: CTR trend, frequency, conversion rate, and the exact copy of every live ad. No human reads this yet.

Step 2: Claude flags drift against thresholds you set. This is the part people skip, and it's the part that makes the difference between automation and noise. You define what "fatigued" means in your account — frequency above a number, CTR down some percentage over a rolling window, whatever fits your volume. Claude compares the pull against those rules and returns a short list: these ad groups are drifting, here's the ad copy that's slipping.

Step 3: New variant copy is generated against the live ads, not your memory of them. This is where <exact title> becomes a component of the loop rather than a standalone trick. When a variant is triggered, Claude reads the current live ad copy and generates page copy that matches it — headline, proof points, CTA language. Because the input is the live ad and not a stale brief, message match is built in from the first draft.

Step 4: The draft runs your QA pass before anything deploys. The loop should reuse <exact title> as an automated gate — promise match against the triggering ad, load weight, mobile fold, form failure paths. A variant that fails QA doesn't deploy; it comes back to you with the failure noted. This is your safety net, and it should never be optional.

Step 5: Deploy and log. Passing variants push to hosting automatically. Every deploy gets logged — which ad group triggered it, what the metrics were, what changed on the page. That log becomes your experiment record.

Where you still belong in the loop

The word "automatic" makes people nervous, and it should — but the nervousness is usually aimed at the wrong step. Claude generating copy isn't the risky part; Claude deploying copy without anyone having defined the rules is.

So keep humans on the perimeter, not in the middle:

You write the thresholds. The rules that trigger a variant are a business decision, not a model decision. Set them, review them monthly.
You set the blast radius. Early on, run the loop in "propose" mode — Claude generates and QA-checks variants but a one-line approval from you deploys them. Once you trust it on low-stakes campaigns, flip auto-deploy on for those, and expand gradually.
You own brand voice. If you've done the work in <exact title>, your brand rules file is already part of every generation, which is what makes unattended variants tolerable in the first place.

The point of the loop was never to remove judgment. It was to remove latency — the two weeks between an ad going stale and the page catching up.

What breaks, realistically

A few honest failure modes before you wire this up:

API access and rate limits. Both major ad platforms gate their APIs behind developer access, and pull frequency has limits. Design the loop to pull daily, not continuously — daily is plenty for fatigue detection.
Thresholds tuned to nothing. If you set rules before you have baseline data, the loop will either fire constantly or never. Run it in observe-only mode for the first couple of weeks: let Claude report what it would flag, and tune from there.
Variant sprawl. If every trigger ships a wholly new page, you'll end up with dozens of lightly-differentiated pages and no idea which change moved what. Constrain variants to one or two elements — headline and proof block, say — so each deploy is a readable experiment.
Silent API drift. Ad platform APIs change fields over time. Your log from step 5 doubles as a canary: if deploys stop or QA failures spike, something upstream broke.

Start smaller than the full loop

If this reads like a lot, it is — but it's layered, and each layer pays for itself on its own. Start with the scheduled pull in observe-only mode: Claude reads the account weekly and tells you what it would refresh. That alone kills the "I didn't notice" problem. Then add variant generation with manual approval. Auto-deploy comes last, and only for campaigns where the stakes justify it.

The pages we've been building with Claude all along were fast. This is the next step: pages that don't wait to be told they're stale — they find out from the source, fix themselves, and leave you a note about what they did.