How to Password Protect a Website Made with Claude

Protection Comes From the Host, Not From Claude

Claude can build a website, but Claude does not decide how you protect that website. Access depends on where you publish the site. A published Claude artifact has no password option. But you can host exported HTML, CSS and JavaScript behind real access control.

For a client-only site, ask Claude for browser-ready files. Publish them on a host that controls access before it serves anything. For email-based sign-in, use Cloudflare Pages with Cloudflare Access. For a shared password, use Netlify or Vercel.

Choose the Right Publishing Path

Claude output Who can open it Password option Good for
Code in a chat or a local project folder Nobody, until you host it somewhere Not applicable Development
Published artifact (Free, Pro and Max plans) Anyone with the link, without a Claude account None Open demos
Shared artifact (Team and Enterprise plans) Invited people, everyone in your organization, or anyone with the link if an owner allows external sharing None. Access follows Claude accounts Internal work
Exported website on a protected host People who pass the host’s sign-in or password screen Yes, but it depends on the host Client review and delivery

Anthropic’s artifact sharing guide describes these options. On Free, Pro and Max, Unpublish revokes the link of a published artifact. But you cannot publish the same artifact again. To publish again, you create a new artifact. If a site needs a password or a list of approved readers, move it from the artifact to a host.

Ask Claude for a Clean Website Export

A useful request is:

Create a browser-ready static website folder. Include index.html and all required CSS, JavaScript, images, and assets. Use relative paths. Do not include API keys, secrets, private prompts, or customer data. Add a short README that explains how to open and test the site locally.

Before you publish:

  1. Open the exported index.html locally.
  2. Click every navigation link and button.
  3. Make sure that the mobile and desktop layouts work.
  4. Search the files for tokens, passwords, email addresses and private notes.
  5. Remove sample data that must not reach a client.
  6. Make sure that each form or API feature has a real backend behind it.

A static export cannot safely contain secret API keys. Treat anything that goes to the browser as visible to every visitor who gets past the access screen.

Pick a Host With Real Access Control

Host How access works Plan requirement
Cloudflare Pages + Cloudflare Access Each reader enters their email and a one-time code. You list the allowed addresses or a whole company domain Access is part of Cloudflare Zero Trust. See its current plans
Netlify One shared site password Pro plan or higher. Not available on Free or Personal
Vercel A shared password, or sign-in with a Vercel account that you give access Password Protection is a paid add-on on Pro and is included on Enterprise. Vercel Authentication is on all plans
GitHub Pages No password. Sites are public unless you use GitHub Enterprise Cloud Not suitable for private client work on standard plans

The steps below use Cloudflare. Email sign-in tells you which approved person entered, and it needs no shared secret. A Netlify and Vercel alternative comes after these steps.

Publish the Claude-Made Site on Cloudflare Pages

  1. Put the final website files in one folder, with index.html at its root.
  2. In the Cloudflare dashboard, open Workers & Pages. Select Create application > Get started > Drag and drop your files.
  3. Name the project and drag in the folder (or a ZIP of it). Select Deploy site. The site appears at <project>.pages.dev (direct upload guide).

If you build the site with Claude Code, Claude Code can deploy the folder for you with Wrangler, Cloudflare’s command-line tool. Sign in once yourself:

npx wrangler login

Then use the deploy command. Claude Code can run it after each revision:

npx wrangler pages deploy ./site --project-name=client-preview

Do not paste Cloudflare API tokens into the chat or into the site’s files.

Put Cloudflare Access in Front of It

  1. Turn on email codes. Go to Zero Trust > Integrations > Identity providers. Select Add new identity provider. Choose One-time PIN (one-time PIN documentation).
  2. In the Pages project, go to Settings > General. Select Enable access policy. This setting protects only preview deployments.
  3. Extend the protection to the main <project>.pages.dev address with Cloudflare’s pages.dev Access steps. Remove the wildcard (the asterisk) from the subdomain of the Access application. Save the change. Then enable the Pages access policy again, so that previews stay protected.
  4. In the Allow policy of the application, add an Include rule. Use Emails for named reviewers, or Emails ending in for the whole domain of a client.
  5. If you add a custom domain, protect it with its own self-hosted Access application.

Our Cloudflare Pages access guide covers these screens step by step. Each code works once and expires 10 minutes after the reader requests it. People who are not on the list never receive a code.

Or Use a Shared Password on Netlify or Vercel

If the client prefers one password for the whole team, use Netlify or Vercel.

On Netlify, sign in and drag the folder onto Netlify Drop to deploy it. Then set the password under Project configuration > General > Visitor access.

On Vercel, deploy the project and open its Settings > Deployment Protection. Choose All Deployments, so that the production address is also protected. Then enable Password Protection.

Send the password through a different channel from the link. For example, send the link by email and the password by text message.

  1. Open the site in a private browser window.
  2. Make sure that the sign-in or password screen appears before any page content.
  3. Sign in with an approved address. Then make sure that the site refuses an unapproved address.
  4. Copy the URL of an image, PDF or script from the developer tools. Open the URL in a new private window. Make sure that it also asks for access.
  5. Do these tests again for every address that serves the site. This includes the pages.dev, netlify.app or vercel.app address, each preview URL and your custom domain.

Update the Site When Claude Makes a Revision

Ask Claude for the revised files and test them locally. Then deploy them to the same project. In Cloudflare Pages, use Create a new deployment. On Netlify, do a new drag and drop on the Deploys page. Or run the same Wrangler command. The client keeps one address, and the access rules stay attached to it. If a revision breaks something, Cloudflare Pages can roll back to the previous deployment.

Cloudflare Access also keeps authentication logs. The logs show which email signed in and when. This information is often enough to know that a client opened the preview.

Password or Verified Email?

A password is quick when several trusted reviewers can share one secret. Email verification is better when you need to know which approved person entered. An allow list can limit access to specific addresses or company domains. You can remove one person, and nothing changes for the others.

Neither method prevents an authorized viewer from taking a screenshot or copying content. Access control limits entry. It does not give you digital rights management (technical limits on copying and use).

Do Not Embed a Fake Password in the Code

A JavaScript form that compares a password in the browser is not secure. Anyone can read the password or the protected content in the page source or in the network requests. You can ask Claude to “add a password to this page”. If you do, say that the host must ask for the password, not the page’s own code. The host must control access before it serves the private files.

Bottom Line

Use Claude to build the website, and use the host to control access. For a public page, a published artifact or ordinary hosting is enough. For client work, export the files. Publish them on Cloudflare Pages behind Cloudflare Access, or on Netlify or Vercel with a password. Then test every address before you share it.

Free email addresses
for your AI agents

Each agent gets an address like myagent.x7k2@revdokumail.com. It can receive emails, send replies and store files.

  • 3 free mailboxes, each with its own address
  • 3,000 incoming and 500 sent emails a month
  • 3 GB of storage for attachments and files
  • Virus, malware, spam and prompt-injection filter
  • Read and reply through API, MCP or CLI
Create free mailbox

You do not need a card.

Share:
Markdown version

History

  • August 7, 2026 — Published by Revdoku Content Team
  • August 1, 2026 — Reviewed by Eugene Mi
  • October 22, 2026 — Last updated by Revdoku Content Team.

Related Articles

↧
Loading PDF…