401 Unauthorized (Nicht autorisiert)

TL;DR — Eine 401 Unauthorized bedeutet, dass der Server möchte, dass Sie sich anmelden, bevor er die Seite ausliefert — Ihre Zugangsdaten fehlen, sind falsch oder abgelaufen. Suchmaschinen melden sich nie an. Wenn eine Seite Googlebot eine 401 zurückgibt, kann Google sie nicht sehen und nimmt sie nicht in die Suchergebnisse auf. Genau das wollen Sie bei privaten Seiten (Staging, Mitgliederbereich) — problematisch ist es nur bei einer Seite, die Menschen tatsächlich finden sollen.

Was eine 401 bedeutet

Wenn Ihr Browser (oder der Crawler einer Suchmaschine) einen Server nach einer Seite fragt, antwortet der Server mit einem Statuscode. 401 Unauthorized bedeutet: „Ich zeige Ihnen das erst, wenn Sie nachweisen, wer Sie sind.“ Die gesendeten Zugangsdaten fehlten, waren ungültig oder abgelaufen — Sie müssen sich also anmelden. Evidence for this claim A 401 response means the request lacks valid authentication credentials and the response must include a WWW-Authenticate challenge. Scope: RFC 9110 defines the status semantics and required challenge header; it does not prescribe a site's authentication product or login flow. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.5.2 — 401 Unauthorized

Sie haben das wahrscheinlich schon erlebt, wenn eine Seite ein Fenster für Benutzername und Passwort öffnet oder Sie zu einer Anmeldeseite weiterleitet. Im Hintergrund ist das häufig eine 401.

Warum das für SEO wichtig ist

Der Haken: Googlebot und Bingbot melden sich nie an. Sie haben keinen Benutzernamen und kein Passwort für Ihre Website und geben nichts in Anmeldefelder ein. Wenn ein Crawler auf eine 401 trifft, kommt er schlicht nicht durch die Sperre. Für Google existiert der Inhalt dieser Seite faktisch nicht.

Das praktische Ergebnis:

• Eine Seite, die 401 zurückgibt, wird nicht indexiert — sie kann nicht in der Suche erscheinen.
• Eine Seite, die früher rankte, aber nun 401 zurückgibt, fällt mit der Zeit aus dem Index. Evidence for this claim Google does not index 4xx URLs and removes already-indexed 4xx URLs over time. Scope: Google's crawler documentation supports the Search indexing outcome for 401 responses; it does not address access decisions for private users. Confidence: high · Verified: 2026-07-14 Google: How HTTP status codes affect Google's crawlers

Wann eine 401 in Ordnung ist (und wann sie ein Problem darstellt)

Eine 401 ist nicht automatisch ein Fehler, den Sie beheben müssen. Sie ist die richtige Antwort für Seiten, die privat bleiben sollen:

• Gute 401: Ihre Staging-Website, ein Mitgliederbereich, ein internes Admin-Tool oder ein Kundenportal. Diese Inhalte sollen vor Google verborgen bleiben, und eine Anmeldesperre erledigt das.
• Schlechte 401: Ein Blogbeitrag, eine Produktseite oder eine Landingpage, die öffentlich sein soll, fordert plötzlich eine Anmeldung — meist wegen einer falsch konfigurierten Firewall, eines übrig gebliebenen Passwortschutzes, eines abgelaufenen Tokens oder eines Plugin-Konflikts.

Der häufigste Fehlalarm lautet: „Aber bei mir wird die Seite doch geladen!“ — Sie sind angemeldet, der Crawler aber nicht. Um zu sehen, was Googlebot sieht, öffnen Sie die Seite in einem privaten/Inkognito-Fenster oder verwenden Sie die URL-Prüfung in der Google Search Console.

401 vs. 403 — die Kurzfassung

Sie sehen 401 häufig neben 403 Forbidden. Die Codes klingen ähnlich, bedeuten aber Unterschiedliches:

• 401 = „Wer sind Sie?“ Zugangsdaten fehlen — melden Sie sich an.
• 403 = „Ich weiß, wer Sie sind, aber nein.“ Der Server hat die Anfrage verstanden, verweigert den Zugriff aber trotzdem.

Für Google ist das Ergebnis jedoch gleich: Keine der beiden Antworten wird indexiert, weil der Crawler den Inhalt in keinem Fall erreicht.

Möchten Sie die technischen Details — den exakten Header, den eine 401 senden muss, was Googles Dokumentation tatsächlich sagt und wie Sie eine unerwünschte 401 beheben? Wechseln Sie zum Tab Fortgeschritten.

