403 Zugriff verweigert

TL;DR — Eine 403 Forbidden bedeutet, dass der Server die Anfrage verstanden hat, sie aber ablehnt — der Anfragende hat keine Berechtigung. Das unterscheidet sie von 404 („hier ist nichts“) und 401 („zuerst anmelden“). Für SEO wird eine Seite, die Googlebot dauerhaft 403 zurückgibt, nicht indexiert und fällt aus dem Index, wenn sie bereits indexiert war. Wenn die Seite gefunden werden soll, muss eine 403 daher behoben werden.

Was eine 403 tatsächlich bedeutet

Wenn Sie als Besucher auf einer Website, die Sie nicht betreiben, auf eine 403 stoßen: Es handelt sich um eine serverseitige Regel und nicht um Ihren Browser. Probieren Sie ein anderes Netzwerk oder Gerät, stellen Sie sicher, dass die Website Ihr VPN nicht blockiert, und löschen Sie Cookies. Bleibt die Antwort bestehen, liegt die Korrektur beim Betreiber; der Rest dieses Artikels richtet sich an ihn.

Wenn Sie (oder ein Suchmaschinen-Bot) eine Seite anfordern, sendet der Server einen Statuscode zurück. 200 bedeutet „Hier ist sie“. 403 Forbidden bedeutet: „Ich habe verstanden, was Sie angefordert haben, aber ich verweigere die Ausgabe.“ Die Verweigerung muss nicht mit Zugangsdaten zu tun haben — der Server kann auch aus anderen Gründen ablehnen und sogar 404 senden, wenn er verbergen möchte, dass eine verbotene Ressource überhaupt existiert. Evidence for this claim A 403 response means the server understood the request but refuses to fulfill it, and authenticating does not necessarily make a difference. Scope: RFC 9110 defines the protocol semantics; it does not identify the application, firewall, or policy responsible for a specific response. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.5.4 — 403 Forbidden

Die einfachste Eselsbrücke für die 4xx-Codes:

• 404 Not Found — „Hier ist nichts.“ Die Seite existiert nicht.
• 403 Forbidden — „Hier ist etwas, aber Sie dürfen es nicht haben.“ Eine aktive Sperre.
• 401 Unauthorized — „Sie müssen sich zuerst anmelden/authentifizieren.“ Eine 403 ist strenger: Selbst eine Anmeldung würde nicht helfen.

Der Server ist bei einer 403 also nicht kaputt. Er arbeitet genau wie angewiesen — die Frage ist, ob er die richtige Anweisung erhalten hat.

Warum das für SEO wichtig ist

Googlebot muss eine Seite abrufen können, um sie zu indexieren. Fragt er Ihre Seite an und erhält 403, kann Google aus dieser Antwort überhaupt keinen Inhalt lesen — der Zugriff wird verweigert, bevor Google so weit kommt. Google indexiert keine Seite, die 403 zurückgibt, und eine zuvor indexierte Seite fällt aus den Ergebnissen, wenn sie weiterhin 403 liefert. Das Ergebnis ähnelt dem Setzen von noindex: Die Seite verschwindet aus Google. Der Mechanismus ist aber anders: Ein noindex-Tag muss abgerufen und gelesen werden, während 403 Google von vornherein am Lesen hindert. 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 indexing outcome for persistent 403 responses, not the article's analogy to noindex. Confidence: high · Verified: 2026-07-14 Google: How HTTP status codes affect Google's crawlers

Hier liegt die Besonderheit, wegen der sich 403 lohnt: Googlebot meldet sich nie an. Er sendet keine Passwörter oder Zugangsdaten. Eine 403 — die oft bedeutet „Ihre Zugangsdaten wurden nicht akzeptiert“ — kann für Googlebot also nicht genau das bedeuten. Das macht sie aber nicht automatisch zu einem Fehler: Die Sperre kann beabsichtigt sein (Staging, Admin-Bereich oder geschützte Inhalte, die nie gecrawlt werden sollen). Eine 403 auf einer Seite, die öffentlich sein soll, ist dennoch untersuchenswert — eine Sicherheitsregel, Firewall oder ein Plugin könnte Googlebot als verdächtig eingestuft haben. Googles eigene Anleitung ist genauso eingegrenzt: Wenn die Seite indexiert werden soll, lassen Sie Googlebot ohne Authentifizierung durch.

Was sie gewöhnlich verursacht

Ich habe keine belastbaren Daten dazu, welche Ursache am häufigsten ist — betrachten Sie dies als Checkliste und nicht als Rangliste:

1. Ein CDN oder eine Firewall (WAF), die den Bot blockiert — Cloudflares Bot Fight Mode ist ein häufiger Verursacher und erwischt neben schlechten Bots auch Googlebot.
2. Eine Server- oder Hosting-Regel, die bestimmte IP-Adressen oder User-Agents blockiert.
3. Eine falsch konfigurierte robots.txt oder .htaccess.
4. Ein Sicherheits-Plugin (etwa Wordfence bei WordPress), das zu aggressiv vorgeht.
5. Eine Anmeldesperre — alles hinter Authentifizierung gibt einem Bot absichtlich 403; dieser Fall ist oft gewollt und kein Fehler.
6. Fehlerhafte Datei-Berechtigungen auf dem Server.

Der schnelle Weg zur Behebung

1. Öffnen Sie in der Google Search Console den Bericht Seitenindexierung und suchen Sie nach “Blocked due to access forbidden (403).” (Übersetzung) „Zugriff wegen Verweigerung (403) blockiert.“
2. Führen Sie die URL durch das Tool URL-Inspection und starten Sie Live-URL testen, um zu sehen, was Googlebot jetzt erhält.
3. Wenn Sie Cloudflare oder ein anderes CDN/eine Firewall verwenden, prüfen Sie die Sicherheitsprotokolle auf blockierten Googlebot-Traffic und lassen Sie verifizierte Such-Bots durch.
4. Verwenden Sie nach der Korrektur Korrektur bestätigen in der Search Console.

