Shopify ships password protection for free. Online Store → Preferences → Restrict store access, set a password, save. The entire storefront goes behind a single page. Nothing renders, no product JSON is served, no theme code runs, nothing is indexable. It is the most secure lock available on the platform, because it sits in front of everything.
If your store is not launched yet, use it. That is the whole recommendation. Apps that sell "password protect your store" as a feature are selling you something Shopify already gives you.
What you also get for free
- A password page you can style, with an email capture field that feeds your customer list.
- A shareable bypass link (Preferences shows it) that lets a specific person in without typing the password.
- Complete crawler exclusion: no risk of a half-finished store being indexed.
- Instant on and off, with no app install, no theme change and no data to migrate.
What a visitor actually sees
Understanding the mechanism matters, because it explains every limitation that follows. When restricted access is on, Shopify intercepts the request before your theme is involved. A visitor to any URL on the storefront gets the password page instead. Not a redirect to a locked product, not a stripped-down version of the page, but a different page entirely. Your Liquid never executes. The product JSON endpoint at /products/handle.js returns nothing useful. There is no partially rendered state for a determined visitor to pick apart, because nothing was rendered.
The password page itself is editable from the theme customiser, and it includes an email capture field wired to your customer list. That field is more useful than most merchants realise: a pre-launch store with a clear promise and an email box is a functioning waitlist, and the addresses land somewhere you can actually use them later. If you are going to be dark for a few weeks, spend twenty minutes on that page.
The bypass link is the other piece worth knowing. Preferences shows a URL with a token appended; anyone opening it is let through without typing anything, and the exemption persists in their browser. It is genuinely convenient for sending a build to a client or a photographer. It is also a single shared secret with no expiry and no per-person revocation, which is exactly the limitation that shows up as the fourth failure case below.
Where it stops being the right tool
1. Part of the store must stay live
The most common case: retail trades publicly while the trade catalog is restricted. Or the homepage and about page are live while a collection is not. The store password cannot express this: there is one door and it is either open or shut.
This is usually the moment a merchant starts looking for an app, and it usually arrives sooner than expected. A brand launches retail, does well, and six months later a distributor asks for trade pricing. Nothing about the retail store should change, but a new set of products needs to exist behind a gate. The store password would take the working retail business offline to solve a problem that affects one collection.
2. Access differs by segment
One shared password means one level of access. If approved wholesale accounts should see trade pricing while the public sees retail, or if VIP customers get a drop 24 hours early, you need a rule attached to the customer rather than a secret attached to the store.
3. The opening is scheduled
A drop at Friday 09:00 means someone has to be awake to remove the password, and the store is completely dark until they are. Scheduled locks open on their own, and let the product page stay visible with the buy button disabled beforehand, which is worth real money, because that page can collect the interest.
4. You need per-recipient links
One shared password cannot be revoked for one person. Give it to twelve buyers and a journalist, and when it inevitably ends up in a forum, your only option is to change it for everyone. Per-recipient access links can be issued, expired and revoked individually, and you can see which ones were used.
Side by side
| Store password | Page-level locking | |
|---|---|---|
| Cost | Free | App, from free tiers upward |
| Scope | Entire storefront | Per collection, product, page or URL |
| Audience control | One shared secret | Tags, accounts, per-recipient links, passwords |
| Indexable while active | No | Yes, if you lock the price and not the page |
| Scheduling | Manual on and off | Scheduled open and close |
| Revoke one person | No | Yes |
| Right for | Pre-launch, rebuilds, seasonal closure | Mixed public and restricted trading |
Decision tree
Is any part of the store meant to be public right now?
|- No -> Shopify's store password. Stop here.
|- Yes
|
Does everyone restricted share the same access?
|- Yes, one shared secret is fine
| -> Page-level password lock on the restricted resources
|- No, access depends on who they are
|
Are you on Plus with real company accounts?
|- Yes -> Native B2B catalogs
|- No -> Tag-based locks with checkout enforcementThe middle ground most merchants end up at
There is a configuration that solves the long-build problem and almost nobody sets up deliberately: launch a deliberately small public site, and lock only the catalog. A homepage that explains what you sell, an about page, a contact page and a blog post or two are enough for Google to start building a picture of the domain. The products stay behind a gate until you are ready, with their prices withheld rather than their pages removed.
The result is that on launch day you are not starting from zero. The domain has been crawled, the brand terms are associated with it, and the product pages that have been quietly indexed without prices start converting the moment the gate opens. Compared with six months behind a password page, the difference in the first month after launch is not subtle.
This is also where the two tools stop being alternatives and start being sequential. Use the store password while the site is genuinely unfinished and there is nothing worth showing anyone. Switch to page-level locking once there is a public story to tell but the catalog is not ready.
Turning the password off on launch day
Removing restricted access takes one click, but a few things are worth doing in order so launch day is not spent debugging.
- 1Check robots.txt and your theme for a lingering noindex. A password-protected store is often also carrying a meta robots noindex tag added during the build, and removing the password does not remove the tag. This is the single most common reason a launched store stays invisible for weeks.
- 2Submit the sitemap in Google Search Console. Crawling does not resume instantly on its own, and a manual submission shortens the wait considerably.
- 3Verify a product page as a logged-out visitor in a private window. The bypass token persists in the browser you have been building in, so your own view is not representative.
- 4Confirm the checkout completes end to end with a real payment method before you announce anything.
- 5If you collected emails on the password page, export them before you restyle it, and send the launch note while the interest is still warm.
Most merchants who arrive looking for a locking app actually need the top branch for the first month and the bottom branch from launch onwards. Use the free tool while it fits, and switch when the requirement outgrows it, not before. Paying for an app to do what Preferences already does is the mistake this post exists to prevent.