Temporary website hosting for client work

Temporary website hosting for client work means putting an unfinished static site online for days or weeks, then taking it offline on purpose, rather than leaving it as a permanent public deployment. The right host depends less on upload convenience than on the link's lifecycle: when it expires, who can open it, whether it updates in place, and what happens once the work is approved.

Those are separate properties, and "temporary" gets used for all of them at once. Sorting them out is what turns a disposable link into a preview you can actually run.

What makes hosting temporary?

A short-lived preview has several moving parts. Before you pick a host, decide which ones you need:

• A URL that stops serving after a date or an event, so an old draft cannot resurface months later.
• A password or auth gate that decides who can open the page. Search indexing is a separate concern.
• One address for every revision, so the link you shared keeps showing the current build.
• A noindex directive that asks supporting search engines not to list the preview. It does not restrict access.
• A clear teardown step when the engagement ends.

Most "temporary hosting" questions are really about one or two of these. A designer sharing a homepage draft mostly needs a stable, updatable link that expires. An agency handing off unreleased brand work needs the password too. Deciding which properties matter keeps you from paying for the wrong thing, or trusting an unlisted URL to do a password's job.

Choosing temporary website hosting for client work

General static hosts publish a site and leave it up until you remove it. That is fine for production, but it pushes expiry, access, and cleanup onto you to remember. The table compares how a few common destinations handle the lifecycle, not their upload mechanics:

Netlify documents whole-site password protection as a Pro feature, with scope varying by plan. Vercel's Deployment Protection gates preview and production URLs; Vercel Authentication is on every plan, while password protection is an Enterprise feature or a paid add-on on Pro. Neither cited access page documents scheduled teardown. If you use one of those general hosts for short-lived work, put the takedown on your project checklist.

The honest read: if the site is heading to a permanent public home anyway, deploying it in place on Netlify, Vercel, or Cloudflare Pages is a direct fit, and you accept manual cleanup. If the link exists only for the review window, a host that treats expiry and access as first-class saves you the reminder.

A lifecycle checklist from upload to teardown

Run a temporary preview as a sequence with a defined end, so nothing stays online by accident:

1. Upload once and keep one URL. Put your static bundle online and note the single address you will reuse. If you are still sorting out how to get the folder online, updating a static site without changing its URL covers replacing the files behind one link.
2. Set access to match the content. You may leave a routine, non-sensitive draft open to anyone with the URL. For unpublished or named-audience work, add a password, and send it through a different channel than the link.
3. Keep it out of search. Confirm the preview sends a noindex directive. This is about listing, not access; why a staging site shows up on Google explains why an unlisted URL and robots.txt are not enough on their own.
4. Decide the end date up front. If the engagement has a fixed close, set an expiry now rather than trusting future-you to delete the link.
5. Share one link and collect feedback in one place. The client preview workflow covers the message, the preflight, and account-free comments so a review does not scatter across email and chat.
6. Update in place through each round. Re-upload the revised build to the same destination; the shared link shows the new version without a new address.
7. Let it go offline cleanly. When the work is approved, allow the expiry to take the link down, or take it offline manually. Keep the final build somewhere you control.

The steps that people skip are four and seven: the ones about the link's end. Setting the close date at the start is what makes the teardown automatic instead of a chore you forget.

What should happen after the preview expires

An expired preview should clearly say that it is gone. HTTP 410 Gone tells browsers and crawlers that the resource is intentionally unavailable and likely to stay that way. A 404 does not say whether the absence is temporary or permanent.

PreviewSend evaluates a project's expiry before the password gate on each request. Once the date passes, the hosted preview and the account-free review APIs return 410, so the link a client or a forwarded contact opens is plainly offline. Because expiry comes first, an expired link does not even present a password prompt. Expiry is optional and set per project, with no plan tier required to use it.

Expiry does not erase your work. The build stays in version history, bounded by your plan retention, while the project is offline to visitors. If a client resurfaces a month later, clear or extend the expiry first. Re-upload a saved build as a new version only if you need to restore different files. Retention is a history policy, not one-click rollback, so keep a copy of whatever you shipped.

One caution worth repeating: noindex and expiry solve different problems. A live preview with noindex asks supporting search engines to keep it out of search listings, which is not the same as controlling who can open it. If the content should not be public to anyone holding the link, that is a password's job while the preview is live, and expiry's job once it is done.

Where a temporary client preview fits

A temporary client preview sits between a finished build and its permanent home. On PreviewSend, you upload 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 get one stable URL that carries every later version at the same address.

While it is live, that URL sends a noindex response header asking supporting search engines not to list the draft, and active projects without a password also serve a robots.txt crawl restriction. Add a project password when the work is unpublished. Reviewers open the link and pin comments with no account, and each new upload becomes the active version without changing the address. When the engagement closes, an optional expiry date takes the link offline on schedule and returns 410, while your build stays in version history within plan retention.

If your project's real destination is a permanent public site, a general host is the simpler answer and you handle cleanup yourself. If the link only needs to live through the review, create a PreviewSend project and set the expiry before you send it.