Blog

Ask, Don't Click: Updating Your Website by Describing the Change

Updated June 12, 2026

Ask, Don't Click: Updating Your Website by Describing the Change

Ask, Don't Click: Updating Your Website by Describing the Change

Product media placeholder

Replace this area with a screenshot or short walkthrough video during the media sweep.

💡

Quick answer: You can update your website by describing the change in workspace chat — but the quality of the result tracks the quality of the ask. A good ask names the page and section, states the change, gives the business reason, and says what to leave alone. The AI returns a draft; you review it in the editor, preview both screen sizes, and approve. Describing replaces the clicking, not the judgment.

For twenty years, changing your own website meant choosing between two taxes: learn the editor (and relearn it every redesign), or queue behind a developer for a two-line copy change. Most small-business sites are out of date not because owners don't care, but because the cost of a small change has always been absurdly larger than the change.

That cost just collapsed. In a Faster workspace you ask for the page change — copy, sections, CTAs, layout, SEO — and review a draft instead of building one. This post is the craft of asking well: the anatomy of a good request, real prompts you can steal, and the review loop that keeps "AI edited my website" from ever being a scary sentence.

Why describing beats clicking

When you start from chat, you start from the business outcome — "I raised my prices," "the fall offer is live," "people keep asking if we do weekends" — and the AI translates that into the page edits, with your site's existing copy, structure, and brand voice as context. You were never going to enjoy hunting for the right block in an editor; the AI doesn't mind, and it doesn't miss the second place the old price appears.

The catch — and it's the whole craft — is that the AI can only be as specific as your ask. Vague requests produce plausible-but-generic drafts. Specific requests produce drafts you barely touch.

The anatomy of a good ask

Every strong page-change request has four parts:

  • Where — the page and section, named. Better yet, mention the page directly so the AI is scoped to it.
  • What — the change, concretely. "Rewrite the headline" is weaker than "rewrite the headline to lead with same-day service."
  • Why — the business goal. The reason shapes a hundred small word choices you'd otherwise have to correct.
  • What not to touch — the constraint. "Keep the testimonials and the photos" turns a risky rewrite into a scoped one.

Real prompts, weak and strong

Updating copy after a business change

Too vague

"Update the services page, our prices changed."

Which prices? To what? The AI has to guess or ask — either way you've saved nothing.

Works first try

"On the services page, change the deep-clean price from $180 to $210 and the move-out clean from $260 to $295. Update the price anywhere else it appears on the site. Don't change any descriptions."

Exact values, site-wide consistency requested, scope fenced. The "anywhere else it appears" line is the one a manual edit always forgets.

Adding a section

Works first try

"Add an FAQ section near the bottom of the booking page answering the five questions customers actually ask: do you do weekends, how far do you travel, what's included, cancellation policy, and whether products are pet-safe. Pull the cancellation wording from the policy on the about page so they match. Use a placeholder image note for a team photo."

Real questions beat invented ones, the cross-page consistency is explicit, and the placeholder media keeps the draft moving before the photo exists.

Sharpening a call to action

Works first try

"The homepage hero button says 'Learn More' and goes to the about page. Change it to 'Check Available Dates' and point it at the booking page. Adjust the sentence above it so the button feels like the obvious next step. Nothing else on the hero changes."

States the current state, the target, and the one supporting edit allowed. Constraints are what make AI edits reviewable in seconds.

SEO without the jargon

Works first try

"My weekly analytics shows people find the lawn-care page searching 'lawn aeration [town]' but the page barely mentions aeration. Rework the page title, description, and the intro paragraph to lead with aeration for our town, keeping the rest of the page as is."

Evidence-driven — straight out of the fifteen-minute analytics ritual — and scoped to the SEO fields plus one paragraph.

The seasonal swap

Works first try

"Swap the homepage promo banner from the spring tune-up offer to the summer AC special: $89 inspection, booked by July 15. Same layout and style as the current banner. Archive nothing — I'll want the spring banner back next year."

Recurring changes like this become one-sentence requests once the pattern exists — the AI has last season's banner as its template.

The review-and-approve loop

The help guide's rule is the whole safety model: AI output is a draft until a human reviews it. The loop that makes asking trustworthy:

  1. Read the draft in the website editor — in place, with the real page around it, not as a chat reply you skim.
  2. Check the specifics against the source of truth — prices, dates, claims, links — the same seven-point pass from our approval workflow post. AI's failure mode is confidently wrong details, not bad grammar.
  3. Preview both screen sizes. A section that's elegant on desktop can stack badly on a phone; the preview is where you find out, not your visitors.
  4. Publish through the safe-publish review — or, for bigger work, do the whole thing on a branch with checkpoints: the multi-page restructure, the rebrand pass, anything you'd want to review as a set and merge once. Checkpoints also mean any change can be walked back — which is what makes delegating edits to AI psychologically cheap. (The deeper machinery behind that confidence is its own story: our guardrails post.)

When clicking is still right

Describing replaces production, not taste. The editor remains the right tool when the change is the looking: nudging spacing until a section breathes, choosing between two photos, judging whether the new headline sits right over the hero image. The pattern across the whole workspace — page edits, motion, translations — is the same division of labor: AI does the authoring, you do the directing. Ask for the change, then put your eyes — and only your eyes — on the result.

Key takeaways

  • Describe page changes from the business outcome: the AI translates them into scoped edits with your site as context.
  • A strong ask has four parts: where, what, why, and what not to touch.
  • Exact values and "everywhere it appears" beat vague nouns: constraints make drafts reviewable in seconds.
  • Run the review loop: read in the editor, verify specifics against the source of truth, preview both screen sizes, publish through the safe-publish flow.
  • Use branches and checkpoints for multi-page work: reversibility is what makes delegation cheap.
  • Keep clicking where the change is the looking: describing replaces production, not taste.

Frequently asked questions

What if the AI changes something I didn't ask it to change?

Scoped asks prevent most of it — that's what the "what not to touch" line is for — and the review step catches the rest before anything publishes. If a draft oversteps, say so plainly ("you also reworded the testimonials — put them back") and the revision narrows.

Do I need to write prompts in some special format?

No — plain sentences are the format. The four-part anatomy isn't syntax, it's just completeness: where, what, why, what stays. Write it the way you'd brief a capable assistant on their first week.

Can I ask for several changes at once?

Yes, and for related changes you should — "raise all three prices and update the FAQ answer about deposits" keeps the site consistent in one pass. For unrelated changes, separate asks keep each draft easy to review. If it would be two tickets for a developer, make it two asks.

How do I undo an AI change after publishing?

Every change is checkpointed, so rolling back is a saved-state restore, not an archaeology project. For anything big enough that you'd be nervous, do it on a branch first and merge after review — then the question never arises.

Will AI-written copy sound like me?

It drafts from your existing pages and your workspace's stored voice context, so it starts closer than you'd expect — and your edits teach it. The first month you'll tweak the tone; by the third, you mostly approve. Keeping a short voice note in workspace memory ("plain words, no exclamation points, prices always visible") accelerates that curve.

The next time you notice the website is out of date — the price, the hours, the offer that ended — don't open the editor and don't email anyone. Say the change out loud, the four-part way, and spend your two minutes on the review instead of the clicking.

Was this guide helpful?

Sunny Arora

Written by

Sunny Arora

Get technical deep dives delivered to your inbox

Join creators and developers who get exclusive insights, tutorials, and behind-the-scenes content every week.

No spam. Unsubscribe anytime.