Password Protection for PrestaShop: Hiding Pages and Products from the Public

"Hide this from the public" sounds like one job. In PrestaShop it's actually four different jobs wearing the same coat, and choosing the wrong one is how merchants end up with wholesale prices leaking to retail shoppers, a "secret" pre-launch product sitting in the sitemap, or a CMS page that a single shared password protects so weakly it might as well be open. The platform gives you genuine tools for each case — customer groups, B2B mode, product visibility, maintenance mode — but they hide different things, at different layers, with very different guarantees. This guide maps which control fits which intent, the exact back-office paths, and the line where "hidden from browsing" stops being "secure."

One thing to settle up front, because it changes every recommendation below: access control is not encryption. PrestaShop's visibility tools decide what a visitor's browser is shown; they don't lock the underlying files. We'll come back to where that distinction bites. For the broader job of locking down the store itself — admin, server, headers — this post stays in its lane and points you to the PrestaShop security hardening checklist.

Reviewed June 2026 against PrestaShop 1.6, 1.7, 8 and 9 customer-group, B2B, product-visibility and maintenance behaviour, and the current mprpasswordprotect module.

First, decide what you're actually hiding

Before touching a setting, name the intent — because the right control follows directly from it:

• A whole audience tier (wholesale buyers, members, a B2B segment) should see things retail visitors shouldn't. This is a groups problem.
• A single product should exist but not show up in browsing or search yet (pre-launch, a link-only sample). This is a product visibility problem.
• The entire store should be invisible while you build or stage it, except to you. This is a maintenance mode problem.
• One specific page (a price list, partner docs, a members landing page) should sit behind a password. This is a page password problem — and the one PrestaShop has no native answer for.

Pick the wrong tool and you either over-restrict (paying B2C customers locked out) or under-restrict (private content indexed by Google). The sections below take each intent in turn.

Method 1 — Customer groups: hide an audience tier, not a single thing

This is the most PrestaShop-native answer and the one most merchants should reach for first when the question is "who is allowed to see this." Access is controlled at the category level, and it cascades to the products inside.

• Create a group under Shop Parameters → Customer Settings → Groups (e.g. "Wholesale", "VIP", "Members").
• Open the restricted category and, in the Group access panel, uncheck the three default groups PrestaShop ships — Visitor (not-logged-in browsers, which includes search-engine crawlers), Guest, and Customer — leaving only your private group ticked.
• Assign the right customers to that group (manually on the customer page, or automatically — more on that below).

Why this is the clean option: when the Visitor group is unchecked, the category and its products genuinely disappear for anyone not logged into the right group. In normal PrestaShop navigation and search they don't surface in category listings or in the search results to anyone who isn't logged into the right group — because the crawler is the Visitor group. The access layer does the hiding, so there's no separate "also remember to noindex it" step for normal browsing. One caveat worth saying out loud: sitemap output depends on your sitemap/SEO module and on how products are assigned, so a product that also sits in another public category, or a careless sitemap module, can still expose the URL — audit the generated sitemap and any multi-category products before you trust the restriction. So what? Your trade pricing stays between you and verified buyers without you babysitting a robots file.

The honest limitation: groups require accounts. A visitor has to register and be placed in the right group before they see anything, so this fits relationships you control (wholesale, membership) rather than "let me share one link with a stranger." If you want to gate pricing for the whole store rather than category by category, B2B mode and the per-group price toggle handle that — next.

Method 2 — B2B mode plus per-group price hiding: gate prices for trade buyers

PrestaShop ships a built-in B2B mode under Shop Parameters → Customer Settings → Enable B2B mode. Be precise about what it actually does, because it's widely overstated. Switching it on adds B2B fields to customer accounts — Company, SIRET, APE, Allowed outstanding amount, Maximum number of payment days, Risk rating — and an Authorized balance entry under the Customers menu. That's the native B2B mode: extra business fields and credit-management plumbing. It does not, by itself, hide prices and it does not add an account-approval gate — new registrations are active immediately like any B2C account.

The control that actually hides prices is separate and lives at the group level: open a group under Shop Parameters → Customer Settings → Groups and uncheck Show prices. With that off for the Visitor (and Guest) group, browsers that aren't logged in can still see the catalogue but no prices and no add-to-cart, while logged-in trade customers in a group that keeps Show prices ticked see everything. If you genuinely need every new account vetted by hand before it can buy, that approval step isn't native — it takes a registration/approval module on top.

