Guide · October 2026
Your AI built the site. Who runs it now?
Claude Code, Lovable and v0 get a website online in an afternoon. Then someone needs to change the phone number, add an article or fix why Google ignores the site. This guide compares the options for running an AI-built website, including where Caelo is the wrong choice.
Day two
Building is solved. Running the site is not.
The people who build sites with AI keep running into the same wall, and they say so plainly:
- "A Claude Code website that the client cannot edit is not a product." (mejba.me)
- "Non-technical website maintainers don't want an HTML editor; they want their website to have an edit button." (Hacker News)
- "We decided to go with Lovable so the recruiting team can maintain it themselves later. Yeah, I'm not sure that's a good idea." (Hacker News)
- A v0 user with nine hard-coded articles asks for a CMS that is neither complex nor expensive. (Vercel community)
Behind these sit three problems. Edits need a developer or another round of prompting. Small prompts change more than intended. And sites rendered in the browser by JavaScript are often read poorly by search engines; Google's John Mueller told the owner of a vibe-coded site that the homepage "should have everything that people and bots need to understand what your site is about" (Search Engine Journal).
Options
Four ways people run AI-built sites today.
| Option | Works well when | What is missing |
|---|---|---|
| Keep prompting (repo + Claude Code, or the builder you started in) | A developer owns the site and changes are rare. | Every edit needs that person. No review step for non-developers; design drifts with each prompt. |
| Headless CMS (Sanity, Payload, Strapi and others, many now with MCP servers) | Content is structured and a developer maintains the frontend. | The agent edits content, not the site: layout, design and performance stay in the code. You run two systems. |
| Git-based CMS (Decap, Tina, Sveltia) | A static site in a repo needs a simple editing form. | Editors fill fields; new sections or pages still need a developer. No AI workflow, no quality gate. |
| WordPress (now with an official MCP adapter) | You need its plugins, or your team already lives in wp-admin. | Moving the AI-built design into a theme is a rebuild. Agent changes go straight to the live site unless you add staging yourself. |
None of these is wrong. Each solves one part: editing, structure or ecosystem. What they leave open is the question of how an AI keeps changing the site without slowly breaking it.
Requirements
What a site run with AI actually needs.
- An edit button for people who do not code. Point at the thing, say what should change.
- Edits made from the site's own parts. The tenth page uses the same header, sections and buttons as the first, so a small request cannot rewrite the design.
- A draft and a preview. Nothing an AI does should reach visitors directly.
- A measurable quality check. Missing meta descriptions, slow pages and accessibility problems are found before going live, not weeks later in analytics.
- A person who publishes, and approval for anything hard to undo.
- Undo that works. Per change, per page, or for the whole site.
- HTML that search engines can read without running JavaScript.
How Caelo does it
The same seven points, built in.
| Need | In Caelo |
|---|---|
| Edit button | Live edit: point at an element on your site and describe the change in the chat next to it. Or use your own agent, such as Claude Code, over MCP. |
| Site's own parts | Every page is assembled from layouts, templates and modules styled by one theme. A page never holds raw HTML of its own. |
| Draft and preview | Every change lands in a draft; staging is a full noindex copy of the site. |
| Quality check | Lighthouse runs on staging for every changed page. Anything below 100, or a page without a meta description, blocks publishing until it is fixed or explicitly accepted. |
| Person publishes | Publish live is always a human click. Deploys, users, domains, themes, plugins, bulk deletes and URL moves wait for approval. |
| Undo | Every write is a snapshot. Undo a chat, or revert a page, a module or the site. |
| Readable HTML | The public site is static HTML, CSS and images from a CDN or Caddy. The editor runs on a separate, private address. |
We use it on this site. In today's quality check, the staged homepage of caelo-cms.com scored 100 in all four Lighthouse categories (median of five mobile runs). An article that scored 99 was held back until a person decided.
Moving in
Bringing an existing AI-built site into Caelo.
You do not start over. After you approve a crawl, the AI reads your existing site, rebuilds it page by page from Caelo modules, keeps page addresses and meta descriptions, sets up redirects where addresses change, and reports what it carried over. Homepage and the main page types come first, so you can check the design before the rest follows.
Hosting stays yours: Docker Compose on your own server, or your own Google Cloud project from about $14 a month. AI runs on your own provider key with cost caps, or on your own agent. Details are on Hosting and costs and Move your site.
Honest limits
When Caelo is the wrong choice.
- Your site is really an app. Logins with business logic, dashboards, a database of your own: keep it in code. Caelo runs websites, with plugins for forms, comments, ratings, newsletter and visitor login.
- You need a shop. There is no e-commerce in Caelo today.
- You need 1.0 today. Caelo is pre-1.0 and under active development. Expect rough edges.
- You are on AWS or Azure only. Both are planned, not available yet.
If none of that applies and your problem is the day after the build, Caelo was made for exactly that.
Next step
Keep building with AI. Stop babysitting the site.
Caelo is open source under MPL 2.0. Install it, connect your agent, and move one site over.