401 Unauthorized Fehler: Bedeutung, Ursachen und Lösung

Was ist der 401 Unauthorized Fehler?

Der 401 Unauthorized Fehler ist ein HTTP Statuscode, der besagt, dass der Server Ihre Anfrage ablehnt, weil er keine gültigen Zugangsdaten findet. Entweder hat der Server gar keinen Benutzernamen samt Passwort gesehen, oder er erkennt die gesendeten Daten nicht an. Meist liefert er einen Header WWW-Authenticate mit, der die erwartete Anmeldemethode nennt.

Wir sind ein Team für digitales Marketing und Webentwicklung, kein Hostinganbieter. Die technischen Erklärungen stützen sich auf RFC 9110, MDN, Google Search Central und die Apache Dokumentation. Unser Ziel ist also einfach: Sie sollen beim Anblick dieses Codes schnell erkennen, wer was beheben muss.

Laut der MDN Referenz zeigt der Code, dass der Anfrage gültige Zugangsdaten für die Ressource fehlen. Trotz des Namens bedeutet er meist "wir konnten Ihre Identität nicht prüfen" und nicht "Sie haben keine Berechtigung". Daher trennt dieser Unterschied den Fehler 401 vom Fehler 403.

Was ist der Unterschied zwischen 401 und 403?

Bei einem 401 weiß der Server nicht, wer Sie sind, oder er kann Ihre Zugangsdaten nicht prüfen. Bei einem 403 hat der Server die Anfrage verstanden und verweigert sie trotzdem. Beim 401 lautet die Lösung deshalb oft "anmelden oder die richtigen Daten senden", beim 403 müssen Berechtigung, Regel oder Firewall Einstellung angepasst werden.

Die folgende Tabelle ordnet beide Codes nach Verantwortlichkeit. Nach RFC 9110 muss ein Server in eine 401 Antwort den Header WWW-Authenticate einfügen. Zudem gilt diese Pflicht für eine 403 Antwort nicht.

Sehen Sie einen 403, liegt das Problem meist in einer Firewall oder in Dateirechten. Das behandeln wir hier nicht; lesen Sie dazu unseren Beitrag über ModSecurity und den 403 Fehler.

Wer behebt den 401 Unauthorized Fehler: Besucher, Websitebetreiber oder Serveradministrator?

Wer zuerst die zuständige Person bestimmt, spart Stunden bei der Suche am falschen Ort. Denn die Person, die den Fehler sieht, kann ihn oft nicht beheben. Die erste Frage lautet deshalb immer: Hat jemand diese Seite absichtlich mit einem Passwort versehen?

• Besucher: Gibt Benutzernamen und Passwort korrekt ein oder löscht die alte Sitzung beziehungsweise das gespeicherte Passwort im Browser.
• Websitebetreiber: Findet heraus, welcher Ordner, welche Anwendung oder welche Integration den Schutz trägt, und entfernt ihn, falls er nicht dorthin gehört.
• Serveradministrator: Prüft die Regeln für die Anmeldung in der Apache oder Nginx Konfiguration, die Passwortdatei und die Proxy Einstellungen.

Zum Beispiel: Sagt ein Kunde "unsere Seite fragt nach einem Passwort", prüfen Sie zuerst, ob ein Schutz der Testumgebung auf die Live Seite gelangt ist. Deshalb löst diese eine Kontrolle überraschend viele Fälle, bevor jemand einen neuen Benutzer anlegt.

Zudem erreichen Sie bei Shared Hosting die Einstellungen auf Serverebene nicht. Dann schicken Sie Ihrem Anbieter am schnellsten die Belege und lassen ihn prüfen.

Was sagt der Header WWW Authenticate aus?

Der Header WWW-Authenticate ist die Antwort des Servers auf eine ungeprüfte Anfrage: "Weisen Sie sich auf diese Art aus". Er nennt also das Verfahren und oft einen Realm. Sobald der Browser ihn sieht, öffnet er das Fenster für Benutzername und Passwort.

Eine typische Antwort sieht so aus:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="Staging"
Content-Type: text/html

Dabei steht "Basic" für das Verfahren und "Staging" für den Bereichsnamen im Dialog. Bei APIs kann derselbe Header ein anderes Verfahren nennen, etwa Bearer. Konkret zeigt das Beispiel von MDN genau eine solche Bearer Aufforderung.

