Passwortschutz für PrestaShop: Seiten und Produkte vor der Öffentlichkeit verbergen

„Das vor der Öffentlichkeit verbergen“ klingt nach einer einzigen Aufgabe. In PrestaShop sind es tatsächlich vier verschiedene Aufgaben unter demselben Mantel, und wer das falsche Werkzeug wählt, riskiert, dass Großhandelspreise bei Endkunden landen, ein „geheimes“ Produkt vor dem Launch in der Sitemap steht oder eine CMS-Seite durch ein einziges geteiltes Passwort so schwach geschützt ist, dass sie praktisch offen ist. Die Plattform bietet für jeden Fall echte Werkzeuge — Kundengruppen, B2B-Modus, Produktsichtbarkeit, Wartungsmodus — aber sie verbergen unterschiedliche Dinge, auf unterschiedlichen Ebenen und mit sehr unterschiedlichen Garantien. Dieser Leitfaden zeigt, welche Steuerung zu welcher Absicht passt, die genauen Backoffice-Pfade und die Grenze, an der „beim Durchstöbern verborgen“ nicht mehr „sicher“ bedeutet.

Ein Punkt muss vorab klar sein, weil er jede Empfehlung weiter unten verändert: Zugriffskontrolle ist keine Verschlüsselung. Die Sichtbarkeitswerkzeuge von PrestaShop entscheiden, was dem Browser eines Besuchers angezeigt wird; sie sperren nicht die zugrunde liegenden Dateien. Wir kommen darauf zurück, wo dieser Unterschied wehtut. Für die umfassendere Aufgabe, den Shop selbst abzusichern — Adminbereich, Server, Header — bleibt dieser Beitrag bei seinem Thema und verweist Sie auf die Checkliste zur Sicherheits-Härtung von PrestaShop.

Geprüft im Juni 2026 anhand des Verhaltens von Kundengruppen, B2B, Produktsichtbarkeit und Wartungsmodus in PrestaShop 1.6, 1.7, 8 und 9 sowie anhand des aktuellen Moduls mprpasswordprotect.

Entscheiden Sie zuerst, was Sie wirklich verbergen

Bevor Sie eine Einstellung ändern, benennen Sie die Absicht — denn daraus ergibt sich direkt die richtige Steuerung:

• Eine ganze Zielgruppe (Großhandelskunden, Mitglieder, ein B2B-Segment) soll Dinge sehen, die normale Besucher nicht sehen sollen. Das ist ein Problem für Gruppen.
• Ein einzelnes Produkt soll existieren, aber noch nicht beim Stöbern oder in der Suche erscheinen (Vorab-Launch, Muster nur per Link). Das ist ein Problem der Produktsichtbarkeit.
• Der gesamte Shop soll unsichtbar sein, während Sie ihn aufbauen oder vorbereiten — außer für Sie. Das ist ein Problem des Wartungsmodus.
• Eine bestimmte Seite (eine Preisliste, Partnerunterlagen, eine Landingpage für Mitglieder) soll hinter einem Passwort liegen. Das ist ein Seitenpasswort-Problem — und genau dafür hat PrestaShop keine native Lösung.

Wählen Sie das falsche Werkzeug, schränken Sie entweder zu stark ein (zahlende B2C-Kunden werden ausgesperrt) oder zu wenig (private Inhalte werden von Google indexiert). Die folgenden Abschnitte gehen jede Absicht der Reihe nach durch.

Methode 1 — Kundengruppen: eine Zielgruppe verbergen, nicht ein einzelnes Element

Das ist die PrestaShop-nativste Antwort und diejenige, zu der die meisten Händler zuerst greifen sollten, wenn die Frage lautet: „Wer darf das sehen?“ Der Zugriff wird auf Kategorie-Ebene gesteuert und wirkt sich auf die darin enthaltenen Produkte aus.

