How to share a website preview with a client

The build is done and the client is waiting. What you send in the next five minutes quietly decides how the review goes. Email the folder as a ZIP and it might bounce off an attachment filter, or land in an inbox where the recipient has to work out how to open it. Paste whichever deploy URL is on screen and the next revision may arrive under a different address, leaving two links in the same thread. Send a public staging link and a half-finished page can surface in a Google search for the client's own brand.

The cleaner handoff is one link that survives your edits. Before sending it, check the build, decide who should be able to open it, and choose where feedback will live. If you still need to get the files online, turning a folder or ZIP into a live URL covers that part.

Check the preview before your client does

A client opens the link on a device you didn't test, at a moment you can't watch. Anything broken becomes their first impression and your first round of feedback, spent on things you already knew how to fix. Ten minutes of preflight moves those items off the client's list and onto yours.

• Open the link in a fresh private window, signed out of everything. That's the state your client is in. A page that only works because you're still logged into some tool won't work for them.
• Click through every page and every primary action. Dead internal links and buttons that do nothing are easy to catch yourself.
• Open it on a phone. The client may tap the link there before opening it on a desktop.
• Confirm the browser tab has a real title, images carry alt text, and headings run in order. The W3C's accessibility easy checks are a fast first review covering page title, image alternatives, heading structure, contrast, and keyboard focus. Treat them as a preliminary pass, not proof of WCAG conformance.
• Run an automated audit. Chrome's Lighthouse scores performance, accessibility, best practices, and SEO straight from DevTools. It's a good signal for catching a regression before the client does, not a stand-in for actually clicking through the page.

Fix what you find, re-upload, and open the real URL one more time. The version behind the link is the version the client judges, so the last thing you check is the live address, not your local copy.

Decide who should be able to open the link

People tend to collapse two separate questions into one: can a search engine find this page, and can a stranger who has the link open it. Those have different answers and different fixes, and a client preview usually needs both.

Search visibility is about indexing. A noindex rule can be delivered as a meta tag or an HTTP response header that asks Google not to index the page. A crawler has to reach the page to see that rule, so a robots.txt block on its own cannot replace it. PreviewSend adds the noindex response header to normal site responses and password challenges. Active projects without a password also serve a robots.txt crawl restriction.

Indexing control does not decide who gets in. A random-looking URL with a noindex directive is harder to discover, but it authenticates no one. Links get forwarded, pasted into shared docs, and left in browser history. If the preview holds unpublished work or should only go to a named group, add a password. It is still a shared secret, so anyone who receives both the link and password can enter. PreviewSend checks the project password on the server before serving any file. The static-site password guide explains why a check inside the page's own JavaScript cannot do the same job.

For a routine review of non-sensitive work, an unlisted link with noindex is usually enough. If the preview contains unpublished material or should only go to a named group, add the password. The two controls work together. Neither one makes a static bundle a safe place for credentials, private keys, or production customer records, so leave those out before you upload.

Send one link, not a moving target

A preview URL is a normal part of shipping software. Vercel defines its Preview environment as a place for testing, QA, or collaboration without affecting the production site. Generated deployment URLs help a development team because each build can have its own address. They help less when several of those addresses pile up in a client email thread and nobody's sure which one to review.

A client review wants the opposite: one address that stays put while the content behind it changes. Upload the build once, get a stable URL, and share that. When you revise, the same link shows the new version. On PreviewSend you can copy or open that URL from the project page, or have it email the hosted link to the client for you, so the address they receive is the one you'll keep updating. If you don't have somewhere to host the build yet, sign up without entering a card and upload the ZIP (up to 100 MB compressed). Eligible first-time owners get a one-time 14-day Pro trial on their first workspace; otherwise, Free limits apply.

Write the message that turns a link into a review

The link is only half of what you send. A client who receives a bare URL doesn't know what they're looking at, what you want from them, or by when. A short, specific message turns the preview into a review:

Subject: [Project] preview ready for your review

Hi [Name],

The [project] preview is ready to look at here:
[link]

This is version 2. Since the last round I've [one line on what changed].

Could you pin each change directly on the preview by [date]? Use the comment
button, then click the part of the page you mean. No account is required.

The link stays the same as I make updates, so keep using it.

Thanks,
[You]

A few things in that message do real work. Naming the version and what changed keeps everyone pointed at the same build. Asking for pinned feedback by a date keeps comments in one review surface instead of letting them dribble across email and chat. Telling the client the link is stable heads off the "is this still the right one?" email later. If the preview is password-protected, send the password through a different channel than the link, so one forwarded email does not carry both.

Keep the feedback in one place

PreviewSend keeps the site and its feedback together without making the client create an account. They can pin a comment to the exact part of the page that needs attention, while the project owner sees every open and resolved note from the project dashboard. That shared context keeps a review clean:

• Keep every round on the preview. Feedback scattered across a call, two texts, and three email threads is how a change gets lost.
• Number your versions and say what changed. "Version 3, reworked the hero copy and the pricing table" gives the client a reason to reload and a way to confirm they're looking at the current build.
• Ask clients to pin notes against the page itself. "The button on the pricing page is too small" is actionable because it remains attached to that button.
• Point them back at the same link each round. Because the URL doesn't change, reloading the address they already have shows your latest upload, so nobody hunts for the newest version.
• Ask reviewers to use the overlay approval as a round-complete signal when their feedback is resolved. For final sign-off, send a named approver link from the project page on Starter and above or during the active Pro trial. The approver confirms the exact version on PreviewSend's first-party approval page, and Pro, Agency, or an active Pro trial can then download a stamped PDF with the version content hash when available. The PDF is an audit record, not a legal or electronic signature.

Update the preview without changing the link

Each round ends the same way. Revise the build, upload it to the same project as a new version, and the shared link now serves it. Earlier versions remain in version history within your plan's retention; the file-level version diff is available on Pro, Agency, and active Pro-trial workspaces. If a prior build needs to go live again, re-upload that saved build as a new version. When the engagement has a fixed end, an optional expiry date can take the link offline on schedule. Because the URL never changes, updating what the client sees is a matter of uploading, not re-sending, and nobody has to be moved onto a new address to follow the work.