How to update a static website without changing its URL

To update a static website without changing its URL, deploy the new build to the site or project you already have instead of creating a new one. Rebuild your files, check the output, upload or push it in place, then reload the live address to confirm the new version is serving. The URL belongs to the destination, so the files behind it change while the link stays put.

When an update seems to have failed, check two things first: whether you created a second site by accident, and whether the browser is showing a cached page.

Does the URL change when you redeploy?

No, as long as the new build goes to the same destination. A static host serves whatever files currently sit behind an address; the address itself is a property of the site or project, not of any single upload. Deploy again into that same site and the link is unchanged.

The URL changes only when you point it somewhere new. Create a fresh site for the revision, or spin up a new project per build, and you get a new address every time, which is exactly what leaves two links in the same email thread. Netlify frames its own flow as updating production by deploying to the existing site; Cloudflare Pages Direct Upload reuses the existing project's values on later deploys rather than minting a new one. Both preserve the project address across later deploys.

Some platforms do let you rename or rotate a URL on purpose. That is a deliberate action, not a side effect of shipping a new build, so a routine update to the same destination should keep its address.

Update the site you already have, not a new one

The core move is to send the new build to the destination that owns your current link. How you do that depends on the host:

• Drag-and-drop hosts. Netlify and Cloudflare Pages let you drop a new build folder onto the existing project. On Netlify you deploy over the production site; on Cloudflare each Direct Upload becomes a new deployment of the same project. The pages.dev or site URL you already shared keeps serving.
• Git-backed hosts. Push to the branch the site tracks. GitHub Pages, Netlify, and Cloudflare Pages rebuild and republish at the same address. The commit is your version record.
• Upload-based previews. On PreviewSend, you upload the revised ZIP as a new version of the same project, and the project URL serves it once the upload finishes. Eligible first-time owners get a one-time 14-day Pro trial on their first workspace, no card required; otherwise Free limits apply.

Whichever you use, deploy the build output, not the source. Zipping or pushing a project root can leave a host staring at raw .jsx files or an out-of-date dist/. If you are unsure which folder is the compiled output, turning a folder or ZIP into a live URL covers where each tool writes its build and how to lay the archive out.

On PreviewSend, an upload has to finish and validate before it becomes the active version. The upload creates the next version, and the project only switches to it after that version finalizes as a newer, ready build. A ZIP that fails validation does not replace what is already live, so a bad upload leaves the current link working rather than breaking it.

A release checklist that keeps the URL fixed

Use this sequence each time:

1. Rebuild from source. Run the project's build command, such as npm run build, so the output reflects your latest changes rather than a stale folder from last week. Verify: the output folder has a fresh index.html and current assets.
2. Preflight the output locally. Serve the build folder and click through it signed out. Verify: pages load, internal links work, and the console is clean before anything ships.
3. Save the build you are replacing. Copy the previous build, or the ZIP you last uploaded, somewhere safe. Verify: you have a known-good archive you could re-deploy if the new one misbehaves.
4. Deploy into the existing site or project. Push, drop, or upload to the destination that owns your current URL, never a new one. Verify: the deploy targets the same project name and address you shared.
5. Confirm the live URL, not your local copy. Open the real link, ideally in a private window, and check the change you shipped is actually there. Verify: the change is visible on the deployed address.

The version behind the link is the one your client, a bookmark, or a shared message will land on, so the last thing you check is the live URL rather than localhost.

Why you still see the old page

You deploy, open the link, and it looks exactly like before. Check caching before you upload the same build again. Browsers and networks hold onto files to load pages faster, so an old copy can linger after the server already has the new one. MDN's guide to HTTP caching explains how that storage and revalidation works.

Confirm it in a few seconds:

• Hard refresh. Reload with cache disabled: Ctrl+Shift+R on Windows and Linux, Cmd+Shift+R on a Mac.
• Try a clean context. Open the URL in a private window or a browser you have not used for the site. No stored copy means you see exactly what a first-time visitor sees.
• Check the actual response. In DevTools, the Network tab shows whether a file came from disk cache or from the server, and what Cache-Control header it carries.

If the private-window page is correct and only your normal window is stale, the deploy worked; the fix is on the caching side. For future updates, use content-hashed asset filenames. When your build tool renames files by content, like index-a1b2c3.js, a changed file gets a new URL the browser has not cached. MDN recommends versioned or hashed URLs for long-lived cached files. Keep the HTML that references those assets on a short cache so it can pick up new filenames promptly. A hard refresh is a useful immediate check, but it does not replace correct cache headers.

Recovering a previous version

A build can ship with a broken layout, or a change can turn out worse than what it replaced. Plan the recovery before you need it.

Recovery depends on the host. Cloudflare Pages, for example, documents rolling a project back to a previous production deployment. Other hosts expect you to deploy an older build again. Either way, keep a copy of every build you ship. On a Git-backed host, the previous commit is also a re-deployable record you can check out and publish again.

PreviewSend keeps earlier uploads in version history, bounded by plan retention (three versions on Free, ten on Starter, twenty on Pro, and unlimited on Agency). Retention is a history policy, not a rollback control: there is no one-click reactivate today. To bring an old build back, re-upload your saved copy as a new version, and it becomes active like any other successful update. On Pro, Agency, and an active Pro trial, a file-level version diff can show what changed between two retained versions before you decide, though that comparison is not available on every plan.

Comments and approvals move with none of this automatically. They are bound to the version they were left on, so a new upload starts a clean comment set rather than inheriting the last round's notes. If a review is mid-flight, resolve or export the current comments before you replace the build.

Where a stable preview URL fits

For a public production site, deploying in place on Netlify, Cloudflare Pages, or a Git host is a direct fit. A client-facing draft may also need one link you keep updating, feedback attached to the page, and indexing controls. The client preview workflow covers that review loop without requiring the client to create an account to comment. PreviewSend accepts a static bundle that includes an index.html, with a 100 MB product limit on the compressed archive (an exact enforced cap of 100 MiB, or 104,857,600 bytes), and each successful update to the same project reuses the address you already sent. On the next round, open the existing project rather than the New site button.