• Legen Sie unter Shop Parameters → Customer Settings → Groups eine Gruppe an (z. B. „Wholesale“, „VIP“, „Members“).
• Öffnen Sie die eingeschränkte Kategorie und entfernen Sie im Bereich Group access die Häkchen bei den drei Standardgruppen, die PrestaShop mitbringt — Visitor (nicht angemeldete Browser, einschließlich Suchmaschinen-Crawler), Guest und Customer — sodass nur Ihre private Gruppe aktiviert bleibt.
• Weisen Sie die passenden Kunden dieser Gruppe zu (manuell auf der Kundenseite oder automatisch — dazu gleich mehr).

Warum das die saubere Option ist: Wenn die Gruppe Visitor deaktiviert ist, verschwinden die Kategorie und ihre Produkte tatsächlich für alle, die nicht in der richtigen Gruppe angemeldet sind. In der normalen PrestaShop-Navigation und -Suche erscheinen sie weder in Kategorielisten noch in Suchergebnissen für jemanden, der nicht in der richtigen Gruppe angemeldet ist — denn der Crawler ist die Gruppe Visitor. Die Zugriffsebene übernimmt das Verbergen, sodass es beim normalen Durchstöbern keinen separaten Schritt „auch noch auf noindex setzen“ gibt. Eine Einschränkung sollte man klar aussprechen: Die Sitemap-Ausgabe hängt von Ihrem Sitemap-/SEO-Modul und davon ab, wie Produkte zugewiesen sind. Ein Produkt, das zusätzlich in einer öffentlichen Kategorie liegt, oder ein unvorsichtiges Sitemap-Modul kann die URL trotzdem offenlegen — prüfen Sie die erzeugte Sitemap und alle Produkte mit mehreren Kategorien, bevor Sie der Einschränkung vertrauen. Und was bringt Ihnen das? Ihre Handelspreise bleiben zwischen Ihnen und geprüften Käufern, ohne dass Sie eine robots-Datei überwachen müssen.

Die ehrliche Grenze: Gruppen setzen Kundenkonten voraus. Ein Besucher muss sich registrieren und der richtigen Gruppe zugewiesen werden, bevor er etwas sieht. Das passt zu Beziehungen, die Sie kontrollieren (Großhandel, Mitgliedschaft), aber nicht zu „ich möchte einem Fremden einen einzelnen Link schicken“. Wenn Sie Preise im ganzen Shop statt Kategorie für Kategorie sperren möchten, helfen der B2B-Modus und die Preis-Anzeige pro Gruppe — dazu als Nächstes.

Methode 2 — B2B-Modus plus Preisausblendung pro Gruppe: Preise für Geschäftskunden sperren

PrestaShop bringt unter Shop Parameters → Customer Settings → Enable B2B mode einen eingebauten B2B-Modus mit. Seien Sie präzise, was er wirklich tut, denn er wird häufig überschätzt. Wird er aktiviert, ergänzt er Kundenkonten um B2B-Felder — Company, SIRET, APE, Allowed outstanding amount, Maximum number of payment days, Risk rating — sowie den Eintrag Authorized balance im Kundenmenü. Das ist der native B2B-Modus: zusätzliche Geschäftsfelder und Infrastruktur für Kreditverwaltung. Er blendet nicht von selbst Preise aus und ergänzt keine Freigabeprüfung für Konten — neue Registrierungen sind sofort aktiv, wie jedes B2C-Konto auch.

Die Steuerung, die Preise tatsächlich ausblendet, ist getrennt davon und liegt auf Gruppenebene: Öffnen Sie unter Shop Parameters → Customer Settings → Groups eine Gruppe und deaktivieren Sie Show prices. Ist das für die Gruppe Visitor (und Guest) ausgeschaltet, können nicht angemeldete Besucher den Katalog weiterhin sehen, aber keine Preise und keine Schaltfläche zum Warenkorb; angemeldete Geschäftskunden in einer Gruppe, bei der Show prices aktiviert bleibt, sehen alles. Wenn wirklich jedes neue Konto vor dem Kauf manuell geprüft werden muss, ist diese Freigabe nicht nativ enthalten — dafür braucht es zusätzlich ein Registrierungs-/Freigabemodul.

