How Clients Can Edit Website Text Themselves: No Code, No CMS Dashboard

The Problem, Stated Plainly

A business owner needs the phone number on their website changed. They don't write code. Whoever built the site does — and is busy. So the edit becomes an email, the email becomes a ticket, and a thirty-second change takes a week.

If you search for a fix you'll find four families of answers. They're genuinely different, and the right one depends on how the site was built and who's supposed to stay in control. Here's the honest comparison.

Option 1: Rebuild on a Page Builder

Webflow, Framer, Squarespace, Wix. The client gets a visual editor and can, in principle, change anything.

Works when: the site is being built fresh, the design can live inside the builder's constraints, and "the client can change anything" is a feature rather than a threat.

Breaks down when: the site already exists as custom code (a rebuild is a project, not an edit), or when full visual control is exactly how layouts get broken. Most agencies have restored a builder site from a backup after a client "just moved one thing."

Option 2: Add a CMS and Give the Client a Login

WordPress on the traditional side; Sanity, Contentful, or Storyblok on the headless side. Content moves into a database, and the client edits it through an admin dashboard.

Works when: there's lots of structured, frequently-changing content — articles, listings, products — and someone whose job is editing it.

Breaks down when: the site is finished custom code (retrofitting means content modelling and wiring every component — we wrote up that trade-off in CMS Chat vs headless CMS), or when the client just needs occasional small edits and now has to learn field names, publish flows, and one more password.

Option 3: Edit-in-Place Overlays

Tools that let a client click text on the live page and retype it, saving the change to a proxy layer or injecting it with a script.

Works when: the changes are cosmetic and temporary — copy tests, quick campaign tweaks.

Breaks down when: you care where the change actually lives. The edit sits in a layer on top of the site rather than in its source, so the site's code and its content quietly diverge. The developer's repo no longer tells the truth about what's live.

Option 4: Chat-Based Editing on Top of the Repo

The newest family, and the one CMS Chat belongs to. The site stays exactly as built — custom code, in Git. The client doesn't get a dashboard or an editor. They get a chat box: "Change 'Worldwide' to 'International' in the homepage headline." The change is made in the site's actual source, as a Git commit the developer can see in their normal tools.

What makes this different from giving an AI free rein over a production site:

• Safe zones. The developer marks what clients may change: text, images, prices, links. Layout, code, and SEO-critical elements are off-limits.
• Escalation instead of failure. A request outside the safe zones doesn't get forced through — it goes to the agency's queue as a pull request, with the client's request attached in plain language.
• SEO guardrails. Before committing a change to a heading or title that ranks, the client sees the keyword, position, and traffic at risk.
• No new skill to learn. Typing "make the summer banner say 20% off" is the entire training manual.

Works when: the site lives in a Git repo (Next.js, Astro, Hugo, Nuxt, Eleventy, plain HTML) and an agency or freelancer wants clients handling routine text and image edits while keeping review and control.

Breaks down when: the site isn't in Git, or the client needs to restructure pages and layouts themselves — that's builder territory.

Choosing Between Them

| Your situation | Best fit | |---|---| | New site, simple needs, client wants full control | Page builder | | Lots of structured content, dedicated editors | CMS | | Temporary cosmetic tweaks | Edit-in-place overlay | | Finished custom-code site, occasional edits, agency stays in control | Chat-based editing on the repo |

For Agencies Specifically

The question usually isn't "can my client edit text" — any of the four options achieves that. It's "can my client edit text without me losing control of the codebase or spending hours training them." That's the version of the problem CMS Chat is built for: clients type what they want, edits land as commits in your repo, and anything risky comes to your team instead of going live.

CMS Chat is in private beta and onboards agencies in small waves. Put your agency in the next wave, or see how it works first.