Wiederholt der Client die Anfrage mit richtigen Daten, sendet er einen Authorization Header. Akzeptiert der Server ihn, erhalten Sie ein 200, sonst wieder ein 401. Liest man beide Header zusammen, sieht man schnell, auf welcher Seite das Problem liegt.

Warum tritt ein 401 Unauthorized Fehler auf?

Zunächst fallen die meisten Ursachen in wenige Gruppen. Wenn Sie Ihre Gruppe kennen, verkürzt das daher die Diagnose.

• Ein Ordner oder die ganze Seite nutzt Basic Auth, und niemand hat Zugangsdaten eingegeben.
• Benutzername oder Passwort sind falsch, oder die Passwortdatei ist veraltet.
• Einer API Anfrage fehlt das Token, es ist abgelaufen oder trägt das falsche Schema.
• Das Sitzungscookie ist verschwunden, oder die Serversitzung ist zu Ende.
• Ein Reverse Proxy oder CDN reicht den Authorization Header nicht an den Ursprungsserver weiter.
• Jemand hat den Schutz der Testumgebung in die Produktion kopiert.

Außerdem kann ein Sicherheits Plugin oder ein Hosting Panel bestimmte Pfade wie einen Admin oder API Pfad mit einem zusätzlichen Passwort schützen. Meist schaltet jemand das bewusst ein, doch nach einigen Monaten weiß es niemand mehr.

Kurz gesagt: Ein 401 ist selten eine Störung. Meist zeigt er, dass eine Regel funktioniert. Somit lautet die eigentliche Frage, ob diese Regel dort hingehört.

In welcher Reihenfolge diagnostizieren Sie einen 401 Fehler?

Ändern Sie nicht wahllos Einstellungen, sondern folgen Sie einer festen Reihenfolge. Somit schließt jeder Schritt eine Möglichkeit aus.

1. Öffnen Sie die Adresse in einem privaten Fenster. Lag es an einer alten Sitzung oder einem gespeicherten Passwort, verschwindet der Fehler.
2. Senden Sie eine Anfrage über die Kommandozeile, damit Sie die Header sehen.
3. Lesen Sie den Wert von WWW-Authenticate und notieren Sie das Verfahren.
4. Probieren Sie dieselbe Adresse aus einem anderen Netz, denn eine Regel kann bestimmte IP Adressen treffen.
5. Lesen Sie das Fehlerprotokoll des Servers und suchen Sie die Zeile zur Anmeldung.
6. Denken Sie an die letzte Änderung: Ging ein neues Plugin, eine Panel Einstellung oder ein Deployment live?

Die Header sehen Sie mit diesem Befehl:

curl -I https://example.com/geschuetzte-seite/

Zeigt die erste Zeile 401 und folgt ein Header WWW-Authenticate, liegt das Problem in einer Regel zur Anmeldung. Fehlt der Header, schreibt dann wahrscheinlich ein Proxy oder die Anwendung die Antwort um.

Haben Sie keinen Zugriff auf die Serverprotokolle, überlassen Sie diesen Schritt Ihrem Anbieter. Eine Protokollzeile zeigt meist, welche Regel den Fehler ausgelöst hat; Sie müssen also nur den passenden Zeitraum anfragen.

Was tun Besucher bei einem 401 Unauthorized Fehler?

Als Besucher können Sie nur wenig tun, aber oft genügt es dennoch. Prüfen Sie zunächst, ob Sie die Adresse richtig getippt haben, denn ein falscher Unterordner führt manchmal in einen Adminbereich.

• Handelt es sich um einen privaten Bereich, geben Sie Benutzernamen und Passwort erneut ein.
• Löschen Sie das gespeicherte Passwort und die Websitedaten im Browser, dann versuchen Sie es noch einmal.
• Probieren Sie einen anderen Browser oder ein privates Fenster.
• Fragen Sie den Websitebetreiber nach dem Passwort und raten Sie nicht.

Sehen Sie den Fehler auf einer Seite, die öffentlich sein sollte, liegt das Problem nicht bei Ihnen. Schicken Sie dem Websitebetreiber dann die Adresse und den Zeitpunkt des Fehlers, damit die Diagnose kurz bleibt.

Außerdem deutet ein 401 auf einer öffentlichen Seite auf eine falsche Konfiguration hin. Besucher springen dann ab, und Suchmaschinen können die Seite ebenfalls nicht lesen.

Wie funktionieren Basic Auth und die Datei .htpasswd?