So the right native recipe for a trade-only store is B2B mode (for the business fields and credit limits) combined with the group "Show prices" toggle (to gate pricing) — not B2B mode on its own. This pattern fits a distributor portal or a wholesale-only brand. It's the wrong fit for a mixed B2B/B2C shop, because hiding prices from the Visitor group hides them from your retail walk-ins too, and a retail shopper who can't see a price simply leaves. For mixed stores, don't gate prices store-wide — use Method 1 (a wholesale group on the trade categories) and leave the retail catalogue open.

Method 3 — Product visibility: hide one product without touching accounts

Every product carries a visibility setting on its Options tab (in older 1.6 it lived under the SEO/associations area). The four values do different things and the names are easy to misread:

• Everywhere — shown in category listings and findable in search. The normal state.
• Catalog only — appears when browsing categories, but the internal search won't return it.
• Search only — returned by search, but not listed when browsing categories.
• Nowhere — the product page still exists at its URL, but nothing on the store links to it. No category, no search, not in the menu.

Nowhere is the pre-launch and "share-with-a-few-people" setting: the page is live so a direct link works, but a casual browser can't stumble onto it. The catch worth saying out loud — this is obscurity, not security. The URL is guessable if your slugs follow a pattern, and the product may still be included in your sitemap depending on which sitemap module you run and how it's configured — verify the generated XML, because a sitemap that lists it would hand the "secret" straight to Google. Treat "Nowhere" as fine for a low-stakes pre-launch sample, and never as a way to protect anything that actually matters. The clean pre-launch recipe: set visibility to Nowhere, share the URL with the handful of people who need it, and flip to Everywhere on launch day.

Method 4 — Maintenance mode: hide the whole store while you build

Under Shop Parameters → General → Maintenance you can switch the storefront off entirely and replace it with a maintenance page, while whitelisting your own IPs (the Maintenance IP field — "Add my IP" fills in the one you're on) so you and your client still see the live store.

This is genuinely useful for two moments: building a new store you don't want indexed or found yet, and staging a redesign for a client to preview before go-live. What it is not is an access-control system — it's all-or-nothing. You can't open one section to members and close the rest; everyone outside the IP list gets the same wall. For ongoing "members see X, public sees Y," that's groups (Method 1), not maintenance mode. While the store is in maintenance it returns an HTTP 503, which is the correct signal to tell crawlers "come back later" rather than "this is gone."

Method 5 — Password-protecting a specific page (the native gap)

The password gate is configured from the module, including employee bypass and noindex behaviour.

The Password Protect module gates requests early through the dispatcher hook, before the page content is rendered:

public function getHooks()
{
    return [
        'actionDispatcherBefore',
    ];
}

Here's the case the platform doesn't cover. There's no native PrestaShop setting to put one CMS page, category, or product behind a simple password prompt. The native tools are all account-based (groups) or all-or-nothing (maintenance). The current mprpasswordprotect module is also an all-storefront gate: it redirects front-office and module requests to a shared password page until the visitor authenticates. That fits pre-launch stores and private storefronts; it is not yet per-page, per-category, or per-product targeting.

The shipped module is useful when the goal is a password-protected storefront: a pre-launch shop, a private catalogue preview, or a temporary client review area. It hooks actionDispatcherBefore, checks the shared password, sets a front-office cookie, and can send a 503/noindex response while the gate is active. So what does that buy you? A whole storefront can be hidden behind one shared password without core edits or customer-account friction. For a dealer price list, one CMS page, one category, or one product, use native groups/product visibility where accounts are acceptable, or treat per-entity password targeting as a missing feature to implement properly.

Be clear-eyed about what a shared password is and isn't: one secret, shared by everyone who has it, with no per-user audit trail. That's the right weight for "moderately private, low blast radius" content (a seasonal lookbook, a partner sheet). It is the wrong weight for legally sensitive data — for which, see the security note below.

Combining methods for real scenarios

Most live setups stack two or three of these, because the intents overlap:

• Wholesale catalogue: customer groups to restrict the trade categories + a verification step before granting the group + group-specific pricing. If you're also collecting trade-application details (VAT number, business type), the patterns for capturing and acting on extra registration data live in customer extra info and IP bans.
• Pre-launch product: visibility set to Nowhere + a shared link to a few people + flip to Everywhere on launch day.
• Members-only page: customer groups if members already have accounts; a per-page password gate needs a targeted module implementation, while the current Password Protection module gates the storefront as a whole.
• New store still being built: maintenance mode with your IP whitelisted until launch.

The SEO trap: hidden in the UI, indexed in Google

Native PrestaShop does not generate XML sitemaps by itself, so the exclusion belongs in whichever sitemap module you use, such as gsitemap or Advanced SEO Sitemap Builder.

The access gate and the sitemap rules need to agree.

The single most common failure here isn't a setting that doesn't work — it's a "hidden" page that quietly stays public to crawlers. Two rules keep private content private:

• Group-restricted content is safe by default. Because a crawler is an unauthenticated Visitor, anything you've hidden from the Visitor group is also hidden from Googlebot. No extra step needed.
• "Nowhere" visibility is not safe by default. The page still exists, and if your SEO/sitemap module includes it, you've published the URL to Google. Check that unlinked products are excluded from the sitemap, and for anything that must stay private, add a noindex directive rather than relying on "nobody links to it."

If you run an SEO/sitemap suite, audit what it actually emits before trusting a restriction — a generous sitemap can undo a careful visibility setting. And remember that a password-gated page should never have appeared in a public sitemap in the first place; the gate handles the humans, the sitemap exclusion handles the bots.

Where access control ends and security begins

This is the line to internalise. Everything above controls what a browser is shown. None of it encrypts files or guarantees a determined person can't reach the underlying asset. Specifically:

• A product's images live at predictable URLs and may be fetchable directly even when the product page is restricted, because image files aren't behind the same access check as the page.
• A "Nowhere" or shared URL can leak through browser history, referrer headers, or someone forwarding the link.
• Content that's loaded into the page but hidden with CSS is still sitting in the page source for anyone who opens dev tools.

So for genuinely confidential material — signed pricing contracts, legal documents, anything where exposure is a real problem — do not lean on storefront visibility at all. Serve it from a properly secured system with real authentication and, ideally, server-level file protection. PrestaShop's visibility controls are built for commercial access control (who gets the wholesale price), not for protecting security-critical data. If you're hardening the store more broadly, the .htaccess security and performance rules cover protecting files and directories at the server layer, and the plain-English guide to securing your store sets the wider context. And if something private has already been exposed, the data breach response guide is the next page to read.

Frequently asked questions

How do I password-protect a single CMS page or product in PrestaShop?

There's no native PrestaShop setting for it — the native tools are either account-based (customer groups) or all-or-nothing (maintenance mode). The current mprpasswordprotect module gates the whole storefront behind one shared password, which fits a pre-launch shop or a private preview, but it isn't yet per-page, per-category, or per-product. For a single page where accounts are acceptable, use customer groups; true per-entity password targeting is a feature that needs a specific implementation.

What's the difference between B2B mode and hiding prices?

They're separate controls and people conflate them. B2B mode (Shop Parameters → Customer Settings) only adds business fields and credit-management plumbing — Company, SIRET, APE, allowed outstanding amount, payment days, risk rating. It does not hide prices and does not add account approval. To hide prices you open a group and uncheck Show prices for the Visitor (and Guest) group. A trade-only store needs both: B2B mode for the fields, the group toggle for the pricing.

If I set a product to "Nowhere", is it private?

No — that's obscurity, not security. The product page still exists at its URL, so a direct link works; "Nowhere" just means nothing on the store links to it. The URL is guessable if your slugs follow a pattern, and depending on your sitemap module it may still be published to Google. Use it for low-stakes pre-launch samples, verify it's excluded from your generated sitemap, and add a noindex directive for anything that genuinely must stay out of search.

Will hiding a product or category also keep it out of Google?

It depends which method you used. Group-restricted content is safe by default — a crawler is an unauthenticated Visitor, so anything hidden from the Visitor group is hidden from Googlebot too, no extra step. "Nowhere" visibility is not safe by default: the page exists and a generous sitemap module can republish the URL. Always audit the XML your sitemap module actually emits before trusting a visibility setting.

Can I use these tools to protect legally sensitive documents?

No. Every method here controls what a browser is shown; none encrypts files. Product images live at predictable URLs and may be fetchable even when the page is restricted, shared links leak through history and referrer headers, and CSS-hidden content still sits in the page source. For signed contracts, legal documents, or anything where exposure is a real problem, serve it from a properly secured system with real authentication and server-level file protection — not storefront visibility.

The takeaway: "hide it from the public" decomposes into hiding an audience tier (groups), a single product (visibility), the whole store (maintenance), or one page (a password module) — and each native tool guarantees something different. Match the tool to the intent, double-check that your sitemap isn't quietly republishing what you hid, and never confuse showing-less with securing. Do that, and the right content reaches the right people without a single private price list turning up in someone's search results.