Das richtige native Rezept für einen reinen Handelsshop ist also B2B-Modus (für Geschäftsfelder und Kreditlimits) kombiniert mit der Gruppenoption „Show prices“ (für die Preissperre) — nicht der B2B-Modus allein. Dieses Muster passt zu einem Händlerportal oder einer reinen Großhandelsmarke. Für einen gemischten B2B/B2C-Shop ist es die falsche Wahl, weil eine Preisausblendung für die Visitor-Gruppe auch Ihre normalen Endkunden trifft, und ein Endkunde, der keinen Preis sieht, geht schlicht wieder. Für gemischte Shops sperren Sie Preise nicht shopweit — nutzen Sie Methode 1 (eine Großhandelsgruppe für die Handels-Kategorien) und lassen Sie den Endkundenkatalog offen.

Methode 3 — Produktsichtbarkeit: ein Produkt verbergen, ohne Konten anzufassen

Jedes Produkt hat im Tab Options eine Sichtbarkeitseinstellung (in älteren 1.6-Versionen lag sie im SEO-/Zuordnungsbereich). Die vier Werte tun Unterschiedliches, und die Namen werden leicht falsch gelesen:

• Everywhere — wird in Kategorielisten angezeigt und ist in der Suche auffindbar. Der Normalzustand.
• Catalog only — erscheint beim Durchstöbern von Kategorien, wird aber von der internen Suche nicht zurückgegeben.
• Search only — wird von der Suche zurückgegeben, aber beim Durchstöbern von Kategorien nicht gelistet.
• Nowhere — die Produktseite existiert weiterhin unter ihrer URL, aber nichts im Shop verlinkt darauf. Keine Kategorie, keine Suche, kein Menü.

Nowhere ist die Einstellung für Vorab-Launches und „mit ein paar Leuten teilen“: Die Seite ist live, sodass ein direkter Link funktioniert, aber ein zufälliger Besucher stolpert nicht darüber. Der Haken muss klar benannt werden — das ist Verschleierung, keine Sicherheit. Die URL ist erratbar, wenn Ihre Slugs einem Muster folgen, und das Produkt kann je nach Sitemap-Modul und Konfiguration weiterhin in Ihrer Sitemap enthalten sein — prüfen Sie das erzeugte XML, denn eine Sitemap, die es listet, würde das „Geheimnis“ direkt an Google weitergeben. Behandeln Sie „Nowhere“ als ausreichend für ein unkritisches Vorab-Muster, aber nie als Schutz für etwas, das wirklich wichtig ist. Das saubere Vorab-Rezept: Sichtbarkeit auf Nowhere setzen, die URL mit den wenigen Personen teilen, die sie brauchen, und am Veröffentlichungstag auf Everywhere umstellen.

Methode 4 — Wartungsmodus: den ganzen Shop während des Aufbaus verbergen

Unter Shop Parameters → General → Maintenance können Sie die Shopoberfläche komplett abschalten und durch eine Wartungsseite ersetzen, während Sie Ihre eigenen IPs freigeben (das Feld Maintenance IP — „Add my IP“ trägt die IP ein, mit der Sie gerade verbunden sind), damit Sie und Ihr Kunde den Live-Shop weiterhin sehen.

Das ist in zwei Momenten wirklich nützlich: wenn Sie einen neuen Shop aufbauen, der noch nicht indexiert oder gefunden werden soll, und wenn Sie ein Redesign für einen Kunden vor dem Go-live zur Vorschau bereitstellen. Was es nicht ist: ein Zugriffskontrollsystem — es ist alles oder nichts. Sie können nicht einen Bereich für Mitglieder öffnen und den Rest schließen; alle außerhalb der IP-Liste sehen dieselbe Sperre. Für dauerhaftes „Mitglieder sehen X, die Öffentlichkeit sieht Y“ sind Gruppen zuständig (Methode 1), nicht der Wartungsmodus. Während der Shop im Wartungsmodus ist, gibt er HTTP 503 zurück, was das richtige Signal für Crawler ist: „später wiederkommen“ statt „das ist verschwunden“.

Methode 5 — Eine bestimmte Seite per Passwort schützen (die native Lücke)