TL;DR — 401 Unauthorized ist ein Clientfehler (RFC 9110 §15.5.2, das RFC 7235 ersetzt), der bedeutet, dass der Anfrage gültige Authentifizierungsdaten fehlen — auch wenn gesendete Zugangsdaten abgelehnt wurden, nicht nur wenn überhaupt keine gesendet wurden. Eine konforme 401 sendet außerdem den Header WWW-Authenticate, der das erwartete Schema nennt. Sie unterscheidet sich von 403 (einer Verweigerung, die diese Aufforderung nicht benötigt und völlig unabhängig von Zugangsdaten sein kann). Google behandelt jedoch für die Indexierung alle 4xx außer 429 gleich: Der Inhalt „existiert nicht“, wird also nicht indexiert und zuvor indexierte URLs fallen mit der Zeit heraus. Da der gewöhnliche Googlebot keine Zugangsdaten sendet, ist eine 403 an Googlebot — nach Googles eigenen Worten — normalerweise eine Fehlkonfiguration des Servers. 401/403 haben keinen Einfluss auf die websiteweite Crawling-Rate (ein weit verbreiteter Mythos), auch wenn eine einzelne URL, die wiederholt 4xx liefert, mit der Zeit seltener gecrawlt wird. Eine 401 ist die richtige, von Google empfohlene Methode, wirklich private Inhalte zu schützen; problematisch ist sie nur bei einer Seite, die indexiert werden soll. Für Paywall-Inhalte gibt es einen zulässigen Weg, der keine pauschale 401 erfordert.

Was eine 401 tatsächlich ist

401 Unauthorized ist eine Clientfehler-Antwort. Die Definition von MDN ist die klarste technische Beschreibung:

“The HTTP 401 Unauthorized client error response status code indicates that a request was not successful because it lacks valid authentication credentials for the requested resource. This status code is sent with an HTTP WWW-Authenticate response header that contains information on the authentication scheme the server expects the client to include to make the request successfully.” (Übersetzung) „Der HTTP-Clientfehler-Statuscode 401 Unauthorized zeigt an, dass eine Anfrage nicht erfolgreich war, weil ihr gültige Authentifizierungsdaten für die angeforderte Ressource fehlen. Dieser Statuscode wird mit einem HTTP-Antwortheader WWW-Authenticate gesendet, der Informationen über das Authentifizierungsschema enthält, das der Server vom Client für eine erfolgreiche Anfrage erwartet.“

Zwei Punkte daraus sind wichtig. Erstens „Authentifizierung“: Der Anfragende hat noch nicht nachgewiesen, wer er ist. Das bedeutet meist fehlende, ungültige oder abgelaufene Zugangsdaten — eine 401 kann aber auch auf Zugangsdaten folgen, die gesendet und abgelehnt wurden. Nehmen Sie daher nicht ohne Prüfung an, dass überhaupt kein Auth-Header vorhanden war. Zweitens muss eine spezifikationskonforme 401 einen WWW-Authenticate-Header enthalten — gemäß RFC 9110 §15.5.2; dieses ersetzt das ältere RFC 7235 — der Header teilt dem Client das erwartete Schema mit (HTTP Basic Auth, ein Bearer-Token, ein Session-Cookie-Ablauf und so weiter). Wenn Sie eine 401 untersuchen, ist dieser Header das Erste, was Sie prüfen sollten: ob er überhaupt vorhanden ist und welches Schema er nennt. Evidence for this claim A 401 response means the request lacks valid authentication credentials and the response must include a WWW-Authenticate challenge. Scope: RFC 9110 defines the status semantics and required challenge header; it does not prescribe a site's authentication product or login flow. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.5.2 — 401 Unauthorized

In meinem eigenen Leitfaden zu Statuscodes fasse ich 401 so zusammen: „Der Client hat sich bei Bedarf noch nicht identifiziert oder verifiziert.“ Das ist die gesamte Idee — noch niemand hat gesagt, wer er ist.

401 vs. 403 Forbidden — der entscheidende Unterschied

Hier werden die meisten Menschen ungenau, daher formuliere ich es scharf. In einer Zeile:

• 401 = „Wer sind Sie?“ — Zugangsdaten fehlen oder sind ungültig; authentifizieren Sie sich und versuchen Sie es erneut.
• 403 = „Ich weiß, wer Sie sind, aber nein.“ — Die Anfrage wurde verstanden, der Zugriff ist aber unabhängig von den Zugangsdaten verweigert.

MDN beschreibt es genauso:

“A 401 Unauthorized is similar to the 403 Forbidden response, except that a 403 is returned when a request contains valid credentials, but the client does not have permissions to perform a certain action.” (Übersetzung) „Eine 401 Unauthorized ähnelt der Antwort 403 Forbidden; eine 403 wird jedoch zurückgegeben, wenn eine Anfrage gültige Zugangsdaten enthält, der Client aber nicht zu einer bestimmten Aktion berechtigt ist.“