Und etwas, das Sie nicht tun sollten: Verwenden Sie niemals 403, um Googlebot zu verlangsamen. Das funktioniert nicht und kann zur Deindexierung Ihrer Seiten führen. Wenn ein Bot Ihren Server überlastet, sind 429 und 503 für diesen Zweck gedacht.

Möchten Sie die ausführliche Version — die Diagnose von Cloudflare/WAF, den 403-Sonderfall von robots.txt und die richtige Allowlist für Bots? Wechseln Sie zum Tab Fortgeschritten.

TL;DR — Eine 403 bedeutet, dass der Server die Anfrage verstanden und aus Gründen des Zugriffs verweigert hat — anders als 404 (verschwunden) und 401 (Authentifizierung). Für die Indexierung ähnelt das Ergebnis einem noindex: Google indexiert eine 403-URL nicht und entfernt eine bereits indexierte URL, auch wenn der Mechanismus (Sperre durch Server/CDN/WAF) nichts mit einem Meta-Tag zu tun hat. Da Googlebot niemals Zugangsdaten sendet, ist eine 403 an Googlebot fast immer eine Fehlkonfiguration — häufig durch CDN-/WAF-Botfilter (Cloudflare Bot Fight Mode ist ein prominenter Fall), Server-IP-/UA-Sperren, Sicherheits-Plugins oder .htaccess-/Berechtigungsfehler. 403 hat keinen Einfluss auf die Crawl-Rate — verwenden Sie den Status niemals zum Drosseln (dafür sind 429/503 gedacht). Und der Sonderfall ist wichtig: Eine 403 auf robots.txt selbst wird freizügig behandelt, während eine 403 auf einer Seite eine harte Sperre ist.

403 vs. 401 vs. 404 — zuerst das richtige Denkmodell

Diese drei Codes werden ständig vermischt, und die Unterscheidung bestimmt die gesamte Diagnose. Die Grunddefinition stammt aus RFC 9110 §15.5.4: Der Server hat die Anfrage verstanden und verweigert ihre Erfüllung. Einige Nuancen desselben Abschnitts sind wichtiger, als man ihnen meist zugesteht:

• Die Verweigerung muss nicht mit Zugangsdaten zu tun haben. RFC 9110 erlaubt 403 aus Gründen, die unabhängig von Authentifizierung sind — sie beweist nicht allgemein, dass der Anfragende „bekannt“ war oder überhaupt Zugangsdaten beteiligt waren. Lesen Sie nicht jede 403 als Authentifizierungsgeschichte.
• Eine 403 muss nicht zugeben, dass die Ressource existiert. Die Spezifikation erlaubt einem Origin-Server, der die Existenz einer verbotenen Ressource verbergen möchte, stattdessen 404 zu antworten. Umgekehrt bedeutet 404 also nicht immer „hier war nie etwas“ — manchmal heißt es „hier ist etwas, von dem Sie nichts wissen sollen“.
• 401 vs. 403 ist nicht nur „schwächer vs. stärker“. 401 ist ausdrücklich eine Authentifizierungs-aufforderung — die Spezifikation verlangt den Header WWW-Authenticate, der dem Client die Authentifizierung erklärt. 403 hat diese Pflicht nicht; die umfassendere Verweigerung verspricht nicht, dass eine erneute Authentifizierung (mit denselben oder anderen Zugangsdaten) etwas ändert. MDNs verständliche Version: Eine 403 sei „ähnlich wie 401, außer dass … Authentifizieren oder erneutes Authentifizieren keinen Unterschied macht. Der Fehler hängt mit der Anwendungslogik zusammen, etwa unzureichenden Berechtigungen.“ Evidence for this claim A 403 response means the server understood the request but refuses to fulfill it, and authenticating does not necessarily make a difference. Scope: RFC 9110 defines the protocol semantics; it does not identify the application, firewall, or policy responsible for a specific response. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.5.4 — 403 Forbidden
• 404 Not Found bedeutet im Normalfall „hier ist nichts“, wobei der oben beschriebene Verbergungsfall zu beachten ist.

Dieser Unterschied ist ein Grund dafür, eine 403 an Googlebot genauer zu prüfen und nicht als Normalfall abzuhaken. Eine 401 für einen Bot auf einer Mitgliederseite funktioniert möglicherweise wie vorgesehen — der Bereich braucht eine Anmeldung. Eine 403 für einen Bot auf einer Seite, die öffentlich sein soll, bedeutet, dass eine Regel den Anfragenden abgewiesen hat. Bevor Sie das einen Fehler nennen, sollten Sie aber wie unten beschrieben bestätigen, dass die Seite tatsächlich öffentlich sein soll.

Wie Google eine 403 behandelt (Ergebnis ähnelt noindex; Mechanismus nicht)

Google ordnet 403 in die übrige 4xx-Familie ein. In der Dokumentation von Search Central heißt es: “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 indexiert keine URLs, die einen 4xx-Statuscode zurückgeben; bereits indexierte URLs, die einen 4xx-Statuscode zurückgeben, werden aus dem Index entfernt.“ Und: “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, dass der Inhalt nicht existiert.“ Google weist außerdem darauf hin, dass die Crawl-Frequenz einer bekannten URL allmählich sinkt, je länger sie 4xx zurückgibt — ein URL-spezifischer Effekt, getrennt von der gesamten Crawl-Rate Ihrer Website. 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 indexing outcome for persistent 403 responses, not the article's analogy to noindex. Confidence: high · Verified: 2026-07-14 Google: How HTTP status codes affect Google's crawlers