Die Passwortsperre wird im Modul konfiguriert, einschließlich Mitarbeiter-Bypass und noindex-Verhalten.

Das Modul Password Protect sperrt Anfragen früh über den Dispatcher-Hook, bevor der Seiteninhalt gerendert wird:

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

Hier liegt der Fall, den die Plattform nicht abdeckt. Es gibt keine native PrestaShop-Einstellung, um eine einzelne CMS-Seite, Kategorie oder ein einzelnes Produkt hinter eine einfache Passwortabfrage zu legen. Die nativen Werkzeuge sind entweder kontobasiert (Gruppen) oder alles-oder-nichts (Wartung). Auch das aktuelle Modul mprpasswordprotect ist eine Sperre für die gesamte Shopoberfläche: Es leitet Front-Office- und Modul-Anfragen auf eine gemeinsame Passwortseite um, bis der Besucher sich authentifiziert. Das passt zu Vorab-Shops und privaten Shopoberflächen; es ist noch keine gezielte Steuerung pro Seite, pro Kategorie oder pro Produkt.

Das ausgelieferte Modul ist nützlich, wenn das Ziel eine passwortgeschützte Shopoberfläche ist: ein Shop vor dem Launch, eine private Katalogvorschau oder ein temporärer Kundenbereich zur Abnahme. Es hängt sich in actionDispatcherBefore ein, prüft das geteilte Passwort, setzt ein Front-Office-Cookie und kann eine 503-/noindex-Antwort senden, solange die Sperre aktiv ist. Was bringt Ihnen das konkret? Eine ganze Shopoberfläche kann hinter einem einzigen geteilten Passwort verborgen werden, ohne Core-Änderungen und ohne Reibung durch Kundenkonten. Für eine Händlerpreisliste, eine einzelne CMS-Seite, eine Kategorie oder ein Produkt nutzen Sie native Gruppen/Produktsichtbarkeit, sofern Konten akzeptabel sind — oder betrachten eine Passwortsteuerung pro Entität als fehlende Funktion, die sauber implementiert werden muss.

Seien Sie nüchtern, was ein geteiltes Passwort ist und was nicht: ein Geheimnis, das alle kennen, die es haben, ohne Prüfspur pro Benutzer. Das ist das richtige Gewicht für „mäßig private Inhalte mit begrenztem Schadensradius“ (ein saisonales Lookbook, ein Partnerblatt). Für rechtlich sensible Daten ist es das falsche Gewicht — siehe dazu den Sicherheitshinweis unten.

Methoden für echte Szenarien kombinieren

Die meisten produktiven Setups stapeln zwei oder drei dieser Methoden, weil sich die Absichten überschneiden:

• Großhandelskatalog: Kundengruppen zur Beschränkung der Handels-Kategorien + ein Prüfschritt vor der Gruppenzuweisung + gruppenspezifische Preise. Wenn Sie zusätzlich Angaben für eine Handelsanfrage erfassen (USt-IdNr., Unternehmensart), finden Sie die Muster zum Erfassen und Auswerten zusätzlicher Registrierungsdaten in zusätzliche Kundendaten und IP-Sperren.
• Produkt vor dem Launch: Sichtbarkeit auf Nowhere + ein geteilter Link an wenige Personen + am Veröffentlichungstag auf Everywhere umstellen.
• Seite nur für Mitglieder: Kundengruppen, wenn Mitglieder bereits Konten haben; eine Passwortsperre pro Seite braucht eine gezielte Modulimplementierung, während das aktuelle Modul Password Protection die Shopoberfläche insgesamt sperrt.
• Neuer Shop im Aufbau: Wartungsmodus mit Ihrer freigegebenen IP bis zum Launch.

Die SEO-Falle: in der Oberfläche verborgen, in Google indexiert

PrestaShop erzeugt selbst keine XML-Sitemaps, daher gehört der Ausschluss in das Sitemap-Modul, das Sie verwenden, etwa gsitemap oder Advanced SEO Sitemap Builder.

Die Zugriffssperre und die Sitemap-Regeln müssen übereinstimmen.

