Lösungen für: HTTP-Fehler 500, 502, 503, 504 und 403 in WordPress

Wenn Ihre WordPress-Website statt Ihrer Inhalte nur noch eine Zahl wie 500, 503 oder 403 zeigt, ist das ein Schreck, aber selten ein Verlust. Ihre Beiträge und Seiten sind in aller Regel noch da. Der Server liefert sie nur gerade nicht aus.

Die konkrete Zahl sagt vor allem, wer gerade antwortet, und weniger, was kaputt ist. Sehen Sie deshalb ins Fehlerprotokoll Ihres Hosters. Bei 500 steht dort meist ein PHP-Fehler oder eine falsche Zeile in der .htaccess. Bei 502, 503 und 504 antwortet PHP nicht oder zu langsam, das klärt meist der Hoster. Bei 403 verweigert eine Regel, eine Dateiberechtigung oder eine Firewall den Zugriff.

Alles in diesem Beitrag habe ich auf einer Testinstallation (WordPress 7.1.4 auf Deutsch, PHP 8.4) absichtlich kaputt gemacht und wieder repariert. Für 502, 503 und 504 habe ich dieselbe Website hinter nginx, hinter Apache mit PHP-FPM und hinter Apache mit FastCGI betrieben, denn genau davon hängt ab, welche Zahl Sie sehen. Wo das Ergebnis anders aussieht, als Foren und Anleitungen behaupten, steht das dabei.

Was bedeuten die HTTP-Fehler 500, 502, 503, 504 und 403 in WordPress?

Das sind Statuscodes, mit denen ein Webserver eine Anfrage beantwortet. Sie stammen nicht von einem zentralen WordPress-Dienst: WordPress läuft auf Ihrem eigenen Webspace, die Ursache liegt also bei Ihrer Website oder Ihrem Hoster. Der Wortlaut hängt vom Server und vom Browser ab:

• 500: „500 Internal Server Error“ oder „Internal Server Error“, auf Deutsch „Interner Serverfehler“. Etwas ist schiefgegangen, und der Server sagt nicht, was. Ist die Antwort leer, zeigt Chrome eine eigene Seite: „Diese Seite funktioniert nicht“, „… kann diese Anfrage momentan nicht verarbeiten“ und „HTTP ERROR 500“.
• 502: „502 Bad Gateway“, auf Deutsch etwa „fehlerhaftes Gateway“. Ein Webserver hat das Programm dahinter gefragt, meist PHP, und keine brauchbare Antwort bekommen. Steht „nginx“ darunter, ist nginx nur der Bote.
• 503: „503 Service Unavailable“ oder „503 Service Temporarily Unavailable“, auf Deutsch „Dienst nicht verfügbar“. Bei WordPress selbst: „Wartungsmodus“ und „Diese Website ist aufgrund planmäßiger Wartungsarbeiten vorübergehend nicht verfügbar. Bitte versuche es in wenigen Minuten erneut.“, in älteren Versionen „Wegen Wartungsarbeiten ist diese Website kurzzeitig nicht verfügbar. Schau in einer Minute nochmal vorbei.“, auf Englisch „Briefly unavailable for scheduled maintenance. Check back in a minute.“
• 504: „504 Gateway Timeout“ oder „504 Gateway Time-out“. Ein Webserver hat auf das Programm dahinter gewartet und irgendwann aufgegeben.
• 403: „403 Forbidden“ und „You don't have permission to access this resource“, auf Deutsch „Sie haben keine Berechtigung, auf diese Ressource zuzugreifen“. Auch „Access denied.“ oder „Sorry, you have been blocked“ gehören dazu. Der Server hat Sie verstanden und liefert absichtlich nicht aus.

Was ist der Unterschied zwischen HTTP 500 und 503 bei WordPress?

Laut Definition meint 500 einen Fehler und 503 eine vorübergehende Überlastung oder Wartung. In der Praxis bestimmt aber der Webserver des Hosters die Zahl. Dieselbe Störung hat in meinem Test je nach Server eine andere Zahl ergeben:

• Ein PHP-Prozess stirbt mitten in der Anfrage: nginx 502, Apache mit PHP-FPM 503, Apache mit FastCGI 500.
• Eine Anfrage dauert 70 Sekunden: nginx und Apache mit PHP-FPM nach 60 Sekunden 504, Apache mit FastCGI schon nach 40 Sekunden 500.
• PHP läuft gar nicht: nginx 502, Apache mit PHP-FPM 503.

Eine Anleitung, die aus der Zahl allein auf die Ursache schließt, kann bei Ihnen also danebenliegen. Der Eintrag im Protokoll sagt mehr, siehe Schritt 3.

Bevor Sie etwas ändern: Ein falscher Handgriff kann mehr Schaden anrichten als der Fehler selbst. Ein Tippfehler in der wp-config.php legt die ganze Website lahm, ein falscher Befehl in der Datenbank oder auf der Kommandozeile lässt sich oft nicht zurücknehmen. Mit diesen Regeln bleibt jeder Schritt umkehrbar:

• Zuerst eine vollständige Sicherung von Dateien und Datenbank, abgelegt außerhalb Ihres Webspace. Viele Hoster bieten dafür eine eigene Funktion an. Fragen Sie im Zweifel nach, wie Sie die Sicherung wieder einspielen.
• Vor jeder Bearbeitung eine Kopie der Datei auf Ihren eigenen Rechner laden. Eine Kopie auf dem Server darf nicht wp-config.php.bak heißen, denn so kann sie jeder samt Datenbank-Passwort im Browser abrufen. Nennen Sie sie wp-config-kopie.php, und löschen Sie sie am Ende.
• Immer nur eine Änderung, dann testen. Hat sie nicht geholfen, machen Sie sie rückgängig, bevor Sie die nächste versuchen.
• Eine Testkopie (Staging) nutzen, wenn Ihr Hoster eine anbietet: Dort darf alles schiefgehen.
• Aufhören ist eine gute Option: wenn Sie nicht mehr wissen, was Sie geändert haben, wenn ein Schritt anders aussieht als hier beschrieben oder wenn die Website täglich Geld verdient. Dann schreiben Sie mir, das Angebot steht am Ende dieses Beitrags.

Schritt 1: Ohne Änderung sehen, wer bei einem HTTP-Fehler in WordPress antwortet

Dafür müssen Sie nichts ändern. Sehen Sie sich zuerst die Fehlerseite an:

• Die Seite trägt die schlichte graue Gestaltung von WordPress: WordPress läuft und hat selbst geantwortet. Bei „Wartungsmodus“ lesen Sie unten beim 503 weiter, bei „kritischer Fehler“ in den Lösungen für: kritischer Fehler und weiße Seite.
• Nur eine schwarze Überschrift auf Weiß, darunter vielleicht „nginx“ oder „Apache“: Der Webserver hat geantwortet, WordPress ist gar nicht zu Wort gekommen. Bei Plesk ist diese Seite gestaltet, mit „Server Error“, der Zahl und „That's what you can do“.
• Eine leere Seite oder „HTTP ERROR 500“ in Chrome: Meist ist PHP abgestürzt, bevor WordPress etwas anzeigen konnte. Auch das steht in den Lösungen für den kritischen Fehler.
• Nur die zwei Wörter „Access denied.“: PHP-FPM darf die Datei nicht lesen, siehe unten beim 403.
• Eine Seite mit Cloudflare-Logo oder „Ray ID“: Cloudflare hat geantwortet, siehe den Abschnitt zu Cloudflare.

Rufen Sie dann drei Adressen auf, mit Ihrer Domain:

• https://ihre-domain.at/wp-includes/images/w-logo-blue.png ist ein Bild, das bei jeder WordPress-Installation dabei ist, und braucht kein PHP. In meinem Test ist es bei 502, 503 und 504 weiter angezeigt worden: Der Webserver läuft, das Problem liegt dahinter. Fehlt auch das Bild, liegt es am Webserver selbst oder an einer Regel. Nur umgekehrt beweist es nichts: Steht nginx vor Apache, was etwa bei Plesk üblich ist, ist das Bild auch bei einer kaputten .htaccess angezeigt worden.
• https://ihre-domain.at/wp-login.php zeigt, ob nur die Startseite betroffen ist oder alles.
• Dieselbe Adresse über ein anderes Netz, zum Beispiel am Handy ohne WLAN. Funktioniert sie dort, ist Ihre eigene IP-Adresse gesperrt, und Sie suchen eine Sperre, keinen kaputten Server.

Der genaue Statuscode steht in den Entwicklertools des Browsers (F12, Reiter „Netzwerk“, Seite neu laden) oder in der ersten Zeile dieses Befehls im Terminal:

curl -I https://ihre-domain.at/

Schritt 2: Eine Störung beim Hoster als Ursache des HTTP-Fehlers ausschließen

Fragen Sie sich, was sich zuletzt geändert hat: ein Plugin, ein Update, eine neue PHP-Version, eine Zeile in der .htaccess, eine Sicherheitseinstellung. Hat sich nichts geändert und sehen Sie 502, 503 oder 504, sollten Sie zuerst nichts ändern, sondern auf die Störungsseite Ihres Hosters sehen und es nach ein paar Minuten noch einmal versuchen. An den Dateien Ihrer Website zu drehen, hilft dabei nicht und kann neue Fehler bringen.

Schritt 3: Den Grund für den HTTP-Fehler von WordPress im Fehlerprotokoll finden

Das Fehlerprotokoll des Webservers nennt den Grund. In Plesk, wie bei meinem eigenen Hosting, finden Sie es unter Websites & Domains → Ihre Domain → Protokolle oder im Dateimanager unter logs. Wo es bei Ihnen liegt, weiß der Support Ihres Hosters. Das WordPress-eigene debug.log hilft hier nicht, denn bei den Fehlern dieses Beitrags kommt WordPress meist gar nicht zum Zug.

Suchen Sie die jüngste Zeile zum Zeitpunkt des Fehlers. Das sind die Einträge aus meinen Tests:

• PHP Fatal error: ein PHP-Absturz. Der Weg steht in den Lösungen für den kritischen Fehler.
• .htaccess: Invalid command … oder … not allowed here: eine Zeile in der .htaccess, siehe 500.
• Request exceeded the limit of 10 internal redirects: eine Weiterleitungsschleife in der .htaccess, siehe 500.
• mod_fcgid: read data timeout und End of script output before headers: Das Skript war zu langsam oder ist abgestürzt, und Apache mit FastCGI zeigt das als 500, siehe 504.
• connect() failed (111: Connection refused) oder failed to make connection to backend: PHP oder der Webserver dahinter läuft nicht, siehe 502.
• Connection reset by peer: Ein PHP-Prozess ist mitten in der Anfrage gestorben, siehe 502.
• upstream sent too big header: Die Kopfzeilen der Antwort sind zu groß, siehe 502.
• upstream timed out oder The timeout specified has expired: zu langsam, siehe 504.
• client denied by server configuration: eine Require-Regel, siehe 403.
• Cannot serve directory: Es gibt keine index.php, siehe 403.
• file permissions deny server access oder unable to check htaccess file: Dateiberechtigungen, siehe 403.
• ModSecurity: Access denied with code 403: die Firewall des Servers, siehe 403.

WordPress-Fehler 500 „Internal Server Error“: Die .htaccess und andere Ursachen ohne PHP-Fehler

Ein 500 bei WordPress ist meist ein PHP-Absturz: Dafür gibt es die Lösungen für den kritischen Fehler, und auch die Datenbankverbindung meldet sich mit einer 500. Hier geht es um den Rest. Ein typisches Zeichen ist eine nackte Seite „Internal Server Error“ und kein PHP-Fehler im Protokoll. Mit einer kaputten .htaccess war in meinem Test alles betroffen, auch die Anmeldung.