Das Ergebnis ähnelt also noindex: Die Seite kommt nicht in den Index und fällt mit der Zeit heraus, wenn sie bereits dort war. Der Mechanismus ist aber wirklich anders: Ein noindex-Tag muss aus dem HTML der Seite abgerufen und gelesen werden, während eine 403 Google am Lesen jeglichen Inhalts hindert — es gibt keine Seite, die Google verarbeiten kann. Zwei unterschiedliche Wege führen zum gleichen Ergebnis: Die Seite erscheint nicht in der Suche. In meinem Leitfaden zu HTTP-Statuscodes beschreibe ich 403 deshalb als „Der Client ist bekannt, hat aber keine Zugriffsrechte“ und weise darauf hin, dass 4xx-Seiten aus dem Index fallen — „bekannt“ ist dabei Googles Berichtskürzel und nicht die Behauptung, dass jede 403 von einem authentifizierten Anfragenden kommt.

Warum eine 403 an Googlebot untersuchenswert ist (aber nicht immer ein Fehler)

Dieser Abschnitt stützt sich auf Googles eigene Hilfe zur Seitenindexierung: “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.“ Lesen Sie das im Kontext: Es handelt sich um eine berichtsspezifische Anleitung für eine Seite, von der die Search Console annimmt, dass Sie die Seite indexieren möchten, und nicht um die universelle Aussage, dass jede 403 an Googlebot ein Fehler ist. Googlebot authentifiziert sich nicht, daher passt eine 403 mit der strikten Begründung „Ihre Zugangsdaten reichen nicht“ nicht ganz — viele 403 haben aber überhaupt nichts mit Zugangsdaten zu tun, und ein Server kann rechtmäßig entscheiden, dass Googlebot (oder jeder andere) eine Ressource nicht erhält.

Bevor Sie also einer Korrektur nachjagen: Soll diese Seite tatsächlich öffentlich und indexiert sein? Wenn es um Staging, einen Admin-Bereich, eine Paywall oder andere geschützte Inhalte geht, ist eine 403 an Googlebot richtig und es gibt nichts zu beheben (mehr dazu im Abschnitt „Wann eine 403 in Ordnung ist“). Wenn sie öffentlich sein soll, sehen Sie wahrscheinlich eine Regel, die beim falschen Anfragenden ausgelöst wurde — etwa ein WAF, das den Crawler als zu blockierenden Bot markiert hat, eine IP-Bereichssperre mit Googles Netzen oder die paranoide Standardeinstellung eines Sicherheits-Plugins. Ich habe aber keine verlässlichen Daten dazu, wie oft welche Ursache tatsächlich vorliegt. Betrachten Sie die Liste unten daher als Prüf-Kandidaten und nicht als Diagnose. Googles Anleitung für eine Seite, die öffentlich sein soll: Lassen Sie nicht angemeldete Nutzer zu oder erlauben Sie Googlebot ausdrücklich ohne Authentifizierung (nach Identitätsprüfung — dazu unten mehr).

403 hat keinen Einfluss auf die Crawl-Rate — nicht zum Drosseln verwenden

Manche greifen zu 403 (oder 404), um Googlebot von einem überlasteten Server fernzuhalten. Tun Sie das nicht. Google sagt ausdrücklich: “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 401- und 403-Statuscodes nicht, um die Crawl-Rate zu begrenzen; 4xx-Statuscodes außer 429 haben keinen Einfluss auf die Crawl-Rate.“ Präzise ist dabei der Geltungsbereich: Google sagt separat, dass die Frequenz des Crawlens einer einzelnen bekannten URL allmählich sinkt, je länger sie 4xx liefert — das ist weniger Interesse an dieser URL und keine websiteweite Drosselung der Crawl-Rate. Wenn Sie Letzteres benötigen, leistet 403 es nicht.

Gary Illyes widmete diesem Thema einen ganzen Beitrag (Don’t 404 my yum): “All 4xx HTTP status codes (again, except 429) will cause your content to be removed from Google Search.” (Übersetzung) „Alle 4xx-HTTP-Statuscodes außer 429 führen dazu, dass Ihr Inhalt aus der Google-Suche entfernt wird.“ Der richtige Notfallhebel ist eine 500, 503 oder 429, die nur kurz zurückgegeben wird (Stunden, nicht Tage) — auch das ist kein Freifahrtschein: Google warnt, dass dauerhafte 5xx-Antworten über mehrere Tage ebenfalls zum Herausfallen von Seiten aus dem Index führen können. Umfang und Dauer sind entscheidend, nicht nur der gewählte Statuscode. Barry Schwartz fasste die Folgen eines früheren Vorfalls prägnant zusammen: Websites hätten “lost load[s] of their pages from our index because they were serving them with a 403 status code instead of a 503.” (Übersetzung) „große Teile ihrer Seiten aus dem Index verloren, weil sie ihre Seiten mit 403 statt 503 auslieferten.“ 503 wird als vorübergehend verstanden; 403 führt zur Deindexierung.

Der robots.txt-Sonderfall: Eine 403 auf robots.txt ist freizügig, nicht restriktiv

Hier übersehen fast alle konkurrierenden Artikel eine Unterscheidung, welche die Intuition umkehrt. Eine 403 auf einer Seite ist eine harte Sperre. Eine 403 auf Ihrer robots.txt-Datei selbst wird dagegen entgegengesetzt behandelt. In Googles robots.txt-Spezifikation heißt es: “Google’s crawlers treat all 4xx errors, except 429, as if a valid robots.txt file didn’t exist. This means that Google assumes that there are no crawl restrictions.” (Übersetzung) „Googles Crawler behandeln alle 4xx-Fehler außer 429 so, als gäbe es keine gültige robots.txt; Google nimmt daher an, dass keine Crawl-Beschränkungen bestehen.“ Evidence for this claim A 403 on `/robots.txt` is handled differently from a 403 on a page: Google treats a non-429 4xx robots response as if no valid robots file exists and assumes no restrictions from that file. Scope: robots.txt fetch only Confidence: high · Verified: 2026-07-16 How Google interprets the robots.txt specification