Der häufigste Fehler hier ist keine Einstellung, die nicht funktioniert — sondern eine „verborgene“ Seite, die für Crawler still öffentlich bleibt. Zwei Regeln halten private Inhalte privat:

• Gruppenbeschränkte Inhalte sind standardmäßig sicher. Weil ein Crawler ein nicht authentifizierter Visitor ist, ist alles, was Sie vor der Visitor-Gruppe verbergen, auch vor Googlebot verborgen. Kein zusätzlicher Schritt nötig.
• Die Sichtbarkeit „Nowhere“ ist standardmäßig nicht sicher. Die Seite existiert weiterhin, und wenn Ihr SEO-/Sitemap-Modul sie einbezieht, haben Sie die URL bei Google veröffentlicht. Prüfen Sie, dass nicht verlinkte Produkte aus der Sitemap ausgeschlossen sind, und setzen Sie für alles, was wirklich privat bleiben muss, eine noindex-Anweisung, statt sich auf „niemand verlinkt darauf“ zu verlassen.

Wenn Sie eine SEO-/Sitemap-Suite nutzen, prüfen Sie, was sie tatsächlich ausgibt, bevor Sie einer Einschränkung vertrauen — eine großzügige Sitemap kann eine sorgfältige Sichtbarkeitseinstellung rückgängig machen. Und denken Sie daran: Eine passwortgeschützte Seite hätte von Anfang an nie in einer öffentlichen Sitemap erscheinen dürfen; die Sperre kümmert sich um Menschen, der Sitemap-Ausschluss um Bots.

Wo Zugriffskontrolle endet und Sicherheit beginnt

Diese Grenze müssen Sie verinnerlichen. Alles oben steuert, was einem Browser angezeigt wird. Nichts davon verschlüsselt Dateien oder garantiert, dass eine entschlossene Person nicht an das zugrunde liegende Asset kommt. Konkret:

• Die Bilder eines Produkts liegen unter vorhersehbaren URLs und können möglicherweise direkt abgerufen werden, selbst wenn die Produktseite eingeschränkt ist, weil Bilddateien nicht hinter derselben Zugriffskontrolle liegen wie die Seite.
• Eine „Nowhere“- oder geteilte URL kann über den Browserverlauf, Referrer-Header oder durch Weiterleiten des Links durchsickern.
• Inhalte, die in die Seite geladen, aber per CSS verborgen werden, stehen weiterhin im Quelltext der Seite für jeden, der die Entwicklertools öffnet.

Für wirklich vertrauliches Material — unterschriebene Preisverträge, juristische Dokumente, alles, bei dem eine Offenlegung ein echtes Problem wäre — sollten Sie sich daher gar nicht auf die Sichtbarkeit der Shopoberfläche verlassen. Stellen Sie es über ein sauber abgesichertes System mit echter Authentifizierung und idealerweise Dateischutz auf Serverebene bereit. Die Sichtbarkeitssteuerungen von PrestaShop sind für kommerzielle Zugriffskontrolle gebaut (wer bekommt den Großhandelspreis), nicht für den Schutz sicherheitskritischer Daten. Wenn Sie den Shop insgesamt härten, behandeln die .htaccess-Regeln für Sicherheit und Performance den Schutz von Dateien und Verzeichnissen auf Serverebene, und der verständliche Leitfaden zur Absicherung Ihres Shops liefert den größeren Kontext. Und falls etwas Privates bereits offengelegt wurde, ist der Leitfaden zur Reaktion auf Datenpannen die nächste Seite, die Sie lesen sollten.

Häufig gestellte Fragen

Wie schütze ich eine einzelne CMS-Seite oder ein Produkt in PrestaShop per Passwort?

Dafür gibt es keine native PrestaShop-Einstellung — die nativen Werkzeuge sind entweder kontobasiert (Kundengruppen) oder alles-oder-nichts (Wartungsmodus). Das aktuelle Modul mprpasswordprotect legt die gesamte Shopoberfläche hinter ein geteiltes Passwort. Das passt zu einem Shop vor dem Launch oder einer privaten Vorschau, ist aber noch nicht pro Seite, pro Kategorie oder pro Produkt nutzbar. Für eine einzelne Seite, bei der Konten akzeptabel sind, verwenden Sie Kundengruppen; echte Passwortsteuerung pro Entität ist eine Funktion, die eine eigene Implementierung braucht.