So prüfen Sie die .htaccess von WordPress

1. Laden Sie die Datei .htaccess aus dem WordPress-Ordner auf Ihren Rechner. Sie liegt neben wp-config.php. Im Dateimanager müssen Sie versteckte Dateien eventuell erst einblenden.
2. Benennen Sie sie auf dem Server um, zum Beispiel in htaccess.alt, und rufen Sie die Website auf.
3. Läuft die Startseite wieder, war es die Datei. Unterseiten zeigen jetzt 404, das ist in diesem Moment normal.
4. Melden Sie sich an und öffnen Sie Einstellungen → Permalinks. Im Test hat schon das Öffnen der Seite die Datei neu geschrieben, ohne Speichern, und alle Unterseiten sind wieder gegangen. Der WP-CLI-Befehl wp rewrite flush --hard hat die Datei dagegen nicht angelegt, sondern nur eine Warnung ausgegeben.
5. Tragen Sie eigene Regeln einzeln wieder ein, aus Ihrer Kopie, und prüfen Sie nach jeder die Website. Die neue Datei enthält nur den Block von WordPress. Regeln von Sicherheits- und Cache-Plugins oder eine Weiterleitung auf https fehlen danach, bis Sie sie zurückholen.

Die üblichen Ursachen für einen 500 durch die .htaccess in WordPress

• Eine Zeile für ein fehlendes Modul: ExpiresActive On hat ohne das passende Apache-Modul einen 500 ergeben. Innerhalb von <IfModule mod_expires.c> … </IfModule> war sie harmlos.
• php_value oder php_flag: Das haben viele Anleitungen und manche Plugins eingetragen, um PHP-Grenzen zu erhöhen. Mit Apache und direkt eingebundenem PHP ist es gegangen, mit PHP-FPM und mit FastCGI hat es sofort einen 500 ergeben (Invalid command 'php_value'). Einem Wechsel des Hosters oder der PHP-Betriebsart kann das also genau so folgen. Solche Werte gehören dann in eine Datei .user.ini, oder Sie stellen sie im Kundenbereich ein.
• Der Hoster erlaubt die Anweisung nicht: Mit AllowOverride FileInfo hat WordPress' eigener Block funktioniert, Options -Indexes und Require all granted haben aber … not allowed here und einen 500 ergeben. Deshalb prüft mein eigenes Skript, das Dateien per Require sperrt, nach dem Eintragen die Website und nimmt den Block bei einem 500 wieder heraus.
• Nur Unterseiten zeigen 500, Startseite und Anmeldung gehen: Das war im Test eine alte RewriteBase und RewriteRule . /alt/index.php, wie sie nach dem Umzug aus einem Unterordner stehen bleibt. Die Weiterleitung läuft dann im Kreis. Tragen Sie den richtigen Pfad ein oder lassen Sie die Datei neu schreiben.

Nicht jeder 500 ohne PHP-Fehler kommt von der .htaccess: Steht read data timeout im Protokoll und ist der Fehler erst nach einer langen Wartezeit gekommen, lesen Sie beim 504 weiter.

WordPress-Fehler 502 Bad Gateway: PHP antwortet dem Webserver nicht

Sie sehen meist nur „502 Bad Gateway“ und vielleicht „nginx“. Das Bild aus Schritt 1 kommt weiter. Die Fehlermeldung kommt vom Webserver, aber das Problem liegt bei dem, was er gefragt hat.

