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. One is running the project's build again and shipping whatever comes out. The other is replacing the files currently being served. While a project is under active development these arrive together, so nobody separates them. For a finished page they are not the same thing, and only the second is what you asked for.
Why they arrived fused has its own page: why the whole pipeline showed up in the first place. What a publishing loop should look like is answered in vibe deployment. This page is narrower: 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 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 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.
- Upload or drag-and-drop hosting. The unit is the folder. You hand over the output directory and the host replaces what it had.
- File-level hosting. The site is stored as addressable files, so 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. 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," and recommended generating the file during the build instead. Reasonable advice, and 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 what 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 pointing 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.
The model that avoids it has four steps:
- Look at the list of versions and find the one that is 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, one fragment, a rename, a deletion. When the change has to stay in one section, the boundary-shaped prompt names what to build, where it goes, and what must stay untouched.
- Publish the draft. That version becomes the live one.
Two properties do the work. The draft is a whole snapshot from the moment it exists, so files you never touch are already in it at the state they had when the site was last correct. You are editing a private copy that starts out identical to the live one. And nothing is public until you publish: visitors keep getting the live version however long the draft sits unfinished, while the draft gets its own address that opens for you when you are signed in.
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.
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
The most common follow-up, with four causes, roughly in order of how often each turns out to be the culprit:
Your browser cached it. A hard reload (Ctrl+Shift+R, or Cmd+Shift+R on a Mac) or a private window settles it in seconds, and should be the first thing you try.
Something between you and the site cached it. A CDN or proxy, usually Cloudflare sitting in front of the site, can serve a stale copy after the origin has the new file. A phone on mobile data will often show a different answer than your laptop.
You are looking at a preview link rather than the live address. They look almost identical and behave completely differently: a preview shows one specific version forever, the main address shows whatever is live.
The change was never published. Still sitting in the draft, and this one 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 sent, bookmarks and a custom domain pointed at the project all survive an update with no action from you. That is the common case rather than the rare one: across 2,400 projects the median site publishes twice more after it first goes live. A new address appears when you create a new site, 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 note about what changed. That is document version control applied to a page: the numbers and the kept copies come from the host, so nobody maintains a naming rule by hand.
When an update turns out wrong, the repair is not editing the mistake back out under pressure. It is making an earlier version live again. Rolling back changes which stored version is served: it deletes nothing, creates nothing, and does not touch the files on your machine. You can roll forward just as easily, which makes the whole thing much less frightening than editing live.
The honest limit is ten versions. Older ones drop out of the list and can no longer be restored, though their preview links keep opening for you. Generous for a landing page, thin for a site somebody edits daily.
When editing files is the wrong answer
Three situations where this approach is the wrong tool.
Somebody else does the editing. The version of the question people actually ask most: how does a client keep their own site current without a developer on call? If the person changing the text should not be near the files, you want a content management system. That is what WordPress and the headless CMS category exist for.
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.
The project owns a database, accounts or server-side code. A different object with different operational requirements.
There is also a plain limit on what a static host serves. Images and fonts publish and serve normally; video and PDFs generally do not, so they 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 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. Static sites only, so the third case above is not one we handle.
Edit in Birta's chat or with your own agent
Describe the change in Birta's chat and its agent edits and publishes it. Or make it with the agent you already use.