How do I password-protect just one section of my website, not the whole thing?
Short answer: If you just need one shared password protecting a section, use Netlify's built-in site password protection rather than building anything custom; it's a setting, not a project. If you need individual logins, with each member seeing their own content, that's a genuinely different, bigger feature, usually built with a dedicated membership tool or custom authentication rather than a quick password gate.
You want part of your site restricted, not the whole thing, and you're trying to work out how much that actually requires.
I'm Ranjit, and I run Blur Studio: 15+ years building software, 120 apps taken live, and clients who have gone on to raise $10M+. I build AI systems and processes that help businesses do a lot more with a lot less time. I also work differently from most of what else is out there, more on that further down this page. Say hello.
This page may contain affiliate links from which Blur Studio earns commissions.
"Password-protected area" covers two genuinely different problems that get confused constantly. One is a single shared password gating a section, fine for a staging site, a dealer price list, or content you just don't want publicly indexed. The other is individual member logins, where each person has their own account and sees their own content. The right tool for one is overkill, or simply the wrong shape, for the other, and the cost of guessing wrong shows up later as either wasted build time or a rebuild once the simpler option runs out of room.
For one shared password, use site protection, not a custom build
If everyone who needs access can reasonably share the same password, the built-in option is genuinely enough. Netlify's own site protection setting puts a password prompt in front of a whole site or branch, no code needed. It's a checkbox and a password field in your site's dashboard, not a feature you build.
This fits well for: a staging version of a site before launch, a dealer or partner price list that's sensitive but doesn't need individual tracking, or an internal draft shared with a client before it's public. If your actual need fits this shape, don't reach for anything more complex.
Where Edge Functions come in, and where they don't
The source material for this question points at Edge Functions as an option, and they can technically gate access by running a check before a page loads and redirecting unauthorized visitors. But there's a real limitation worth knowing before building that way: Netlify's own documentation states Edge Functions aren't compatible with custom headers, including basic HTTP authentication, on the same paths. If your access-control approach relies on basic auth headers, an edge function running on those same paths won't apply as expected, which is the kind of conflict that's easy to build around accidentally and hard to debug once it's live.
In practice, this means Edge Functions are a reasonable fit for custom, code-based access logic (checking a cookie set at a previous login step, for instance) but not for the simplest shared-password case, which site-level password protection already covers natively without any of this complexity.
For individual logins, this is a genuinely bigger feature
If "members only" actually means each person logs in with their own account and sees content specific to them, you're describing a real authentication system, not a password gate. That typically means a dedicated tool (Memberstack and similar services are built specifically for this on static sites) or a custom-built login system with its own user database, session handling and access rules.
This is a meaningfully bigger lift than a shared password, and it's worth being honest with yourself early about which one you actually need. A common mistake is starting with "we'll just password-protect it for now" and then gradually needing per-user tracking, different access tiers, or usage limits, none of which a shared password was ever designed to support, forcing a rebuild later instead of building the right thing from the start. Thinking through where the need realistically goes over the next year or two, not just what covers today's request, is worth the extra ten minutes before committing to either approach.
A worked example: a wholesaler protecting a dealer price list
A wholesale distributor wanted their dealer-only pricing page hidden from the general public and from search engines, but accessible to the roughly forty dealers who regularly ordered from them. The first instinct was to build some kind of login system so each dealer could have their own account, which would have meant a real authentication build: a user database, password resets, session handling, none of it trivial for a static site.
Talking through what dealers actually needed clarified the real requirement: nobody needed per-dealer tracking or different pricing by account, they just needed the page kept away from the general public and from search indexing. A single shared password, distributed to all forty dealers through an existing newsletter, solved the entire problem using Netlify's built-in site protection, a dashboard setting rather than a build. The distributor saved what would have been a multi-week authentication project by correctly identifying that the shared-password case, not the individual-login case, was what they actually had.
Common mistakes with access control
- Building individual logins "to be safe" when a shared password would genuinely cover the need. The extra complexity costs real build and maintenance time for a capability (per-user tracking, individual access revocation) that may never actually get used.
- Starting with a shared password when you already know you'll need per-user tracking soon. If you can already see a near-term need for individual accounts or tiered access, building that from the start is usually cheaper than migrating off a shared password later.
- Assuming a shared password keeps content out of search results automatically. Confirm your specific setup also blocks search engine indexing if that matters, since password-protecting a page and keeping it out of a search index are related but not automatically the same thing.
What I'd actually tell you
Be honest about which problem you actually have before building anything. If you're protecting a staging site or a sensitive-but-shared resource, the built-in site password is the right answer and anything more is wasted effort. If you're building an actual membership experience where people log in to see their own stuff, that's real software, and treating it like a quick password gate will cost you a rebuild later when the shared-password approach inevitably runs out of room.
When this calls for something else entirely
If you're building a genuine subscription or membership product where access tiers, billing and individual accounts all matter together, a dedicated membership platform built for that specific job, with payment handling baked in, will save you far more time than assembling the pieces yourself with Edge Functions and a database. Trying to bolt payment processing onto a custom-built login system, rather than starting from a platform that already handles billing, subscriptions and access tiers together, is one of the more common ways this kind of project ends up costing far more than initially planned.
How I'd approach this
For a shared password need, I'll tell you honestly that Netlify's own site protection is enough and you don't need to pay me to build it. Where I actually get involved is the real membership case: individual logins, access tiers, content scoped to each user, which is a proper piece of software worth building correctly from the start rather than patching a password gate repeatedly as your needs grow.
Questions people ask
What's the simplest way to password-protect a staging site?
Netlify's built-in site password protection, set directly in your site's dashboard with no code. It puts one shared password in front of the whole site or a specific branch, which is exactly right for a staging or draft site.
Can Edge Functions gate access with a password?
They can run custom access-check logic, but they're not compatible with custom headers including basic HTTP authentication on the same paths, per Netlify's own documentation. For a simple shared password, built-in site protection is the more reliable and much simpler option.
What's the difference between a shared password and member logins?
A shared password gates access for anyone who has it, with no individual tracking. Member logins give each person their own account and content, a genuinely bigger feature usually needing a dedicated membership tool or custom authentication system, not a password gate.
Should I start with a password gate and add individual logins later?
Only if you're confident the need will stay simple. If you suspect you'll eventually need per-user access, tiers or usage tracking, building the real membership system from the start usually costs less overall than rebuilding after outgrowing a shared password.
Does a membership tool like Memberstack work with a static site?
Yes, tools like Memberstack are specifically built to add login and member-gated content to static sites without needing you to build a custom backend yourself.