Wenn Ihre Firewall also robots.txt mit 403 beantwortet, schließt Google daraus, dass Sie keine Regeln haben, und crawlt frei — auch Pfade, die Sie eigentlich sperren wollten. Illyes formulierte es farbig: Wenn Sie eine Regel für Ihre „schmutzige Wäsche“ hatten, weiß Googlebot nun ebenfalls davon. Verwechseln Sie nicht „meine robots.txt gab 403 zurück“ (Google ignoriert jetzt Ihre Regeln) mit „meine Seiten gaben 403 zurück“ (diese URLs werden deindexiert). Die Wirkungen sind entgegengesetzt, und eine falsche Diagnose führt dazu, dass Sie am falschen Problem arbeiten.

Wie Bing 403 behandelt

Ehrlich gesagt ist Bings öffentliche Dokumentation zu 403 dünner als Googles Dokumentation, daher halte ich den Umfang eng. Bingbot wird durch dieselben Mechanismen wie Googlebot abgewiesen — robots.txt-Regeln, IP-/User-Agent-Sperren auf Serverebene sowie WAF-/Firewall-Regeln. Bing Webmaster Tools zeigt Crawl-Fehler in seinen Warnungen zu Crawl-Fehlern. Die praktische Schlussfolgerung ist bei beiden Suchmaschinen gleich: Lassen Sie den verifizierten Crawler durch Ihre Sicherheits-Schicht, und verifizieren Sie den Bot anhand veröffentlichter IP-Bereiche und Reverse DNS, statt einem User-Agent-String zu vertrauen. Betrachten Sie Bing außerdem als Erinnerung: „Googlebot beheben“ bedeutet nicht automatisch „alle Bots beheben“. Prüfen Sie nach einer WAF-Änderung die Tools beider Suchmaschinen.

Häufige Ursachen (nicht gerankt — es gibt keine Prävalenzdaten über Websites hinweg)

CDN-/WAF-Bot-Schutz — die in bestehender SEO-Literatur am wenigsten beachtete Ursache. Hier würde ich 2026 mit der Prüfung beginnen, auch wenn ich nicht sagen kann, wie oft dies tatsächlich der Verursacher gegenüber den anderen Punkten ist. Cloudflares Bot Fight Mode und Super Bot Fight Mode, verwaltete WAF-Regeln und eigene Firewall-Regeln geben Googlebot und Bingbot regelmäßig versehentlich 403. Das Indiz: Die Sperre liegt am Edge, daher sehen Origin-Server und CMS völlig sauber aus, während GSC weiterhin 403 meldet. Prüfen Sie im CDN-Dashboard unter Security Events, ob der Crawler herausgefordert oder blockiert wurde.

2. IP- oder User-Agent-Sperren auf Server-/Hosting-Ebene. Manche Hosts blockieren standardmäßig nach User-Agent oder begrenzen nach Rate; IP-Bereichssperren gegen missbräuchlichen Traffic können Crawler-Netze miterfassen.

3. Fehlkonfiguration von robots.txt / .htaccess. Ein übernommenes Deny from oder eine fehlerhafte Rewrite-Regel kann ein ganzes Verzeichnis sperren. (Und denken Sie an den robots.txt-Sonderfall oben.)

4. Sicherheits-Plugins. Wordfence, iThemes Security und ähnliche Tools werden mit aggressiven Bot-Blockierungsstandards ausgeliefert, die legitime Crawler erfassen können.

5. Anmeldesperren / authentifizierte Inhalte. Alles hinter Authentifizierung gibt einem Bot absichtlich 403 — Googlebot meldet sich nie an. Dieser Fall ist oft beabsichtigt (siehe den letzten Abschnitt).

6. Datei-/Verzeichnisberechtigungen. Die klassische Ursache auf dem Server. Für WordPress dokumentiert Rank Math sinnvolle Werte — Verzeichnisse 755/750, Dateien 644/640, wp-config.php 400/440 — und das „Regenerate .htaccess“ über die Permalink-Einstellungen als häufige Korrektur.

7. Malware / kompromittierte Website, die schlechte Zugriffsregeln einschleust, und 8. Geo-Blocking, das versehentlich den IP-Bereich eines Crawlers erfasst.

Eine 403 diagnostizieren — die ausgebende Schicht isolieren

Die meisten Leitfäden springen direkt zu „Deaktivieren Sie Ihre Plugins“. Die eigentliche Fähigkeit besteht darin, herauszufinden, welche Schicht die Anfrage ablehnt — ein nackter 403-Statuscode sagt das allein nicht. Sie benötigen Response-Header, Protokolle oder einen Security-Event-Eintrag, der tatsächlich auf CDN, WAF, Anwendung, Host, Berechtigungen, Geografie oder Cache verweist, bevor Sie einen Verursacher benennen. Springen Sie nicht ohne Beleg zu „wahrscheinlich der WAF“. So unterscheidet sich die Korrektur nach Schicht:

1. GSC-Seitenindexierung → „Blocked due to access forbidden (403)“ zeigt betroffene URLs; anschließend URL-Inspection → Live-URL testen für die aktuelle Live-Antwort.
2. Reproduzieren Sie den Fehler mit curl und wechseln Sie User-Agents, um zu bestätigen, welchen Status der Server tatsächlich zurückgibt:

   # Als allgemeiner Client
   curl -I https://example.com/page/
   # Googlebot-UA nachahmen (testet UA-basierte Regeln)
   curl -I -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://example.com/page/

   Wenn ein normaler Browser-UA 200, der Googlebot-UA aber 403 erhält, haben Sie eine User-Agent-Regel gefunden.
3. Prüfen Sie den Status von robots.txt selbst (gibt sie 403 zurück? Anderes Problem — siehe oben).
4. Prüfen Sie CDN-/WAF-Security-Events, ob der Crawler herausgefordert oder blockiert wurde.
5. Verifizieren Sie, dass es wirklich Googlebot ist, per Reverse- und Forward-DNS und nicht per UA-String (der sich trivial fälschen lässt).
6. Isolieren Sie die Ursache durch schrittweises Deaktivieren — jeweils eine WAF-Regel oder ein Plugin —, bis die 403 verschwindet.

Beheben — Bots auf die richtige Weise allowlisten

Die naheliegende Korrektur ist, den User-Agent-String von Googlebot zu allowlisten. Hören Sie dort nicht auf: User-Agent-Strings lassen sich trivial fälschen; eine reine UA-Allowlist ist eine Sicherheitslücke, durch die jeder Scraper, der Googlebot behauptet, direkt hineinkommt. Verifizieren Sie richtig:

• Bestätigen Sie Bots per Reverse DNS plus Forward DNS oder anhand der veröffentlichten IP-Bereiche von Google/Bing.
• Die meisten CDNs/WAFs bieten eine Kategorie „verifizierte Bots“, die diese Prüfung übernimmt — bevorzugen Sie diese gegenüber einer rohen UA-Allow-Regel.
• Beheben Sie die konkrete Regel (eine verwaltete WAF-Regel, eine Firewall-Regel oder eine Plugin-Einstellung), statt die Sicherheit insgesamt zu deaktivieren.
• Klicken Sie danach im GSC-Bericht zur Seitenindexierung auf Korrektur bestätigen und fordern Sie bei Dringlichkeit über URL-Inspection eine erneute Indexierung an.

Wann eine 403 tatsächlich in Ordnung ist — diese Fälle nicht „beheben“

Nicht jede 403 ist ein Fehler. Für Staging-Websites, Admin-Bereiche, private Mitgliederbereiche sowie Paywall-/geschützte Inhalte, die nie indexiert werden sollten, ist 403 korrekt und beabsichtigt. In einem Ahrefs- oder Screaming-Frog-Audit ist eine 403 dort kein Problem. Eine Korrektur ist nur erforderlich, wenn eine Seite, die öffentlich und indexierbar sein soll, versehentlich blockiert wird. Lösen Sie nicht reflexartig jede 403 aus einem Audit; bestätigen Sie zuerst, dass die Seite tatsächlich in den Index soll.

Für die größere Familie — wie sich 4xx und 5xx unterscheiden und welchen Platz 403 darin einnimmt — siehe meinen Leitfaden zu HTTP-Statuscodes und ihren SEO-Auswirkungen sowie die verwandten Deep Dives zu 401 Unauthorized und 404 Not Found in diesem Cluster.

KI-Zusammenfassung

Eine verkürzte Zusammenfassung der Advanced-Version:

• 403 = „verstanden, aber abgelehnt.“ Laut RFC 9110 muss die Verweigerung nichts mit Zugangsdaten zu tun haben, und der Server kann sogar 404 senden, wenn er verbergen möchte, dass eine verbotene Ressource existiert. Anders als 404 (existiert normalerweise nicht) und 401 (eine konkrete Authentifizierungsaufforderung mit WWW-Authenticate) lässt sich eine 403 nicht zuverlässig durch erneute Authentifizierung beheben.
• Indexierungsergebnis ähnelt noindex, der Mechanismus ist aber anders. Ein noindex-Tag muss abgerufen und gelesen werden; 403 hindert Google am Lesen jeglichen Inhalts. Beide Wege führen dazu, dass die Seite nicht in der Suche erscheint.
• Eine 403 an Googlebot ist untersuchenswert und nicht automatisch ein Fehler. Prüfen Sie zuerst, ob die Seite tatsächlich öffentlich sein soll. Wenn ja, ist die wahrscheinliche Ursache eine falsch ausgelöste Regel (WAF, IP-Sperre oder Sicherheits-Plugin) — es gibt aber keine zuverlässigen Daten zur häufigsten Ursache. Betrachten Sie die Ursachen als Checkliste und nicht als Rangfolge.
• 403 hat keinen Einfluss auf die websiteweite Crawl-Rate. Die eigene Crawl-Frequenz einer bekannten URL sinkt allmählich, je länger sie einen Fehler dieser Klasse zurückgibt; das ist nicht dasselbe wie die Drosselung der gesamten Website. Verwenden Sie 401/403 niemals zum Drosseln von Googlebot; verwenden Sie stattdessen kurzzeitig 429/503/500 — auch das kann bei zu langer Dauer zur Deindexierung führen.
• robots.txt-Sonderfall (entgegengesetzte Wirkung): Eine 403 auf einer Seite ist eine harte Sperre; eine 403 auf robots.txt selbst wird freizügig behandelt — Google nimmt an, dass keine Crawl-Regeln existieren.
• Diagnose nach Belegen, nicht nach Vermutung. Eine nackte 403 identifiziert ihre Quelle nicht — bestätigen Sie die Quelle anhand von Response-Headern, Protokollen oder CDN-Sicherheitsereignissen, bevor Sie eine bestimmte Schicht beschuldigen. GSC-Seitenindexierung plus Live-URL-Test → curl mit/ohne Googlebot-UA → CDN-Security-Events → Bot per DNS/IP und nicht per UA verifizieren → schrittweise deaktivieren.
• Behebung: Verifizierte Bots allowlisten (DNS/IP oder CDN-Kategorie „verifizierte Bots“), nicht den rohen UA-String. Danach Korrektur im GSC bestätigen.
• Manche 403 sind korrekt: Staging, Admin, Mitgliederbereiche und Paywall-Inhalte — beheben Sie diese nicht. Prüfen Sie die Absicht, bevor Sie einen Fehler annehmen.

