Du klickst auf einen Link und bekommst statt der Seite nur eine knappe Absage: 403 Forbidden. Keine Erklärung, kein Hinweis, was du falsch gemacht hast. Das Ärgerliche daran ist, dass derselbe Fehler zwei völlig verschiedene Leute trifft. Den Besucher, der einfach nur eine Seite lesen will, und den Betreiber, dessen eigene Website plötzlich niemanden mehr hineinlässt.
Dieser Artikel ist für beide Seiten geschrieben. Die Screenshots und Beispiele stammen von redirect301.de selbst, das seit 2010 auf einem Apache-Server läuft. Die Diagnose unten bringt dich mit ein paar Klicks zum richtigen Abschnitt.
Ohne JavaScript läuft die Diagnose nicht. Spring direkt zum passenden Teil: Du besuchst eine Seite oder es ist deine eigene Seite.
Was der Statuscode 403 bedeutet
Festgelegt ist der Code in RFC 9110, der Norm für HTTP. Dort heißt es sinngemäß: Der Server hat die Anfrage verstanden, weigert sich aber, sie zu erfüllen. Hast du dabei Anmeldedaten mitgeschickt, hält der Server sie für nicht ausreichend. Die Norm sagt aber auch ausdrücklich, dass eine Anfrage aus Gründen verboten sein kann, die mit einer Anmeldung gar nichts zu tun haben. Im Alltag steckt hinter einem 403 deshalb oft eine IP-Sperre, eine Regel auf dem Server oder fehlende Dateirechte und kein falsches Passwort.
Zwei Abgrenzungen helfen beim Einordnen. Bei einem 401 fragt der Server nach Zugangsdaten, der Browser zeigt dann ein Anmeldefenster, und mit dem richtigen Passwort geht es weiter. Ein 403 lässt sich durch erneutes Anmelden nicht lösen. Und bei einem 404 gibt es die angefragte Seite nicht. Ein Server darf übrigens statt 403 auch 404 antworten, wenn er gar nicht verraten will, dass es dort etwas gibt. Ein 404 schließt eine Sperre deshalb nicht immer aus.
Wer sperrt? Die Fehlerseite verrät es
Zwischen deinem Browser und der Seite, die du sehen willst, liegen mehrere Stationen. An jeder davon kann ein 403 entstehen, und wer ihn beheben kann, hängt davon ab, an welcher.
- 1 Dein Gerät und dein Netz VPN oder Proxy, Browser-Erweiterung, Firmenfilter, gesperrte IP-Adresse Beheben du selbst
- 2 Schutzdienst davor Dienste wie Cloudflare mit Bot-Schutz, Länder- und IP-Sperren Beheben der Betreiber
- 3 Webserver Dateirechte, Regeln in der .htaccess, Ordner ohne Startdatei, Firewall des Hosters Beheben Betreiber oder Hoster
- 4 Anwendung Sicherheits-Plugin, Sperre nach Fehlversuchen, fehlende Berechtigung im Benutzerkonto Beheben der Betreiber
Bevor du irgendetwas änderst, schau dir die Fehlerseite genau an. Sie sieht je nach Station anders aus, und das ist der schnellste Hinweis auf den Verursacher. Die Standardseite von Apache ist eine schmucklose weiße Seite mit der Überschrift „Forbidden“ und einem einzigen Satz darunter. So sieht sie aus, wenn du hier auf redirect301.de einen Ordner ohne Startseite aufrufst:
Eine gestaltete Fehlerseite verrät dagegen kaum etwas. wordpress.org liefert für einen gesperrten Ordner eine Seite im eigenen Design mit Navigation und Suchfeld aus. Dass dahinter ein nginx-Server antwortet, sieht man der Seite nicht an, nur der Statuscode bleibt 403.
| Was du siehst | Wer vermutlich sperrt |
|---|---|
| Weiße Seite: „Forbidden“, darunter „You don't have permission to access this resource.“ | Apache mit Standardseite |
| „403 Forbidden“, darunter eine Linie und „nginx“ | nginx mit Standardseite |
| Der Name Cloudflare und eine Kennung, die Ray ID | Cloudflare als Schutzdienst vor der Seite |
| Logo oder Design des Hosters | Sperre beim Hoster, etwa eine Firewall |
| Seite im Design der Website | Die Website selbst oder der Server mit eigener Fehlerseite, von außen nicht zu unterscheiden |
Du besuchst eine Seite: was du selbst tun kannst
Als Besucher kannst du nur an der ersten Station etwas ändern, also an deinem Gerät und deinem Netz. Das klingt nach wenig, reicht aber erstaunlich oft. Die wichtigste Frage ist, ob der Fehler nur auf einer Seite auftritt oder auf vielen.
Der 403 kommt auf vielen Seiten gleichzeitig
Dann liegt es fast sicher nicht an den Seiten, sondern an dir oder deinem Anschluss. Ein typischer Fall stand vor einiger Zeit im Forum r/de_EDV auf Reddit: Im Heimnetz kam auf vielen Seiten ein 403, auf allen Geräten, vom Spiele-Login bis zum Möbelhaus. Über den Hotspot des Handys funktionierte alles. Die meisten Antworten vermuteten, dass die öffentliche IP-Adresse des Anschlusses auf einer Sperrliste gelandet war. Eine bestätigte Lösung gab es im Thread nicht, aber das Muster ist eindeutig: Wenn es über mobile Daten klappt, ist dein Anschluss gesperrt, nicht dein Gerät.
Häufige Ursachen in diesem Fall:
- VPN oder Proxy: Viele Seiten sperren die Adressen bekannter VPN-Dienste, weil von dort auch viele Bots kommen. Schalte das VPN testweise aus oder wähle einen anderen Server.
- IP-Adresse auf einer Sperrliste: Bei vielen Privatanschlüssen bekommst du eine neue Adresse, wenn du den Router neu verbindest. Die alte hatte vorher womöglich jemand anderes, der damit Unfug getrieben hat.
- Browser-Erweiterung: Werbeblocker, Datenschutz-Erweiterungen oder Tools, die den User-Agent verändern, können deine Anfragen für Schutzsysteme wie die eines Bots aussehen lassen. Teste einen anderen Browser ohne Erweiterungen.
Der 403 kommt nur auf einer Seite
Dann ist eine Sperre auf genau dieser Seite wahrscheinlich, und die kann gewollt sein. Manche Bereiche sind nur für angemeldete Nutzer gedacht, manche Seiten sperren ganze Länder, und manche Adressen zeigen auf einen Ordner, dessen Inhalt niemand sehen soll. Geh diese Reihenfolge durch:
- Adresse prüfen. Endet sie auf einen Schrägstrich und zeigt auf einen Ordner statt auf eine Seite? Dann probier die Startseite der Website und klick dich von dort durch.
- Privates Fenster öffnen. Dort fehlen deine gespeicherten Cookies, und Erweiterungen sind meist ausgeschaltet. Klappt es dort, lösch die Cookies dieser einen Seite oder schalte die Erweiterungen der Reihe nach ab.
- Mobile Daten testen. Klappt es am Handy ohne WLAN, ist dein Netz gesperrt, etwa ein Firmennetz mit Filter oder deine aktuelle IP-Adresse.
- Kurz warten. Wer in kurzer Zeit viele Seiten abruft, landet bei manchen Schutzsystemen für eine Weile auf der Sperrliste.
- Den Betreiber anschreiben. Steht auf der Fehlerseite eine Kennung wie die Ray ID von Cloudflare, schick sie mit. Damit findet der Betreiber deine Anfrage in seinem Protokoll.
Was nicht hilft: den Browser neu installieren oder die Seite immer wieder neu laden. Ein 403 ist eine Entscheidung der Gegenseite, an deinem Browser ist nichts kaputt. Eine Ausnahme gibt es beim Fall „viele Seiten, nur im eigenen Netz“: Sperrlisten führen Adressen, von denen Spam oder Angriffe kamen. Das kann auch ein verseuchtes Gerät in deinem Heimnetz verursacht haben, dann lohnt ein Virenscan auf allen Geräten.
Es ist deine Seite: Ursachen auf dem eigenen Server
Als Betreiber hast du einen großen Vorteil: Du musst nicht raten. In den meisten Fällen schreibt der Webserver ins Fehlerprotokoll, warum er nein gesagt hat. Deshalb kommt das Protokoll zuerst, und erst danach die einzelnen Ursachen.
Zuerst ins Fehlerprotokoll schauen
Das Fehlerprotokoll heißt bei Apache meist error_log oder error.log, bei Hostern findest du es in der Regel im Kundenmenü. Such nach der Uhrzeit deines Aufrufs. Die Meldungen von Apache 2.4 tragen eine Kennung, die mit AH beginnt, und die verrät die Ursache ziemlich genau:
| Meldung im Log | Was dahintersteckt |
|---|---|
AH01630: client denied by server configuration | Eine Regel sperrt, meist Require oder Deny in der .htaccess oder Serverkonfiguration |
AH01276: Cannot serve directory … No matching DirectoryIndex … forbidden by Options directive | Ordner ohne Startdatei, die Verzeichnisauflistung ist abgeschaltet |
AH00035: access to … denied … because search permissions are missing on a component of the path | Einem Ordner auf dem Weg zur Datei fehlt das Recht zum Betreten |
AH00132: file permissions deny server access | Der Webserver darf die Datei nicht lesen |
access forbidden by rule (nginx) | Eine deny-Regel in der nginx-Konfiguration |
"/pfad/" is forbidden (13: Permission denied) (nginx) | Fehlende Rechte auf die Startdatei oder den Ordner |
Nicht jede Sperre landet im Fehlerprotokoll. Eine Rewrite-Regel mit [F] etwa taucht je nach Einstellung nur im Zugriffsprotokoll auf, dort als Zeile mit dem Status 403. Steht dein Aufruf in keinem der beiden Protokolle, hat dein Webserver die Anfrage nie gesehen. Dann sperrt eine Station davor, also ein Schutzdienst wie Cloudflare oder eine Firewall des Hosters, die eigene Protokolle führt.
Falsche Dateirechte
Nach einem Umzug, einem Upload per FTP oder dem Entpacken eines Archivs stimmen die Rechte oft nicht mehr. Der Webserver läuft unter einem eigenen Benutzer und muss Dateien lesen und Ordner betreten dürfen. Die WordPress-Dokumentation empfiehlt dafür Werte, die auch für andere Systeme taugen: 644 oder 640 für Dateien, 755 oder 750 für Ordner und 440 oder 400 für die wp-config.php.
Im FTP-Programm setzt du die Rechte per Rechtsklick, in FileZilla heißt der Menüpunkt „Dateiberechtigungen“. Mit SSH-Zugang geht es für einen ganzen Ordnerbaum auf einmal:
find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;Setz dabei bitte nicht aus Verzweiflung alles auf 777. Das löst den 403 zwar oft, erlaubt aber jedem Prozess auf dem Server, deine Dateien zu ändern.
Ordner ohne Startdatei
Rufst du einen Ordner auf, sucht der Server nach einer Startdatei wie index.html oder index.php. Findet er keine und ist die automatische Verzeichnisauflistung abgeschaltet, antwortet Apache mit 403. Genau so entsteht die Standardseite im Screenshot oben: Im Ordner /includes/ von redirect301.de liegt keine Startdatei, und die .htaccess schaltet die Auflistung mit Options -Indexes ab.
Das ist gewollt und sinnvoll, denn sonst könnte jeder den Inhalt des Ordners durchblättern. Die Google Search Console meldete für diese Seite im Sommer neun solcher Adressen mit 403, alle waren Ordner ohne Startdatei. Handlungsbedarf gibt es da nur, wenn ein Ordner eigentlich eine Seite anzeigen soll. Dann fehlt die index-Datei oder sie heißt anders, als der Server erwartet.
Regeln in der .htaccess
Die .htaccess ist die häufigste Ursache für einen 403, den man sich selbst eingebaut hat. Drei Muster sind typisch:
- Require und Deny:
Require all deniedsperrt alles,Require all grantederlaubt alles. Seit Apache 2.4 ist das die richtige Schreibweise. Das alteOrder,AllowundDenyfunktioniert nur noch über ein Kompatibilitätsmodul. Die Apache-Dokumentation rät ausdrücklich davon ab, alte und neue Anweisungen zu mischen, weil die alten dabei Vorrang bekommen können und ein Ordner trotzRequiregesperrt bleibt. Wer alte Anleitungen kopiert, landet genau dort. - Rewrite-Regeln mit [F]: Das Flag
[F]beendet eine Regel mit einem 403. So arbeiten Sperren gegen Spam-Bots und der Hotlink-Schutz für Bilder. Ist die Bedingung zu weit gefasst, trifft sie auch echte Besucher. Beim Hotlink-Schutz etwa bekommen fremde Seiten absichtlich einen 403, wenn sie deine Bilder einbinden. - IP-Sperren für den Admin-Bereich: Wer den Login per IP-Adresse absichert und keine feste IP hat, sperrt sich nach dem nächsten Adresswechsel selbst aus. Ein Verzeichnisschutz mit .htpasswd ist für wechselnde Adressen die bessere Wahl.
Der schnellste Test: Benenne die .htaccess per FTP um, zum Beispiel in .htaccess-test. Ist der 403 dann weg, steckt die Ursache in der Datei. Nimm die Zeilen anschließend blockweise wieder dazu, bis der Fehler zurückkommt. Denk daran, dass ohne .htaccess auch Weiterleitungen und schöne URLs fehlen, der Test sollte also nur kurz dauern.
Die Firewall des Hosters
Viele Hoster setzen eine Web Application Firewall wie ModSecurity vor die Websites. Sie prüft jede Anfrage auf Muster, die nach Angriff aussehen, und blockt sie, meist mit einem 403. Das trifft gelegentlich auch harmlose Anfragen: ein Beitrag mit Code-Schnipseln, ein sehr langes Formular, bestimmte Wörter in einem Suchfeld. In WordPress zeigt sich das oft beim Klick auf „Aktualisieren“ im Editor, ausführlich beschrieben im Artikel WordPress speichert nicht mehr vollständig.
Erkennen lässt sich das am Protokoll: ModSecurity vermerkt bei einer Sperre die Nummer der Regel, die zugeschlagen hat. Je nach Hoster steht das im normalen Fehlerprotokoll oder in einem eigenen Firewall-Protokoll, manchmal bekommst du es nur über den Support. Mit dieser Nummer kann der Hoster die Regel für deine Seite oder für einen bestimmten Pfad ausnehmen. Schalte die Firewall nicht komplett ab, nur weil eine Regel stört.
Sicherheits-Plugins in WordPress
Sicherheits-Plugins sperren IP-Adressen nach mehreren Fehlversuchen beim Login, blocken ganze Länder oder schreiben eigene Regeln in die .htaccess. Kommst du selbst nicht mehr ins Backend, deaktivierst du das Plugin per FTP: Benenne seinen Ordner unter wp-content/plugins um. WordPress findet es dann nicht mehr und schaltet es ab. Prüf danach trotzdem die .htaccess, denn Regeln, die das Plugin dort eingetragen hat, können stehen bleiben.
Gibt die Website insgesamt merkwürdige Fehler aus, hilft der Überblick unter WordPress reparieren.
401, 403, 404, 410 und 429 im Vergleich
Ein 403 wird gern verwendet, wo ein anderer Code besser passen würde. Diese Übersicht hilft, den richtigen zu wählen, und beim Lesen eines Logs, die Codes auseinanderzuhalten:
| Code | Bedeutung | Passt, wenn … |
|---|---|---|
| 401 | Unauthorized | eine Anmeldung fehlt oder falsch ist und der Server danach fragt |
| 403 | Forbidden | der Zugriff verboten ist und eine Anmeldung daran nichts ändert |
| 404 | Not Found | es die Adresse nicht gibt, oder ihre Existenz verborgen bleiben soll |
| 410 | Gone | eine Seite dauerhaft entfernt wurde |
| 429 | Too Many Requests | jemand in kurzer Zeit zu viele Anfragen geschickt hat |
Welchen Code eine Adresse gerade liefert, prüfst du mit dem Statuscode-Checker, für bis zu zehn Adressen auf einmal. Verwandte Fehler mit eigenem Artikel sind der HTTP Error 500 und der HTTP Error 431.
Was Google mit einem 403 macht
Für Google bedeuten alle Codes der 4xx-Gruppe, mit Ausnahme von 429, dasselbe: Der Inhalt existiert nicht. Liefert eine Seite, die bereits im Index steht, einen 403, entfernt Google sie aus dem Index. Das kann auch unabsichtlich passieren, wenn eine Firewall oder ein Plugin den Googlebot für einen Angreifer hält.
Ein zweiter Punkt betrifft Server, die unter zu vielen Anfragen ächzen. Google rät ausdrücklich davon ab, das Crawling mit 401 oder 403 zu bremsen, weil diese Codes keinen Einfluss auf die Crawling-Geschwindigkeit haben. Wer den Googlebot kurzzeitig drosseln will, antwortet mit 500, 503 oder 429.
Ob Google auf deine Seiten 403 bekommt, zeigt die Search Console im Bericht zur Seitenindexierung. Bei Ordnern ohne Startdatei, wie oben beschrieben, ist das in Ordnung. Bei echten Inhaltsseiten solltest du sofort nachsehen.
Eine eigene 403-Seite einrichten
Die schmucklose Standardseite lässt Besucher ratlos zurück. Mit einer Zeile in der .htaccess zeigt Apache stattdessen eine eigene Seite:
ErrorDocument 403 /403.htmlSchreib auf diese Seite in normaler Sprache, dass der Bereich gesperrt ist, verlinke die Startseite und nenne einen Weg, dich zu erreichen. Achte darauf, dass die Fehlerseite selbst nicht in einem gesperrten Ordner liegt, sonst kann der Server sie nicht ausliefern.
Häufige Fragen
Liegt ein 403 an mir oder an der Website?
Tritt er auf vielen Seiten gleichzeitig auf, liegt es an deinem Gerät oder deinem Anschluss, etwa an einem VPN oder einer gesperrten IP-Adresse. Tritt er nur auf einer Seite auf, sperrt meist diese Seite, oft mit Absicht.
Ist mein Rechner gehackt, wenn ich einen 403 bekomme?
In aller Regel nicht. Ein 403 ist eine Entscheidung des Servers, kein Fehler auf deinem Rechner. Kommt er aber auf vielen Seiten und nur in deinem Netz, steht vermutlich deine IP-Adresse auf einer Sperrliste. Dorthin kommt sie, wenn von ihr Spam oder Angriffe ausgingen, etwa von einem früheren Nutzer der Adresse oder von einem verseuchten Gerät in deinem Netz.
Was ist der Unterschied zwischen 401 und 403?
Bei 401 fragt der Server nach Zugangsdaten, und mit den richtigen kommst du hinein. Bei 403 hilft eine Anmeldung nicht, der Zugriff ist verboten, egal wer fragt.
Warum bekomme ich auf meiner eigenen Seite einen 403?
Die häufigsten Ursachen sind falsche Dateirechte, eine Regel in der .htaccess, ein Ordner ohne Startdatei, die Firewall des Hosters oder ein Sicherheits-Plugin. Das Fehlerprotokoll des Servers nennt dir in den meisten Fällen direkt, welche davon zutrifft.
Quellen
Abgerufen am 07.10.2026.
- RFC 9110: HTTP Semantics, 403 Forbidden
- RFC 6585: 429 Too Many Requests
- Google Search Central: HTTP-Statuscodes und Google Suche
- Google Search Central: Crawling-Frequenz verringern
- Apache: Upgrade auf 2.4, Zugriffssteuerung
- Apache: mod_authz_core und Require
- Apache: mod_rewrite mit Flag [F]
- Apache: ErrorDocument
- Cloudflare: Error 403
- WordPress: Dateirechte
- OWASP Core Rule Set: Anomaly Scoring