Passwortschutz bedeutet hier, eine Website oder einzelne Verzeichnisse per Benutzername und Passwort zu sperren, meist über HTTP Basic Authentication auf dem Webserver. Wer keine Zugangsdaten schickt, erhält statt der Seite eine Antwort mit Status 401.
Wie funktioniert Basic Auth?
Der Server antwortet auf eine Anfrage ohne Zugangsdaten mit 401 und dem Header WWW-Authenticate. Der Browser fragt nach Benutzername und Passwort und sendet sie beim nächsten Aufruf im Authorization-Header. Bei Basic Auth steht dort Basic und das Paar aus Benutzername und Passwort, Base64-codiert.
Base64 ist eine reversible Kodierung. MDN weist darauf hin, dass Basic Auth deshalb nur über HTTPS genutzt werden sollte, sonst lassen sich die Zugangsdaten mitlesen.
Typische Einsatzfälle sind Staging-Umgebungen, Testserver und interne Bereiche.
Passwortschutz und SEO
Laut RFC 9110 bedeutet 401, dass die Anfrage keine gültigen Zugangsdaten enthält. Crawler ohne Zugangsdaten erhalten daher 401 statt Inhalt. Google nennt den Passwortschutz in der Dokumentation zum Entfernen von Inhalten als Weg, eine Seite für Googlebot und andere Crawler unzugänglich zu halten, während berechtigte Nutzer sie sehen. Außerdem verwendet Google keine Inhalte von URLs mit 4xx-Status, zu denen 401 zählt, und entfernt bereits indexierte URLs aus dem Index. Google schreibt in der robots.txt-Einführung, dass robots.txt kein Mechanismus ist, um eine Seite aus Google herauszuhalten. Dafür nennt Google noindex oder Passwortschutz. Eine per robots.txt blockierte URL kann weiterhin in den Suchergebnissen erscheinen, wenn andere Seiten mit beschreibendem Text auf sie verlinken.
Für Staging gilt deshalb: Wird der Schutz beim Livegang nicht entfernt, bleibt die Live-Seite unerreichbar. Umgekehrt gilt, dass ein Testserver ohne Schutz und ohne noindex indexiert werden kann.
| Mittel | Verhindert Crawling? | Hält die URL aus der Suche? | Was Google dazu schreibt | Typischer Einsatz |
|---|---|---|---|---|
robots.txt Disallow | ja | nein, die URL kann ohne Inhalt indexiert werden, wenn andere Seiten auf sie verlinken | dient vor allem dazu, den Server nicht mit Anfragen zu überlasten; kein Mittel, eine Seite aus Google herauszuhalten | Crawler-Last begrenzen, Bereiche vom Abruf ausnehmen |
noindex im Robots-Meta-Tag | nein, Google muss die Seite abrufen können | ja | wirkt nur, wenn die Seite nicht per robots.txt gesperrt ist; Google entfernt die Seite dann, auch wenn andere Websites auf sie verlinken | HTML-Seiten, die erreichbar bleiben, aber nicht in den Suchergebnissen erscheinen sollen |
noindex im HTTP-Header X-Robots-Tag | nein, Google muss die URL abrufen können | ja | jede Regel des Robots-Meta-Tags ist auch als Header möglich; gleiche Voraussetzung wie beim Meta-Tag | Dateien ohne HTML-Head wie PDFs, Bilder oder Videos |
rel="canonical" | nein | nicht direkt; starkes Signal dafür, welche von mehreren gleichen URLs kanonisch wird | hilft, Signale wie Links auf die bevorzugte URL zu bündeln; für die Kanonisierung weder robots.txt noch noindex verwenden | Duplikate und sehr ähnliche Seiten, etwa durch Parameter |
| Statuscode 410 (oder 404) | nein, Google ruft die URL aber nach und nach seltener ab | ja, eine bereits indexierte URL wird entfernt | behandelt 404 und 410 gleich | Seite dauerhaft entfernt, es gibt keinen Ersatz |
| Passwortschutz (Login) (dieser Begriff) | ja, Crawler erreichen die Inhalte nicht | ja | einer der Wege, die Google für das dauerhafte Entfernen nennt; berechtigte Nutzer sehen die Seite, Crawler nicht | Private oder vertrauliche Inhalte |
| Search Console: Entfernungen | nein, Google kann die URL weiter crawlen | blendet die URL für etwa sechs Monate aus den Suchergebnissen aus | nur vorübergehend; dauerhaft wirken 404/410, Passwortschutz oder noindex | Eilfall, bis eine dauerhafte Maßnahme greift |
robots.txt und noindex schließen sich gegenseitig aus. Ist eine URL per robots.txt gesperrt, liest Google das noindex nie, und die URL kann trotzdem in den Ergebnissen erscheinen. noindex in der robots.txt selbst unterstützt Google nicht. Quellen: Google Search Central: Introduction to robots.txt (last updated 2025-12-10); Google Search Central: Block Search indexing with noindex (last updated 2025-12-10); Google Search Central: Robots meta tag, data-nosnippet, and X-Robots-Tag specifications (last updated 2026-03-24); Google Search Central: How to specify a canonical URL (last updated 2026-07-10); Google Crawling Infrastructure: How HTTP status codes affect Google's crawlers (last updated 2026-02-04); Google Search Central: Remove information from Google (last updated 2025-12-10); Search Console Help: Removals and SafeSearch reports tool. Stand: .
Beispiel
AuthType Basic
AuthName "Zugang zur Staging-Seite"
AuthUserFile /pfad/zur/.htpasswd
Require valid-user
Die Datei .htpasswd enthält die Benutzer mit gehashten Passwörtern und gehört außerhalb des öffentlich erreichbaren Verzeichnisses.
Häufige Fehler
- Basic Auth über HTTP statt HTTPS.
- Schutz bleibt nach dem Relaunch auf der Live-Domain aktiv.
- Syntaxfehler in der
.htaccessführen zu einem 500-Fehler (Praxiserfahrung). - Eine Seite, die in der Suche erscheinen soll, ist versehentlich geschützt. Die Search Console führt dafür den Status „Blocked due to unauthorized request (401)“ (englische Bezeichnung): Die Seite wurde für Googlebot durch eine Autorisierungsanfrage gesperrt.
Quellen
- HTTP authentication – MDN Web Docsdeveloper.mozilla.org
- Einführung in robots.txt – Google Search Centraldevelopers.google.com
- Verzeichnisschutz mit .htaccess einrichten – speedIT Wissensdatenbank (ergänzend)speedit.org
- RFC 9110: HTTP Semantics, 15.5.2 401 Unauthorized – IETFrfc-editor.org
- Entfernen von Informationen aus der Google Suche – Google Search Centraldevelopers.google.com
- Page indexing report – Search Console Help (Blocked due to unauthorized request (401))support.google.com
Stand: