How Claude Code Edits a Website: What Changes When Your Site Lives in Git

When people hear that a website can be “edited by Claude Code,” they often picture an AI loose in their admin panel. The reality is calmer and more controlled than that. This post walks through what actually happens when an agent edits a site that lives in git, and the guardrails that make it safe.

The site is a folder of files

On a code-based site, built with a framework such as Astro, the whole website lives in a repository: a folder of files tracked by git.

• Pages are files, often one per URL.
• Blog posts are Markdown files with a block of details at the top: title, description, date, tags.
• Design lives in components, small reusable building blocks such as a header, a pricing table or a call to action.
• Settings such as redirects and site metadata are plain configuration files.

Nothing is hidden in a database. That is the key difference from a traditional CMS, and it is why an agent can work on the site so effectively: it can read everything, search everything, and change anything in plain text.

The instructions file sets the rules

Claude Code reads a project instructions file, usually named CLAUDE.md, at the start of every session. This is where your team writes down how the site works and what the agent should and should not do.

A good instructions file for a marketing site covers:

• Voice and copy rules, such as banned phrases, punctuation preferences and reading level.
• Content structure, for example that every blog post needs a description of a certain length and a call to action halfway through.
• Design rules, such as which components to use and which colours and fonts are allowed.
• Boundaries: files the agent must never change, like legal pages or tracking scripts.
• The publishing process: build the site, fix any errors, and open a branch for review.

Because the file lives in the repository, it improves over time. When a reviewer corrects the same thing twice, the fix goes into the instructions, and the agent stops making that mistake.

What an edit looks like, step by step

Here is a typical request and what happens next.

A marketer asks: “Add a three-question FAQ to the enterprise pricing page about security reviews, in our usual tone, and link to it from the main navigation.”

1. The agent reads the instructions file and the relevant files: the pricing page, the navigation component, and a few existing FAQ sections to match their style.
2. It makes the changes across those files.
3. It runs the build. If anything breaks, such as a broken link or a malformed component, it fixes the problem and builds again.
4. It commits the change to a new branch, not to the live site.
5. The host creates a preview. Platforms like Vercel and Netlify build a private preview link for every branch.
6. A person reviews and approves. Once the change is merged, the live site updates in a minute or two.

The person never had to find the right screen, remember which template controls the navigation, or wait on a developer.

The guardrails that keep it safe

Letting an agent edit your website sounds risky until you look at how much control git gives you. The setup we recommend has four layers.

Guardrail	What it does
Branches only	The agent never changes the live site directly. Every edit lands on a separate branch.
Build checks	The site must build cleanly before a change can be merged, which catches broken links, bad formatting and missing fields.
Preview links	Every branch gets its own private preview, so a person sees the change exactly as visitors would.
Full history	Every change is recorded. Anything can be compared, explained or rolled back in seconds.

On top of that, you can limit what the agent is allowed to run, and keep anything sensitive, such as form endpoints or API keys, out of the files it edits.

Where the time savings come from

Single edits are faster, but the real gains are in work that is tedious or impossible in a CMS.

Bulk edits. “Rewrite the meta descriptions on every post older than a year so they reflect current pricing.” In a CMS, that is hours of clicking. In a repository, it is one request and one review.

Consistency fixes. “Find every page that still uses our old product name and update it.” The agent can search the entire site at once and show every change in a single preview.

Scheduled work. An agent can run on a schedule to check for broken links, refresh outdated statistics, or publish articles from an AI content system, always through the same review gate.

Structured content for AI search. Adding FAQ sections, comparison tables or schema markup across a site helps assistants like ChatGPT and Perplexity understand and cite your pages, a core part of generative engine optimization.

What still needs a person

An agent is fast, but it does not know your business the way your team does. People still need to:

• Decide what to change and why.
• Review previews, especially anything involving pricing, legal claims or customer data.
• Keep the instructions file current as the brand and the site evolve.

The shift is from doing the edits to directing and approving them.

Getting started

If your site is already code-based, start by writing a short instructions file and trying a few low-risk edits on a branch. If it is on WordPress or another CMS, the first step is deciding whether a move is worth it. Our guide on whether to migrate from WordPress to Claude Code walks through that decision.