How do I show a draft website to a client without Google finding it?

This page may contain affiliate links from which Blur Studio earns commissions.

There are three different things people reach for here, and only one of them actually solves the problem completely. A "noindex" tag asks search engines nicely not to index a page; most respect it, but it's a request, not a lock, and it does nothing about a human stumbling onto the link. An unguessable, un-shared URL feels private but breaks the moment anyone forwards it, screenshots it into a group chat, or it leaks through a browser's autocomplete history. A genuine password check is the only one of the three that actually stops both problems at once: it blocks search engines from reading the content at all, and it blocks anyone without the password regardless of how they got the link.

Why this matters more than it seems

A draft site getting indexed isn't just embarrassing. If the draft has placeholder pricing, an unfinished privacy policy, or content that later changes significantly, you can end up with a stale, wrong version of your site sitting in Google's index and sometimes outranking the real one for a while after launch, which is a genuinely annoying problem to clean up after the fact. Catching this before launch, rather than after, is the entire point of locking the draft down properly from day one.

Setting up a password on a staging copy

1. Put the draft on its own staging URL, separate from your production domain, so you're never accidentally password-locking the live site by mistake.
2. Turn on a host-level password for that specific staging URL. Netlify offers password protection as part of its access controls for sites and deploy previews, on the Pro plan or Enterprise; it isn't included on Free or Personal, so check your plan before promising a client it's covered.
3. Add a noindex tag as a second layer, not a replacement for the password. It costs nothing and adds a bit of extra protection against the rare case of a search engine still picking up metadata about the page.
4. Share the password through a channel you control, a direct email or message to the specific client, not a public or easily-forwarded group thread.
5. Test it from a private or incognito browser window before sending the link, to confirm the password actually gates the page and you haven't left a cached, unprotected version reachable some other way.

What I'd actually tell an agency or freelancer

If you're regularly sharing drafts with clients, this is worth setting up once as a standard step in your workflow rather than improvising it project by project. Setting this up once, in your hosting dashboard, saves you from improvising it under deadline pressure on a Friday afternoon. The agencies that get burned here are usually the ones who relied on "just don't share the link" as their only protection, which works right up until a client forwards it to a business partner for a second opinion, completely reasonably, and now three more people have the URL with no password in front of it.

One thing worth deciding upfront: will the client need to review multiple draft versions over the project, or just one final check before launch? If it's multiple rounds, set the password once at the start of the project rather than re-explaining the process every time you send a new draft link, and consider keeping a short, reusable note in your project files with the staging URL and current password so you're not hunting for it three weeks later.

A practical note on budgeting for the Pro requirement

If you're currently on Netlify's Free or Personal tier and password protection is genuinely something you need regularly for client work, factor the Pro plan's cost into what you charge for the project, rather than discovering mid-project that the feature you assumed was included actually needs an upgrade. For an agency running several client drafts at once, this is usually a small, easily justified line item against the time saved versus any workaround.

When this isn't quite enough

Netlify's own guidance is candid that its access controls are rule-based and relatively basic on lower plans, which is fine for keeping a client draft private but not built to withstand a genuinely determined, repeated attempt to get in, or to stop sophisticated scraping. If you're protecting something more sensitive than a client preview, a dedicated access-control or bot-protection service built for that specific job is the better fit, since a simple password gate was never designed to be a security product on its own.

A worked example: an agency that got burned by a forwarded link

A small web agency relied for years on "just don't share the link" as their only protection for client drafts, relying on an unguessable, auto-generated staging URL rather than a real password. It worked without incident until a client, trying to be helpful, forwarded the staging link to their business partner for a second opinion on the design, completely reasonably from the client's perspective, with no idea the link itself was the only thing standing between the draft and the open internet. The partner then shared it again in a group chat asking for more opinions. Within a day, a half-finished site with placeholder copy and an incomplete pricing page had been seen by a dozen people who were never meant to see it in that state, and the agency had no way to know how many more had the link, since there was no password check that could have stopped it or logged who'd accessed it.

After that, the agency added a mandatory password step to every project's staging environment regardless of how small the project was, specifically because the failure mode wasn't a sophisticated attack, it was an ordinary, well-intentioned client doing something completely normal with a link that happened to have no real protection behind it.

A practical note on rotating passwords between projects

Reusing the exact same staging password across every client project is a small but real risk: if one client's password leaks or gets casually shared, every other current project using the same password is also exposed. A simple project-specific password, even something as basic as the client's name plus a short suffix, costs nothing extra to set up and keeps one leak contained to a single project instead of your entire active client roster.

How I'd approach this

For a standard client review, a password on the staging URL plus a noindex tag is genuinely enough, and I'd set that up on Netlify or whichever host you're already using as a default step rather than something to remember separately each time. Where I actually get involved is when a client needs something more structured than a single shared password, several stakeholders each needing their own access record, or a staging environment that needs to survive many review rounds without the password process becoming a recurring headache. That's a small, specific build, not a huge one, and it's worth doing properly once rather than re-solving it on every project.