How to Edit a Static Website With Claude Code, Step by Step

Put the site's source in a Git repository, install Claude Code, open it in that repository, give it one narrow instruction, review the diff it produces, run the site locally, then deploy through your host's Git integration — a revert undoes it if something's wrong. That's the whole shape of the workflow. The rest of this guide is the concrete steps, with a real example.

This is the reproducible setup for "Route 1: let a coding agent edit the repository," the first of three routes covered in our broader guide, how ChatGPT, Claude, Codex or Cursor can edit an existing website. That post compares routes; this one is the walkthrough for the repository route specifically, using Claude Code as the example tool.

What do I need before I start?

A Git repository containing the site's actual source — not a folder of rendered HTML pulled from "View Source" in a browser, but the files that build the site: plain HTML/CSS/JS, or a static-site generator's source (Markdown content plus templates, for something like Eleventy, Hugo, or Astro). If your site currently lives inside a hosted builder with no code export, this route doesn't apply yet; see our export capability matrix for what you can actually get out of a given builder first. If your generator needs a build step, have Node.js (or whatever the generator needs) installed so you can run that build locally.

How do I install Claude Code and open my project?

Claude Code's own quickstart gives the current install command for macOS, Linux, and WSL: curl -fsSL https://claude.ai/install.sh | bash (Windows has its own PowerShell and CMD variants) (Claude Code Docs, "Quickstart", checked September 2026). Confirm it worked with claude --version. Then open your repository and start a session:

cd /path/to/your/site
claude

You'll be prompted to log in on first use with a Claude subscription or Console account (same source). Claude Code "reads your project files as needed" — you don't have to paste in the codebase yourself (same source).

How do I give it a scoped instruction?

Name the exact file or page, the exact change, and what must stay untouched. A vague "make the homepage better" invites a wider diff than you wanted. For example: "On index.html only, change the hero heading from 'Welcome' to 'Book a consultation today'. Do not change any other file, the navigation, or the footer. Show me the diff before you do anything else."

Example (hypothetical): A consultant runs a static site built with Eleventy, source in a GitHub repository, deployed via Netlify. She opens Claude Code in that repository and types: "On src/pricing.md, replace the paragraph under the 'Hourly Rate' heading with this text: [pasted text]. Don't touch the layout template or any other content file. Run npm run build afterward and tell me if it fails." Claude Code locates the file, makes the edit, and reports the build result — she still reviews the diff and the rendered page herself before anything ships. This is illustrative only, not a test we ran.

How do I review the change before anything ships?

First, know which permission mode you're in, because it decides whether you're asked before each edit. Claude Code's quickstart says auto mode is the built-in starting mode for interactive terminal sessions on Pro, Max and Team plans: "a classifier reviews actions instead of you, and Claude edits most files and runs most commands without asking you." On other plans, Manual mode is the starting mode, and it asks before file edits (Claude Code Docs, "Quickstart", checked September 2026). Press Shift+Tab to switch modes for the session; for a first edit on a live site, Manual mode is the calmer choice (Claude Code Docs, "Configure permissions").

Whatever the mode, Git is your real checkpoint: nothing reaches the live site until you commit and push. Before committing, run git diff and read which lines changed, not just which files.

Then run the project's own build or test command yourself (npm run build, hugo, or whatever your generator uses) and open the result at a real screen width, not just trust that the diff looks reasonable. A change that looks like one line in a template can affect every page that uses it.

How do I deploy through my host's Git integration?

Commit the change, push it, and let your host's Git integration build and publish it — don't hand-copy files to a server. Using Netlify as one concrete example of how a Git-connected host works: pushing to your repository triggers a new deploy, and Netlify holds every change until it's fully ready — "No changes go live on your site's public URL before all changes have been uploaded. Once all the changes are ready, the new version of the site immediately goes live on the CDN" (Netlify Docs, "Deploy overview", checked September 2026). A merge to your configured production branch triggers a production deploy; other branches can be configured for their own preview URLs (same source). GitHub's protected-branch settings can require a review and passing checks before that merge happens at all, which is exactly the checkpoint you want between "Claude Code proposed a diff" and "the diff is live" (GitHub Docs, "About protected branches", checked September 2026).

How do I roll back if something's wrong?

Two different rollback tools exist here, and it's worth knowing which one you need. For a code-level mistake — the change itself was wrong — revert the commit with git revert, which creates a new commit undoing the change, and push that; your host's Git integration then deploys the reverted state the normal way. For a deploy that's simply the wrong version to have live right now, some hosts offer an instant switch instead of a rebuild: Netlify's own documentation describes "Publish Deploy" as a button that "doesn't trigger a new deploy but instead publishes a previous atomic deploy that is still available to you. Rollbacks are instantaneous" (Netlify Docs, "Manage deploys", checked September 2026) — but that same page warns that "if your Netlify site is connected to a Git repository and has auto publishing turned on, any new Git-triggered production deploys will overwrite the previously rolled back version" (same source), so it's a stopgap, not a substitute for fixing the repository. Either way, record which commit was live before you started, so "back to before" has a concrete answer.

What are the real limitations here?

• This is the repository route only. If your site is a hosted builder with a closed editor and no code export — Wix, Squarespace, Framer, and similar — there's no repository for Claude Code to open. See can ChatGPT, Claude, Codex or Cursor edit an existing website? for the browser-agent and API routes that apply there instead.
• A rendered HTML dump is not a working source. If you only have a copy of the final HTML output (from "Save Page As" or a crawler), you're missing the templates, build process, and often the working links between pages. Rebuilding from that is a bigger job than editing an existing generator's source.
• Your plan may start you in auto mode. On Pro, Max and Team plans Claude Code edits most files without asking unless you switch to Manual mode, so the git diff review before committing is the step that can't be skipped.
• A deploy is a separate, later step from a saved file. Nothing here auto-publishes; the Git push and the host's own build are what make a change live, which is also exactly where the checkpoint for review belongs.
• Give it limited access. Point Claude Code at the one repository the task needs rather than a broader directory holding unrelated projects or credentials; see how to give an AI agent access to your website for the general access-scoping version of this advice across platforms.

How do I verify the result?

• Check which permission mode the session is in, and read git diff before committing.
• Run the project's own build/test command locally and confirm it passes.
• Open the changed page at desktop and mobile widths before pushing.
• Push to a branch first if your host and repository support preview deploys, and check that preview before merging to production.
• After the production deploy, open the live page — not just the local preview — and confirm the change is actually there.
• Record the commit hash that was live before the change, in case you need git revert.

Bottom line: The setup that makes editing a static site with Claude Code safe isn't exotic — a real Git repository, one scoped instruction, a diff you actually read, a local build check, deployment through your host's own Git integration, and git revert (or your host's instant rollback) as the way back. The mechanism is the same one any developer already uses; Claude Code just does the file-finding and the first draft of the edit.