Basic Auth ist das einfachste Anmeldeverfahren in HTTP. Der Client verbindet Benutzername und Passwort, kodiert sie mit Base64 und sendet sie im Authorization Header. Base64 ist also keine Verschlüsselung, sondern nur eine Kodierung.

Deshalb warnt die Apache Dokumentation, dass Basic Authentication das Passwort unverschlüsselt überträgt, und empfiehlt mod_ssl für sensible Daten. Das heißt: Basic Auth braucht HTTPS. Zum Zertifikat lesen Sie unseren Beitrag zum SSL Zertifikat.

Eine .htpasswd Datei ist eine einfache Textdatei mit einer Zeile pro Benutzer: Benutzername und Hash des Passworts. Die Datei enthält also den Hash, nicht das Passwort selbst. Apache empfiehlt, sie in einem Verzeichnis abzulegen, das Besucher über das Web nicht erreichen.

Praktische Folge: Legen Sie die Datei in public_html ab, kann schon eine kleine Fehlkonfiguration den Download für jeden öffnen. Halten Sie sie deshalb in Ihrem Home Verzeichnis, außerhalb des Webroots.

Wie schützen Sie ein Verzeichnis unter Apache mit .htpasswd?

Erstellen Sie zuerst die Passwortdatei außerhalb des Webroots. Der Befehl fragt Sie nach dem Passwort, Sie müssen es also nicht in die Kommandozeile tippen.

htpasswd -c /home/benutzer/.htpasswd beispiel_nutzer

Beim zweiten Benutzer lassen Sie die Option -c weg, sonst setzen Sie die Datei zurück. Danach tragen Sie diese Zeilen in die .htaccess Datei des zu schützenden Verzeichnisses ein:

AuthType Basic
AuthName "Staging"
AuthUserFile "/home/benutzer/.htpasswd"
Require valid-user

Diese vier Zeilen sind eine gekürzte Fassung des Beispiels aus der Apache 2.4 Dokumentation. Damit sie greifen, muss die Serverkonfiguration AllowOverride AuthConfig erlauben. Details finden Sie im Apache Leitfaden zur Authentifizierung.

Schreiben Sie außerdem den Dateipfad absolut. Für ein starkes Passwort nutzen Sie unseren Passwort Generator.

Fürchten Sie, die Konfiguration zu beschädigen, legen Sie vorher eine Sicherung an. Testen Sie nach der Änderung eine ungeschützte und eine geschützte Adresse, damit Sie sehen, dass die Regel nur das gewünschte Verzeichnis trifft.

Wie aktivieren Sie Basic Auth in Nginx?

In Nginx erledigen die Direktiven auth_basic und auth_basic_user_file dieselbe Aufgabe. Laut Nginx Dokumentation schaltet auth_basic die HTTP Basic Authentication ein und nutzt Ihren Text als Realm. Die Direktive auth_basic_user_file zeigt auf die Datei mit Benutzernamen und Passwort Hashes.

location /staging/ {
    auth_basic           "Staging";
    auth_basic_user_file /home/benutzer/.htpasswd;
}

Das Dateiformat entspricht Apache. Laut Dokumentation funktionieren Hashes von htpasswd oder openssl passwd. Sie bezeichnet das einfache SHA Format zudem als schwach, wählen Sie also einen modernen Hash.

Laden Sie Nginx allerdings nie neu, ohne die Konfiguration vorher zu testen. Denn ein einziger Tippfehler kann die ganze Seite lahmlegen.

Arbeiten Sie auf einem Live Server und sind unsicher, testen Sie an einer Kopie oder überlassen Sie es Ihrem Hostinganbieter. Eine fehlerhafte Regel kann Ihre gesamte Seite hinter einem 401 oder sogar einem 500 sperren.

Wie schützen Sie einen Ordner mit cPanel Directory Privacy?

Nutzen Sie cPanel, richten Sie denselben Schutz ohne Dateibearbeitung ein. Laut cPanel Dokumentation ändert die Oberfläche Directory Privacy (Verzeichnisschutz) die Dateien .htaccess und .htpasswd für den gewählten Ordner an Ihrer Stelle.

1. Öffnen Sie in cPanel das Werkzeug Directory Privacy.
2. Navigieren Sie zu dem Ordner, den Sie schützen möchten.
3. Aktivieren Sie die Option zum Passwortschutz des Verzeichnisses und geben Sie eine Bezeichnung ein.
4. Fügen Sie den berechtigten Benutzer samt Passwort hinzu und speichern Sie.

