Was eine 401-Antwort bedeutet
Eine 401 Unauthorized-Antwort besagt, dass der Server die angefragte Ressource erst ausliefert, wenn der Anfragende gültige Anmeldedaten vorlegt. Der Name ist historisch gewachsen: Der Status betrifft fehlende oder fehlgeschlagene Authentifizierung und nicht die Feststellung, dass dem Anfragenden die Berechtigung fehlt. Eine regelkonforme Antwort enthält in der Regel eine WWW-Authenticate-Abfrage, die das Authentifizierungsverfahren benennt.
Bei einem Mitgliederbereich, einem API-Endpunkt, einem Vorschau-Link oder einem privaten Dokument kann 401 die richtige Grenze sein. Zum SEO-Problem wird es, wenn eine Seite für normale Besucher oder eine CSS-, JavaScript-, Bild- oder Datenanfrage, die zum Rendering dieser öffentlichen URL nötig ist, mit 401 antwortet. Ein Suchmaschinen-Crawler kann sich nicht wie ein normales Mitglied anmelden und die geschützte Antwort deshalb nicht zuverlässig abrufen.
Festlegen, was öffentlich sein soll
Gehen Sie von der Aufgabe der Seite aus. Produktseiten, Artikel, Kategorien, Hilfeseiten und öffentliche Landingpages müssen ohne Sitzung abrufbar sein. Kontoseiten, Rechnungen und private Vorschauen sollten eine Anmeldung verlangen und dürfen weder in der öffentlichen Navigation noch in Sitemaps erscheinen. Diese Einordnung verhindert eine häufige Fehlkorrektur: die Zugriffskontrolle abzuschwächen, nur damit ein Monitoring-Tool einen Status 200 meldet.
| Antwort | Bedeutung | Typische Maßnahme |
|---|---|---|
| 401 | Zugangsdaten werden verlangt oder abgelehnt | Für private Ressourcen beibehalten; die Abfrage auf vorgesehenen öffentlichen Routen entfernen. |
| 403 | Der Server versteht die Anfrage, verweigert sie aber | Autorisierungs- und Bot-Regeln prüfen; nicht als Login-Aufforderung behandeln. |
| 404 | Es ist keine aktuelle Ressource vorhanden | Für stillgelegte oder unbekannte URLs zurückgeben, solange kein passender Ersatz existiert. |
Eine Seite kann öffentlich sein, während Teile ihres Ablaufs privat bleiben. Erlauben Sie zum Beispiel der Produktseite und ihren Bilddateien das anonyme Laden und fordern Sie erst an, wenn jemand einen Kontobereich öffnet. Halten Sie das öffentliche HTML so eigenständig, dass ein Erstbesuch nicht von einer Anfrage mit Zugangsdaten abhängt.
Antwortpfad prüfen
Testen Sie eine Beispiel-URL ohne Browser-Cookies und notieren Sie den finalen Status, die Weiterleitungskette und die Antwort-Header. Prüfen Sie danach die Netzwerkanfragen der Seite auf 401-Antworten bei Ressourcen, die fürs Rendering entscheidend sind. Eine Anmeldesperre, die ein CDN, ein Reverse-Proxy, eine Anwendungs-Middleware oder eine vorgelagerte API setzt, kann einzelne Pfade unterschiedlich treffen. Eine erfolgreiche Anfrage an die Startseite ist deshalb kein ausreichender Beleg.
Rufen Sie die exakte URL in einer sauberen Sitzung auf und erfassen Sie den finalen Status sowie den Header WWW-Authenticate.
Vergleichen Sie eine funktionierende öffentliche Route mit der betroffenen Route, einschließlich Weiterleitungen und benötigter Ressourcen.
Ändern Sie nur die Route oder die Middleware-Regel, die die öffentliche Ressource falsch einordnet.
Bestätigen Sie, dass die öffentliche Route anonym erreichbar ist und eine bewusst private Route weiterhin eine Anmeldung verlangt.
Die praktische Prüfung hat zwei Richtungen. Ist eine öffentliche Seite inzwischen mit einer Anmeldeabfrage versehen, korrigieren Sie ihre Zugriffsregel und testen Sie die gerenderte Seite erneut. Ist eine geschützte Seite versehentlich öffentlich geworden, stellen Sie die Grenze wieder her und sorgen Sie dafür, dass sie aus internen Links, Feeds und XML-Sitemaps verschwindet. Statuscodes beschreiben das Verhalten; sie ersetzen keine Routenübersicht.
Die Korrektur verifizieren
Crawlen Sie nach dem Deployment eine kleine Stichprobe von Templates erneut als anonymer Anfragender. Prüfen Sie das finale HTML und die Ressourcen, die den Hauptinhalt, Styles, Skripte, Bilder und strukturierte Daten tragen. In der Google Search Console hilft die URL-Prüfung, ein aktuelles Abruf-Problem von einem älteren Indexierungsbericht zu unterscheiden. Die Live-Antwort selbst zu prüfen, ersetzt sie aber nicht.
Verwenden Sie eine explizite Liste öffentlicher und authentifizierter Routen, bevor Sie diese Problemklasse als behoben betrachten. Das brauchbare Ergebnis ist kein universelles Status 200, sondern eine konsistente Grenze: Vorgesehene öffentliche Seiten laden normal, vorgesehene private Seiten bleiben geschützt.
Nehmen Sie geschützte Assets und APIs in die Prüfstichprobe auf. Eine öffentliche Seite kann mit 200 antworten, während die Anfrage für den Hauptinhalt, das Stylesheet oder ein Bild eine 401 erhält und das gerenderte Ergebnis unvollständig bleibt. Prüfen Sie für jede fürs Rendering entscheidende Anfrage den finalen Status und die Authentifizierungsabfrage und testen Sie nach jeder Änderung der Zugriffsregel erneut.
Überwachen Sie den Status nach URL-Klassen statt nach einer undifferenzierten Gesamtzahl. Eine öffentliche Artikelseite, die 401 liefert, verlangt eine andere Untersuchung als ein Kontoendpunkt, der jede anonyme Anfrage korrekt mit einer Anmeldung beantwortet. Halten Sie Stichprobe, Zeitpunkt, Zustand des Anfragenden und finale URL bei jedem Befund fest, damit eine spätere Änderung gegen dieselbe Bedingung geprüft werden kann.