403 Forbidden: Warum der Server den Zugriff verweigert

Ein 403 Forbidden ist für Website-Betreiber eine seltsame Meldung: Die Seite ist da, der Server antwortet, aber er weigert sich, sie auszuliefern. Anders als beim Fehler 500 ist nichts abgestürzt. Irgendeine Regel hat entschieden, dass diese Anfrage nicht bedient wird. Die Kunst besteht darin, herauszufinden, welche Regel das war, denn auf einem Hosting-Account gibt es mehrere Stellen, die einen 403 erzeugen können: das Dateisystem, die Webserver-Konfiguration, die .htaccess, das CMS und vorgeschaltete Schutzfilter. Dieser Beitrag zeigt, wie Sie die Quelle eingrenzen, was die typischen Log-Einträge bedeuten und warum ein übersehener 403 auch Ihre Google-Sichtbarkeit kostet.

Was bedeutet 403 Forbidden, und worin unterscheidet er sich von 401 und 404?

Laut RFC 9110, Abschnitt 15.5.4 hat der Server die Anfrage verstanden, verweigert aber ihre Ausführung. Eine Anmeldung ändert daran in der Regel nichts. Genau das trennt den 403 vom 401: Beim 401 fehlt eine gültige Anmeldung, und mit dem richtigen Passwort geht die Tür auf. Beim 403 ist die Tür für diese Anfrage grundsätzlich zu, egal wer klopft. Der 404 wiederum sagt, dass unter der Adresse nichts liegt.

Für die Fehlersuche ist eine Frage wichtiger als die Definition: Sehen alle Besucher den 403 oder nur einige? Trifft er alle Seiten, liegt die Ursache meist im Dateisystem oder in der Konfiguration. Trifft er nur bestimmte Personen, Länder, Geräte oder Bots, steckt fast immer ein Filter dahinter.

Welche Ursachen hat ein 403 Forbidden auf der eigenen Website?

In der Praxis lassen sich fast alle Fälle auf fünf Auslöser zurückführen. Welcher es ist, verrät meist schon der Zeitpunkt, an dem der Fehler zum ersten Mal auftrat.

Fehlende Startdatei. Ruft ein Besucher eine Domain oder ein Verzeichnis ohne Dateinamen auf, sucht der Webserver nach einer index.php oder index.html. Fehlt sie, bliebe nur, den Verzeichnisinhalt als Liste anzuzeigen. Das ist auf Produktivsystemen aus gutem Grund abgeschaltet, also antwortet der Server mit 403. Typisch nach einem Umzug, bei dem die Dateien in einem Unterordner gelandet sind, oder wenn die Domain auf das falsche Verzeichnis zeigt.

Falsche Dateirechte. Der Webserver muss Dateien lesen und Verzeichnisse durchlaufen dürfen. Haben Dateien nach einem Upload oder dem Entpacken eines Archivs die Rechte 600 oder Verzeichnisse 700, kann er sie je nach Serverkonfiguration nicht ausliefern. Der Normalfall sind 644 für Dateien und 755 für Verzeichnisse.

Regeln in der .htaccess. Zeilen wie "Require all denied", "Deny from all" oder Sperren für bestimmte IP-Bereiche wirken auf den Ordner, in dem die Datei liegt, und auf alle Unterordner. Sicherheits-Plugins schreiben solche Regeln oft selbst, etwa um wp-config.php, Upload-Verzeichnisse oder bestimmte Dateiendungen zu schützen. Läuft eine Regel zu breit, sperrt sie plötzlich auch legitime Aufrufe.

Das CMS selbst. WordPress, TYPO3 oder Shopware liefern einen 403, wenn ein Benutzer eine Funktion aufruft, für die seine Rolle keine Berechtigung hat, oder wenn ein Sicherheitstoken abgelaufen ist.

Schutzfilter vor der Anwendung. Web Application Firewalls, Bot-Sperren, Rate-Limits und Länderblocks antworten ebenfalls mit 403. Sie sind die häufigste Ursache, wenn der Fehler nur einzelne Besucher trifft, etwa ein Formular mit verdächtig aussehenden Eingaben, ein Firmennetz mit auffälligen Zugriffen oder einen Crawler mit unbekanntem User-Agent.

Wie finden Sie heraus, wer den Zugriff sperrt?

Raten kostet Zeit. Schneller geht es, wenn Sie den Verursacher über drei Hinweise eingrenzen: Wie sieht die Fehlerseite aus, wen trifft sie, und was steht im Error-Log? Die Seite allein sagt schon viel. Eine schlichte Servermeldung ohne Design stammt vom Webserver oder einem Filter davor, eine Seite im Layout der Website vom CMS. Testen Sie anschließend aus einem anderen Netz, etwa über das Smartphone ohne WLAN. Funktioniert die Seite dort, ist Ihre IP-Adresse oder Ihr Netz gesperrt und nicht die Seite selbst. Den entscheidenden Hinweis liefert das Error-Log. Bei webhostone finden Sie es im Adminpanel bei den Log-Dateien des jeweiligen Projekts; die Anleitung fehlerhafte Aufrufe in der Logdatei finden zeigt den Weg. Suchen Sie den Zeitpunkt Ihres letzten Aufrufs. Die folgenden Einträge sind die häufigsten, links in der Schreibweise von Apache, darunter jeweils die Entsprechung bei NGINX.