Die Bezeichnung erscheint nur als Name in der .htaccess; sie benennt den Ordner nicht um. Zudem erben Unterverzeichnisse den Schutz ihres übergeordneten Ordners.

Eine Grenze ist wichtig: Die cPanel Dokumentation sagt klar, dass dieser Schutz Verzeichnisse nicht abdeckt, die Sie über FTP, SFTP oder Web Disk erreichen. Er sperrt also nur den Webzugriff.

Bewahren Sie deshalb keine geheimen Daten in einem Ordner auf, der nur so geschützt ist. Sensible Dateien außerhalb des Webroots sind daher sicherer.

Warum erscheint die Basic Auth Abfrage immer wieder?

Kehrt der Dialog trotz richtigem Passwort zurück, akzeptiert der Server Ihre Eingabe nicht. Es gibt einige typische Gründe, und Sie schließen sie in wenigen Minuten aus.

• Der Hash in der Passwortdatei passt nicht zum eingegebenen Passwort.
• Der Pfad bei AuthUserFile ist falsch, oder der Server kann die Datei nicht lesen.
• Ein Reverse Proxy oder CDN verwirft den Authorization Header, bevor er den Ursprung erreicht.
• Die Adresse leitet zwischen www und ohne www oder zwischen http und https um.

Vor allem der letzte Punkt überrascht viele. Denn ein Browser merkt sich Zugangsdaten meist für einen bestimmten Ursprung und Realm. Ändert eine Weiterleitung den Ursprung, fragt der Browser erneut. Eine einzige kanonische Adresse hilft daher dem SEO und der Nutzerführung.

Außerdem kann ein Passwort mit Umlauten oder Sonderzeichen einen Konflikt bei der Kodierung auslösen. Probieren Sie zur Diagnose zuerst ein einfaches Passwort und wechseln Sie danach zu einem starken.

Im Fehlerprotokoll stehen die Meldungen "Benutzer nicht gefunden" und "Passwort stimmt nicht" in getrennten Zeilen. Welche Sie sehen, verrät Ihnen also, ob das Problem in der Datei oder im Passwort liegt.

Warum erscheint auf WordPress ein 401 Unauthorized Fehler?

Bei WordPress stammt ein 401 meist nicht vom Kern, sondern von den Schichten drumherum. Drei Quellen treten am häufigsten auf: Basic Auth auf Serverebene, die Authentifizierung der REST API sowie Sicherheits und Cache Plugins.

Haben Sie eine Staging Umgebung mit .htpasswd geschützt, treffen auch die Anfragen von WordPress an sich selbst auf diese Wand. Zum Beispiel gehören geplante Aufgaben und die Prüfungen der Websitegesundheit dazu. Eine Warnung in der Websitegesundheit einer geschützten Testumgebung sollte Sie also nicht überraschen.

Für die REST API nennt die WordPress Entwicklerdokumentation drei Wege: Cookie Authentifizierung mit Nonce, Anwendungspasswörter und Plugins. Ohne Nonce zählt die Anfrage somit als nicht authentifiziert, selbst wenn Sie angemeldet sind. Anwendungspasswörter gibt es seit WordPress 5.6, und sie nutzen Basic Auth über HTTPS.

Zum Beispiel: Kann eine mobile App oder ein Automatisierungstool keine Inhalte veröffentlichen, prüfen Sie zuerst, ob das Anwendungspasswort zum richtigen Benutzer gehört. Danach kontrollieren Sie, ob der Proxy den Authorization Header weiterreicht.

Bei Plugin Problemen hilft es, Plugins einzeln auszuschalten. Bevor Sie das auf einer Live Seite versuchen, bereiten Sie Ihre Backup Strategie vor.

Wie lösen Sie einen 401 Unauthorized Fehler bei API und Token?

Bei APIs bedeutet ein 401 fast immer "Token ungültig". Entwickler begegnen diesen Situationen am häufigsten:

• Das Token ist abgelaufen, und der Ablauf zur Erneuerung hat nicht funktioniert.
• Der Authorization Header hat das falsche Format, zum Beispiel fehlt das Wort Bearer.
• Die Anfrage traf die falsche Umgebung, etwa ein Testschlüssel am Live Endpunkt.
• Ein Zeitunterschied hat ein signiertes Token ungültig gemacht.
• Eine Zwischenschicht hat den Header entfernt.

