How to Update Your Website by Just Asking

The hard part of owning a small website was never getting it built.

It was the Tuesday six months later when your prices changed, your hours moved, or the phone number on the site was one job old. The site was done, the person who built it had moved on, and a two-line change meant an email, a wait, and often an invoice. So the change did not happen, and the site quietly went stale.

Stale is worse than plain. A visitor forgives a simple site. A visitor who drives to your shop because the site said you were open does not forgive the site.

That maintenance trap is what conversational editing removes. On Nanopage, updating your site works the same way building it did: you say what changed, in plain language, and the site changes.

What the editing loop looks like

Every Nanopage site has an editing chat in the dashboard. An update is a short loop:

1. Open your site in the dashboard.
2. Type what you want changed, the way you would text a colleague.
3. Wait a moment while the site is rebuilt.
4. Review the result.
5. Publish it, or ask for another adjustment.

There is no page builder to learn, no blocks to drag, no CMS field hunting. The message is the interface.

Real messages look like this:

• "We're closed Mondays now. Update the hours."
• "Change the phone number to 0141 555 0192 everywhere it appears."
• "Add a new service: gutter cleaning, from £90, and mention we do it year-round."
• "Replace the headline photo with the one I just uploaded."
• "Winter menu: remove the gazpacho, add pumpkin soup at 6.50."
• "Add a section for the March workshop with a sign-up link to this URL."

None of these require knowing where in the code the old value lives. Saying what changed is enough.

Why this beats doing it yourself in a page builder

Drag-and-drop builders promised the same freedom, and for the initial build they mostly deliver. The problem shows up at edit time.

Six months after launch, you do not remember which template you used, which block the hours live in, or why moving one section breaks the spacing of another. Every small edit starts with fifteen minutes of relearning the tool. That friction is small, but it is paid on every single change, so changes stop happening.

A conversation has no relearning cost. The way you asked for the site in January is the way you update it in July. You never open a layout editor, so you cannot break the layout. And because the change is described in your words, the site's text stays in your voice instead of drifting into whatever you managed to make the editor do.

The comparison with hiring someone is even simpler: the middleman loop of email, wait, revise, invoice is replaced by a message and a minute. That was the argument of The Middleman Is Gone, and it applies double to maintenance, because maintenance is where the middleman was most expensive relative to the size of the change.

How to ask for changes that come back right

Editing by chat rewards the same habit as building by chat: say what you want, concretely. A few patterns help.

State the change, not the mechanism. "Make the opening hours easier to find" works better than guessing at implementation, like "move the third section up and make the font bigger." Describe the outcome and let the builder decide how.

Give exact values for facts. Prices, dates, times, addresses, names, and links should be spelled out exactly as they should appear. "Update the hours" invites a wrong guess; "open Tuesday to Saturday, 9 to 17, closed Sunday and Monday" does not.

Say "everywhere" when you mean everywhere. If your phone number appears in the header, the contact section, and the footer, ask for it to be changed everywhere it appears, so no stale copy survives.

Batch related changes into one message. "Three updates: new Saturday hours 10 to 14, add Maria to the team section, remove the Christmas banner" is one rebuild and one review, instead of three rounds.

Keep taste changes separate from fact changes. Facts are quick to verify. "Make it feel warmer" needs your judgment on the result. Doing them in separate rounds keeps each review easy.

Review before you publish

An AI builder is fast, not infallible. The loop has a review step, and you should actually use it, especially for facts.

After a change, check three things:

1. The thing you asked for is there and exact. Read the new price or date character by character.
2. Nothing nearby changed that should not have. Skim the section around the edit.
3. The page still works on your phone, since that is where most visitors are.

This is thirty seconds of proofreading, the same as rereading an important message before sending it. It replaces the old code review, staging server, and deployment email chain. Nothing goes live until you are happy with it.

Make updating a habit, not a project

Because changes are cheap now, the winning strategy is many small updates instead of one big overhaul a year.

A useful rhythm for a small business:

• When a fact changes, update the site the same day. Hours, prices, phone, staff. These are one-message fixes, and they are the difference between a site people trust and a site people learn to ignore.
• Once a month, skim the whole page. Read it as a stranger. Anything out of season, sold out, or no longer true gets one message.
• When you notice a pattern in questions, add the answer. If three customers ask the same thing this week, the site should answer it by next week.
• After you see your stats, adjust. If your analytics show visitors landing on the menu but calling to ask about parking, add a parking line near the top. Your built-in analytics tells you what people look at; the editing chat lets you act on it the same afternoon.

None of these are projects. Each is one message. A site maintained this way stays accurate by default, which is something the old model never achieved at small-business scale, at any price.

What about bigger changes?

The same loop handles more than housekeeping.

You can ask for a new section, a reorganized page, a different tone, or a seasonal redesign the same way you ask for a new phone number. Bigger asks benefit from a bit more brief: what the change is for, what must stay, and what can go. The website brief template works for revisions just as well as for first builds.

And because publishing is a separate step, you can iterate on a bigger change over several rounds and only publish when the whole thing is ready. Your visitors never see the drafts.

The short version

The expensive part of a website was never the launch. It was every change after the launch.

Conversational editing turns each change into a message:

• Open the editing chat, say what changed, in plain words.
• Give exact values for prices, hours, dates, and contact details.
• Ask for facts to be updated everywhere they appear.
• Review the result, then publish.
• Fix facts the day they change; skim the whole page monthly.

The site you launch in one day is easy. The site that is still accurate a year later is the real advantage, and now it costs a sentence at a time.