You can change a live site without republishing all of it, but only if your host stores the site as files you can edit in place. Most do not. Where that path exists, an update looks like this: take the version that is currently live, change the one file, publish that. Everything you did not touch travels along unchanged, and the address stays exactly where it was. If the page still looks old afterwards, that is almost always caching rather than a failed update.
What "redeploying" actually means for a finished site
Two different actions share the word.
The first is running the project's build again and shipping whatever comes out. The second is replacing the files that are currently being served. While a project is under active development these arrive together, so nobody bothers to separate them. For a page that is finished they are not the same thing at all, and only the second one is what you were asking for.
Why they arrived fused is a longer argument, and it has its own page: why the whole pipeline showed up in the first place. What a publishing loop should look like is a separate question too, answered in vibe deployment. This page is narrower. It is about what mechanically happens when you change something on a site that is already live.
Can you change one file without republishing the whole site?
It depends entirely on what your host treats as the smallest change it can accept.
- Git-backed hosting. The unit is a commit. On GitHub Pages, or anything else wired to a repository, a one-word typo fix runs the same build as a redesign, because the build is how the host learns anything changed at all.
- Upload or drag-and-drop hosting. The unit is the folder. You hand over the output directory, and the host replaces what it had with what you gave it.
- File-level hosting. The site is stored as addressable files, so a single one can be read and changed without restating the rest.
The first two are far more common, and the people who run them say so plainly. In September 2021 someone asked on the Netlify support forum: "Is it possible to update this JSON file on your live site without having to redeploy the entire site twice?" The reply from coelmay opened: "Short answer is no." The recommendation that followed was to generate the file during the build instead — reasonable advice, and also a clear statement that the smallest thing you can change is the site.
There is a real objection to the alternative, and PreviewSend states it well: "Upload the complete build output. Replacing one file by hand leaves old assets behind and mismatched with the new HTML, which is how half-updated pages and broken styles happen."
That is correct, and it is the thing a file-level path has to answer.
What editing a live site looks like from the inside
Patching a live site by hand really does produce half-updated pages: an HTML file that now points at a stylesheet the server no longer has. The fix is not to be more careful. It is to never let a half-state reach the public address at all.
The model that avoids it has four steps:
- Look at the list of versions and find the one that is currently live.
- Create a new version from it. It starts as a draft, and a draft is a complete copy of the version it came from, not an empty folder.
- Change what you need inside the draft: one file, or one fragment of one file, or a rename, or a deletion. When the change has to stay in one section, the boundary-shaped prompt is the one to reach for: it names what to build, where it goes, and what must stay untouched.
- Publish the draft. That version becomes the live one.
Two properties do all the work here.
The draft is a whole snapshot from the moment it exists. Files you never touch — stylesheets, images, fonts — are already in it, at the state they had when the site was last correct. You are not patching a live folder. You are editing a private copy that happens to start out identical to it.
Nothing about it is public until you publish. Visitors on the live URL keep getting the version that is live now, however long the draft sits there unfinished. The draft gets its own address, which opens for you when you are signed in, so you can look at the change before it replaces anything.
So both answers are true at once. Yes, you can change a single file. And yes, replacing one file on a live site is a bad idea — which is why the file is what you edit, and the version is what you publish. Those being different things is the whole trick.
When the change comes from a prompt
If the tool that built the site is still connected to it — and how that connection works is an open standard rather than a trick — this is what "make the headline shorter" turns into. It does not resend the site. It reads the part of the file it needs, replaces that fragment, and publishes the resulting version. Images and fonts travel the same way, so asking for a different picture on the page does not send you off to find somewhere else to host it.
That is the loop people are describing when they say they want to edit by prompting rather than deploying. Worth being precise, though: the word "deploy" has not disappeared. Something is still checked and still published. What disappeared is having to restate the entire site in order to change part of it.
If none of this is live yet, publishing it the first time is its own short procedure. The Claude Code guide walks through it end to end.
Why you still see the old page
This is the most common follow-up, and there are four causes. Roughly in order of how often each one turns out to be the real culprit:
Your browser cached it. A hard reload (Ctrl+Shift+R, or Cmd+Shift+R on a Mac) or a private window settles this in seconds, and should be the first thing you try before assuming anything went wrong.
Something between you and the site cached it. A CDN or a proxy — Cloudflare sitting in front of the site is the usual one — can keep serving a stale copy after the origin already has the new file. Some networks are more aggressive than others, and a phone on mobile data will often show you a different answer than your laptop.
You are looking at a preview link rather than the live address. These look almost identical and behave completely differently. A preview link shows one specific version forever; the main address shows whatever is live. It is very easy to keep refreshing a preview of the version you started from.
The change was never published. It is still sitting in the draft. This is the one that costs people the most time, because everything feels done.
The first two are worth preventing rather than diagnosing repeatedly. Give assets filenames that include a hash of their contents so a changed file is a new name, and keep the cache lifetime short on the HTML that references them.
The address stays the same
Publishing into a project you already have does not mint a new URL. PreviewSend puts it exactly right: "The URL belongs to the destination, so the files behind it change while the link stays put."
Links you have already sent out, bookmarks, and a custom domain pointed at the project all survive an update without any action from you. A new address appears when you create a new site, not when you change one you already had — which is the same question read from the other end as why an artifact never gets one.
Undoing an update instead of editing it back
Every successful publish is kept as a numbered version with its date and, if you supplied one, a short note about what changed.
When an update turns out to be wrong, the repair is not to edit the mistake back out under pressure. It is to make an earlier version live again. Rolling back changes which stored version is being served: it does not delete the newer version, does not create another one, and does not touch the files on your own machine. You can roll forward again just as easily, which makes the whole thing much less frightening than editing live.
The honest limit is that the list holds the last ten versions. Older ones drop out of it and can no longer be restored, though their preview links keep opening for you. Ten is generous for a landing page and thin for a site somebody edits every day, so it is worth knowing which of those you have before you rely on it.
When editing files is the wrong answer
Three situations where this whole approach is the wrong tool, and pretending otherwise would waste your afternoon.
Somebody else does the editing. This is the version of the question people actually ask most often: how does a client keep their own site current without a developer on call? If the person changing the text is a client or a colleague who should not be near the files, you want a content management system. That is what WordPress and the headless CMS category exist for, and a file-level edit path is not a substitute for one.
The content updates itself. Live scores, a stock feed, anything that has to be current without a human deciding so — that needs a data source the page reads, not a file somebody republishes. No editing workflow, however short, solves a problem that is really about where the data lives.
The project owns a database, accounts, or server-side code. Then it is a different object with different operational requirements, and it deserves them.
There is also a plain limit on what a static host will serve at all. Images and fonts publish and serve normally; video and PDFs generally do not, so they still need a public URL of their own. If you are unsure what counts, what actually travels with the page covers it.
Birta is built around the loop described above: a connected tool edits the files of a site that is already published, each publish is kept as its own version, a bad change is undone by making an earlier version live again, and your own domain points at it whenever you want it to. Static sites only — the third case above is not one we handle.
Edit through the same connection you published with
Every publish is kept as its own version, so a change that turns out wrong is one click from being undone.