Auch in meinem eigenen Leitfaden stelle ich denselben Kontrast heraus: “The client hasn’t identified or verified itself when needed” (Übersetzung) „Der Client hat sich bei Bedarf noch nicht identifiziert oder verifiziert“, während “The client is known but doesn’t have access rights” (Übersetzung) „der Client bekannt ist, aber keine Zugriffsrechte hat“. Authentifizierung gegenüber Autorisierung.

Diese Kurzform ist zuverlässig. Hier ist aber der schärfere Protokolltest, wenn Sie in Code oder einer WAF-Regel zwischen beiden wählen müssen: 401 erfordert die Aufforderung WWW-Authenticate — RFC 9110 macht sie verpflichtend —, während 403 sie nicht benötigt, weil eine 403-Verweigerung Gründe haben kann, die nichts mit Zugangsdaten zu tun haben (IP-Sperre, Berechtigungsregel oder Rate-Limit-Richtlinie). „Waren Zugangsdaten vorhanden?“ reicht daher allein nicht zur Unterscheidung: Eine 401 kann auf abgelehnte und nicht nur auf fehlende Zugangsdaten folgen. Fragen Sie bei der Wahl des Codes stattdessen: Gebe ich eine Authentifizierungsaufforderung aus (401) oder eine schlichte Verweigerung (403)?

Hier kommt die nicht offensichtliche SEO-Wendung — und Googles eigener Punkt zu 403. Der gewöhnliche Googlebot sendet niemals Zugangsdaten. Eine gezielt an Googlebot ausgelieferte 403 bedeutet daher nach Googles eigenen Worten, dass der Server etwas falsch macht:

“HTTP 403 means that the user agent provided credentials, but was not granted access. However, Googlebot never provides credentials, so your server is returning this error incorrectly. The page will not be indexed.” (Übersetzung) „HTTP 403 bedeutet, dass der User-Agent Zugangsdaten bereitgestellt hat, aber keinen Zugriff erhielt. Googlebot stellt jedoch niemals Zugangsdaten bereit; daher gibt Ihr Server diesen Fehler falsch zurück. Die Seite wird nicht indexiert.“

Das ist eine nützliche Diagnose. Eine 401 an Googlebot kann beabsichtigt sein (die Seite ist absichtlich geschützt). Eine 403 an Googlebot weist normalerweise auf eine Fehlkonfiguration hin — Googlebot hat keine Zugangsdaten gesendet, daher sollte nichts eine Antwort „Zugangsdaten abgelehnt“ auslösen. Wenn Sie 403s auf Seiten sehen, die Googlebot erreichen sollte, prüfen Sie zuerst CDN, WAF oder Serverkonfiguration. (Das beschreibt Googles gewöhnliche Crawler. Google dokumentiert spezielle Crawler und vom Nutzer ausgelöste Fetcher als eigene Kategorien mit eigenem Verhalten. Verallgemeinern Sie die Regel „sendet nie Zugangsdaten“ daher nicht auf jede Google-Produktintegration, ohne dies zu prüfen.)

Die letzte Zeile ist der entscheidende Punkt: Für die Indexierung behandelt Google beide identisch.

Wie Google 401-Seiten behandelt

Googles Dokument zu HTTP-Statuscodes ist bei der 4xx-Familie eindeutig:

“Google doesn’t use the content from URLs that return 4xx status codes. If a URL was previously used but is now returning 4xx status code, Google systems will stop using the URL over time. In the case of Google Search, Google doesn’t index URLs that return a 4xx status code, and URLs that are already indexed and return a 4xx status code are removed from the index.” (Übersetzung) „Google verwendet den Inhalt von URLs, die 4xx-Statuscodes zurückgeben, nicht. Wenn eine URL zuvor verwendet wurde, nun aber einen 4xx-Statuscode zurückgibt, stellen die Google-Systeme die Verwendung der URL mit der Zeit ein. In der Google-Suche indexiert Google keine URLs, die einen 4xx-Statuscode zurückgeben; bereits indexierte URLs, die einen 4xx-Statuscode zurückgeben, werden aus dem Index entfernt.“ Evidence for this claim Google does not index 4xx URLs and removes already-indexed 4xx URLs over time. Scope: Google's crawler documentation supports the Search indexing outcome for 401 responses; it does not address access decisions for private users. Confidence: high · Verified: 2026-07-14 Google: How HTTP status codes affect Google's crawlers

Und 401 ist innerhalb dieser Familie kein Sonderfall. In der Tabelle des Dokuments stehen „401 (unauthorized)“ und 403 (forbidden) als getrennte Zeilen mit einer gemeinsamen Erklärung:

“All 4xx errors, except 429, are treated the same: Google crawlers inform the next processing system that the content doesn’t exist.” (Übersetzung) „Alle 4xx-Fehler außer 429 werden gleich behandelt: Google-Crawler informieren das nächste Verarbeitungssystem darüber, dass der Inhalt nicht existiert.“

Das Ergebnis ist binär und keine Herabstufung. Eine 401-Seite rankt nicht „schlechter“ — sie wird überhaupt nicht indexiert oder vollständig entfernt, wenn sie zuvor indexiert war. Es handelt sich nicht um eine bloße Abstufung. Das entspricht der Grundaussage aus meinem Leitfaden zu HTTP-Statuscodes: 4xx-Fehler lassen Seiten aus dem Index fallen. Dieser Artikel vertieft genau diesen Punkt für 401.

Eine Nuance betrifft den Zeitpunkt: Die Entfernung erfolgt „mit der Zeit“ und nicht beim ersten fehlerhaften Abruf. Googles Dokumentation beschreibt einen schrittweisen Prozess, und das Crawling-System wurde historisch als tolerant gegenüber kurzlebigen Fehlern beschrieben, bevor es eine URL als tatsächlich verschwunden behandelt.

Der Mythos der Crawl-Rate — 401 bremst das Crawling NICHT

Dieser Punkt führt viele ansonsten gute Artikel in die Irre, daher möchte ich präzise sein. Eine 401 (oder 403) verlangsamt Googles Crawl-Rate nicht. Google sagt das direkt:

“Don’t use 401 and 403 status codes for limiting the crawl rate. The 4xx status codes, except 429, have no effect on crawl rate.” (Übersetzung) „Verwenden Sie die Statuscodes 401 und 403 nicht, um die Crawl-Rate zu begrenzen. Die 4xx-Statuscodes außer 429 haben keinen Einfluss auf die Crawl-Rate.“

Das ist wichtig, weil Sie Ratschläge sehen werden, eine Absicherung von Seiten mit 401 „spare Crawl-Budget“ oder „verschwende Crawl-Budget“ — beide Formulierungen sind falsch. Nur 429 (und Signale aus dem 5xx-Bereich wie 503) weisen Googlebot an, sich zurückzuhalten. Eine 401 ist keine Drosselung, sondern ein „Inhalt existiert nicht“-Signal für die Indexierung, ohne Ausnahme. Wenn Sie das Crawling vorübergehend verlangsamen wollen, verwenden Sie 429/503 — nicht 401/403.

Eine Abgrenzung ist wichtig, weil diese beiden Aussagen leicht vermischt werden: „Kein Einfluss auf die Crawl-Rate“ betrifft die gesamte Website. Separat sagt Google, dass eine einzelne URL, die dauerhaft 4xx zurückgibt, mit der Zeit seltener gecrawlt wird — ihre eigene Wiederholungsfrequenz sinkt allmählich. Das sind unterschiedliche Ebenen: Ihr websiteweites Crawl-Budget wird nicht gedrosselt, aber eine dauerhaft 401 liefernde URL wird ausdrücklich seltener geprüft, weil Google sie zurückstuft.

Ein Sonderfall ist ebenfalls wichtig: Eine 401 auf einer normalen Seite und eine 401 auf /robots.txt werden nicht gleich behandelt. Wenn Ihre robots.txt einen anderen 4xx-Statuscode als 429 (einschließlich 401) zurückgibt, behandelt Google das so, als gäbe es überhaupt keine robots.txt — es nimmt für diese Datei keine Crawl-Beschränkungen an, statt Ihre gesamte Website als unerreichbar zu betrachten. Schützen Sie /robots.txt nicht mit derselben Authentifizierungssperre wie Ihre privaten Seiten.

Ist eine 401 immer ein Problem? Nein.

Eine 401 ist nur dann ein Fehler, wenn sie auf einer Seite, die öffentlich sein soll, unbeabsichtigt auftritt. Wenn die Seite wirklich privat ist, ist 401 der richtige Weg, sie aus der Suche herauszuhalten — und genau das empfiehlt Google. John Mueller hat es klar formuliert (wiedergegeben vom Search Engine Journal): Der ideale Ansatz sei eine serverseitige Authentifizierung, die normale Nutzer am Anzeigen des Inhalts hindert — “that would include GoogleBot.” (Übersetzung) „das würde GoogleBot einschließen.“ (Wiedergegeben vom Search Engine Journal aus einem Google-Hangout von 2019; als akkurat paraphrasierte Aussage eines Vertreters und nicht als fragmentgenau verifiziertes wörtliches Zitat behandeln.)

Serverseitige Authentifizierung (die eine 401 erzeugt) ist sein empfohlener Mechanismus, um nicht öffentliche Inhalte zu verbergen — und ist der robots.txt vorzuziehen —, gerade weil sie den Zugriff blockiert, statt Bots nur darum zu bitten, draußen zu bleiben.