Lesen Sie in diesem Fall den Header WWW-Authenticate der Antwort. Denn viele APIs nennen dort den Grund in einem kurzen Code. Der Header zeigt daher die Richtung und senkt das Rätselraten.

Verwechseln Sie dennoch 401 und 403 nicht. Ist das Token gültig, aber ohne Recht auf die Ressource, ist 403 die richtige Antwort. Bauen Sie eine eigene API, erleichtert die saubere Trennung beider Codes die Arbeit der Entwickler auf der Clientseite erheblich.

Schreiben Sie Schlüssel niemals in den Code oder in ein öffentliches Repository. Nutzen Sie stattdessen Umgebungsvariablen oder einen Tresor für Geheimnisse. Zu allgemeinen Sicherheitsrisiken lesen Sie unsere OWASP Top 10 Übersicht.

Wie wählen Sie in der eigenen Anwendung zwischen 401, 403 und 404?

Der passende Code in Ihrer Anwendung hilft Entwicklern und Suchmaschinen, Sie richtig zu verstehen. Die Grundregel trennt somit fehlende Identität von fehlender Berechtigung.

• Sendet die Anfrage keine oder ungültige Zugangsdaten, antworten Sie mit 401 und ergänzen WWW-Authenticate.
• Ist die Identität gültig, aber das Recht reicht nicht, antworten Sie mit 403.
• Möchten Sie sogar die Existenz einer Ressource verbergen, können Sie mit 404 antworten.

Die dritte Möglichkeit beschreibt zudem RFC 9110. Zur Abgrenzung dieser Codes ist RFC 9110 die Primärquelle. Ein 404 erschwert allerdings die Fehlersuche, wählen Sie ihn also nur, wenn Sie wirklich Geheimhaltung brauchen.

Eine Falle bleibt: Eine Anmeldeseite mit Status 200 und dem Text "Zugriff verweigert" sendet Suchmaschinen ein falsches Signal. Zu diesem Fehlertyp lesen Sie unseren Beitrag zu Soft 404 Fehlern.

Schreiben Sie keine Passwörter, Token oder internen Pfade in den Antworttext. Halten Sie die Fehlermeldung kurz und neutral.

Schadet ein Passwortschutz für die Staging Umgebung dem SEO?

Ein Passwort auf der Staging Umgebung ist der zuverlässigste Weg, sie vor Suchmaschinen zu verbergen. Denn Google kann den Inhalt einer Seite nicht lesen, die mit 401 antwortet. Laut Search Central behandelt Google alle Fehler der Klasse 4xx außer 429 gleich und meldet dem nächsten System, dass der Inhalt nicht existiert.

Diese Logik unterscheidet sich allerdings von einem noindex Tag. Damit Google eine noindex Regel sieht, muss die Seite crawlbar sein; sperren Sie sie per robots.txt oder erreicht Google sie nicht, liest Google die Regel nie. Den Unterschied erklärt unser Vergleich von noindex und robots.txt.

In der Praxis ist dieser Aufbau für Staging am robustesten: Setzen Sie ein Passwort oder eine IP Beschränkung, veröffentlichen Sie die Sitemap nicht und tragen Sie "Schutz entfernen" in die Checkliste für den Livegang ein. Ein vergessenes Passwort sperrt Ihre Live Seite für den Googlebot.

Das Gegenteil gilt ebenso. Ein noindex Tag oder eine robots.txt Regel, die in die Produktion gelangt, kann Ihre Seiten aus den Suchergebnissen werfen. Prüfen Sie daher nach jedem Release Statuscode und Tags der Startseite. Für eine technische SEO Prüfung sehen Sie sich unsere SEO Beratung an.

Was ist besser für Staging: Basic Auth, IP Beschränkung oder VPN?

Die richtige Methode hängt daher von Teamgröße und Testablauf ab. Keine ist allein perfekt, deshalb erleichtert ein kurzer Vergleich die Wahl.

Für ein kleines Team genügen Basic Auth und HTTPS meist. Teilen Sie aber ein Design zur Freigabe durch den Kunden, schicken Sie das Passwort über einen getrennten Kanal und nicht in derselben E Mail.

Legen Sie die Passwortdatei und die Zugangsdaten nicht in einem Code Repository ab. Echte Kundendaten auf eine Testseite zu kopieren, ist ein weiteres Risiko; arbeiten Sie möglichst mit Beispieldaten.