• PHP läuft nicht. In meinem Test ist die Website sofort wieder gegangen, als PHP wieder gestartet war. Im Protokoll steht Connection refused. Das liegt beim Hoster: Rufen Sie an und nennen Sie die Uhrzeit. Hat es direkt nach einem Wechsel der PHP-Version begonnen, sagen Sie auch das. Dasselbe passiert, wenn bei einem Hoster mit nginx und Apache der Apache nicht antwortet.
• Ein PHP-Prozess stirbt, die nächste Anfrage geht wieder. Dann sind Sie mal betroffen und mal nicht, oder nur auf einer bestimmten Seite. Im Protokoll steht Connection reset by peer. Einen harten Abbruch nach einem Zeitlimit des Servers sieht man genauso: Im Test mit einem 10-Sekunden-Limit ist nach 10 Sekunden eine 502 gekommen. Merken Sie sich die Seite und die Uhrzeit, und schalten Sie Plugins der Reihe nach ab, wenn nur eine bestimmte Aktion betroffen ist. Wie das ohne Dashboard geht, steht in den Lösungen für den kritischen Fehler. In einem Forum z.B. hat ein Betroffener seine 502 beim Abmelden so auf ein bestimmtes Plugin eingegrenzt.
• Die Antwort hat zu große Kopfzeilen. Das betrifft oft nur eine Aktion wie das Anmelden, Abmelden oder Benutzer wechseln, weil dort viele Cookies gesetzt werden. In meinem Test hat nginx 3 KB Cookies durchgelassen und bei 8 KB eine 502 gezeigt (upstream sent too big header), während Apache mit PHP-FPM allein auch 16 KB ausgeliefert hat. Größere Puffer in nginx (fastcgi_buffer_size 32k und fastcgi_buffers 8 32k) haben es behoben. Das ändert Ihr Hoster, oder Sie ersetzen das Plugin, das so viele Cookies setzt.

WordPress-Fehler 503 Service Unavailable: Wartungsmodus, Sperre oder Überlastung

Eine 503 meint „gerade nicht“, und sie kommt aus sehr verschiedenen Quellen. Ist sie dauerhaft? Laut Definition nicht, aber sie verschwindet nur von selbst, wenn ihre Ursache verschwindet.

Der Wartungsmodus von WordPress. Während Updates legt WordPress im Hauptordner die Datei .maintenance an und löscht sie danach wieder. Solange sie gilt, zeigen Website, Anmeldung und Dashboard die Meldung, auch wenn Sie angemeldet sind. Bleibt die Datei nach einem abgebrochenen Update liegen, haben Sie zwei Möglichkeiten: Warten Sie zehn Minuten, oder löschen Sie die Datei .maintenance per Dateimanager oder FTP. Im Test ist die Website nach 9 Minuten noch gesperrt gewesen, nach 11 Minuten wieder frei, denn WordPress beachtet die Datei nur so lange. Maßgeblich ist die Zeit in der Datei, nicht ihr Dateidatum. Danach prüfen Sie unbedingt, ob das Update vollständig durchgelaufen ist.

Ein Wartungs-Plugin. Das Plugin LightStart (wp-maintenance-mode) hat im Test Besuchern 503 und „Maintenance mode“ gezeigt, mir als angemeldetem Administrator aber die normale Website. Sie sehen dann also keinen Fehler, Ihre Besucher schon. Prüfen Sie das in einem privaten Fenster.

Eine Sperre durch Wordfence. Eine in Wordfence gesperrte Adresse hat in meinem Test 503 und „Your access to this site has been limited by the site owner“ bekommen, nicht 403, während alle anderen Besucher die normale Website gesehen haben. Sperrt es Sie selbst aus, hilft das Umbenennen des Plugin-Ordners, wie in den Lösungen für den Login beschrieben.

PHP antwortet nicht, und Apache steht davor. Das ist derselbe Fall wie beim 502, nur mit anderer Zahl: Apache zeigt „The server is temporarily unable to service your request due to maintenance downtime or capacity problems.“ Fragen Sie Ihren Hoster, ob PHP läuft und ob er Ihre Website wegen eines Limits gebremst hat. Das empfiehlt auch die Dokumentation von Cloudflare.

Schadet ein HTTP-Fehler 503 meiner WordPress-Website bei Google?