Der Entscheidungsrahmen ist einfach:

• Soll 401 bleiben: Staging-Umgebungen, Mitgliederbereiche, interne Tools und alles, was wirklich privat ist. Funktioniert wie vorgesehen. Beheben Sie es nicht.
• Muss behoben werden: Eine öffentliche, indexierbare Seite, die versehentlich 401 zurückgibt — etwa wegen eines CDN-/WAF-Fehlalarms, einer übrig gebliebenen Basic-Auth-Konfiguration, eines abgelaufenen Tokens oder eines Plugin-/Middleware-Konflikts.

SEO-Auswirkungen und die Falle „Bei mir funktioniert es“

Die praktischen Fehlerbilder:

• Seiten, die indexiert werden sollen, bleiben unsichtbar, bis die Sperre entfernt wird.
• Seiten, die zuvor rankten, verschwinden, wenn sie anfangen, 401 zurückzugeben.
• Die Falle „Bei mir funktioniert es“: Die testende Person ist authentifiziert, angemeldet oder verwendet eine freigegebene IP-Adresse — der Crawler nicht. Googles eigene Anleitung zum 401-Fall lautet: „Sie können diesen Fehler überprüfen, indem Sie die Seite im Inkognito-Modus aufrufen.“ Noch besser: Testen Sie unauthentifiziert mit curl -I https://example.com/page oder verwenden Sie den Live-Test der URL-Prüfung in der Search Console.

Wenn Sie einen echten Crawler tatsächlich durchlassen müssen, verifizieren Sie ihn per IP / Reverse DNS und vertrauen Sie niemals allein auf den User-Agent-String — User-Agent-Strings lassen sich trivial fälschen. Googlebot allein anhand seines Namens auf eine Allowlist zu setzen, ist eine Sicherheitslücke und keine Lösung.

Was ist mit Paywall- oder exklusiven Abonnenteninhalten?

Eine pauschale 401 für alle (einschließlich Googlebot) ist nicht Ihre einzige Möglichkeit, wenn geschützte Inhalte weiterhin ranken sollen. Google unterstützt die Indexierung von Paywall-Inhalten über die strukturierte Datenangabe isAccessibleForFree, verbunden mit dem Zugriff für Googles spezielle Crawler-Identitäten bei Inhalten für Abonnenten oder registrierte Nutzer. Der Zweck des Markups:

“This structured data helps Google differentiate paywalled content from the practice of cloaking, which violates spam policies.” (Übersetzung) „Diese strukturierten Daten helfen Google, Paywall-Inhalte von der Praxis des Cloakings zu unterscheiden, die gegen die Spam-Richtlinien verstößt.“

Die darin enthaltene Warnung: Googlebot stillschweigend den vollständigen Inhalt auszuliefern, ohne dies durch strukturierte Daten offenzulegen, ist Cloaking — ein Risiko für die Spam-Richtlinien. Wenn geschützte Inhalte indexiert werden sollen, tun Sie es auf dem vorgesehenen Weg (Markup plus Crawler-Zugriff) und nicht durch eine heimliche Umgehung.

So beheben Sie eine unerwünschte 401

1. Bestätigen Sie, dass sie tatsächlich unerwünscht ist. Soll diese Seite öffentlich sein? Wenn sie zum Staging oder zu einem Mitgliederbereich gehört, gibt es nichts zu beheben.
2. Entfernen Sie die Authentifizierungspflicht auf öffentlichen Seiten — entfernen Sie übrig gebliebene Basic-Auth-Konfigurationen (.htaccess/nginx), beheben Sie abgelaufene Tokens und lösen Sie Plugin-/Middleware-Konflikte.
3. Prüfen Sie CDN/WAF — und nehmen Sie nicht an, dass Sie bereits wissen, welche Schicht die 401 ausgegeben hat. Die Antwort (und ihr WWW-Authenticate-Header) zeigt, dass eine Aufforderung erfolgte, aber nicht, wo sie entstand — Anwendung, Identitäts-/Auth-Proxy, Bot-Management-Regeln von CDN oder WAF und Origin-Server können sie alle erzeugen. Fehlalarme von Edge-Bot-Management-Regeln sind häufig; untersuchen Sie die Protokolle jeder Schicht und verifizieren Sie Googlebot per Reverse DNS, bevor Sie etwas allowlisten.
4. Lassen Sie verifizierte Crawler per IP/Reverse DNS durch, nicht per User-Agent.
5. Verwenden Sie 401 nicht zum Deindexieren, wenn Sie eine Seite öffentlich machen könnten — verwenden Sie stattdessen noindex (bei erlaubtem Crawling). Eine Anmeldesperre ist für Inhalte gedacht, die wirklich privat bleiben müssen.
6. Validieren Sie die Korrektur mit dem Live-Test der URL-Prüfung — behandeln Sie einen Erfolg aber als Bestätigung des aktuellen Abrufs und nicht als Garantie. Google verspricht keinen festen Zeitplan für erneutes Crawlen, erneute Indexierung oder eine Ranking-Erholung nach der Behebung einer 401; ein bestandener Live-Test zeigt, dass Googles Live-Abruf durchkommt, nicht dass planmäßiges Crawling oder die Indexierung bereits nachgezogen haben. Geben Sie dem Prozess Zeit und prüfen Sie den Bericht zur Seitenindexierung erneut, statt eine sofortige Umkehr zu erwarten.

