Nicht jede statische Website ist in dem Moment bereit für das öffentliche Web, in dem sie hochgeladen wird.
Ein Kundenpreview enthält vielleicht noch Entwurfstexte. Eine Portfolio-Case-Study soll nur von einer bestimmten Recruiterin gesehen werden. Interne Dokumente sind für das Team nützlich, aber nicht für Suchergebnisse gedacht. Eine Launch-Seite braucht Freigabe, bevor die Domain öffentlich beworben wird.
Genau dafür ist Passwortschutz sinnvoll. Er ist kein vollständiges Identitätssystem. Er ist ein gemeinsames Tor vor statischen Inhalten, wenn vor dem Anzeigen ein wenig kontrollierter Zugriff nötig ist.
Wofür Passwortschutz gut ist
Statische Websites haben oft eine private Zwischenphase. Die Website ist gebaut. Die Dateien existieren. Der Link funktioniert. Aber die Zielgruppe ist noch begrenzt.
| Anwendungsfall | Warum ein Passwort-Gate hilft |
|---|---|
| Kundenreview | Stakeholder prüfen eine echte URL, bevor der öffentliche Launch startet. |
| Interne Dokumente | Teams teilen statische Notizen, Handbücher oder Projektseiten, ohne sie für alle zu öffnen. |
| Portfolio-Review | Ausgewählte Case Studies können privat an Recruiter, Kunden oder Interviewer gesendet werden. |
| Studien- oder Teamprojekt | Prüfer öffnen das Projekt, während das Team entscheidet, was dauerhaft öffentlich bleiben soll. |
| Kampagnen-Staging | Text, Tracking-Links, Assets und mobile Layouts werden vor der Promotion geprüft. |
| PDF- oder Asset-Sammlung | Eine statische Seite kann Dokumente, Dateien oder Referenzmaterial hinter einem Zugriffsschritt bündeln. |
Es geht nicht um Schutz gegen gezielte Angriffe. Es geht darum, versehentliche öffentliche Verbreitung zu vermeiden, während Arbeit geprüft, freigegeben oder überarbeitet wird.
Passwort-Gate, noindex oder vollständige Authentifizierung?
Das sind unterschiedliche Werkzeuge. Wer sie gleichsetzt, erzeugt falsche Erwartungen.
| Werkzeug | Was es leistet | Was es nicht leistet |
|---|---|---|
| Passwortschutz | Blockiert beiläufigen Zugriff mit einem gemeinsamen Passwort, bevor die Website ausgeliefert wird. | Erstellt keine Nutzerkonten, Rollen, Audit-Logs oder SSO. |
noindex | Bittet Suchmaschinen, eine Seite nicht in Suchergebnissen zu zeigen. | Verhindert nicht, dass jemand mit URL die Seite öffnet. |
robots.txt | Gibt Crawlern öffentliche Hinweise zu Pfaden. | Ist öffentlich und sollte nicht als Schutz behandelt werden. |
| Vollständige App-Authentifizierung | Verwaltet Nutzer, Sitzungen, Berechtigungen und Identität. | Erfordert App-Logik, nicht nur statisches Hosting. |
| Netzwerkzugriffskontrolle | Beschränkt Zugriff über Identity Provider, Gerät, IP oder Organisationsrichtlinien. | Ist schwergewichtiger, als die meisten Kundenpreviews brauchen. |
Google beschreibt noindex als Steuerung der Indexierung. Das ist nützlich, wenn eine Seite nicht in der Suche erscheinen soll, aber es ist keine Datenschutzgrenze. Cloudflare Access und Vercel Deployment Protection zeigen das andere Ende: stärkere Zugriffssysteme für Anwendungen und Deployments. Ein einfaches Passwort-Gate liegt dazwischen.
Die ganze statische Erfahrung schützen, nicht nur die Homepage
Eine statische Website ist mehr als index.html.
Wenn nur die Homepage geschützt ist, Bilder, Skripte, PDFs oder Deep Links aber öffentlich bleiben, kann der Preview trotzdem leaken. Ein sinnvoll geschützter statischer Preview setzt die Zugriffskontrolle vor die veröffentlichte Erfahrung, inklusive der Dateien, die die Seite ausmachen.
Vor dem Teilen eines geschützten Links sollten diese Pfade geprüft werden:
| Pfadtyp | Was prüfen |
|---|---|
| Homepage | Der erste Besuch fragt nach dem Passwort. |
| Deep Links | Projektseiten, Dokumentseiten oder Kampagnen-Unterseiten erfordern ebenfalls Zugriff. |
| Assets | Bilder, PDFs, Skripte und Downloads sind nicht über offensichtliche Direktlinks offen. |
| Formulare | Falls ein Formular existiert, verhält es sich nach Freigabe korrekt. |
| Fehlerseiten | 404- oder Fallback-Seiten verraten keine sensiblen Texte oder Dateinamen. |
Das ist besonders wichtig bei Portfolios und Kundenarbeit. Eine redigierte Homepage hilft wenig, wenn unveröffentlichte Screenshots weiterhin unter /assets/client-redesign-final.png erreichbar sind.
Den richtigen Passwort-Workflow wählen
Geteilte Passwörter sind einfach zu betreiben. Disziplin brauchen sie trotzdem.
| Situation | Praktische Gewohnheit |
|---|---|
| Ein kurzer Review-Zyklus | Ein starkes gemeinsames Passwort nutzen und nach dem Review rotieren. |
| Mehrere Kundenteams | Separate Projekte oder Review-Links verwenden, wenn Zielgruppen getrennt bleiben sollen. |
| Link wurde zu breit weitergeleitet | Passwort ändern und nur an die vorgesehenen Personen senden. |
| Projekt wird öffentlich | Passwortschutz nach finaler Freigabe und Domain-Launch deaktivieren. |
| Arbeit bleibt sensibel | Öffentliche Seite redigieren und Details nur genehmigten Personen zeigen. |
Für einen Kundenpreview sollte kein leicht merkbares Spaßpasswort verwendet werden. Nimm ein ausreichend langes Passwort und teile es über einen Kanal, der zur Sensibilität der Arbeit passt.
Wo Passwortschutz nicht reicht
Passwortschutz ist nützlich, weil er leichtgewichtig ist. Genau dort liegt auch seine Grenze.
Ein echtes Authentifizierungsmodell ist nötig, wenn du brauchst:
- Nutzerkonten oder Einladungen pro Person.
- Unterschiedliche Berechtigungen je Zuschauer.
- SSO über Google Workspace, Microsoft Entra, Okta oder andere Identity Provider.
- Audit-Logs, die zeigen, wer was angesehen hat.
- Rechtliche, Compliance- oder Vertragsanforderungen an Zugriff.
- Entzug für eine einzelne Person, ohne alle anderen zu ändern.
- Sensible Kundendaten, Zahlungsdaten, Gesundheitsdaten oder regulierte Datensätze.
Für einen statischen Preview ist ein gemeinsames Passwort oft die richtige Menge Kontrolle. Für ein Kundenportal, internes System oder regulierten Workflow ist es das nicht.
Häufige Fehler bei geschützten statischen Previews
Die meisten Probleme sind klein, aber lästig.
| Fehler | Besserer Ansatz |
|---|---|
| Öffentlichen Link senden, bevor Schutz aktiv ist | Gate zuerst aktivieren, dann in einem privaten Browserfenster testen. |
| Deep Links vergessen | Projektseiten, Dokumentseiten, Assets und PDFs direkt öffnen. |
| Ein Passwort dauerhaft verwenden | Nach Review-Zyklen, Launches oder versehentlichem Weiterleiten rotieren. |
noindex als Privatsphäre behandeln | noindex für Suchverhalten nutzen, nicht für Zugriffskontrolle. |
| Vertrauliche Details veröffentlichen | Namen, Metriken, Screenshots und private Pfade vor dem Upload redigieren. |
| Gate nach Launch versehentlich behalten | Entscheiden, ob die finale Website öffentlich, geschützt oder aufgeteilt sein soll. |
Ein geschützter Preview braucht denselben Inhaltscheck wie eine öffentliche Website. Passwörter reduzieren versehentliche Offenlegung; sie machen unvorsichtiges Publizieren nicht harmlos.
Wie das in statisches Deployment passt
Passwortschutz funktioniert am besten, wenn er Teil des Deployment-Flows ist und nicht später angeklebt wird.
Ein praktischer Ablauf:
- Statische Website bauen oder exportieren.
- Ordner, ZIP, HTML-Output, Framework-Build, Portfolio oder PDF-gestützte Seite hochladen.
- Passwortschutz aktivieren, bevor der Preview geteilt wird.
- Link und Passwort an Reviewer senden.
- Text, Dateien, mobile Darstellung und Assets korrigieren.
- Passwort rotieren, wenn sich die Zielgruppe ändert.
- Schutz entfernen oder beibehalten, wenn die finale Veröffentlichungsentscheidung fällt.
So bleibt der Review nah an der echten Website. Reviewer sehen dieselben Routen, Assets und responsiven Verhaltensweisen, die später auch die öffentliche Version nutzen wird.
Wie DeployPages diesen Fall abdeckt
DeployPages ist auf statisches Publizieren ausgelegt. Deshalb ist Passwortschutz für statische Previews und privates Teilen gedacht, nicht als Backend-Auth-System.
Du kannst einen statischen Ordner, ZIP, ein HTML-Projekt, Portfolio, Docs-Export, eine AI-generierte Website oder eine Seite mit PDF-Assets veröffentlichen und danach in den Projektkontrollen Passwortschutz aktivieren, sofern der aktuelle Workspace-Plan ihn enthält. Besucher müssen das Projektpasswort eingeben, bevor sie die veröffentlichte Website sehen. Dasselbe Projekt kann außerdem Analytics, Custom Domains, Instant Rollback und CLI Deploys nutzen.
Der geschützte Preview bleibt dadurch schlicht: Website hochladen, während der Review-Phase schützen und danach entscheiden, ob die finale Version privat bleibt oder auf eine öffentliche Domain wechselt.
Checkliste vor dem Teilen
Bevor du eine passwortgeschützte statische Website versendest:
- Link in einem privaten Browserfenster öffnen und Passwortscreen prüfen.
- Einen Deep Link testen, nicht nur die Homepage.
- Direkte Links zu wichtigen PDFs, Bildern, Skripten und Downloads testen.
- Vertrauliche Namen, private Metriken, interne Kommentare und Entwurfspfade entfernen.
- Ein starkes gemeinsames Passwort nutzen und es so speichern, dass das Team es rotieren kann.
- Passwort getrennt vom Link teilen, wenn die Arbeit sensibel ist.
- Entscheiden, wann Schutz entfernt, rotiert oder beibehalten wird.
- Vor dem Ersetzen einer geprüften Version einen Rollback-Pfad behalten.
Passwortschutz ist nicht dazu da, eine statische Website kompliziert zu machen. Er macht die private Phase weniger riskant, während Arbeit bewertet, korrigiert und freigegeben wird.