Kurzfristig nicht. Laut Google bremsen 5xx-Fehler zunächst das Crawlen, und bereits indexierte Adressen bleiben erhalten, fallen bei einem anhaltenden Fehler aber irgendwann aus dem Index. Für eine geplante Wartung ist ein 503 die richtige Antwort. Das Gegenbeispiel: Eine eigene Wartungsseite wp-content/maintenance.php hat im Test Status 200 geliefert, solange sie den Status nicht selbst gesetzt hat. So kann sie als Ihr Inhalt durchgehen. Beginnen Sie sie mit <?php http_response_code( 503 ); ?>.

WordPress-Fehler 504 Gateway Timeout: Die Antwort dauert zu lange

Der Webserver hat gewartet und aufgegeben. Oft ist das nicht Ihre Schuld, und es muss auch keine Störung sein: Oft ist eine einzelne Anfrage zu langsam, etwa ein Import, eine Sicherung oder ein Scan. In meinem Test ist die Meldung bei nginx und Apache mit PHP-FPM genau nach 60 Sekunden gekommen, und eine 50-Sekunden-Anfrage ist problemlos durchgelaufen. Wo die Grenze bei Ihnen liegt, weiß Ihr Hoster.

Apache mit FastCGI zeigt stattdessen 500. Diese Betriebsart heißt in Plesk „FastCGI-Anwendung (Apache)“, und auch meine eigene Website läuft so. Dort ist im Test schon nach 40 Sekunden „Internal Server Error“ gekommen, im Protokoll mod_fcgid: read data timeout in 40 seconds. Wer diese Zeile nicht liest, sucht vergeblich in der .htaccess.

Der übliche Rat, max_execution_time zu erhöhen, passt nur in einem Fall. Ich habe drei Sorten von Langsamkeit nachgestellt, mit einem PHP-Zeitlimit von 30 Sekunden:

• PHP rechnet selbst 70 Sekunden lang: Das Limit hat nach 30 Sekunden gegriffen, und ich habe nicht 504 gesehen, sondern den kritischen Fehler mit Status 500. Mit einem Limit von 300 Sekunden ist dann bei 60 Sekunden doch die 504 gekommen.
• PHP wartet 70 Sekunden auf etwas anderes, etwa auf eine fremde Schnittstelle: Das Limit hat gar nicht gegriffen, nach 60 Sekunden ist die 504 gekommen.
• Eine langsame Datenbankabfrage von 70 Sekunden: ebenso.

Eine 504 lässt sich also nicht von Ihnen durch ein höheres PHP-Limit beseitigen. Die Grenze liegt beim Webserver, und die ändert nur Ihr Hoster. Auch einer der Betroffenen in einem Forum hat das Limit erhöht und die 504 trotzdem nach 60 Sekunden bekommen.

Was hilft stattdessen:

• Prüfen Sie, ob die Arbeit trotzdem fertig geworden ist. Hinter einer 504 läuft PHP weiter: Meine 75-Sekunden-Aufgabe hat die Meldung nach 60 Sekunden ausgelöst und ihre Arbeit danach trotzdem beendet. Starten Sie einen Import also nicht sofort noch einmal, sonst haben Sie vielleicht alles doppelt.
• Teilen Sie große Aufgaben, zum Beispiel einen Import in mehrere kleinere Dateien.
• Lassen Sie sie per SSH und WP-CLI laufen, wenn Sie das können. Dort steht kein Webserver dazwischen: Eine 70-Sekunden-Aufgabe ist im Test einfach durchgelaufen.

Kommt die 504 ohne besondere Aktion, auch auf der Startseite, sind vermutlich alle PHP-Prozesse belegt. Bei zwei belegten Prozessen hat der nächste Besucher im Test 60 Sekunden gewartet und dann die 504 bekommen, während das Bild aus Schritt 1 sofort gekommen ist. Fragen Sie Ihren Hoster, wer die Prozesse belegt und wie viele Ihr Tarif hat.

WordPress-Fehler 403 Forbidden: Regeln, Dateirechte und Firewalls