Für den vollständigen Google-Search-Console-Ablauf aus Diagnose, Behebung und Validierung speziell für den Status „Blocked due to unauthorized request (401)“ im Bericht zur Seitenindexierung siehe den begleitenden Artikel — dieser Beitrag bleibt auf der Ebene von Protokoll und Konzept.

Bing

Bing verhält sich funktional genauso: Eine URL, die Bingbot 401 (oder 403) zurückgibt, ist nicht zugänglich und wird nicht indexiert. Bingbot benötigt wie Googlebot unauthentifizierten Zugriff; verifizieren Sie ihn für eine Allowlist anhand der veröffentlichten IP-Bereiche und nicht anhand des User-Agents.

KI-Zusammenfassung

Eine verkürzte Zusammenfassung der Advanced-Version:

• 401 = fehlende, ungültige oder abgelehnte Zugangsdaten („Wer sind Sie?“). RFC 9110 §15.5.2 (das RFC 7235 ersetzt) verlangt einen WWW-Authenticate-Header, der das vom Client zu verwendende Schema nennt — und eine 401 beweist nicht, dass überhaupt keine Zugangsdaten gesendet wurden; sie kann auf gesendete und abgelehnte Daten folgen.
• 401 vs. 403, der zuverlässige Test: 401 erfordert die Aufforderung WWW-Authenticate; 403 nicht, weil eine 403-Verweigerung völlig unabhängig von Zugangsdaten sein kann (IP-Sperre, Berechtigungsregel, Rate-Limit). Da der gewöhnliche Googlebot keine Zugangsdaten sendet, ist eine 403 an Googlebot laut Google meist eine Fehlkonfiguration des Servers — Google dokumentiert andere Crawler-/Fetcher-Identitäten getrennt; verallgemeinern Sie das nicht auf jeden Google-Client.
• Indexierungsergebnis ist identisch: Google behandelt alle 4xx außer 429 gleich — der Inhalt „existiert nicht“, wird also nicht indexiert, und zuvor indexierte URLs fallen mit der Zeit heraus. Das ist binär, keine Herabstufung.
• Keine websiteweite Crawl-Rate, aber sinkende URL-Frequenz: 401/403 drosseln die gesamte Crawl-Rate nicht — nur 429-/5xx-Signale tun das. Separat wird eine einzelne URL, die dauerhaft 4xx liefert, mit der Zeit seltener gecrawlt. Außerdem wird eine 401 auf /robots.txt selbst als „keine robots.txt vorhanden“ und nicht als Sperre behandelt.
• Eine 401 ist oft richtig: Serverseitige Authentifizierung ist Googles empfohlener Weg, Staging-, Mitglieder- und private Seiten zu verbergen. Problematisch ist sie nur bei einer Seite, die indexiert werden soll — und die Antwort allein verrät nicht, welche Schicht (App, Identitätsproxy, CDN/WAF oder Origin) sie erzeugt hat.
• Die Falle „Bei mir funktioniert es“: Sie sind authentifiziert, der Crawler nicht. Testen Sie im Inkognito-Modus, mit curl -I oder der URL-Prüfung — ein bestandener Live-Test bestätigt nur den aktuellen Abruf und keinen garantierten Zeitplan für erneutes Crawlen oder eine Wiederherstellung.
• Paywalls: Verwenden Sie isAccessibleForFree plus Crawler-Zugriff und keine pauschale 401. Googlebot stillschweigend den vollständigen Inhalt zu geben, ist Cloaking.
• Behebung: Entfernen Sie die Authentifizierungspflicht, verifizieren Sie Crawler per IP/Reverse DNS (nie per User-Agent) und verwenden Sie noindex — nicht 401 —, um eine Seite zu deindexieren, die öffentlich sein könnte.

Offizielle Dokumentation

Primärquellen von Google und aus der HTTP-Spezifikation.

Google

