Choose Between Public, Password, and Identity-Based Website Access

Decide who can see the content

Every website has one of three access levels. The right level depends on two things: how sensitive the content is, and if you need to know who opened it.

Access	Who gets in	What you learn about visitors	Good fit
Public	Anyone who has or finds the address	Totals from your analytics tool	Launched sites, public docs, demos, daily updates
Shared password	Anyone who has the password	Totals only. One visitor looks like another	Client previews, small internal reports
Approved identity	Only the addresses or accounts on your list	A sign-in record for each person	Investor updates, client portals, gated reports, sales handoffs

The sections below explain when each level fits. They also show how to set up each level on Cloudflare Pages, Netlify, Vercel and GitHub Pages. Finally, they list what to test before you send the link.

Use public access when reach matters more than control

Public access is right for content that you are happy for people to forward. Examples are a launched site, documentation, a public demo or a daily update. Before a page goes public, make sure that it has no client names, draft prices, internal numbers or test data.

An unlisted address or a long random address is still public. Anyone who receives the link can open it and pass it on. A noindex tag keeps a page out of search results, but it does not stop anyone from opening it.

To count visits on a public site, add a privacy-focused analytics tool. Cloudflare Web Analytics does not collect the personal data of visitors. On Cloudflare Pages, you turn it on in the Metrics tab of the project. On other hosts, you paste its script before the closing </body> tag. Plausible is another option, and it uses no cookies. Both tools report trends, not people.

Use a shared password for a small, low-risk group

A shared password fits a client preview, an internal report or a review link for a small number of people. It keeps casual visitors and search engines out, and visitors need nothing except the password.

The options for a shared password depend on the host:

• On Netlify, basic password protection needs a paid plan (Pro or higher). Set it under Project configuration > General > Visitor access. You can limit the password to previews or also apply it to production. These choices depend on your plan. See the Netlify password protection docs and our Netlify walkthrough.
• On Vercel, Password Protection is a paid add-on on Pro, and it is included on Enterprise. It is not available on Hobby. It is under Settings > Deployment Protection (Vercel docs). Our Vercel guide shows the setup.
• Cloudflare Pages and GitHub Pages have no built-in shared password. On Cloudflare, use the email sign-in from the next section.

Know the limits before you rely on a shared password. People pass passwords on, and you cannot tell who used the password. To remove one person, you must change the password and send the new password to everyone else. A shared password keeps a draft out of public view. It does not prove who saw the draft.

A password prompt that is written in JavaScript inside the page does not protect the page. The host still sends the files to anyone who requests them. Also, the password is in the page source. The host must do the check before it sends any file.

Use identity-based access when you need to know who opened it

Sometimes access must be personal: one reviewer at a time, removable, with a record of who came in. In that case, let the host sign in each visitor with an email address or an account. A form that asks visitors to type their email is not the same thing. Anyone can type the address of a different person. An email sign-in sends a code to the address, so the visitor proves that they control the address.

Cloudflare Pages with Cloudflare Access is the most flexible option for outside reviewers. The reviewers do not need an account anywhere. Set it up in five steps:

1. Turn on email codes. In the Cloudflare dashboard, go to Zero Trust > Integrations > Identity providers. Select Add new identity provider. Choose One-time PIN (docs).
2. Protect the site. For preview deployments, open Workers & Pages. Select the project. Under Settings > General, turn on Enable access policy (docs). That switch does not cover the production pages.dev address or a custom domain. A Cloudflare zone is a domain that you added to Cloudflare. For a custom domain on a zone, go to Zero Trust > Access controls > Applications. Select Create new application. Choose Self-hosted and private. Add the domain as a public hostname (docs). The production pages.dev address needs its own steps. The Cloudflare Pages known issues page lists them.
3. Decide who can enter. Add an Allow policy with an Emails rule that lists each reviewer. To admit everyone at one company, use Emails ending in instead (policy docs). By default, Access denies everyone else.
4. Share the link. The visitor enters their email address and receives a single-use code. The code expires after 10 minutes. The visitor uses the code to sign in. An address that is not on the list gets no code.
5. See who came in. Go to Zero Trust > Insights > Logs > Access authentication logs. This log lists each sign-in attempt with the email, application, time, IP address and country. It also shows if Access allowed the attempt (docs).

Our Cloudflare Pages access guide shows these screens in more detail.

The email code is only half of the control. It proves that the visitor owns an address. The allow list (the addresses in your Allow policy) limits the audience. A policy that admits any email address gives you a log of names, but no privacy.

Other hosts offer identity-based access with stricter requirements for visitors:

• Vercel Authentication works on all plans. Visitors sign in with a Vercel account. People without access can request it (docs). On Hobby, you can give access to only one external user. A Shareable Link lets in anyone who has the link, so it removes the identity check.
• Netlify team login admits only members of your Netlify team. It is an Enterprise feature. It is good for internal reviews, not for clients.
• GitHub Pages can be private only for organizations on GitHub Enterprise Cloud. Visitors need read access to the repository (docs). In all other cases, a Pages site is public, even if its repository is private.

If you share a PDF or a slide deck and not a website, a document-sharing tool can be a better fit. For example, Papermark has password-protected links and analytics per page and per viewer.

Check every address before you share

If visitors can reach the same files at a second URL, protection on one URL is not enough. List every address that serves the content:

• The custom domain
• The default domain of the host (*.pages.dev, *.netlify.app, *.vercel.app)
• Preview and branch URLs
• Older deployment URLs, which often stay reachable after a new deploy. Cloudflare Pages keeps the hash URL of each deployment, and Netlify gives every deploy a permanent link.

Open each address in a private browser window where you are not signed in. Then open a direct link to a PDF, an image and a nested page. A common mistake is protection that covers only the home page. With Cloudflare Access, also try an address that is not on the list. Make sure that no code arrives.

Change access as the project moves on

Access is not a one-time choice. A common path has three stages. While the site is a draft, use a password-protected preview. When clients or outside reviewers join, change to email sign-in. At launch, make the site public.

When you launch, remove protection from the production address only. Keep the previews protected, so that unfinished work stays private.

To remove one person under identity-based access, delete their address from the policy. Access checks the policy at sign-in. So a person who already signed in keeps access until their session expires. For sensitive content, set a short Session Duration on the Access application.

Quick rule of thumb

Use this rule to choose the access level:

• When reach matters more than control, use public access.
• When the link is private but it does not matter who opens it, use a shared password.
• If you need follow-up, accountability or proof of access, use identity-based access. Also use it if you expect to remove one person later.

A docs portal with Ask AI
and support tickets

Connect a repository, or describe your product to start. Each docs site has search, Ask AI, an API console, an MCP server and support tickets.

• Publishes from GitHub on every push
• Works with Mintlify repositories
• API console from your OpenAPI file
• MCP server and llms.txt for AI agents
• Ask AI and support tickets
• Analytics for people and AI agents

Start Free→ Questions? Ask AI in our docs

No card required.