A private link and a public deploy are the two ends of one dial: how findable the page should be. A job-by-job map of where each endpoint fits, plus the in-between cases most real work actually lands in.
There is one decision you make before any other when a page is done, and it is not "where do I host this." It is quieter than that: should a stranger be able to find this, or should it reach only the people I hand it to? Picture a single dial. All the way to one side, the page is built to be discovered. All the way to the other, it is delivered to a named list and nobody else. Almost every hosting choice you will ever make is just a position on that dial — and most of the confusion in this space comes from treating two points on one instrument as if they were two warring products.
A public deploy sits at one end: an address built to be found, indexed by search, open to anyone who arrives. A private link sits at the other: an unguessable address, not indexed, meant only for the people you hand it to. Same HTML, opposite assumption about who shows up. Get the position right and the page does its job quietly. Get it wrong and you spend the next week either wondering why nobody found your launch, or scrubbing a client draft out of search results.
Public is the right shape when discovery is the goal. You want strangers to arrive. You want the page indexed, linkable, shareable to an audience you do not personally know.
This is the home of:
The tell is simple: if "nobody found it" would count as failure, the page wants the public end of the dial. Reach is a feature there, not a risk.
Private is the right shape when the audience is a list you control. The page is for specific people, and everyone else arriving would be noise at best, exposure at worst.
This is the home of:
Here the tell inverts: if "a stranger found it" would count as a problem, the page wants the private end. With a private link, "anyone can see it" means anyone you sent the link to — not the public. The default is no-index and unguessable, so the page is delivered, not published. Add a password when the link alone is not gate enough, and an expiry when the page should stop existing once the engagement closes. That is the model behind a link that never expires until you decide it should, or an expiring link that closes itself on schedule.
Most finished work is delivered, not published. Drop a self-contained HTML or ZIP and get an unguessable private link in seconds — no-index by default, password and expiry optional. The viewer needs no account.
The endpoints are the clean cases. The part people get wrong is assuming a page picks one and stays there. It doesn't. The dial turns over a page's lifetime, and most projects pass through several positions before they settle — if they settle at all. Four patterns cover almost everything:
Draft-then-publish. A landing page starts as a private link so the team and a client can review it without it being live or indexed. Once approved, you publish the public version. The artifact never changed; its position on the dial did. Tools that let you keep a page private by default and flip one specific link to searchable handle this without a migration — private as the rule, public as the deliberate exception for one page.
Narrow-then-wide. A workshop microsite goes to twelve registrants as a private link. The same content, later, becomes a public recap anyone can read. Start narrow, widen on purpose.
Wide-then-narrow. A campaign page is public while the campaign runs, then should quietly disappear — an event microsite that disappears once it is over rather than lingering as a stale public URL. Public for the window, gone after.
Permanently private. Plenty of pages never want the public end at all. A client proofing link, an internal dashboard shared privately, a resume on its own URL you send to named recruiters — these live their whole life as private deliveries and lose nothing by it. "Private" is not a lesser, draft-stage version of "public." For a great deal of professional work it is the finished, correct, permanent state.
The common mistake is assuming everything is heading toward public. Most of what gets made and sent is delivered to a known audience and never needs a stranger to find it.
There is a case where neither endpoint fits, and it is worth naming honestly: when the page is not really a static page.
The private-versus-public dial is about a finished file — HTML you can hand over and serve as-is. The moment the page must read or write live data — a login that checks a database, a payment that hits a processor, a form that stores submissions and emails you, a feed that updates per visitor — you are past static hosting in any form. No link, private or public, solves that, because the work is a server, not a file.
That is where a full application platform is the right tool. Vercel and Netlify exist precisely for pages with a backend behind them — serverless functions, databases, build pipelines. If your page needs a server, reach for one of those and don't fight a static link into a job it can't do.
The honest boundary: a private link owns the static slice — a self-contained page delivered to people you choose. It is the right tool for a finished deck, a report, a one-pager, a vibe-coded app that runs entirely in the browser. It is the wrong tool the instant real backend logic is involved. Knowing which side of that line you are on saves more time than any feature comparison.
Two questions, in order:
Should a stranger be able to find this?
Does the page need live data — logins, payments, saved input?
Land on "no stranger, no backend" and you are in the large, quiet middle where most finished work actually lives — a page that just needs to reach the right people and nobody else. That is the HTML hosting job a private link was built for: not publishing to the world, but delivering to a list. The dial doesn't have to be at the loud end to be doing real work.
Cloudflare Pages is a public, global CDN site — built to be found and to scale. A private link is built to reach a named audience and nobody else. They solve opposite halves of "I made a page, now what." Here's the honest fit for each, where the backend boundary sits, and how to pick in one question.
A Loom or screenshot shows the reviewer your build. A live private link lets them click through it themselves. Here's exactly what each format loses in transit — and when a recording is still the right call.
GitHub Pages publishes a public, git-tracked site to the open web. A private unguessable link delivers a self-contained page to specific people. Here is the honest split — by who reaches it, what the URL is for, and where the work lives — so you pick the right one instead of bending one to fit.
miinideck turns a single HTML file into an unguessable link with optional password and expiry. Default-private, never indexed.