Auf dieser Seite: [ausblenden]
Der eigene Absturzbildschirm von WordPress ist ein HTTP 500. Das gilt auch für eine leere weiße Seite. Dies gilt auch für die nicht gestaltete Seite, die Ihr Webserver bereitstellt, wenn er aufgibt. Der schwerwiegende Fehlerhandler von Core gibt a 500 Antwort auf wp_die() bevor es gedruckt wird “Auf dieser Website ist ein schwerwiegender Fehler aufgetreten.” Der Statuscode ist in allen drei Fällen identisch, Es sagt also fast nichts. Der Seitentext verrät Ihnen viel. Wer es gedruckt hat, halbiert die Liste der Ursachen ungefähr, bevor Sie eine einzelne Datei berühren.
Schnelle Antwort: Lesen Sie, was gerendert wurde, nicht der Code. Eine gestaltete WordPress-Seite bedeutet, dass PHP ausgeführt wurde, WordPress geladen, dann ist ein Plugin oder Theme gestorben. Suchen Sie im Posteingang des Site-Administrators nach einem Wiederherstellungslink. Eine bloße Serverseite ohne WordPress-Stil bedeutet, dass die Anfrage nie so weit gekommen ist, Benennen Sie also .htaccess um und lesen Sie das Serverprotokoll. Zwischen den beiden liegt eine leere weiße Seite, und das Debug-Protokoll behebt das Problem in etwa einer Minute.
Zuletzt überprüft: September 2026. Constants, memory defaults and PHP support dates verified against WordPress core documentation and php.net this month.
Drei Bildschirme, Ein Statuscode
Every guide opens with a list of causes. Corrupt .htaccess, plugin conflict, memory limit, permissions, and so on down the page. That list is accurate and close to useless, because you can’t tell from a status code which entry applies to you. Sorting by what rendered is faster.
A styled WordPress page. Grey background, small centered box, the sentence “Auf dieser Website ist ein schwerwiegender Fehler aufgetreten” with a link to a WordPress support page. This is core talking. PHP started, wp-config.php parsed, WordPress booted far enough to register its shutdown handler, and then something threw a fatal error. Almost always a plugin, ein Thema, or code you pasted into functions.php. Springe zu the recovery section.
A bare server page. Times New Roman on white, the words “interner Serverfehler”, maybe an Apache or LiteSpeed version string at the bottom. Or your host’s own branded error page. WordPress never got a word in. The failure happened in the web server, in the PHP process manager, or in a config file the server read before handing anything to PHP. Start at .htaccess.
Nothing at all. A white page, no text, view-source shows an empty document. PHP died with error display switched off, and either the fatal came before WordPress could install its handler, or the handler itself couldn’t finish. Fatals inside wp-config.php, inside a must-use plugin, or in an opcache-stale file land here. So do out-of-memory kills, because PHP can run out of memory while trying to render the error about running out of memory.
One more screen gets confused with this constantly. “Datenbankverbindung fehlgeschlagen” is not a 500. WordPress meldet, dass MySQL dies abgelehnt hat, und der Fix befindet sich in Ihren Datenbankanmeldeinformationen, nicht in einer der folgenden Dateien.
Was dieser Leitfaden überprüft hat, und was es nicht tat
Wo in diesem Handbuch eine Zahl erscheint, es kam von demjenigen, der es veröffentlicht, im September überprüft 2026. Speicherstandardwerte und Debugging-Konstanten stammen aus der WordPress-Core-Dokumentation und aus der Core-eigenen Funktionsreferenz. Das PHP-Verhalten stammt aus dem PHP-Handbuch, insbesondere die Seiten zu verzeichnisspezifischen INI-Dateien und zu unterstützten Versionen. Die Speicherorte der Protokolle stammen aus der offiziellen Dokumentation jedes Control Panels und nicht aus einem Forumsbeitrag, in dem sie zitiert wird.
Drei Dinge haben wir bewusst ausgeschlossen. Hinweise, die nur auf einem Host funktionieren, werden als solche gekennzeichnet und nicht als allgemein angezeigt. Korrekturen, die Datenbankänderungen erfordern, sind verfügbar, weil a 500 Fehler entstehen fast nie dort und das Risiko ist unverhältnismäßig. Und alle Ansprüche, die wir nicht auf eine Anbieterseite oder eine Kernquelle zurückführen konnten, wurden verworfen statt abgesichert.
Der später beschriebene Plugin-Paketfehler wurde aus erster Hand überprüft. Wir haben drei Release-Archive von WordPress.org heruntergeladen, deren Inhalt aufgelistet, und verglich sie mit der eigenen Bootstrap-Datei des Plugins. Alles andere ist hier Dokumentationsarbeit. Wir haben nicht jeden Fehler auf einem Live-Server reproduziert, und wir haben nichts bewertet. Wir können Ihnen auch nicht sagen, welche Ursache statistisch gesehen am häufigsten vorkommt. Niemand veröffentlicht diese Daten, und die Führer, die behaupten, es zu wissen, geben keine Quelle an.
Bestätigen Sie, dass es sich wirklich um ein handelt 500
Browser übertreiben den Unterschied zwischen Serverfehlern. Chrome zeigt für mehrere von ihnen dieselbe nicht hilfreiche Seite an, und eine zwischengespeicherte Kopie kann Ihnen den gestrigen Fehler zeigen. Überprüfen Sie den tatsächlichen Antwortheader, bevor Sie eine Stunde mit dem falschen Problem verbringen.
Von einem Terminal, Führen Sie curl -i https aus://yoursite.com. Verwenden Sie -i und nicht -I. Das Kapital sendet eine HEAD-Anfrage und wirft den Seitentext weg, Das ist die Hälfte, die Ihnen sagt, wer den Fehler gedruckt hat. In einem Browser, Öffnen Sie DevTools, Gehen Sie zur Registerkarte Netzwerk, neu laden, und klicken Sie auf die oberste Anfrage. In jedem Fall möchten Sie die dreistellige Nummer, und es ist wichtig, welches Sie bekommen:
- 500 bedeutet, dass der Server es versucht hat und etwas in Ihrer Anwendung kaputt gegangen ist. Fast alles unten gilt.
- 502 bedeutet einen Stellvertreter vorn (normalerweise NGINX) Ich habe eine Müllantwort vom Backend erhalten, mit dem es gesprochen hat. Oftmals ein PHP-FPM-Prozess, der abgestürzt ist oder nie ausgeführt wurde.
- 503 bedeutet, dass der Server aktiv ist und dies absichtlich ablehnt. Überlast, einen Wartungsmodus, oder eine Ressourcenobergrenze, die Ihr Plan erreicht hat.
- 504 bedeutet, dass das Backend erreicht wurde, aber nicht rechtzeitig geantwortet wurde. Eine langsame Abfrage, ein hängender externer API-Aufruf, ein Cronjob, der einen Arbeiter frisst.
Die Definition ist unverblümt, weshalb die erste so vage ist. Die HTTP-Referenz von Mozilla beschreibt 500 als generisches Allheilmittel “Dies zeigt an, dass der Server keinen passenderen 5XX-Fehler finden kann, mit dem er antworten kann”. Ein Server, der wusste, was schief gelaufen ist, hätte es gesagt.
Zwei Dinge, die es wert sind, gleichzeitig ausgeschlossen zu werden. Laden Sie die Site in ein privates Fenster. Ein Servicemitarbeiter oder ein aggressiver Cache stellt gerne noch lange nach der Wiederherstellung der Site eine gespeicherte Fehlerseite bereit. Und probieren Sie das Frontend und /wp-admin separat aus. Ein Frontend, das geladen wird, während wp-admin wirft 500 weist auf einen bestimmten Punkt hin, und darauf kommen wir zurück weiter unten.
Als WordPress die Seite druckte
Wenn Sie das gestylt haben “kritischer Fehler” Seite, WordPress hat den Großteil der Diagnosearbeit bereits erledigt und versucht, Ihnen die Antwort zu geben. Seit Version 5.2, Der Kern erkennt schwerwiegende Fehler und pausiert, was auch immer sie verursacht hat. Anschließend wird die Adresse in den Einstellungen per E-Mail gesendet, Allgemein mit einem Link in den Wiederherstellungsmodus. Wenn Sie diesem Link folgen, bleibt das defekte Plugin nur für Ihre Browsersitzung deaktiviert. Sie können sich anmelden und es entfernen, während Besucher weiterhin die Fehlerseite sehen.
Überprüfen Sie zuerst diesen Posteingang, Spam inklusive. Dann wissen Sie, warum es so oft leer ankommt.
Die WordPress-Dokumentation äußert sich offen zum Fehlermodus. Plugins werden der Reihe nach geladen. Wenn der schwerwiegende Fehler ausgelöst wird, bevor Ihr SMTP-Plugin geladen wird, Der E-Mail-Versand erfolgt stattdessen über die eigene Mail-Funktion des Servers. Auf einer gemeinsam genutzten IP ohne SPF-Ausrichtung, Diese Nachricht wird gefiltert oder direkt verworfen. Die Warnung über Ihre defekte Website ist selbst defekt, durch den gleichen Absturz. Das kann man im Moment nicht beheben, but it does explain the missing email. Unser Leitfaden zu why WordPress stops sending email covers the deliverability side properly.
Erhalte die eigentliche Fehlermeldung
No email means you read the log instead. Two lines in wp-config.php, über dem “Hören Sie auf zu bearbeiten” comment:
- definieren( "WP_DEBUG", wahr );
- definieren( ‘WP_DEBUG_LOG’, wahr );
Core writes to wp-content/debug.log standardmäßig. Reload the broken page once, then open that file and read the last entry. A PHP fatal names the file and the line number, and the folder in that path is your culprit. That’s the whole diagnosis, and it takes longer to describe than to do.
Leave WP_DEBUG_DISPLAY alone while you do it, or set it to false explicitly. Printing errors to the screen on a live site publishes your absolute server paths to anyone reloading the page (and some people go looking for exactly that).
There’s a blunter instrument for the cases where the log stays empty. Adding define( „WP_DISABLE_FATAL_ERROR_HANDLER“, wahr ); schaltet den Handler vollständig aus, Daher taucht PHPs eigener Fehler anstelle des höflichen Ersatzes von WordPress auf. Core überprüft diese Konstante in wp_is_fatal_error_handler_enabled(), und die Wirkung tritt sofort ein. Benutzen Sie es für die dreißig Sekunden, die zum Lesen der Nachricht benötigt werden, dann nimm es raus. Wenn der Handler weg ist, verlieren Sie auch den Wiederherstellungsmodus, und jeder Besucher sieht den rohen Fehler.
Isolieren des Plugins oder Themes
Sie können auf einem Dashboard, das Sie nicht erreichen können, nicht auf „Deaktivieren“ klicken. Machen Sie es also aus dem Dateisystem. Core prüft file_exists() auf jedem aktiven Plugin, bevor es eines davon lädt, und überspringt stillschweigend diejenigen, die verschwunden sind.
Über FTP oder den Dateimanager Ihres Hosts, umbenennen wp-content/plugins zu Plugins-Off. Laden Sie die Website neu. Wenn es zurückkommt, Sie haben die fehlerhafte Ebene gefunden.
Dann tun Sie etwas, bevor Sie den Ordner wieder umbenennen, denn die Reihenfolge ist wichtiger, als jeder Führer zugibt. Laden Sie zuerst /wp-admin. Das Überspringen im Frontend und das Deaktivieren in der Datenbank sind zwei unterschiedliche Verhaltensweisen, wird von zwei verschiedenen Funktionen verwaltet. Das Frontend springt einfach. Nur die Administratorseite führt validate_active_plugins aus(), welches „deactivate_plugins“ aufruft() und schreibt die Änderung tatsächlich. Benennen Sie den Ordner wieder um, ohne das Dashboard aufzurufen, und alle Ihre Plugins sind weiterhin als aktiv markiert, das kaputte inklusive. Die Seite stirbt wieder, sobald Sie es tun, und es sieht so aus, als hätte der Test nichts bewiesen.
Sobald das Dashboard den leeren Ordner gesehen hat, Benennen Sie es wieder um und aktivieren Sie die Plugins einzeln wieder, Nachladen nach jedem. Diejenige, die die Site wieder zum Erliegen bringt, ist Ihre Antwort. Gleiche Technik für Themen: Benennen Sie den Ordner des aktiven Themes um und WordPress greift auf einen Standardordner zurück.
Mit SSH, WP-CLI erledigt dies in einem Befehl, und seine globalen Flags sind der nützliche Teil. Ausführen des WP-Plugins deaktivieren –alle mit –skip-plugins startet WordPress, ohne überhaupt Plugins zu laden. Der Fatale feuert nie, Damit wird der Befehl ausgeführt. Beachten Sie den dokumentierten Grenzwert: Mu-Plugins werden in beiden Fällen immer noch geladen. Ein Fehler in wp-content/mu-plugins überlebt beide Ansätze, und dieser Ordner muss von Hand verschoben werden.
Der Mai 2026 Fall, der dies konkretisiert hat
Plugin-Fatal-Fehler sind in der Regel auf einen Konflikt zurückzuführen, wo zwei Dinge, die jeweils für sich funktionieren, nicht zusammenarbeiten. Manchmal ist einfach die Verpackung selbst kaputt, und eine Veröffentlichung aus diesem Jahr zeigt den Mechanismus sauber.
Shortcodes Ultimate, ein Plugin aktiv auf 400,000 Websites, ausgelieferte Version 7.5.1 auf 18 Kann 2026 wobei das gebündelte /freemius/-Verzeichnis im Paket fehlt. Linie 31 der Hauptdatei dieser Version heißt immer noch require_once auf /freemius/start.php, ohne file_exists-Überprüfung. Wir haben alle drei Archive heruntergeladen, um dies zu bestätigen. Ausführung 7.5.0 hält 223 Dateien in diesem Ordner, 7.5.1 hält keine, und 7.5.3 stellt wieder her 222. Das beschädigte Archiv ist ein Megabyte kleiner als die Veröffentlichung auf beiden Seiten.
Wenn require_once auf eine Datei zeigt, die nicht vorhanden ist, liegt ein schwerwiegender Fehler vor. Jede Anfrage, jeder Besucher, keine ausnahmen. Der Autor hat den Ersatz markiert, 7.5.3, am nächsten Morgen 19 Kann 2026. Der Changelog-Eintrag ist eine Zeile: “Problem mit fehlendem /freemius/-Ordner behoben”. Versionen 7.5.1 und 7.5.2 erscheinen überhaupt nicht mehr in der Tag-Liste des Plugins.
Daraus ergeben sich für jeden, der gerade ein Protokoll liest, zwei Dinge. Die Schuldzuweisung an einen Konflikt ist eine Vermutung. Ein Fehler, der einen Herstellerpfad innerhalb eines Plugin-Ordners angibt, ist normalerweise kein Konflikt. Und wenn die Website direkt nach einem automatischen Update abstürzt, Das Zurücksetzen dieses Plugins um eine Version ist ein guter erster Schritt, kein letzter Ausweg. Möglicherweise wurde das kaputte Ding bereits zurückgezogen.
Der .htaccess-Fix, und derjenige, der nach hinten losgeht
Diese Datei war der erste Verdächtige, als der Server die Fehlerseite druckte, weil Apache es liest, bevor PHP überhaupt involviert ist. Eine ungültige Anweisung darin wird zurückgegeben 500 für jede Anfrage an dieses Verzeichnis und alles darunter.
Die Reparatur ist eine Umbenennung, keine Bearbeitung. Über FTP, Benennen Sie .htaccess in Ihrem WordPress-Root in htaccess-old um und laden Sie es neu. Seite zurück? Die Datei war das Problem. Gehen Sie zu Einstellungen, Permalinks im Dashboard und klicken Sie auf „Änderungen speichern“, ohne etwas zu ändern, und WordPress schreibt einen sauberen Rewrite-Block. Die Seite ist immer noch kaputt? Benennen Sie es wieder um und fahren Sie fort, weil du es beseitigt hast.
Jetzt kommt der Teil, der die Leute zum Stolpern bringt. Die meisten 500-Fehler-Anleitungen empfehlen Ihnen, Ihr Speicherlimit zu erhöhen, indem Sie eine Zeile wie „php_value memory_limit 256M“ zu .htaccess hinzufügen. Auf viel Hosting in 2026, diese Zeile ist selbst das 500.
Hier ist der Mechanismus. php_value ist eine von mod_php bereitgestellte Direktive, das alte Modell, bei dem PHP innerhalb des Apache-Prozesses ausgeführt wird. Hosts sind größtenteils auf PHP-FPM oder FastCGI umgestiegen, wobei PHP als separater Pool ausgeführt wird und mod_php nicht geladen wird. Apache erfüllt eine Anweisung, die kein geladenes Modul erkennt, weigert sich, das Verzeichnis bereitzustellen, und kehrt zurück 500. Das PHP-Handbuch gibt die Aufteilung deutlich an. INI-Dateien pro Verzeichnis “werden nur von der CGI/FastCGI SAPI verarbeitet”, und Benutzer von Apache-Modulen werden für den gleichen Effekt auf .htaccess verwiesen. Zwei Mechanismen, und Sie benötigen denjenigen, den Ihr Host tatsächlich ausführt.
Also welches hast du?? Um das herauszufinden, ist eine einzige Datei nötig, und fast kein Reiseführer fordert Sie auf, nachzuschauen. Legen Sie eine Datei namens check.php in Ihrem Web-Root ab, enthält einen Aufruf von phpinfo(). Laden Sie es in einen Browser und lesen Sie es Server-API Linie oben.
“Apache 2.0 Handler” ist mod_php, also funktioniert php_value. “FPM/FastCGI” oder “CGI/FastCGI” bedeutet, dass dies nicht der Fall ist. “LiteSpeed V” ist das Zweideutige. Die gleiche Zeichenfolge gilt für LiteSpeed Enterprise, was php_value ehrt, und OpenLiteSpeed, Dies übernimmt die Umschreiberegeln von .htaccess und ignoriert den Rest. Auf beiden, Überspringen Sie die Frage und verwenden Sie .user.ini. Dann löschen Sie check.php, weil phpinfo() übergibt Ihre gesamte Serverkonfiguration an jeden, der die URL errät. Und wenn check.php a auslöst 500 auch, Ihre .htaccess-Datei ist immer noch defekt und Sie haben sie noch nicht umbenannt.
Auf FPM oder FastCGI ist die entsprechende Datei .user.ini, in Ihrem WordPress-Root abgelegt, enthält „memory_limit = 256M“ und sonst nichts. Ein dokumentierter Fallstrick ist im Lieferumfang enthalten, und es verschwendet viel Zeit. PHP speichert diese Dateien zwischen 300 Sekunden standardmäßig, gesetzt durch user_ini.cache_ttl. Speicher die Datei, sofort neu laden, sehe keine Veränderung, und es sieht so aus, als ob der Fix fehlgeschlagen ist. Das ist nicht der Fall. Warten Sie fünf Minuten.
Zwei verwandte Traps befinden sich in derselben Datei. Jede aus einem Tutorial kopierte Regel, die auf ein Modul verweist, das Ihr Server nicht lädt, macht genau das, was php_value tut. Der übliche Täter ist eine SecFilterEngine-Zeile, eingefügt, um eine Firewall auszuschalten. Auf NGINX, in der Zwischenzeit, nichts davon trifft zu. NGINX verfügt über keinen .htaccess-Mechanismus, Die Datei wird also ignoriert und kann nicht Ihre Ursache sein. LiteSpeed und OpenLiteSpeed lesen es, Deshalb “Überprüfen Sie .htaccess” bleibt ein guter Rat für die meisten Shared-Hosting-Angebote.
Speichergrenzen: Die reellen Zahlen
Die Standardwerte sind niedriger, als die meisten Leute annehmen, and knowing them saves you from raising a limit that was never the constraint.
WordPress sets WP_MEMORY_LIMIT to 40M auf einer einzigen Website, and 64M on multisite. It lifts the admin side to WP_MAX_MEMORY_LIMIT of 256M for heavier jobs like media handling and core updates. The core documentation adds the qualifier that matters. WordPress checks what PHP has been allocated first, and it can only request within that. If your host caps PHP at 128M, setting 512M in wp-config.php changes nothing.
That asymmetry between 40M and 256M also explains one common symptom directly. A site whose front end loads fine but whose dashboard throws 500 is often a site sitting between the two limits.
To test it, add define( ‘WP_MEMORY_LIMIT’, „256M’ ); to wp-config.php and reload. Wenn der Fehler behoben ist, treat that as a diagnosis and not a repair. Something in your stack is using six times the default to render one page. The honest next step is finding out what. Otherwise the next plugin you install pushes you over the new ceiling too.
Dateiberechtigungen und wem Ihre Dateien gehören
Permission errors produce 500s reliably. They turn up most often after a migration or a restored backup, when files arrive owned by the wrong user.
The safe values are 755 für Verzeichnisse, 644 für Dateien. Set wp-config.php to 640 oder 600 if your host allows it. And don’t reach for 777 because a tutorial promised it would fix an upload problem.
Ob 777 actually returns a 500 depends on your handler, und die meisten Ratschläge zu diesem Punkt sind etwa ein Jahrzehnt veraltet. suPHP weigert sich, etwas auszuführen, das von der Gruppe oder der Welt beschreibbar ist, und es meldet sich im Protokoll mit einer eindeutigen Zeichenfolge: SoftException in Application.cpp. suEXEC von Apache wendet eine ähnliche Regel auf CGI-Programme an. Es prüft, ob das Ziel vorhanden ist “NICHT von jemand anderem beschreibbar”, und dass der Eigentümer der Datei mit dem Benutzer übereinstimmt, unter dem sie ausgeführt wird. PHP-FPM hat keine solche Ablehnung, und cPanel empfiehlt es jetzt anstelle von suPHP. Also auf einem aktuellen Stack, 777 ist eher ein Sicherheitsproblem als die Ursache Ihres Problems 500. Durchsuchen Sie das Fehlerprotokoll nach dieser SoftException-Zeichenfolge, bevor Sie eine Stunde mit chmod verbringen.
Der Besitz ist ebenso wichtig wie der Modus. Jede Datei unter Ihrem Web-Root sollte dem Benutzer Ihres Hosting-Kontos gehören. Nicht rooten, und nicht an den Webserver-Benutzer. Wenn eine Berechtigungskorrektur nicht funktioniert und Sie sich auf Shared Hosting befinden, Eröffnen Sie hier ein Ticket. Für die Korrektur der Eigentumsrechte ist der Zugriff erforderlich, über den Ihr Konto nicht verfügt.
PHP-Versionssprünge
Eine Website, die über Nacht kaputt ging, ohne dass sich auf Ihrer Seite etwas geändert hat, wurde oft auf der Seite Ihres Hosts geändert. PHP-End-of-Life-Daten bestimmen geplante Upgrades, und ein Plugin, das seit drei Jahren nicht aktualisiert wurde, trifft auf eine Syntax, die es nicht mehr gibt.
Die Daten stammen direkt aus der Tabelle der unterstützten Versionen von php.net. PHP 8.1 Keine Sicherheitsupdates mehr erhalten 31 Dezember 2025. PHP 8.2 ist seit dem Ende nur für die Sicherheit bestimmt 2024, mit eigenem Cutoff 31 Dezember 2026. PHP 8.3 bekommt Patches durch 2027, 8.4 durch 2028, und 8.5, freigegeben 20 November 2025, durch 2029.
WordPress selbst ist still geblieben, während PHP umgezogen ist. WordPress 7.0 “Armstrong” weiter versendet 20 Kann 2026 und 7.1 “Mary Lou” auf 19 August 2026, und keiner von beiden hat den PHP-Boden erhöht 7.4. Die Empfehlung ist weiterhin PHP 8.3 oder neuer. Diese Lücke ist die Falle. WordPress läuft problemlos auf einer PHP-Version, die schon seit Jahren keine Sicherheitsupdates mehr erhält. Nichts in Ihrem Dashboard warnt Sie, Bis ein Host-seitiges Upgrade das Problem erzwingt.
Wenn Sie in Ihrem Control Panel die PHP-Version wechseln können, Das Zurücksetzen einer Nebenversion ist ein schneller Test. Es bestätigt die Ursache in weniger als einer Minute. Behandeln Sie den Rollback als vorübergehend, obwohl. Sie führen jetzt ein älteres PHP aus, um Code aufzunehmen, der ersetzt werden muss. Unser Leitfaden zum WordPress “erfordert eine neuere PHP-Version” Warnung Hier erfahren Sie, wie Sie herausfinden, welche Erweiterung Sie zurückhält.
Wenn es der Server ist, Nicht Ihre Website
Manche 500er können Sie nicht reparieren, und das frühzeitige Erkennen erspart Ihnen das Umbenennen von Ordnern, die nie das Problem waren.
Eine Firewall-Regel funktioniert nicht richtig. ModSecurity kehrt normalerweise zurück 403 wenn es etwas blockiert. Zwei Fälle kehren zurück 500 stattdessen. Eine Regel, die während der Anforderungsverarbeitung fehlschlägt, oder eine .htaccess-Zeile geschrieben, um die Firewall dort auszuschalten, wo das nicht erlaubt ist. Der Tell befindet sich im Server-Fehlerprotokoll, Dabei tragen blockierte Anfragen eine Regel-ID in eckigen Klammern. Sie können diese Regeln nicht über ein gemeinsames Konto anpassen, also geht dieser mit der angehängten Protokollzeile zur Unterstützung.
Ein PHP-Prozesspool, der gestorben ist. Öfter a 502 als ein 500, Aber es lohnt sich zu prüfen, wann unter Last Fehler auftreten und gehen, und nicht bei jeder Anfrage. Zeitweilige Ausfälle, die mit dem Datenverkehr zusammenhängen, stellen ein Ressourcenproblem dar, kein Codeproblem, und keine noch so große Plugin-Umbenennung berührt sie.
Festplattenkontingent. Bei einem vollen Konto ist PHP nicht in der Lage, Sitzungsdaten zu schreiben, temporäre Dateien oder ein eigenes Protokoll, und diese Fehler tauchen als auf 500. Wenn die Seite vor einer Stunde noch in Ordnung war, Überprüfen Sie vor allem Ihre Verbrauchswerte im Bedienfeld.
Wo sich Ihr Fehlerprotokoll tatsächlich befindet
Das WordPress-Debug-Protokoll zeichnet PHP-Fehler in WordPress auf. Es werden keine .htaccess-Syntaxfehler aufgezeichnet, Berechtigungsverweigerungen oder Firewall-Blockaden, weil diese passieren, bevor PHP ausgeführt wird. Für diese benötigen Sie das Serverprotokoll, und jedes Panel bringt es an einen anderen Ort:
- cPanel: die Fehlerschnittstelle unter „Metriken“.. In der Dokumentation von cPanel wird beschrieben, dass dies der Fall ist 300 der aktuellsten Einträge, Neueste zuerst. Viele Konfigurationen legen auch eine error_log-Datei direkt in public_html ab.
- Hostinger hPanel: Dateimanager, dann das .logs-Verzeichnis in Ihrem Kontostammverzeichnis, enthält eine Datei mit dem Namen error_log_ und Ihre Domain. Nur PHP-Fehler, Fehler auf Serverebene werden dort also nicht angezeigt.
- SiteGround-Site-Tools: Statistiken, dann Fehlerprotokoll für kürzlich vom Server erkannte Fehler, mit einer php_errorlog-Datei im Site-Stammverzeichnis für diejenigen auf PHP-Ebene.
- Wolkenwege: den Protokollordner in Ihrem Anwendungsverzeichnis, erreichbar über SSH oder SFTP, mit separatem Apache, NGINX- und PHP-Dateien.
- Einfaches VPS: /var/log/apache2/error.log unter Debian und Ubuntu, /var/log/httpd/error_log auf Systemen der RHEL-Familie, /var/log/nginx/error.log für NGINX.
Zwei Apache-Protokollzeilen sind auf den ersten Blick erkennbar. “Vorzeitiges Ende der Skript-Header” und “Ende der Skriptausgabe vor den Headern” meine das Gleiche. Das Skript wurde angehalten, bevor etwas zurückgegeben wurde, das der Server verwenden konnte. Das ist ein PHP-Prozess, der mitten in der Anfrage abstürzte, was Sie zurück auf die PHP-Seite und nicht auf die Konfigurationsseite verweist.
Welchen Fix Sie zuerst ausprobieren sollten
Wenn Sie alle oben genannten Methoden der Reihe nach durchgehen, wird aus einem fünfzehnminütigen Problem ein Nachmittag. Was du zuletzt getan hast, und was noch funktioniert, grenzt es schneller ein als jede Checkliste.
Etwas hat sich geändert, und wissen Sie was?. Ein Plugin aktualisiert, bearbeitete Functions.php, habe einen Ausschnitt eingefügt, Thema gewechselt. Machen Sie diese eine Sache rückgängig, und sonst nichts. Wenn es ein automatisches Update wäre, Überprüfen Sie, ob die Version, die Sie verwenden, noch auf WordPress.org existiert, bevor Sie sie debuggen. Eine zurückgezogene Version ist nicht Ihr Fehler, den Sie beheben müssen.
Es hat sich nichts geändert, und es ist über Nacht kaputt gegangen. Dies ist bis zum Beweis des Gegenteils hostseitig. Überprüfen Sie zunächst Ihre PHP-Version, dann Ihr Festplattenkontingent, dann das Serverfehlerprotokoll. Ein geplantes PHP-Upgrade oder eine begrenzte Ressourcenbeschränkung erklären die meisten dieser Probleme, und keiner hinterlässt eine Spur in wp-content/debug.log.
Nur /wp-admin löst aus 500. Das Frontend lädt gut, Daher ist die Erinnerung der erste Kandidat, angesichts der Aufteilung von 40 Mio. gegenüber 256 Mio. des Kerns. Zweitens ist eine beschädigte Datei in wp-admin oder wp-includes. Eine saubere Neuinstallation des Kerns behebt das Problem, ohne Ihre Inhalte zu beeinträchtigen. Ersetzen Sie diese beiden Verzeichnisse durch einen neuen WordPress-Download, and leave wp-content and wp-config.php exactly where they are.
A browser and nothing else. No FTP, kein SSH, kein Dateimanager. Your host’s control panel almost certainly has a file manager, so start there. Wenn nicht, the sequence is: check the inbox for a recovery link, Erstellen Sie dann ein Ticket mit dem genauen Zeitpunkt des ersten Fehlers. Der Support kann Protokolle lesen, was nicht möglich ist.
Es kommt und geht. Zeitweilige 500er unter Stau stellen ein Kapazitätsproblem dar. Das Umbenennen von Plugin-Ordnern hilft nicht, und auch keine Speicherkonstante. Das Limit, das Sie erreichen, gehört zum Konto, nicht auf die Anfrage. Entweder benötigt der Standort weniger bewegliche Teile oder der Plan erfordert mehr Spielraum. Das ist wo verwaltetes WordPress-Hosting hört auf, ein Luxus zu sein, da Ressourcenobergrenzen und PHP-Upgrades für Sie erledigt und nicht bekannt gegeben werden.
Verhindern, dass es zurückkommt
Die meisten 500er-Wiederholungen lassen sich auf eine einzige Gewohnheit zurückführen: Live-Aktualisierung, auf einmal, ohne Weg zurück. Das zu reparieren ist billig.
Aktualisieren Sie in kleinen Mengen und laden Sie die Site zwischendurch neu. Zehn gemeinsam aktualisierte Plugins liefern zehn Verdächtige und keine Informationen. Erstellen Sie ein Backup vor allem, was den Kern oder ein tief integriertes Plugin berührt. Bestätigen Sie dann, dass Sie es wiederherstellen können, denn ein ungetestetes Backup ist eine Vermutung über die Zukunft.
Legen Sie die Administrator-E-Mail auf ein Postfach fest, das jemand liest. Der Wiederherstellungsmodus ist wertlos, wenn der Link in einem verlassenen Posteingang landet. Behalten Sie PHP auf einer Version bei, die noch Sicherheitspatches erhält. Stand September 2026 das technisch beinhaltet 8.2, aber nur bis 31 Dezember, damit 8.3 oder neuer ist diejenige, die eingeschaltet sein muss. Behandeln Sie die Upgrade-Benachrichtigung eines Hosts als Testfrist, keine Ankündigung zum Ablegen. Und wenn ein Plugin im Mittelpunkt Ihrer Website steht, Überprüfen Sie ab und zu den Veröffentlichungsverlauf. Wer ein kaputtes Paket einmal verschickt, tut es in der Regel noch einmal.
Inszenierung ist die wahre Antwort, und viele Shared-Pläne beinhalten es jetzt, anstatt es den teuren Stufen zu vorbehalten. One click to copy the site, break the copy, and leave the live version alone. If your plan doesn’t have it, that’s worth weighing against price the next time you renew.
Häufig gestellte Fragen
Was verursacht a 500 Plötzlich ein interner Serverfehler?
Etwas hat sich geändert, even if you didn’t change it. On your side, that’s usually a plugin or theme update, an edit to functions.php, or a snippet pasted into wp-config.php. On your host’s side, it’s a PHP version upgrade, a hit resource cap, or a full disk. If you genuinely changed nothing, check your PHP version and your disk usage before you start renaming folders.
Kann ich ein Problem beheben? 500 Interner Serverfehler selbst, Oder brauche ich meinen Gastgeber??
Die meisten von ihnen, Ja. Renaming .htaccess, renaming the plugins folder, raising the memory limit and fixing file permissions all work over FTP or a file manager. Three cases need your host. File ownership problems, ModSecurity rules firing on your requests, and PHP-FPM pools that keep dying. Each needs access your account doesn’t have. Send support the exact time of the failure, plus the log line if you have one.
Warum bekomme ich eine 500 Fehler nur in wp-admin, wenn das Frontend funktioniert?
Usually memory. WordPress allows 40M by default on the front end, and raises it to 256M for admin tasks. A dashboard that dies while the site loads is often sitting between those two figures, on a plan that can’t reach the higher one. The other common cause is a corrupted file in wp-admin or wp-includes. Fix that by replacing both directories from a fresh WordPress download, leaving wp-content and wp-config.php alone.
Ist ein 500 Fehler das gleiche wie 502, 503 oder 504?
Nein, und der Unterschied verrät Ihnen, wer das Problem repariert. EIN 500 bedeutet, dass die Anwendung fehlgeschlagen ist, also ist es normalerweise deins. EIN 502 bedeutet, dass ein Proxy eine ungültige Antwort vom Backend erhalten hat, typischerweise ein toter PHP-FPM-Prozess. EIN 503 bedeutet, dass der Server Anfragen absichtlich ablehnt, B. durch Überlastung oder einen Wartungsmodus. EIN 504 bedeutet, dass das Backend nie rechtzeitig geantwortet hat. Die letzten drei Punkte zur Infrastruktur, Sie gehen also mit dem angehängten Zeitstempel an Ihren Host.
Wie behebe ich ein 500 Fehlermeldung, wenn ich mich überhaupt nicht bei WordPress anmelden kann?
Für keine der Hauptkorrekturen benötigen Sie das Dashboard. Das Umbenennen von .htaccess und wp-content/plugins funktioniert beide über FTP oder einen Hosting-Dateimanager. WordPress überspringt Plugins, deren Ordner verschwunden sind, Sie müssen jedoch /wp-admin einmal laden, damit es in der Datenbank bleibt. Mit SSH, wp-Plugin deaktivieren –alles plus das –Das Flag „skip-plugins“ startet WordPress, ohne Plugins zu laden, Das Verhängnis wird also nie ausgelöst. Wenn der Absturz nur auf dem Anmeldebildschirm und nicht auf der gesamten Website auftritt, Die Cookie- und Sperrursachen sind eine separate Liste.
Tut ein 500 Ein interner Serverfehler hat mein Google-Ranking beeinträchtigt?
Ein kurzer nicht. In der Crawling-Dokumentation von Google heißt es, dass die Crawler 5xx-Fehler verursachen “durch Krabbeln vorübergehend langsamer werden”. Es heißt auch, dass bereits indizierte URLs beibehalten werden, dann “schließlich fallen gelassen” wenn der Fehler weiterhin besteht. Stunden sind also in Ordnung, und Tage sind es nicht. Wenn Sie das Problem noch am selben Tag beheben, werden Sie mit ziemlicher Sicherheit keinerlei Auswirkungen auf das Ranking feststellen. Die tatsächlichen Kosten während eines Ausfalls sind verlorener Datenverkehr und verlorenes Vertrauen, danach keine bleibende Strafe.
Wie lange dauert die Reparatur eines 500 Error?
Ob es sich um .htaccess oder ein einzelnes Plugin handelt, zehn Minuten, und das meiste davon wartet auf FTP. Wenn es sich um eine Speicherobergrenze oder eine Nichtübereinstimmung der PHP-Version handelt, ein oder zwei Stunden, da Sie testen und nicht nur zurückkehren. Wenn es Eigentum ist, eine Firewall-Regel oder ein aussterbender Prozesspool, Es dauert so lange wie die Ticketwarteschlange Ihres Gastgebers. Das ist das eigentliche Argument dafür, herauszufinden, welches der drei Sie haben, bevor Sie beginnen.
Die Kurzversion
Schauen Sie sich die Seite an, bevor Sie sich eine Checkliste ansehen. Ein formatierter WordPress-Fehler bedeutet, dass der Absturz innerhalb von WordPress passiert ist, Überprüfen Sie daher den Admin-Posteingang auf einen Wiederherstellungslink und lesen Sie dann wp-content/debug.log. Eine nackte Serverseite bedeutet, dass der Absturz vor dem Laden von WordPress aufgetreten ist, Benennen Sie also .htaccess um, Überprüfen Sie dann, ob die Verzeichnisse vorhanden sind 755 und Dateien sind 644. Eine leere Seite bedeutet, dass Sie erfahren, was PHP tatsächlich gesehen hat, wenn Sie den Handler für schwerwiegende Fehler 30 Sekunden lang ausschalten.
Dann widersetzen Sie sich der Lösung, die jeder ohne Einschränkung empfiehlt. Das Hinzufügen von php_value memory_limit zu .htaccess ist eine funktionierende Lösung für mod_php und eine sofortige 500 ist PHP-FPM, und PHPs eigenes Handbuch sagt, welches welches ist. Wenn Ihr Host FPM ausführt, die Datei ist .user.ini, und es wird fünf Minuten lang zwischengespeichert, bevor Ihre Änderung etwas bewirkt.
Bin hier wegen eines anderen Symptoms gelandet? Zwei benachbarte Probleme haben ihre eigenen Führer. “Wegen geplanter Wartungsarbeiten kurzzeitig nicht verfügbar” Es handelt sich eher um ein hängengebliebenes Update als um einen Absturz, und es löscht sich nach zehn Minuten von selbst. Ein Absturz, der nur auf den Anmeldebildschirm trifft, ist mal wieder ein anderes Problem, mit Cookie- und Sperrursachen, die niemals .htaccess berühren.