Was ist Fehler 401 (Unauthorized)?

Der 401 gehört zur Gruppe 4xx der HTTP-Statuscodes, den Fehlern auf Seiten des Clients. Die gültige Definition steht in RFC 9110 vom Juni 2022, Abschnitt 15.5.2: Die Anfrage wurde nicht ausgeführt, weil ihr „gültige Zugangsdaten für die Authentifizierung fehlen“. Derselbe Abschnitt verpflichtet den Server, den Header WWW-Authenticate mit mindestens einer Challenge zu senden, also mit dem Verfahren, über das sich der Client anmelden kann. Als Beispiel nennt die RFC die Zeile WWW-Authenticate: Basic realm="simple". Die deutsche Übersetzung „nicht autorisiert“ übernimmt die Unschärfe des Originals.

Ein Server antwortet mit 401, wenn eine Ressource eine Anmeldung verlangt und die Anfrage ohne Zugangsdaten oder mit nicht akzeptierten ankommt. Wurde nichts mitgeschickt, fordert der 401 den Client auf, sich anzumelden. Wurden Zugangsdaten mitgeschickt, wurden sie laut RFC abgelehnt, und der Client darf es mit anderen erneut versuchen. Im Browser erscheint ein Schutz nach dem Verfahren Basic als Fenster, das Benutzername und Passwort abfragt. Bei einer API kommt der 401 zum Beispiel, wenn das Zugriffstoken fehlt oder nicht mehr gilt.

Für Google ist der 401 ein 4xx-Fehler wie die anderen. Googles Doku zu Statuscodes, zuletzt aktualisiert am 4. Februar 2026, behandelt alle 4xx außer 429 gleich: Google indexiert die URL nicht, und eine bereits indexierte nimmt es aus dem Index. Laut Search-Console-Hilfe schickt der Googlebot nie Zugangsdaten mit, alles hinter einem 401 bleibt also außerhalb der Suche. Außerdem warnt Google, dass 401 und 403 nicht taugen, um die Crawling-Frequenz zu senken, denn die 4xx außer 429 ändern sie nicht.

Ein Sonderfall ist die Datei robots.txt selbst. Antwortet sie mit 401, verhält sich Google so, als gäbe es keine gültige robots.txt, und geht davon aus, dass das Crawling nicht eingeschränkt ist.

Eine Testumgebung unter staging.beispiel.de ist mit Benutzername und Passwort geschützt. Wer sie aufruft, sieht das Anmeldefenster, der Googlebot bekommt einen 401 und indexiert sie nicht. So empfiehlt Google es für private Inhalte.

Ein Shop holt seinen Katalog über eine externe API. Das Token läuft ab, die API antwortet mit 401, und der Katalog wird nicht mehr aktualisiert, bis jemand das Token erneuert. Mit Google hat dieser 401 nichts zu tun.

Der dritte Fall ist ein Versehen: Eine Zugangsregel für den Kundenbereich greift auch für den ganzen Blog-Ordner. In der Search Console stehen diese Seiten dann unter „Wegen nicht autorisierter Anforderung (401) blockiert“ und fallen aus dem Index.

Die Search Console führt im Bericht zur Seitenindexierung eine eigene Kategorie: „Wegen nicht autorisierter Anforderung (401) blockiert“. Soll die Seite indexiert werden, nennt die Google-Hilfe zwei Wege: die Anmeldepflicht entfernen oder den Googlebot durchlassen, nachdem seine Identität geprüft ist. Zur Kontrolle rät sie, die Seite im Inkognitomodus aufzurufen. Zwei schnelle Prüfungen:

• Öffne die URL in einem Inkognitofenster. Erscheint das Anmeldefenster, bekommt jeder Besucher ohne Sitzung den 401, auch Google.
• Frag in der Kommandozeile nur die Header ab, etwa mit curl -I. Die Antwort zeigt den Code 401 und den Header WWW-Authenticate.

Als Schutz tut der 401, was er soll. Google empfiehlt für vertrauliche oder private Inhalte den Passwortschutz und schreibt, dass sie so nicht in der Suche erscheinen oder, falls sie schon dort sind, mit der Zeit aus den Ergebnissen verschwinden. Weder robots.txt noch noindex schaffen das allein: Eine in robots.txt gesperrte URL kann weiter in den Ergebnissen stehen, wenn andere Seiten auf sie verlinken, und die Regel noindex wirkt nur, wenn der Crawler die Seite abrufen kann. Der Nachteil ist die Kehrseite davon: Was ranken soll, darf nicht hinter einem 401 liegen, denn Google indexiert nicht, was es nicht bekommt.

Quelle: RFC 9110, Abschnitte 15.5.2, 15.5.4 und 15.5.5; Google, „How HTTP Status Codes Affect Google's Crawlers“ (abgerufen am 11.11.2026).

Wo die Grenze zwischen 401 und 403 liegt, beschreiben die Quellen nicht gleich. Die Search-Console-Hilfe geht davon aus, dass ein 403 nach mitgeschickten Zugangsdaten kommt, die RFC 9110 lässt einen 403 auch aus Gründen zu, die mit den Zugangsdaten nichts zu tun haben. Mehr dazu im Eintrag zu Fehler 403.

• Schütz die Testumgebung auf dem Server mit Benutzername und Passwort, damit jede Anfrage ohne Zugangsdaten einen 401 bekommt.
• Verlass dich nicht allein auf robots.txt: Laut Google kann eine dort gesperrte URL in den Ergebnissen erscheinen, wenn andere Seiten auf sie verlinken.
• Belass es nicht bei noindex oder dem Header X-Robots-Tag: Für private Inhalte empfiehlt Google den Passwortschutz.
• Öffne die Testumgebung in einem Inkognitofenster und prüf, ob das Anmeldefenster erscheint.
• Prüf nach dem Livegang, dass der Schutz nicht auf die echte Domain mitgewandert ist: Ruf mehrere URLs im Inkognitofenster auf und sieh in der Search Console in der 401-Kategorie nach.
• Soll ein Bezahlbereich indexiert werden, nimm keinen 401: Google beschreibt dafür strukturierte Daten, die Bezahlinhalte kennzeichnen.

• Schick zum 401 immer den Header WWW-Authenticate mit, wie RFC 9110 es verlangt.
• Nimm 401, wenn die Anmeldung fehlt, und 403, wenn der Server den Zugriff aus einem anderen Grund verweigert.
• Nutz weder 401 noch 403, um das Crawling von Google zu bremsen; dafür verweist Google auf seine Anleitung zum Senken der Crawling-Frequenz.
• Prüf, bevor du einen angeblichen Googlebot durchlässt, ob er echt ist: per Reverse-DNS-Abfrage oder mit den IP-Listen, die Google veröffentlicht.

• Eine Testumgebung für versteckt halten, weil robots.txt sie sperrt.
• Den Schutz nach einem Relaunch auf einem öffentlichen Bereich aktiv lassen.
• Die robots.txt mit 401 ausliefern und glauben, das sperre Google aus: Google behandelt sie wie eine fehlende robots.txt.
• 401 oder 403 einsetzen, um die Last durch das Crawling zu senken.
• Jede Anfrage durchlassen, die sich als Googlebot ausgibt, ohne sie zu prüfen.

Dieser Eintrag entstand im November 2026 mit KI-Unterstützung. Die Fakten stammen aus RFC 9110, aus Googles Dokumentation zu Statuscodes, robots.txt, noindex und zur Prüfung von Crawlern sowie aus der Search-Console-Hilfe. Er wurde vor der Veröffentlichung geprüft und enthält keine Kundendaten.