Offizielle Dokumentation

Primärquellen dazu, wie 403 und die 4xx-Familie behandelt werden.

Protokoll

• RFC 9110 §15.5.4: 403 Forbidden — die grundlegende HTTP-Spezifikation: Die Verweigerung muss nicht mit Zugangsdaten zu tun haben, und ein Origin kann stattdessen 404 senden, um eine verbotene Ressource zu verbergen.

Google

• Wie HTTP-Statuscodes Googles Crawler beeinflussen — die maßgebliche Aussage, dass 4xx-URLs (außer 429) aus dem Index entfernt werden und keinen Einfluss auf die Crawl-Rate haben.
• Bericht zur Seitenindexierung — Search-Console-Hilfe — der Status „Zugriff wegen Verweigerung (403) blockiert“ und die Erklärung, dass Googlebot niemals Zugangsdaten bereitstellt.
• 403/404 nicht zum Drosseln verwenden — Gary Illyes, Februar 2023, dazu, warum 4xx nicht zum Drosseln des Crawlings geeignet ist.
• Googles Crawl-Rate reduzieren — der richtige Ansatz: 500/503/429 kurzzeitig zurückgeben, nicht 403/404.
• Wie Google die robots.txt-Spezifikation interpretiert — der Sonderfall, dass ein 4xx auf robots.txt als keine Beschränkungen behandelt wird.
• Verifying Googlebot — Reverse DNS und veröffentlichte IP-Bereiche, um korrekt zu allowlisten.

Bing / Microsoft

• List of crawl error alerts — Bing Webmaster Tools — Bings Kategorien für Crawl-Fehler.

CDN/WAF

• Fake bot detection blocking legitimate requests — Cloudflares eigene Dokumentation dazu, wie verwaltete Fake-Bot-Regeln Fehlalarme erzeugen können; hilfreich, um zu bestätigen und nicht nur anzunehmen, dass eine WAF-Regel die ausgebende Schicht ist.

Allgemeine Webreferenz

• MDN — 403 Forbidden — die maßgebliche Grunddefinition und die klare Unterscheidung zwischen 401 und 403.

Zitate aus der Quelle

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

Google — Behandlung von 4xx / 403

• “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) „Die zitierte Quelle bestätigt die unmittelbar beschriebene technische Aussage.“ — 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) „Die zitierte Quelle bestätigt die unmittelbar beschriebene technische Aussage.“ 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) „Die zitierte Quelle bestätigt die unmittelbar beschriebene technische Aussage.“ Zum Zitat springen

Google — der Punkt „Googlebot authentifiziert sich nie“

• “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) „Die zitierte Quelle bestätigt die unmittelbar beschriebene technische Aussage.“ — Search-Console-Hilfe, „Blocked due to access forbidden (403)“. Zum Zitat springen

Gary Illyes, Google — 4xx nicht zur Begrenzung verwenden

• “All 4xx HTTP status codes (again, except 429) will cause your content to be removed from Google Search. What’s worse, if you also serve your robots.txt file with a 4xx HTTP status code, it will be treated as if it didn’t exist.” (Übersetzung) „Die zitierte Quelle bestätigt die unmittelbar beschriebene technische Aussage.“ — Google Search Central Blog, Februar 2023. Zum Zitat springen
• “Return a 500, 503, or 429 HTTP status code to Googlebot when it’s crawling too fast.” (Übersetzung) „Die zitierte Quelle bestätigt die unmittelbar beschriebene technische Aussage.“ Zum Zitat springen

Google — der 403-Sonderfall von robots.txt

• “Google’s crawlers treat all 4xx errors, except 429, as if a valid robots.txt file didn’t exist. This means that Google assumes that there are no crawl restrictions.” (Übersetzung) „Die zitierte Quelle bestätigt die unmittelbar beschriebene technische Aussage.“ — Anleitung zur Interpretation der robots.txt-Spezifikation durch Google. Zum Zitat springen

MDN — die allgemeine Definition und die Unterscheidung 401 vs. 403

• “The HTTP 403 Forbidden client error response status code indicates that the server understood the request but refused to process it. This status is similar to 401, except that for 403 Forbidden responses, authenticating or re-authenticating makes no difference.” (Übersetzung) „Die zitierte Quelle bestätigt die unmittelbar beschriebene technische Aussage.“ — MDN Web Docs. Zum Zitat springen

Barry Schwartz, Search Engine Roundtable — Schweregrad 403 vs. 503 Wiedergegebene Berichterstattung über eine Google-Aussage und keine Google-Primärseite. Außerdem liefert die Quelle selbst automatisierten Fetchern 403 (eine thematisch passende Ironie). Vor einer endgültigen Einordnung im Browser prüfen.

• Googles Warnung laut Berichterstattung: Websites hätten “lost load[s] of their pages from our index because they were serving them with a 403 status code instead of a 503.” (Übersetzung) „große Teile ihrer Seiten aus dem Index verloren, weil sie ihre Seiten mit 403 statt 503 auslieferten.“ Berichterstattung lesen

Eine 403 diagnostizieren — Entscheidungsbaum

Beginnen Sie mit dem, was Googlebot tatsächlich erhält, und grenzen Sie anschließend nach Schicht ein.

