A private repo does not make your Pages site private.

A private repo does not give you a private site

This is the misunderstanding worth clearing first, because it is the one that leaks documents. Repository visibility and Pages visibility are separate settings. You can mark a repository private, deploy Pages from it, and still be serving that site to anyone on the internet who finds the URL. GitHub states it plainly in the Pages visibility documentation: unless your enterprise uses Enterprise Managed Users, sites are publicly available by default even when the repository is private or internal.

And you cannot fall back on the URL being hard to guess, because Pages URLs are not obscure by design — they are derived from the account and repository name, in the shape username.github.io/repository. Anyone who knows both knows the address.

The one supported way to make it private

Publish the site privately, which requires GitHub Enterprise Cloud. Access control for Pages then restricts the site to people with read access to the source repository. That is a real feature and it works, with two consequences worth understanding before you plan around it:

• Every viewer needs a GitHub account with repository access. The unit of access is a GitHub identity, not a link. A client, a contractor without a seat, or a colleague in another company cannot open it.
• On Enterprise Managed Users it flips the other way. Pages sites can then only be published as private, and only to other members of the enterprise.

So the honest summary: GitHub Pages privacy is organisation-shaped. It answers “only my colleagues should see this” well, and answers “only this one person outside my company should see this” not at all.

What people usually actually want

Reading the question as it is normally asked — a page that should not be public, sent to somebody specific — there are three workable answers, and only one of them is GitHub.

• Your viewers are all in your org and you are on Enterprise Cloud. Use private Pages. It is built for exactly this and nothing here beats it.
• Your viewers are colleagues but you are not on Enterprise Cloud. Pages cannot do it. Put the site behind any host that supports a password or an SSO gate.
• Your viewer is a client, or anyone who should not need a GitHub account. You want a link that is unguessable, optionally gated, and openable in a browser by someone who has never heard of your repo.

Plain disclosure, since this is our own site and that third case is what we sell: Stacktree gives every page an unguessable URL by default on every plan including the free one, with a passcode or a company-email-domain gate available on paid plans, and no account for whoever opens it. Where GitHub Pages is the better answer, the list above says so.

What GitHub Pages gets right

GitHub Pages is excellent at one specific shape of work: long-lived, public-facing static sites that live next to their source code. If you're publishing documentation for an open-source project, the Pages + Jekyll/Hugo combo is hard to beat.

What it doesn't fit

Almost everything else in the modern agent-and-AI workflow:

• Private artifacts. "Private Pages" requires GitHub Enterprise Cloud and only gates to GitHub users on the org, not "anyone with the link."
• Agent emissions. Pages can't be the target of a tool call without a commit + push round-trip. Every iteration is a new commit, every commit triggers a rebuild, every rebuild adds latency.
• Stable URLs across iterations. Pages serves whatever's at HEAD. Replace-in-place semantics require careful branch hygiene.
• Short-lived outputs. A 24-hour PR review link doesn't need a repo, a workflow, or a branch.

How Stacktree differs

• Private by default. Every URL is unguessable; no Git-host log-in dance for viewers.
• 200 ms publish. No CI, no rebuild: the HTML is live by the time the API call returns.
• Replace-in-place. The same URL survives across every revision via update_site.
• MCP-native. Agents publish via tool call: publish_html({ file: "spec.html" }).
• Three gating layers. Unguessable URL on every plan, plus an optional password and email-domain gate from Solo at $19 a month. Pages has zero of the latter two, at any price.
• Optional E2E encryption. AES-GCM in the browser, key in URL fragment; the server stores ciphertext only.

Migration in five minutes

1. Export your Pages site as a folder of static HTML (any modern build does this).
2. Upload via the dashboard, or curl -F file=@site.zip https://api.stacktr.ee/sites.
3. Set a slug, and a password or email gate if the plan includes them.
4. Point your custom domain (Solo and above) at Stacktree via Cloudflare for SaaS.

If the viewers are clients, not colleagues

GitHub’s private path assumes the viewer is inside your org. A client is not, and never will be: no seat, no login, and no reason to get one. If the people opening the page are clients rather than colleagues, the shape of the problem changes, and so does the answer. That handoff has its own page: share an HTML file with a client, as a link they just open.