Was bedeutet die Warnung zu 401 Seiten in der Search Console?

Die Search Console zeigt im Bericht zur Seitenindexierung, dass der Googlebot auf einer Seite eine Abfrage zur Anmeldung gefunden hat. Laut Google Hilfe bedeutet die Meldung "Übermittelte URL gibt nicht autorisierte Anfrage (401) zurück", dass eine Autorisierungsabfrage die Seite für den Googlebot sperrt.

Die Lösung hängt vom Zweck der Seite ab:

• Soll die Seite öffentlich sein, entfernen Sie die Anmeldung.
• Ist die Seite wirklich privat, nehmen Sie sie aus der Sitemap und reichen Sie sie nicht ein.
• Möchten Sie den Googlebot hineinlassen, geben Sie nach der Prüfung seiner Identität Zugriff.

Starten Sie nach der Korrektur den Livetest im URL Prüftool und beantragen Sie die Validierung. Wissen Sie nicht, wie Sie den Bericht lesen, helfen unsere Search Console Anleitung und der Beitrag zu nicht indexierten Seiten.

Einen Punkt sollten Sie nicht übersehen: Steht eine Seite nur wegen ihres privaten Charakters in der Liste, ist alles in Ordnung. Gefährlich wird es, wenn Seiten dort erscheinen, die Sie indexieren möchten.

Was passiert, wenn die robots.txt ein 401 zurückgibt?

Zunächst erwartet Sie ein überraschendes Ergebnis. Laut Google Dokumentation behandeln die Crawler von Google alle Fehler der Klasse 4xx außer 429 so, als gäbe es keine gültige robots.txt Datei. Antwortet Ihre robots.txt also mit 401, geht Google von keinerlei Crawl Beschränkung aus.

Das macht es gefährlich, geschützte Bereiche per robots.txt zu "verstecken". Denn ein Crawler, der die Datei nicht lesen kann, ignoriert jede Regel. Überlassen Sie Privatsphäre deshalb echter Zugriffskontrolle und nicht der robots.txt.

Auch der umgekehrte Fall verwirrt: Gibt die robots.txt einen Fehler 5xx zurück, stoppt Google das Crawling für die ersten 12 Stunden und nutzt danach die letzte gute Fassung. Beide Fälle unterscheiden sich, prüfen Sie also, dass die Datei immer mit 200 antwortet.

Für eine sichere Datei nutzen Sie unseren robots.txt Generator. Zu häufigen Fehlern lesen Sie den Beitrag über robots.txt Fehler.

Wie wirken 401 Seiten auf Überwachung und Tools für defekte Links?

Eine geschützte Adresse sieht für automatische Werkzeuge wie ein Fehler aus. Uptime Monitore zählen meist jede Antwort außer 200 als Ausfall. Dadurch können Sie jede Nacht eine Meldung "Seite down" erhalten, obwohl der Server genau wie vorgesehen arbeitet.

Dasselbe passiert ebenso bei Scans nach defekten Links. Ein Crawler kann einen Link mit der Antwort 401 als defekt markieren. Fragen Sie beim Lesen der Ergebnisse deshalb zuerst, ob die Seite absichtlich geschützt ist. Unser Broken Link Checker listet solche Adressen ebenfalls auf.

Wirkt Ihre Seite ausgefallen, prüfen Sie zuerst, ob wirklich ein Ausfall vorliegt. Dazu nutzen Sie das Werkzeug Ist die Seite down, das zeigt, wie eine Adresse von außen antwortet.

Die Lösung ist einfach: Hinterlegen Sie Zugangsdaten im Überwachungstool oder nehmen Sie den geschützten Bereich aus der Überwachung. Diese Entscheidung erspart Ihrem Team somit Alarmmüdigkeit.

Ist es sicher, den Googlebot an der Anmeldung vorbeizulassen?

Manchmal müssen geschützte Seiten trotzdem gecrawlt werden. Dann können Sie dem Googlebot Sonderzugriff geben, aber Sie müssen vorsichtig sein. Vertrauen Sie nicht dem Text des User Agents, denn jeder kann ihn fälschen.

Die Google Dokumentation bietet zwei Prüfwege: die Domain per Reverse DNS Abfrage bestätigen oder die Adresse mit den von Google veröffentlichten IP Bereichen abgleichen. Die Seite entscheidet also nicht für Sie, ob Sie den Googlebot an der Anmeldung vorbeilassen. Sie erklärt nur, wie Sie erkennen, dass eine Anfrage wirklich von Google kommt.