Im Unterschied zu den anderen vier ist 403 kein Ausfall, sondern eine Entscheidung. Irgendwer hat Ihnen den Zugriff verweigert, und die Frage ist, wer. Prüfen Sie zuerst, ob auch ein anderes Netz betroffen ist (Schritt 1).

Eine Regel in der .htaccess. Require all denied oder eine Require ip-Zeile für eine andere Adresse haben im Test alles auf 403 gesetzt, auch die Anmeldung. Im Protokoll steht client denied by server configuration. Sichern Sie die Datei und nehmen Sie die Zeile heraus. Betrifft es nur /wp-admin/, liegt meist eine eigene .htaccess in diesem Ordner, siehe Schritt 4 der Lösungen für den Login.

Dateiberechtigungen. Was Sie sehen, hängt davon ab, welche Datei betroffen ist und wie PHP läuft:

• Die .htaccess ist nicht lesbar: Alles zeigt 403, auch Bilder, mit dem Zusatz „Server unable to read htaccess file, denying access to be safe“.
• Ein Bild oder eine andere Datei ist nicht lesbar: Nur diese Datei zeigt 403. Die übrige Website läuft normal.
• Die index.php ist nicht lesbar: Mit PHP-FPM zeigt die Startseite „Access denied.“ und 403, die Anmeldung funktioniert. Mit direkt eingebundenem PHP ist stattdessen eine leere Seite mit 500 gekommen.
• Der Ordner wp-admin ist nicht lesbar: /wp-admin/ zeigt 403, und die Startseite zeigt den kritischen Fehler.

Das Handbuch von WordPress nennt als Werte 755 oder 750 für Ordner und 644 oder 640 für Dateien, und niemals 777. Korrigieren Sie gezielt das, was das Protokoll nennt, im Dateimanager oder per FTP, und nicht pauschal alles, denn die wp-config.php darf strenger sein. Auch der Eigentümer zählt: Eine Datei mit 600, die einem anderen Benutzer gehört hat, hat im Test 403 ergeben, mit 644 ist sie geladen worden. Nach einem Umzug fragen Sie deshalb Ihren Hoster danach.

Die index.php fehlt. Dann zeigt die Startseite 403 (Cannot serve directory), Unterseiten zeigen 404. Holen Sie die Datei aus einer Sicherung oder aus dem WordPress-Paket. Fehlt mehr, helfen die Schritte zum abgebrochenen Update in den Lösungen für den kritischen Fehler.

Die Firewall des Hosters (ModSecurity). Das ist der Fall, in dem Sie 403 nur beim Speichern sehen, und nur bei bestimmten Inhalten. Ich habe ModSecurity mit den üblichen OWASP-Regeln vor die Testinstallation gesetzt: Ein normaler Absatz hat sich speichern lassen. Ein Beitrag mit einem PHP-Beispiel, einem SQL-Befehl, einem Pfad wie ../../etc/passwd oder einem onclick im HTML hat 403 bekommen, bevor WordPress überhaupt zum Zug gekommen ist. Bei einem Betroffenen in einem Forum waren es die Vorlagen eines Plugins mit Inline-Stilen. Fragen Sie Ihren Hoster, welche Regel gegriffen hat und ob er sie für diese Adresse ausnehmen kann. In Plesk heißt die Funktion „Web Application Firewall“. Schalten Sie sie zum Testen nur kurz ab und danach wieder ein.

WordPress selbst. Sehen Sie die graue WordPress-Gestaltung, ist Ihr Webserver in Ordnung:

• „Du bist leider nicht berechtigt, auf diese Seite zuzugreifen.“ Ihr Benutzer hat diese Rolle nicht, siehe die Lösungen für den Login.
• „Der Link, dem du gefolgt bist, ist abgelaufen.“ Das Sicherheitsmerkmal der Aktion stimmt nicht, meist weil die Seite zu lange offen war. Laden Sie sie neu und wiederholen Sie die Aktion.
• „Die Cookie-Prüfung ist fehlgeschlagen“ beim Speichern im Editor bedeutet dasselbe. Melden Sie sich neu an.