• Wie HTTP-Statuscodes sowie Netzwerk- und DNS-Fehler die Google-Suche beeinflussen — die Behandlung von 4xx, die Regel „gleich behandelt“ und die Warnung zur Crawl-Rate für 401/403.
• Page Indexing report — die Statusdefinitionen „Blocked due to unauthorized request (401)“ und „Blocked due to access forbidden (403)“.
• Strukturierte Daten für Abos und Bezahlinhalte — isAccessibleForFree und die vorgesehene Alternative zu einer pauschalen 401.
• Googlebot und andere Google-Crawler verifizieren — vor einer Allowlist per IP/Reverse DNS verifizieren, nicht per User-Agent.

Standards / Referenz

• RFC 9110 §15.5.2 — HTTP Semantics: 401 Unauthorized — die aktuelle Spezifikation von 401 und WWW-Authenticate (ersetzt RFC 7235).
• MDN — 401 Unauthorized — die technische Definition für Entwickler (keine SEO-spezifische Quelle).

Zitate aus den Quellen

Dokumentierte Aussagen. Jeder Link führt als Deep-Link direkt zur zitierten Passage auf der Quellseite.

Google — Behandlung von 4xx (einschließlich 401)

• “Google doesn’t use the content from URLs that return 4xx status codes… Google doesn’t index URLs that return a 4xx status code, and URLs that are already indexed and return a 4xx status code are removed from the index.” (Übersetzung) „Google verwendet den Inhalt von URLs, die 4xx-Statuscodes zurückgeben, nicht … Google indexiert keine URLs, die einen 4xx-Statuscode zurückgeben, und URLs, die bereits indexiert sind und einen 4xx-Statuscode zurückgeben, werden aus dem Index entfernt.“ — Dokumentation von Google Search Central. Zum Zitat springen
• “All 4xx errors, except 429, are treated the same: Google crawlers inform the next processing system that the content doesn’t exist.” (Übersetzung) „Alle 4xx-Fehler außer 429 werden gleich behandelt: Google-Crawler informieren das nächste Verarbeitungssystem darüber, dass der Inhalt nicht existiert.“ Zum Zitat springen
• “Don’t use 401 and 403 status codes for limiting the crawl rate. The 4xx status codes, except 429, have no effect on crawl rate.” (Übersetzung) „Setzen Sie die Statuscodes 401 und 403 nicht zur Begrenzung der Crawl-Rate ein. Die 4xx-Statuscodes mit Ausnahme von 429 wirken sich nicht auf die Crawl-Rate aus.“ Zum Zitat springen

Google — Search-Console-Hilfe, Einträge zu 401 und 403

• “The page was blocked to Googlebot by a request for authorization (401 response)… You can verify this error by visiting the page in incognito mode.” (Übersetzung) „Die Seite wurde durch eine Autorisierungsaufforderung (401-Antwort) für Googlebot blockiert … Sie können diesen Fehler überprüfen, indem Sie die Seite im Inkognito-Modus aufrufen.“ — Google Search Console-Hilfe, Bericht zur Seitenindexierung. Zum Zitat springen
• “HTTP 403 means that the user agent provided credentials, but was not granted access. However, Googlebot never provides credentials, so your server is returning this error incorrectly. The page will not be indexed.” (Übersetzung) „HTTP 403 bedeutet, dass der User-Agent Zugangsdaten bereitgestellt hat, ihm aber kein Zugriff gewährt wurde. Googlebot stellt jedoch niemals Zugangsdaten bereit; daher gibt Ihr Server diesen Fehler fälschlicherweise zurück. Die Seite wird nicht indexiert.“ Zum Zitat springen

Google — Paywall-Inhalte

• “This structured data helps Google differentiate paywalled content from the practice of cloaking, which violates spam policies.” (Übersetzung) „Diese strukturierten Daten helfen Google, Paywall-Inhalte von der Praxis des Cloakings zu unterscheiden, die gegen die Spam-Richtlinien verstößt.“ — Dokumentation von Google Search Central. Zum Zitat springen

MDN — die technische Definition

• “The HTTP 401 Unauthorized client error response status code indicates that a request was not successful because it lacks valid authentication credentials for the requested resource.” (Übersetzung) „Der HTTP-Clientfehler-Statuscode 401 Unauthorized zeigt an, dass eine Anfrage nicht erfolgreich war, weil ihr gültige Authentifizierungsdaten für die angeforderte Ressource fehlen.“ — MDN Web Docs (sekundäre technische Referenz, nicht SEO-spezifisch). Zum Zitat springen
• “A 401 Unauthorized is similar to the 403 Forbidden response, except that a 403 is returned when a request contains valid credentials, but the client does not have permissions to perform a certain action.” (Übersetzung) „Eine 401 Unauthorized ähnelt der Antwort 403 Forbidden; eine 403 wird jedoch zurückgegeben, wenn eine Anfrage gültige Zugangsdaten enthält, der Client aber nicht zu einer bestimmten Aktion berechtigt ist.“ Zum Zitat springen