Q1. Befindet sich die 403 auf einer Seite, die Sie indexiert haben möchten?

• Nein (Staging, Admin, Mitgliederbereich, Paywall) → sie ist wahrscheinlich korrekt. Belassen Sie die Seite gesperrt. Ende.
• Ja → weiter.

Q2. Gibt die Seite 403 zurück oder robots.txt?

• robots.txt gibt 403 zurück → anderes Problem: Google ignoriert nun alle Crawl-Regeln (behandelt robots.txt als nicht vorhanden). Korrigieren Sie robots.txt so, dass sie 200 zurückgibt; die 403 Ihrer Seite kann ein separates Problem sein.
• Die Seite gibt 403 zurück → weiter.

Q3. Reproduziert curl die Antwort — und hängt sie vom User-Agent ab?

curl -I https://example.com/page/
curl -I -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://example.com/page/

• Browser-UA = 200, Googlebot-UA = 403 → eine User-Agent-Regel blockiert den Bot (WAF, Serverkonfiguration oder Plugin). Weiter mit Q4.
• Beide = 403 → eine umfassendere Sperre (IP-Bereich, Verzeichnisberechtigungen, .htaccess-Deny). Prüfen Sie Serverkonfiguration und Dateiberechtigungen.
• Beide = 200, aber GSC zeigt weiterhin 403 → die Sperre liegt wahrscheinlich am Edge/CDN und richtet sich nach IP oder dem Status „verifizierter Bot“. Weiter mit Q4 und CDN-Security-Events prüfen.

Q4. Sitzen Sie hinter einem CDN/WAF (Cloudflare usw.)?

• Ja → prüfen Sie Security Events, ob der Crawler herausgefordert oder blockiert wurde. Verdächtig sind Bot Fight Mode / Super Bot Fight Mode, verwaltete WAF-Regeln oder eine eigene Firewall-Regel. Lassen Sie verifizierte Such-Bots durch (keine rohe UA-Allowlist).
• Nein → prüfen Sie IP-/UA-Sperren auf Serverebene, anschließend Sicherheits-Plugins (Wordfence usw.) und dann .htaccess sowie Dateiberechtigungen.

Q5. Ist die Regel behoben?

• Allowlisten nach verifiziertem Bot / DNS / IP-Bereich, niemals nur nach UA-String → Korrektur bestätigen im GSC-Bericht zur Seitenindexierung → bei Dringlichkeit über URL-Inspection eine erneute Indexierung anfordern.

Anti-Patterns — 403-Fehler, die ich ständig sehe

403 (oder 404) verwenden, um Googlebot zu verlangsamen. Der Mythos lautet, dass eine 403 das Crawling drosselt. Das tut sie nicht — 4xx (außer 429) hat keinen Einfluss auf die Crawl-Rate und deindexiert stattdessen die Seiten, die Sie mit 403 ausliefern. Wenn Sie ein Crawling verlangsamen müssen, geben Sie kurzzeitig (Stunden bis ein oder zwei Tage) 429, 503 oder 500 zurück oder verwenden Sie den Crawl-Rate-Bericht der Search Console. 403 ist niemals das Tool zur Crawl-Steuerung, auch nicht vorübergehend.

403 in einem Audit genauso behandeln wie 404. Beide lassen die URL letztlich aus dem Index fallen, daher liegt es nahe, sie zusammenzufassen. 404 bedeutet aber meist „verschwunden“, während 403 bedeutet „Zugriff aktiv verweigert“ — manchmal eine behebbare Fehlkonfiguration, manchmal eine beabsichtigte Sperre. Die Zusammenfassung verdeckt in beiden Fällen das eigentliche Problem. Diagnostizieren Sie Ursache und Absicht und nicht nur das Ergebnis.

Annehmen, Googlebot habe etwas Verdächtiges getan und die Sperre verdient. Googlebot sendet nie Zugangsdaten, daher passt eine 403 mit der Begründung „falsche Zugangsdaten“ nicht wirklich auf ihn. Das bedeutet aber nicht, dass jede Sperre ein Fehler ist — bestätigen Sie zuerst, dass die Seite öffentlich sein sollte. Falls ja, rationalisieren Sie die Sperre nicht als etwas, das Googlebot ausgelöst hat; finden Sie die ausgelöste Regel (WAF, IP-Sperre oder Plugin).

Nur nach User-Agent-String allowlisten. UA-Strings lassen sich trivial fälscht, daher lädt eine Regel allow if UA contains "Googlebot" jeden Scraper direkt durch, der vorgibt, Google zu sein. Verifizieren Sie per Reverse plus Forward DNS oder veröffentlichten IP-Bereichen oder verwenden Sie die Kategorie verifizierte Bots Ihres CDNs.

Eine 403 auf robots.txt mit einer 403 auf Seiten verwechseln. Die Wirkungen sind entgegengesetzt. Eine 403 auf einer Seite ist eine harte Sperre, die zur Deindexierung führt. Eine 403 auf robots.txt lässt Google annehmen, dass Sie keine Crawl-Regeln haben — es kann also Pfade crawlen, die Sie sperren wollten. Diagnostizieren Sie zuerst, welchen Fall Sie tatsächlich sehen.

Beabsichtigte 403 „beheben“. Staging-Websites, Admin-Bereiche, Mitgliederbereiche und Paywall-Inhalte sollen Crawler absichtlich mit 403 abweisen. Wenn Sie in einem Audit reflexartig jede 403 lösen, könnten Sie Dinge öffentlich machen, die nie indexiert werden sollten. Bestätigen Sie zuerst, dass die Seite öffentlich sein soll.

Das Framework aus Absicht, Umfang und ausgebender Schicht