Ein 403 im Protokoll ist oft gewollt. In vier Tagen hat meine eigene Website 2.843 Mal mit 403 geantwortet, meist auf Anfragen wie /.env und /.git/config, mit denen automatische Scanner nach offenen Geheimnissen suchen. Dazu ist Kommentar-Spam gekommen, den mein Formular abweist. Solange Ihre Besucher nichts davon merken, müssen Sie hier nichts reparieren.

HTTP-Fehler in WordPress, wenn Cloudflare davor liegt

Hat Ihre Website Cloudflare, wie meine, gibt es eine Station mehr. Laut Cloudflare bedeutet eine 502 oder 504 mit Cloudflare-Logo in aller Regel, dass Ihr eigener Server diesen Fehler geliefert hat. Das ist also trotzdem ein Fall für Ihren Hoster. Dazu kommen eigene Nummern, die nur Cloudflare kennt:

• 520: Ihr Server hat leer oder unverständlich geantwortet.
• 521: Ihr Server hat die Verbindung abgelehnt. Er läuft nicht, oder er sperrt Cloudflare aus.
• 522: Ihr Server hat nicht rechtzeitig geantwortet.
• 524: Die Verbindung steht, aber die Antwort kommt nicht innerhalb von 125 Sekunden. Das ist die 504 von Cloudflare.

Bei 403 und „Sorry, you have been blocked“ hat Cloudflare selbst entschieden. Sehen Sie im Cloudflare-Dashboard unter „Security Events“ nach, welche Regel gegriffen hat. Ich sperre auf meinen Websites zum Beispiel xmlrpc.php absichtlich, und genau diese Seite zeigt das Bild:

Bei meiner Anmeldeseite läuft außerdem eine Browser-Prüfung von Cloudflare. Ein normaler Browser kommt durch, aber ein Programm ohne JavaScript wie curl erhält dort 403 und „Just a moment…“. Meldet Ihre Überwachung also 403, obwohl die Seite im Browser funktioniert, kann das der Grund sein.

Wenn nichts davon hilft

• Fragen Sie Ihren Hoster, und zwar konkret: Nennen Sie den Statuscode, die genaue Uhrzeit und die Adresse. Fragen Sie, ob PHP läuft, ob ein Limit erreicht ist und welche Zeile das Protokoll zu diesem Zeitpunkt zeigt. Er sieht, was Sie nicht sehen.
• Spielen Sie eine Sicherung ein, wenn der Fehler nach einer Änderung aufgetreten ist, die Sie nicht rückgängig machen können. Was seither geändert wurde, geht dabei verloren.
• Fragen Sie mich. Schreiben Sie mir den Statuscode und die Zeile aus dem Protokoll. Das Angebot steht gleich unter diesem Beitrag.

Dieser Beitrag behandelt Serverfehler, keine Hacks. Sehen Sie im Protokoll Dateien oder Plugins, die Sie nie installiert haben, wenden Sie sich an Ihren Hoster (oder an mich), statt weiter zu probieren.

Damit es beim nächsten Mal schneller geht

• Bewahren Sie eine Kopie Ihrer .htaccess auf, auf Ihrem Rechner, damit sich jede Änderung in Sekunden rückgängig machen lässt.
• Lassen Sie große Aufgaben nicht über den Browser laufen, wenn es kleiner oder per WP-CLI geht.
• Lassen Sie die Website überwachen. Dann haben Sie die Uhrzeit, wenn Sie den Hoster anrufen. Was sonst noch zur Pflege gehört, steht in WordPress-Website richtig pflegen.

Zeigen dagegen nur einzelne Seiten „404“ oder scheitert ein Bild beim Hochladen mit „HTTP-Fehler“, ist das ein anderes Problem, auch wenn es ähnlich klingt: Die Website läuft dann, nur eine bestimmte Adresse oder ein bestimmter Vorgang nicht.