You Launched the Claude-Built Site. Now Who Changes the Headline?
Michael Sacca•(No live web search in this session, so I'm writing from well-established mechanics — how static sites work, how Git-based deploy pipelines behave, and how content files are typically structured in AI-generated codebases. Verify anything tool-specific before you commit to it.)
A few weeks ago I wrote about creating a blog with AI in one afternoon — Claude scaffolds the site, you own the domain, and the posting workflow repeats without starting over. That post ended at a healthy launch. This one starts at the uncomfortable part: day 30, when your PPC test says the headline is wrong, and the person who needs to fix it is a marketer with no terminal open and no developer on the team.
Generic website-builder content never hits this problem because the builder is the editing interface. You click, you type, you publish. But Claude doesn't give you a builder. It gives you files. And files, it turns out, are either the best or worst editing interface on earth depending on which of four setups you chose at launch — usually without knowing you were choosing.
Why this gap exists at all
When Claude generates a landing page, it typically produces static code: HTML, some CSS, maybe a JavaScript file or a framework build. The words on the page live inside that code. There's no database, no admin panel, no "edit" button — that's partly why the site deploys cleanly and cheaply, a point I covered in Claude Wrote the Code. Here's Where It Deploys Without a Fight.
The trade is real: you gave up a content layer to get simplicity. The question is how to get the content layer back in the smallest possible dose.
The four setups, worst to best
1. Ask Claude to regenerate the page (the trap)
The obvious move — open the chat, say "change the headline to X," get new code, redeploy — works exactly once per person. The problems compound fast: Claude doesn't remember your last revision unless you feed the whole history back, small edits drift the design, and every change routes through a full regeneration. You've turned a ten-second copy edit into a code review. This is a deployment strategy, not an editing strategy.
2. Edit the file directly (viable, if you set it up right)
Here's the part nobody tells you: on a well-structured static site, changing a headline doesn't require knowing how to code. It requires knowing where the words live. If Claude put the headline in index.html between two tags, anyone comfortable with a text editor can change the text between them.
The discipline that makes this work is separation: ask Claude, at scaffold time, to put all editable copy in one obvious place — a content file, a clearly labeled section, one string per line — rather than scattered through markup. If your site is already built and the copy is scattered, one Claude session to refactor it into a structured file is worth the effort. That's the whole maintenance story, solved on day one instead of day 30.
3. Git-based editing (the workflow most teams should adopt)
If your host deploys from a repository — which is how most static hosting works — your edit workflow is: change the content file, commit, push, and the site redeploys itself. Platforms like GitHub let you edit files through a web interface that looks a lot like a very plain document editor. No local tools, no terminal required.
This is the actual answer to "no developer on the team." A marketer can learn edit one file → save → the site updates in a couple of minutes in a single sitting. The safety net is real too: every version is preserved, and rolling back a bad headline is one click, which is more than most builders can say.
4. A headless CMS (when editing frequency justifies it)
If copy changes daily, or several people need to edit without touching anything code-shaped, a headless CMS is the missing layer: content lives in a separate service, the static site pulls it in at build time, and editors get a real form-based interface. This adds a moving part — an account, a build dependency, usually a cost once you outgrow free tiers — so the honest advice is: don't start here. Start with option 3 and promote yourself to option 4 only when the friction actually hurts.
The permission question people forget
Whichever path you pick, someone needs access. If the whole site lives in one person's GitHub account and that person is on vacation, day 30 becomes day 35. Before launch, answer:
- Who can commit to the repo?
- Who can access the hosting dashboard?
- Is there a written note — even a shared doc — describing where the editable content lives and how a change goes live?
That last one is the cheapest insurance in this whole workflow. Claude can write the note for you; that's a five-minute ask at scaffold time.
Where MCP changes this
If you've followed the earlier post on wiring MCP servers so your pages update from campaign data, you know the frontier version of this: Claude pulling metrics and pushing revisions on its own. But that's the automated endgame, not the baseline. The unglamorous middle — a human edits a content file, pushes, the site rebuilds — is what keeps the site maintainable on the days nobody's automating anything. Get that working first; the agents slot in later, and they slot in more cleanly if the copy was separated from the code back when it was cheap to do.
The short version
The maintenance gap isn't solved by picking a tool; it's solved by a decision you make at build time: words live in one place, separate from markup, and changes ship through a Git push. Set that up on day one and day 30 is a two-minute edit anyone on the team can make. Skip it, and every future headline change is a regeneration roulette wheel.
If you haven't built yet, fold this into the original scaffold prompt. If you already launched scattered, spend one Claude session on the refactor — it's the highest-leverage hour you'll spend on that site all quarter.