Zudem ist das für die meisten Unternehmen unnötig. Inhalte hinter einer Anmeldung sollten ohnehin nicht in den Suchergebnissen stehen. Möchten Sie den Inhalt auffindbar machen, verschieben Sie ihn am besten auf eine öffentliche Seite.

Schlecht geschriebene Sonderregeln können Ihre Seite sperren oder für die falschen Personen öffnen. Sind Sie unsicher, nehmen Sie diese Änderung daher nicht selbst vor.

Welche Angaben sollten Sie sammeln, wenn Team oder Kunde einen 401 melden?

Die Meldung "Ich komme nicht auf die Seite" reicht für eine Diagnose nicht aus. Denn wenige Zeilen richtiger Information ersparen Stunden an Rückfragen. Ergänzen Sie daher Ihr Meldeformular oder Ihre Support Vorlage um die folgenden Felder.

• Vollständige Adresse: Sie zeigt, auf welcher Seite oder Subdomain der Fehler auftritt.
• Datum und Uhrzeit: Beides hilft, die passende Zeile im Serverprotokoll zu finden.
• Screenshot: Er zeigt, ob der Dialog von Ihrer Seite oder vom Browser stammt.
• Netzwerkart: Sie verrät, ob der Besucher Büro, Heimnetz oder Mobilfunk nutzte.
• Letzte Änderung: Sie zeigt, ob ein neues Plugin, eine Panel Einstellung oder ein Deployment live ging.

Arbeiten Sie mit einer technisch versierten Person, bitten Sie auch um die Ausgabe der Kommandozeile. Die ersten Zeilen des curl Befehls von oben liefern Statuscode und Header in einem Zug.

So arbeitet der Support mit Belegen statt mit Ausprobieren. Die Gewohnheit spart Zeit im Team und im Austausch mit Ihrem Hostinganbieter.

Wann überlassen Sie das 401 Problem Ihrem Hostinganbieter?

Sie müssen allerdings nicht jeden 401 selbst lösen. In manchen Lagen ist ein Support Ticket die richtige Entscheidung.

• Sie nutzen Shared Hosting und erreichen die Serverkonfiguration nicht.
• Das Problem trat auf der ganzen Seite auf, und Sie kennen die letzte Änderung nicht.
• Eine WAF, ein CDN oder ein Load Balancer erzwingt die Regel.
• Sie sind unsicher beim Bearbeiten einer Apache oder Nginx Datei auf einem Live Server.
• Sie vermuten einen Angriff oder unbefugten Zugriff.

Nennen Sie im Ticket die Adresse, den Zeitpunkt des Fehlers, den Statuscode und den Header WWW-Authenticate. So diagnostiziert der Anbieter das Problem, ohne es nachzustellen. Wie Sie bei der Wahl die Qualität des Supports beurteilen, lesen Sie in unserer Anleitung zur Hosting Auswahl.

Denn eine kaputte Servereinstellung kostet mehr als der Fehler selbst. Probieren Sie deshalb keinen Befehl auf dem Live Server aus, dessen Wirkung Sie nicht kennen.

Welche Checkliste verhindert einen 401 Unauthorized Fehler?

Die folgende Liste kostet vor jedem Release fünf Minuten und verhindert die meisten überraschenden 401 Fehler.

1. Bestätigen Sie, dass niemand den Schutz der Testumgebung in die Live Umgebung kopiert hat.
2. Testen Sie, dass Startseite, robots.txt und Sitemap mit 200 antworten.
3. Listen Sie jeden Pfad mit Basic Auth an einer Stelle auf.
4. Halten Sie Passwortdateien außerhalb des Webroots und nutzen Sie nur HTTPS.
5. Dokumentieren Sie Laufzeiten und Erneuerung der API Token.
6. Prüfen Sie den Bericht der Search Console jede Woche.

Außerdem sollten Sie Themen wie Geschwindigkeit und Barrierefreiheit im selben Ablauf prüfen. Zum Beispiel testen Sie Ihr Zertifikat schnell mit unserem SSL Check.

Möchten Sie das technische Fundament Ihrer Seite als Ganzes aufbauen, sehen Sie sich unser Webdesign an. Wir betreiben kein Hosting; wir helfen Ihnen allerdings bei der richtigen Entscheidung für die Infrastruktur.