John Mueller, Google (wiedergegeben vom Search Engine Journal)

• Zum Verbergen nicht öffentlicher Inhalte ist eine serverseitige Authentifizierung, die normale Nutzer — “that would include GoogleBot” (Übersetzung) „einschließlich GoogleBot“ — am Anzeigen hindert, der ideale Ansatz. Wiedergegeben vom Search Engine Journal aus einem Google-Hangout von 2019; als akkurat paraphrasierte Aussage eines Vertreters und nicht als fragmentgenau verifiziertes wörtliches Zitat behandeln.

401 vs. 403 — was sehe ich tatsächlich, und muss ich es beheben?

Die beiden Fragen, die Leser tatsächlich haben: Ist das eine 401 oder eine 403? und Ist das ein Problem? Gehen Sie diese beiden Fragen durch.

Prompt: eine unbeabsichtigte 401 diagnostizieren

Fügen Sie die anonymen Response-Header einer betroffenen URL sowie die relevante Auth-, CDN- oder Middleware-Konfiguration ein. Entfernen Sie vorher Tokens, Cookies und Geheimnisse.

Diagnose why this public URL returns HTTP 401 to an unauthenticated client. Check for
a valid WWW-Authenticate challenge, separate origin authentication from CDN/WAF and
application middleware, and distinguish an intentional private gate from a public-page
regression. Return: evidence, likely issuing layer, minimum safe fix, and exact
anonymous validation requests. Do not recommend user-agent-only bot allowlisting.

[PASTE SANITIZED HEADERS, LOG EVENT, AND CONFIG]

Prompt: eine Authentifizierungs-Ausnahme prüfen

Review this proposed crawler-access rule for a gated site. Identify whether it relies
only on a spoofable user-agent, whether crawler identity is verified by published IP
ranges or reverse-and-forward DNS, and whether serving different content would create
a cloaking risk. Give a least-privilege alternative and a rollback test.

[PASTE SANITIZED RULE]

Shell: die anonyme Authentifizierungsaufforderung untersuchen

Führen Sie dies in einem Terminal ohne Browser-Cookies oder Zugangsdaten aus.

URL='https://example.com/private'
curl -sS -D - -o /dev/null "$URL"

Bei einer echten 401 prüfen Sie WWW-Authenticate. Eine öffentliche URL, die anonym 401, in Ihrem angemeldeten Browser aber 200 zurückgibt, ist die oben beschriebene Falle des Authentifizierungszustands.

PowerShell: dieselbe anonyme Antwort untersuchen

$response = Invoke-WebRequest -Uri 'https://example.com/private' -SkipHttpErrorCheck
$response.StatusCode
$response.Headers['WWW-Authenticate']

Shell: allgemeine und behauptete Bot-User-Agents vergleichen

URL='https://example.com/page'
curl -sS -o /dev/null -w 'generic %{http_code}\n' "$URL"
curl -sS -o /dev/null -w 'claimed-bot %{http_code}\n' -A 'Googlebot' "$URL"

Der Vergleich kann eine User-Agent-Regel sichtbar machen, verifiziert Googlebot aber nicht; jeder Client kann diese Zeichenfolge senden. Bestätigen Sie echten Crawler-Traffic separat per IP oder Reverse-and-Forward-DNS, bevor Sie Zugriffsregeln ändern.

Tools zum Auffinden der Schicht, die 401 zurückgibt

• Bulk HTTP Status Code Checker: Bestätigen Sie, welche öffentlichen URLs ohne Ihre Browsersitzung 401 zurückgeben, und exportieren Sie die betroffene Menge.
• HTTP Header Checker: Untersuchen Sie WWW-Authenticate, Cache-/CDN-Header und Weiterleitungs-Hops auf Hinweise zur ausgebenden Schicht.
• Googlebot Verifier: Validieren Sie Crawler-IP-Nachweise, bevor Sie eine Zugriffsausnahme anlegen; ein User-Agent allein beweist nichts.
• Search Console URL Inspection, Live-Test: Bestätigen Sie nach der Korrektur, worauf Googles Live-Abruf zugreifen kann.
• CDN-/WAF-Sicherheitsereignisse und Origin-Logs: Verknüpfen Sie Request-ID und Zeitpunkt, um festzustellen, ob Edge, Anwendung oder Origin die 401 erzeugt hat.

Testen Sie Ihr Wissen: 401 Unauthorized

Fünf kurze Fragen dazu, was eine 401 bedeutet und wie Suchmaschinen sie behandeln. Wählen Sie jeweils eine Antwort und prüfen Sie anschließend Ihre Auswahl.

Änderungsprotokoll