Was ist der Unterschied zwischen B2B-Modus und dem Ausblenden von Preisen?

Das sind getrennte Steuerungen, die oft vermischt werden. Der B2B-Modus (Shop Parameters → Customer Settings) ergänzt nur Geschäftsfelder und Infrastruktur für Kreditverwaltung — Company, SIRET, APE, allowed outstanding amount, payment days, risk rating. Er blendet keine Preise aus und ergänzt keine Kontofreigabe. Um Preise auszublenden, öffnen Sie eine Gruppe und deaktivieren Show prices für die Gruppe Visitor (und Guest). Ein reiner Handelsshop braucht beides: den B2B-Modus für die Felder, die Gruppenoption für die Preise.

Ist ein Produkt privat, wenn ich es auf „Nowhere“ setze?

Nein — das ist Verschleierung, keine Sicherheit. Die Produktseite existiert weiterhin unter ihrer URL, sodass ein direkter Link funktioniert; „Nowhere“ bedeutet nur, dass nichts im Shop darauf verlinkt. Die URL ist erratbar, wenn Ihre Slugs einem Muster folgen, und je nach Sitemap-Modul kann sie trotzdem bei Google veröffentlicht werden. Nutzen Sie diese Einstellung für unkritische Vorab-Muster, prüfen Sie, dass sie aus Ihrer erzeugten Sitemap ausgeschlossen ist, und setzen Sie für alles, was wirklich aus der Suche herausbleiben muss, eine noindex-Anweisung.

Bleibt ein Produkt oder eine Kategorie auch aus Google heraus, wenn ich es verberge?

Das hängt davon ab, welche Methode Sie verwendet haben. Gruppenbeschränkte Inhalte sind standardmäßig sicher — ein Crawler ist ein nicht authentifizierter Visitor, also ist alles, was vor der Visitor-Gruppe verborgen ist, auch vor Googlebot verborgen, ohne zusätzlichen Schritt. Die Sichtbarkeit „Nowhere“ ist nicht standardmäßig sicher: Die Seite existiert, und ein großzügiges Sitemap-Modul kann die URL erneut veröffentlichen. Prüfen Sie immer das XML, das Ihr Sitemap-Modul tatsächlich ausgibt, bevor Sie einer Sichtbarkeitseinstellung vertrauen.

Kann ich diese Werkzeuge zum Schutz rechtlich sensibler Dokumente verwenden?

Nein. Jede Methode hier steuert, was einem Browser angezeigt wird; keine verschlüsselt Dateien. Produktbilder liegen unter vorhersehbaren URLs und können abrufbar sein, selbst wenn die Seite eingeschränkt ist, geteilte Links sickern über Verlauf und Referrer-Header durch, und per CSS verborgene Inhalte stehen weiterhin im Quelltext der Seite. Für unterschriebene Verträge, juristische Dokumente oder alles, bei dem eine Offenlegung ein echtes Problem wäre, stellen Sie die Inhalte über ein sauber abgesichertes System mit echter Authentifizierung und Dateischutz auf Serverebene bereit — nicht über die Sichtbarkeit der Shopoberfläche.

Die Quintessenz: „Vor der Öffentlichkeit verbergen“ zerfällt in vier Aufgaben — eine Zielgruppe verbergen (Gruppen), ein einzelnes Produkt verbergen (Sichtbarkeit), den ganzen Shop verbergen (Wartung) oder eine Seite schützen (Passwortmodul) — und jedes native Werkzeug garantiert etwas anderes. Passen Sie das Werkzeug an die Absicht an, prüfen Sie doppelt, dass Ihre Sitemap nicht still wieder veröffentlicht, was Sie verborgen haben, und verwechseln Sie weniger anzeigen nie mit absichern. Dann erreichen die richtigen Inhalte die richtigen Menschen, ohne dass eine private Preisliste in den Suchergebnissen von irgendjemandem auftaucht.