How to Password Protect Website Pages in Framer (No Code)

• Framer has no built-in way to password protect website pages, unlike some other site builders.
• Three real approaches exist: a shared password (native toggles, .htaccess, embeds), a custom-built auth system (wiring up Firebase or Supabase yourself), or a dedicated no-code plugin.
• A shared password is the fastest to set up and the weakest long-term: no per-user accounts, no reset flow, nothing to revoke for one person without changing it for everyone.
• Per-user auth, whether custom-built or plugin-based, is more secure and scales better once a site grows past a single gated page.
• The comparison further down breaks out setup effort, security, and best use case for all three.

If you've searched for "password protect a website," you've probably noticed something: Framer doesn't have a settings toggle for it. You dig through the dashboard, check every settings tab, and come up empty. That's not you missing something. It isn't there.

Some builders do have it. Wix and HubSpot both ship a native password toggle. Framer doesn't, and that's why many people end up wiring up Firebase or Supabase themselves and getting stuck halfway through, pricing out a freelance developer for what feels like a five-minute job, or bolting on an embed script that breaks Framer's native feel. It shows up constantly for indie makers launching a paid course, small agencies gating a client's staging site, and SaaS founders who just need one dashboard route locked down before launch.

This post compares the three real approaches, a shared password, a custom-built auth system, and a dedicated plugin, then walks through setting up a real protected page in Framer without code.

No. Framer has no site password field, no page-level password option, and no toggle anywhere in its dashboard for this. HubSpot and Wix both include one. Framer doesn't. Full stop.

That's less a Framer oversight than a product decision. Framer is a design tool first, and access control has always been left to the plugin layer, which is exactly the gap a tool like Auth Plugin fills.

Outside a dedicated plugin, most advice boils down to two paths, and it's worth knowing what each one actually gives you before picking one.

A shared password. This covers native toggles on other builders, a server-side .htaccess file paired with a .htpasswd credentials file (needs FTP access and a server you control, which Framer sites don't expose), a client-side tool like PageCrypt (encrypts HTML at build time, but the payload still sits in the page source and only HTML is protected by default), or a free embed service like Bravenet (works, but it's a second system bolted onto your Framer site). All of these land in the same place: one password, shared by everyone who has it.

A custom-built auth system. Wiring up Firebase or Supabase yourself gets you real per-user accounts, but it means writing and maintaining backend code, which is exactly what pushes most Framer builders toward a no-code option instead.

A dedicated plugin. Auth Plugin's Protected Pages feature gives you the same gate outcome as a shared password, but built on real per-user accounts from the start. Setup is covered further down in this post.

A shared password gets someone past the door, but it isn't what security standards mean by authentication. NIST guidelines describe authenticators as bound to individual subscriber accounts, not a single secret handed to a group, and they require verifiers to rate-limit failed login attempts. None of the DIY methods above do either of those things by default.

Here's what that looks like in practice. Say a small agency password-gates a client's staging site with one shared password, handed out to the client, a couple of stakeholders, and a contractor helping with copy. Months later the contractor's engagement ends, but the password doesn't expire and nobody remembers everyone who has it. The only real fix is resetting the password and redistributing it to everyone who still needs access, hoping nobody who shouldn't have it still does. With a shared password, there's no way to revoke access for just one person.

Fine for a "coming soon" page you'll take down in a week. Not fine for a client portal, a paid course, or anything else you plan to keep gated long-term.

Auth Plugin's Protected Pages feature gives you the "gate this page" outcome people are searching for, but built on real per-user accounts instead of one shared secret.

Setup is four steps:

1. Open Auth Plugin inside your Framer project.
2. Go to Protected Pages.
3. Click Add and enter the page path you want to lock, like /dashboard. Auth Plugin auto-generates the matching pattern (/dashboard.*), so every page under it is covered too, not just the one path.
4. Save. Anyone who is not signed in gets redirected straight to /sign-in, and the page itself never loads for them, not even a flash of content before the redirect fires.

Under the hood, Protected Pages checks the requested path before your page content ever renders, then hands off to a session check that decides whether to let the request through. That's what makes it a real gate rather than a piece of content that just gets hidden with CSS after loading.

Test it the same way you'd test any access control: open the page in an incognito window while signed out and confirm you land on /sign-in, then sign in and confirm you land back on the page you asked for.

That's the whole setup. One indie maker documented on Auth Plugin's own site finished this exact process in 20 minutes. If you later want tiered access instead of one flat gate, say a free tier and a paid tier seeing different content, the role-based access approach builds on this exact same feature. Pricing and what's included on each tier is covered further down.

Only the pages you actually gate. Protected Pages works at the path level (/dashboard.*, /members.*, whatever pattern you set), not across the whole domain, so your homepage, pricing page, and other public marketing content stay fully crawlable. Google can't index pages users can't access, so once a page is gated, it drops out of search results for as long as it stays protected, the same way any login-only page would. That's different from a whole-site password wall, where the entire page (or the entire site, depending on the setting) is pulled from what search engines can index the moment protection is turned on.

Setup effort, security, and the situation each one actually fits:

None of these is universally best. A shared password is the right call for something temporary. Auth Plugin exists for everything past that point, without the backend work custom auth demands.

A single protected page is often just the starting point, not the destination. The same underlying system that powers Protected Pages also runs full membership sites, Google OAuth sign-in, and magic links or OTP for anyone who wants passwordless login instead of a typed password at all. OAuth support currently covers Google and GitHub, not every provider under the sun, but for most Framer sites that covers the login buttons people actually expect to see.

Because Protected Pages is already built on real per-user identities, moving from one gated page to a full membership site later isn't a rebuild. A dashboard page can already show the signed-in user's name with an identity component, or show and hide sections based on whether someone is logged in at all. You're just turning on features you already have access to under the same plan, not migrating to a new one.

Yes. Auth Plugin's Basic tier is free: 100 identities, 1 site, all 13 components, and unlimited Protected Pages, with no trial window or expiry date attached.

Compare that to a free embed tool that only ever gives you a shared password with no path to real accounts, or a page-builder plan you upgraded to just to get a password field. The free tier here already includes actual per-user login, not just a lock screen bolted on top.

If a flat gate isn't enough, say a free tier that can view some pages and a paid tier that can see more, that's what the Pro plan's advanced access control is for, sitting on top of the same Protected Pages you set up on Basic.

Not natively. There's no password toggle in Framer's dashboard. A plugin like Auth Plugin adds page protection through Protected Pages instead.

No. Google can't index pages users can't access, so any page you gate drops out of search results for as long as it stays protected.

Yes. Protected Pages works at the path level, so you can gate a single page, or a whole section with a pattern like /members.*, without affecting the rest of the site.

You can, with a shared-password approach, but it means no per-user accounts, no reset flow, and no way to revoke access for one person without changing the password for everyone. Auth Plugin's Protected Pages uses real per-user accounts instead.

Only the pages you gate. Path-level protection leaves your public pages fully crawlable; only the specific pages or patterns you protect drop out of search results.

Yes. The same system behind Protected Pages also supports full membership sites, tiered role-based access, and OAuth or passwordless sign-in, so a single protected page can grow into a full membership area later.

Across Framer builders, a common pattern shows up: what starts as a simple password need for one staging page often turns into a real requirement for user accounts once a project grows into a client portal or a membership site. Most Framer sites only need to protect a single page at first, and that's a perfectly reasonable place to start. It can expand into role-based access or a full membership system later without rebuilding anything.

You don't need a full membership system just to stop people from stumbling onto a page that isn't ready yet. Pick the one page you actually want gated, add it to Protected Pages, test it in an incognito window, and you're done in about the time it took to read this post.