The Page Went Live. Now Someone Wants to Change It: Who Maintains an AI-Built Website?

We've covered the theory and the walkthrough on this blog. We argued that AI domain hosting is a new category, we walked through the deployment step most tutorials skip, and we even showed what happens when you send paid traffic to an AI-built page. What we haven't done is the thing that actually fills your calendar after launch: maintenance.

Here's the uncomfortable truth about every "build a landing page with Claude in 10 minutes" tutorial, including the good ones: they all end at publish. The video stops. The article concludes. The page is live, everyone high-fives, and then — nine days later — your paid media lead Slack-messages you: "Can we test a new headline on the pricing section? Also legal wants the disclaimer reworded. Oh, and the pixel ID changed."

There is no tutorial for that week. So here it is.

The core difference: you don't have a developer, you have a conversation

On a traditionally built site, maintenance has a clear owner. A developer made changes. A CMS made some changes possible without them. Either way, there was a person or system whose job was "edit the live page."

With an AI-built page, the person who built it is... whoever prompted it. If that was you, great — you can reopen the chat. But that chat transcript is now your maintenance interface, and it has failure modes a codebase doesn't:

• Context decay. By message forty, Claude has forgotten the exact structure it used in message three. Your edit request lands in a conversation that no longer "remembers" the whole page.
• Regeneration drift. Ask for a headline change and the model sometimes helpfully "improves" three other things on the page while it's in there. You asked for a fresh coat of paint; it repainted the house.
• The lost file problem. If you deployed by copying code out of the chat window, your source of truth is a chat log. If you deployed as files, your source of truth is whatever repo or folder you saved. These are very different maintenance experiences, and we'll get to both.

The fix for all three is the same principle: the chat is not your source of truth. The files are.

Set yourself up before launch, or pay for it in week two

Most of the maintenance pain in AI-built pages is self-inflicted at build time. Three habits prevent almost all of it.

1. Treat the generated code as files, not chat output. Save every file Claude produces into a real folder or repo, and make future edits against those files — paste the current file back into the chat and ask for the modified version, rather than asking the model to recall the page from memory. This turns "regeneration drift" into a diff you can review.

2. Name the editable things. Somewhere in your project, keep a short list: which file holds the headline, which file holds the form, which snippet holds the analytics pixel. On a hand-built site a developer knows this; on an AI-built site, ten minutes of documentation saves you re-reading 800 lines of generated HTML at 5pm on a Friday.

3. Keep third-party scripts in one obvious place. Pixels and tags are the single most common post-launch edit, and the most common way to break a page. Put them in one block, clearly commented, so the swap is find-and-replace instead of surgery.

The four edits you'll actually get asked for

In practice, almost every week-two request falls into one of these buckets. They're not equally easy.

Copy tweaks: easy, with one trap

Headline changes, disclaimer rewording, swapping a testimonial — this is the AI-built page's home turf. Paste the file, describe the change, get the file back. The trap: message match. If the headline changes, the ad that points at the page may no longer match it, and your paid performance quietly degrades. We covered why that pairing matters in the landing page builder scorecard — the same rule applies after launch, not just at build time.

Pixel and tag swaps: easy if you planned, painful if you didn't

A new pixel ID or a restructured tag is mechanical — find the block, replace the snippet, redeploy. If your analytics live in one commented block, this is a five-minute job. If they're scattered across files because the build prompt never specified structure, this is the moment you go find every script tag by hand. If analytics wiring was an afterthought at build time, our post on making pages legible and measurable covers the structure worth retrofitting.

New sections: medium difficulty, real risk

"Add a pricing table below the FAQ" sounds like a one-line request. It's the request most likely to come back with a subtly restyled version of the whole page, because the model re-renders its understanding of your design system rather than only appending. The countermove is to scope the prompt: "Add a pricing section between the FAQ and the footer. Do not modify any existing markup or styles." Then diff the result against the old file before it goes live. If you don't know how to diff files, this is the one skill worth learning — it's one command, and it turns "did it change something I didn't ask for?" from a guess into a fact.

Whole-campaign variants: where AI-built pages earn their keep

The flip side: the same conversational workflow that makes maintenance awkward makes iteration cheap. "Same page, but the headline speaks to startups instead of agencies, and the hero image section references B2B" is a genuinely fast request. We've argued before that variant iteration cost is the metric that should decide your builder, and this is where the AI-built workflow shines — as long as each variant is a separate file or folder, not a mangled fork of one.

So who actually does the editing?

Four realistic answers, in order of how often we see them:

You, via the chat. Works fine for copy and small edits, provided you're editing files, not memories. This is the default and it's legitimate — you don't need a developer for a headline swap any more than you needed one to prompt the page in the first place.

You, or a colleague, with a text editor. For truly mechanical edits — changing a string, swapping an ID — opening the HTML file directly is faster and safer than a round trip through the model. AI-generated pages tend to be readable HTML, which is a quiet advantage: you can often edit them by hand even if you couldn't have written them.

Another AI session. Handing maintenance to a fresh conversation — or wiring an agent into your deploy pipeline the way we described in MCP for Marketers — works well when the files are clean and the instructions are specific. A new session with your files is often a better maintainer than your original build chat, because it reads the actual page instead of remembering a conversation about it.

A developer, eventually. If the page grows into a real site with forms, auth, or integrations, at some point the conversational workflow hits its ceiling and you want a human who owns the codebase. Knowing where that line is — and not pretending the chat can scale past it — is part of the job.

The honest summary

The week-two reality of an AI-built page is this: the edits are all doable, the chat is a good editor but a bad filing system, and whether maintenance is pleasant or miserable was decided at build time, not at edit time.

Save the files. Comment the pixel block. Scope your edit prompts. Diff before you deploy. Do those four things and the follow-up work that no tutorial covers becomes a few minutes a week instead of a re-architecting exercise.

And when someone asks "who maintains this thing?" — the honest answer is: whoever can read a file and describe a change clearly. Which, if you built the page with AI in the first place, was already you.