Ein 403-Audit wird schneller, wenn ich drei Fragen der Reihe nach beantworte:

1. Absicht: Soll diese Ressource öffentlich sein? Lassen Sie eine bewusst private Sperre in Ruhe. Behandeln Sie eine 403 auf einer indexierbaren Seite als Vorfall.
2. Umfang: Betrifft der Fehler eine URL, ein Verzeichnis, einen User-Agent, eine Region oder jede Anfrage? Die Grenze identifiziert die verantwortliche Regel meist schneller, als Plugins zufällig zu verändern.
3. Ausgebende Schicht: Vergleichen Sie CDN-/WAF-Event, Origin-Zugriffsprotokoll, Anwendungsprotokoll und Response-Header. Ändern Sie die erste Schicht, welche die 403 tatsächlich ausgibt, nicht jede Schicht, die dies theoretisch könnte.

Prüfen Sie nach der Korrektur anonymen Zugriff und den Zugriff eines verifizierten Crawlers getrennt. Ein behaupteter Googlebot-User-Agent ist nützlich, um eine UA-Regel zu reproduzieren, aber kein Beweis für die Identität des Crawlers.

Prompt: eine 403 nach Schicht isolieren

Diagnose this HTTP 403 using only the evidence I paste. Classify the likely issuing
layer as CDN/WAF, web server, application/security plugin, filesystem permissions,
or intentional access control. Compare generic and claimed-bot responses, identify
which observation supports each conclusion, and give the smallest safe change plus
an anonymous curl test and Search Console validation. Do not recommend disabling all
security or trusting a user-agent string as identity.

[PASTE SANITIZED HEADERS, CURL OUTPUT, SECURITY EVENT, AND LOG LINES]

Prompt: eine WAF-Ausnahme prüfen

Review this WAF rule intended to stop 403s for legitimate search crawlers. Check its
scope, whether crawler identity is verified, what non-crawler traffic it could admit,
and whether robots.txt behaves differently from page URLs. Return a least-privilege
rewrite, test cases, and rollback conditions. Do not invent provider syntax.

[PASTE RULE AND PROVIDER]

Tools zur Diagnose von 403-Antworten

• Bulk HTTP Status Code Checker: Finden Sie heraus, ob die Sperre isoliert ist oder ein URL-Muster betrifft, ohne Ihre Anmeldesitzung mitzuschicken.
• HTTP Header Checker: Prüfen Sie CDN-Fingerprints, Request-IDs und Sicherheitsheader, die bei der Identifikation der ausgebenden Schicht helfen.
• Googlebot Verifier: Validieren Sie IP-Nachweise, bevor Sie einen Crawler durchlassen; der User-Agent allein ist niemals ein Beweis.
• Search Console Seitenindexierung und URL-Inspection: Ermitteln Sie die betroffene Menge, testen Sie die aktuelle Antwort live und validieren Sie nach der Korrektur.
• CDN-/WAF-Sicherheitsereignisse plus Origin-Logs: Wenn das Edge einen Block protokolliert und der Origin keine Anfrage sieht, gehört die Korrektur an das Edge.

Testen Sie Ihr Wissen: 403 Forbidden

Fünf kurze Fragen dazu, was eine 403 bedeutet und wie Sie damit umgehen. Wählen Sie jeweils eine Antwort und prüfen Sie die Antwort anschließend.

Ressourcen, die Ihre Zeit wert sind

Meine verwandten Texte

• HTTP-Statuscodes und ihre SEO-Auswirkungen — die vollständige Übersicht zu 4xx/5xx, der Platz von 403 unter den Codes und die Mechanik, mit der 4xx-Seiten aus dem Index fallen.
• Der Einsteigerleitfaden für technisches SEO — dort wird erklärt, wie Crawl-/Indexierungsprobleme wie 403 in den größeren Zusammenhang passen.
• Robots.txt und SEO: Alles, was Sie wissen müssen — der robots.txt-403-Sonderfall und die tatsächliche Funktionsweise von Crawl-Steuerung.

Meine Vorträge

• So funktioniert die Suche (SlideShare) — mein Ablauf von Crawling über Rendering und Indexierung bis zur Auslieferung; eine 403 ist ein Fehler am allerersten Gate. (Dauerhafter Hinweis: „Das ist mein Verständnis der Systeme … nicht zu 100 % vollständig oder korrekt.“)

Aus der Branche

• 403/404 nicht zum Drosseln verwenden (Google Search Central Blog) — Gary Illyes dazu, warum 4xx das falsche Werkzeug zum Drosseln des Crawlings ist.
• Googles Crawl-Rate reduzieren (Google Search Central) — der richtige Ansatz mit 500/503/429 zum Vergleich.
• Google warnt vor dem Missbrauch von 403-Statuscodes (Search Engine Roundtable) — die Anekdote zum Schweregrad von 403 vs. 503 (im Browser prüfen; die Seite gibt Bots 403).
• Google: 403-/404-Fehlerantworten nicht zum Drosseln von Googlebot verwenden (Search Engine Journal) — Berichterstattung über die Anleitung von 2023.
• So beheben Sie „Zugriff wegen Verweigerung (403) blockiert“ in der Google Search Console (SEOTesting) — solide Ursachen-/Behebungsstruktur, einschließlich der Frage, ob jede 403 behoben werden sollte.
• So beheben Sie den Fehler „Zugriff wegen Verweigerung (403) blockiert“ (Rank Math) — konkrete WordPress-chmod-Werte und ein Health-Check-Ablauf.
• HTTP-Statuscodes: Warum crawlt meine Website nicht? (Screaming Frog) — die crawlerseitige Diagnose (UA-Wechsel, JS-Rendering, IP-/UA-Allowlisting).

Änderungsprotokoll