Feature · Password protection
Password protect a web page. We can’t even see it.
Passwords are on Solo and Team. Start your 10-day trial, cancel anytime.
What it does
A lock that’s easy for them, invisible to us
One password per page, set by you
Add a password when you publish or any time after, from the page’s settings. Change it or remove it whenever you like: the link itself never changes.
Hashed: we can’t see it
Passwords are hashed (PBKDF2) before they’re stored. Nobody at Pagelive can read your password or look it up, not even to help you recover it. You just set a new one.
No account for your recipient
Your client opens the link in any browser, types the password once, and reads. No signup, no app, no login wall: the only secret they need is the one you gave them.
Hidden from search by default
A password is half the story. Every Pagelive page is also noindex by default (we tell Google not to list it), so the locked page isn’t sitting in search results inviting attempts.
The full posture (what’s served where, and what we never do with your content) is on the security page.
Hashed
The lock is enforced at the edge
How it works
Three steps to a locked page
Publish your page
Say “publish this” in Claude, drop the HTML, or publish from the dashboard. You can set the password right at publish time.
Set the password
Pick a password for that page, or add one later from the page’s settings. It’s hashed the moment you save it.
Share link + password
Send the link, share the password separately if you like. Your recipient enters it once and reads, and your link tracking still works.
Frequently asked
Publish the page on Pagelive and switch on a password, at publish time or later from the page’s settings. The password is checked at the edge before the page is served, so nothing reaches the browser until it is right. No server, no .htaccess, no code. Passwords and email gates come with Solo and Team.
Pagelive sets the password per page, and each page is one link. Most AI-built proposals, decks and reports are a single page, so one switch covers the whole thing. For a multi-page site on your own server, use the server or your host’s protection; the guide on how to password protect a web page compares the options honestly.
No. They open the link in any browser, enter the password you gave them, and read. No account, no app, no signup: for them it’s just a locked page.
No. Passwords are hashed (PBKDF2) before storage, so we can’t read them: there’s nothing to “look up.” If a password is forgotten, you set a new one from the page’s settings and the link keeps working.
Yes, anytime, from the page’s settings. The link never changes, so you can lock a page for the negotiation and unlock it after signature without resending anything.
Yes. Switch the page to a verified email: the reader confirms their address with a one-time code, or signs in with Google, and your analytics show who opened it. Or send each person their own recipient link, so their opens show under their name without a code. The verified email, like the password, is checked before the page is served; a recipient link only names the reader, it does not lock the page.
It’s one layer of several. Pagelive pages are also noindex by default (they won’t show up on Google), and content is served separately from your account and billing, on SOC 2 Type II-ready infrastructure on Cloudflare. The password is the lock; the rest keeps the door out of sight.
Comparing every way to do it, including .htaccess and your host’s settings? Read how to password protect a web page. Related: custom domains · link tracking. Sending one private page per client? See a page per client instead of a client portal.