Website & digital presence
Website edits by chat
The opening hours are wrong, the new team member is missing, the price list is from last year. Not because it doesn't matter – but because the back end is intimidating and the fear of breaking something clicks along with you.
Website edits by chat
01Website edits by chat
Editing by chat turns that around: you write what should change – "we're now open until 2pm on Saturdays" – and get a proposal with a preview. Only once you approve does the website change. And only in the places meant for it: copy, opening hours, references, team, jobs. The structure, the design, the code – all of that stays untouchable. Breaking something isn't possible by design. That's how the website no one touches becomes one that stays current.
Straight up: this isn't a free AI agent tinkering with your website – that would be the dangerous part. Only defined fields change, only after your approval. And: the chat needs a clean underpinning (structured content in the CMS). Whether your website already has that is what the review settles – any needed rework is then part of the project, not fine print.
02Demo
The website of a fictional physio practice. Give one of the three instructions – on the right you see the preview, and only your approval makes the change “live”. Try the third one too.
physio münchner freiheit
Why nothing can break here: every command runs through a field check – only the approved content fields are reachable at all. And nothing is written until a human approves the preview. Everything else ends before that.
Two signals, two fates: the first is an allowed content change and runs all the way to the website. The second wants to touch the structure – and ends at the check.
03How it works
- 01
Decide what should be editable
Which content really changes regularly for you? Opening hours, team, references, prices, jobs, news – the list is usually shorter than you'd think, and exactly that becomes editable.
- 02
Bring the content into a clean data model
The editable content becomes structured fields instead of running text in a page builder. That's the foundation – and it also shows whether the existing CMS plays along or underpinning work is needed.
- 03
Connect the chat and draw the limits
The chat learns which fields it may change and which never. Every proposal comes with a preview: this is how the page would look. Nothing goes live without your okay.
- 04
Practise the approval flow
Who may edit, who approves? In a solo business that's one person and one click – in a team there are roles. The flow is fitted to your day-to-day, not the other way round.
- 05
Watch and extend
After a few weeks it becomes clear which changes actually come up. Then it's adjusted: new fields added, phrasing helpers refined, the log sharpened.
04Stages
The core problem – the fear of breaking something – can be solved before any chat at all. The tiers build on each other.
Entry: controlled editing without a chat
Cleanly structured CMS fields plus a short guide: you only ever change content, never structure. Often that solves the problem already.
Extended: the chat editor
Edits by chat for a few clearly bounded fields – with proposal, preview and approval. Copy, FAQs, opening hours.
Full build: several content types across the team
References, jobs, events, team – with roles and permissions, a change log and a draft mode for four-eyes approvals.
05Technical implementation
- Basic principle: an API layer may only change defined CMS fields – everything else is technically out of reach.
- The language model only generates change proposals; writing happens after your approval (tool calls behind confirmation).
- CMS to suit what's there: Webflow CMS/API, a headless CMS, a database or Markdown content – the chat sits in front of it, not inside it.
- Every change lands in the log: who, when, what – with the option to restore the previous state.
- Access by login only; a draft mode instead of direct publishing on request.
- Hosting: the existing website plus a small back end for chat and approvals.
for context · This shows how something like this usually gets built – not how it has to be built for you. What actually fits is worked out in the project: around your existing setup, your team, and what stays easy to maintain.