Ein Hinweis zur .htaccess: Wer im Adminpanel NGINX statt Apache als Webserver gewählt hat, kann eine .htaccess als Ursache ausschließen, weil NGINX diese Dateien nicht auswertet. Umgekehrt gilt nach einem Wechsel von NGINX auf Apache: Alte .htaccess-Dateien werden plötzlich wieder aktiv und können Sperren mitbringen, an die niemand mehr gedacht hat.

Wie beheben Sie den Fehler in der richtigen Reihenfolge?

Die Schritte sind so sortiert, dass zuerst die häufigen und risikolosen Prüfungen kommen. Sichern Sie vor jeder Änderung an Dateien oder Rechten das Projekt.

• Schritt 1: Startdatei und Zielverzeichnis prüfen. Liegt im Verzeichnis, auf das die Domain zeigt, eine index.php oder index.html? Nach Umzügen landet die Website oft eine Ebene zu tief, etwa unter /html/wordpress statt /html. Entweder die Dateien verschieben oder die Domain im Adminpanel auf den Unterordner zeigen lassen.
   
• Schritt 2: Dateirechte korrigieren. Prüfen Sie per FTP oder SSH die Rechte des Verzeichnisses und der aufgerufenen Datei. Die Anleitung Dateirechte per sFTP oder SSH anpassen zeigt beide Wege. Setzen Sie Verzeichnisse auf 755 und Dateien auf 644. Die Rechte 777 sind keine Lösung, sondern ein Sicherheitsrisiko, und auf Servern, auf denen Skripte unter Ihrem Benutzer laufen, führen sie sogar zu einem neuen Fehler.
   
• Schritt 3: .htaccess testen. Benennen Sie die Datei im betroffenen Verzeichnis und in den übergeordneten Verzeichnissen nacheinander um, zum Beispiel in .htaccess_test, und laden Sie die Seite neu. Verschwindet der 403, suchen Sie in der Datei nach Deny-, Require- oder RewriteRule-Zeilen mit dem Flag [F]. Benennen Sie die Datei danach unbedingt zurück, denn ohne sie fehlen bei WordPress und anderen Systemen die Regeln für sprechende URLs.
   
• Schritt 4: Sicherheits-Plugins und CMS-Rechte prüfen. Trifft der 403 nur das Backend, einen Login oder eine Schnittstelle, deaktivieren Sie probeweise das Sicherheits-Plugin, indem Sie sein Verzeichnis per FTP umbenennen. Prüfen Sie außerdem die Rolle des betroffenen Benutzers und leeren Sie Cache und Cookies; ein abgelaufenes Sicherheitstoken erzeugt bei Formularen gern einen 403, der nach dem Neuladen verschwindet.
   
• Schritt 5: Filter und Sperren prüfen. Im Sicherheitszentrum des Adminpanels NextGen lassen sich typische Angriffspunkte wie xmlrpc.php und Backend-Logins automatisch schützen und Bots gezielt sperren. Das ist sinnvoll, kann aber eine Anwendung treffen, die genau diese Endpunkte braucht, etwa eine App, die über XML-RPC Beiträge veröffentlicht, oder ein Monitoring-Dienst mit ungewöhnlichem User-Agent. Solche Schutzregeln können Sie dort einzeln abschalten. Nutzen Sie zusätzlich ein CDN oder eine Plugin-Firewall, prüfen Sie auch deren Protokoll.

Warum schadet ein 403 Ihrer Sichtbarkeit bei Google?

Für Besucher ist ein 403 ärgerlich, für die Suchmaschine ist er eindeutig. Google behandelt 403 wie andere 4xx-Codes: Die Seite gilt als nicht vorhanden und fällt nach einiger Zeit aus dem Index, so beschreibt es die Search-Central-Dokumentation zu HTTP-Statuscodes und Crawling. Google rät dort ausdrücklich davon ab, 401 oder 403 einzusetzen, um die Crawling-Frequenz zu drosseln. Das Risiko liegt in Sperren, die niemand bemerkt, weil sie nur Bots treffen: Eine zu scharf eingestellte Bot-Sperre, eine Länderblockade oder ein Plugin, das unbekannte User-Agents abweist, kann den Googlebot aussperren, während die Website im eigenen Browser einwandfrei läuft. Prüfen Sie deshalb in der Google Search Console im Bericht zur Seitenindexierung, ob Seiten mit dem Grund "Blockiert aufgrund von unzulässigem Zugriff (403)" auftauchen, und testen Sie wichtige URLs mit der URL-Prüfung.

Wann sollten Sie den Support einschalten?

Bleibt der 403 nach den fünf Schritten bestehen, sitzt die Sperre meist an einer Stelle, auf die Sie keinen Zugriff haben, etwa in der Serverkonfiguration oder einem vorgeschalteten Filter. Im Webhosting von webhostone kümmert sich webhostone um Webserver, PHP und die Schutzmechanismen auf Systemebene, Sie um Anwendung, Dateien und .htaccess. Beim Managed Server prüft der Support zusätzlich Webserver-Konfiguration, Firewall-Regeln und Dienste direkt auf dem System, weil er es selbst betreibt. Damit die Analyse schnell geht, schicken Sie drei Angaben mit: die betroffene URL, den genauen Zeitpunkt eines fehlgeschlagenen Aufrufs und Ihre öffentliche IP-Adresse zu diesem Zeitpunkt. Der Support ist an Werktagen telefonisch erreichbar, und die Server stehen seit 1998 ausschließlich in Rechenzentren in Deutschland.