Deine Website zeigt plötzlich eine Fehlermeldung, und du hast keine Ahnung, was sie bedeutet? Willkommen im Club. Ich hab in über zehn Jahren WordPress ziemlich jede dieser Meldungen gesehen – bei Kunden, in fremden Installationen und ein paarmal auch bei mir selbst.

Die gute Nachricht: Fast alle davon lassen sich einordnen, wenn man weiß, wonach man schaut. Und die allermeisten sind harmloser, als sie klingen.

Ich geh hier die Meldungen durch, die mir am häufigsten begegnen. Für jede: was sie wirklich bedeutet, woran es meistens liegt und was du selbst machen kannst, bevor du jemanden anrufst.

Bevor du irgendwas machst: diese drei Regeln

Ich weiß, du willst die Seite wieder online haben. Trotzdem – diese drei Punkte ersparen dir im Zweifel Stunden.

Erstens: Mach ein Backup. Auch jetzt. Ja, auch von der kaputten Website. Es klingt unlogisch, ein defektes System zu sichern, aber genau dieser Stand enthält deine Inhalte und die Spuren des Problems. Wenn deine erste Reparatur schiefgeht, willst du zurückkönnen.

Zweitens: Ändere immer nur eine Sache. Der Klassiker ist, gleichzeitig drei Plugins zu deaktivieren, PHP umzustellen und den Cache zu leeren. Wenn es dann läuft, weißt du nicht, warum. Und beim nächsten Mal stehst du wieder da.

Drittens: Schreib auf, was du geändert hast. Zwei Zeilen im Notizblock reichen. Wenn du am Ende doch jemanden brauchst, verkürzt das die Fehlersuche massiv.

„Es gab einen kritischen Fehler auf deiner Website“

Die Meldung, die seit WordPress 5.2 den weißen Bildschirm abgelöst hat. Sie klingt dramatisch, ist aber eigentlich eine Verbesserung: WordPress hat gemerkt, dass etwas abstürzt, und zeigt statt einer leeren Seite wenigstens einen Hinweis.

Was dahintersteckt: Ein PHP-Fehler. Irgendein Code – fast immer ein Plugin oder das Theme – hat etwas versucht, das die PHP-Version auf deinem Server nicht kann oder das schlicht kaputt ist.

Die häufigsten Auslöser, in dieser Reihenfolge:

• Ein Plugin wurde aktualisiert und verträgt sich nicht mehr mit einem anderen
• WordPress oder PHP wurde aktualisiert, ein altes Plugin kommt nicht mit
• Jemand hat Code in die functions.php eingefügt – ein fehlendes Semikolon reicht
• Der Arbeitsspeicher reicht nicht (dazu unten mehr)

Was du tun kannst: Schau zuerst in dein E-Mail-Postfach. WordPress schickt bei diesem Fehler automatisch eine Mail an die Administrator-Adresse – und in der steht oft schon, welches Plugin schuld ist. Diese Mail enthält außerdem einen Link in den Wiederherstellungsmodus, mit dem du dich einloggen kannst, obwohl die Seite tot ist.

Kommt keine Mail (weil der Mailversand auch nicht funktioniert), gehst du über den Dateizugriff: Benenne im Ordner /wp-content/ den Ordner plugins in plugins-alt um. Damit sind alle Plugins auf einen Schlag deaktiviert. Läuft die Seite jetzt? Dann benennst du zurück und deaktivierst die Plugins einzeln, bis du den Übeltäter hast.

Die weiße Seite ohne alles

Der berüchtigte „White Screen of Death“. Keine Meldung, kein Hinweis, nur Weiß. Sieht schlimmer aus als der kritische Fehler, ist aber dasselbe Problem – nur ohne die freundliche Fehlermeldung.

Warum du gar nichts siehst: Entweder ist die Fehleranzeige abgeschaltet, oder der Absturz passiert so früh, dass WordPress nicht mal mehr seine eigene Fehlerseite bauen kann.

Der Weg ist derselbe wie oben: Fehlerprotokoll einschalten, dann steht die Ursache in der debug.log. Wenn du nur auf einzelnen Seiten Weiß siehst und der Rest läuft, ist es meistens ein Speicherproblem.

„Fehler beim Aufbau einer Datenbankverbindung“

Diese Meldung ist erfreulich ehrlich: WordPress kommt nicht an die Datenbank. Alle Inhalte deiner Website – Seiten, Beiträge, Einstellungen, Kommentare – liegen dort. Ohne Datenbank keine Website.

Die drei realistischen Ursachen:

• Die Zugangsdaten stimmen nicht mehr. Passiert typischerweise nach einem Umzug oder wenn beim Hoster das Datenbank-Passwort geändert wurde. Die Daten stehen in der wp-config.php.
• Der Datenbankserver ist überlastet oder down. Bei günstigen Shared-Hosting-Paketen gar nicht so selten. Prüf, ob andere Websites auf demselben Paket auch betroffen sind.
• Die Datenbank ist beschädigt. Seltener, aber möglich. WordPress bringt dafür ein eigenes Reparaturwerkzeug mit.

Das Reparaturwerkzeug aktivierst du, indem du in die wp-config.php die Zeile define( 'WP_ALLOW_REPAIR', true ); einträgst. Danach rufst du deine-domain.de/wp-admin/maint/repair.php auf. Wichtig: Diese Zeile hinterher wieder entfernen, denn die Seite ist ohne Login erreichbar.

ERR_TOO_MANY_REDIRECTS: die Weiterleitungsschleife

Der Browser sagt sinngemäß: „Diese Seite schickt mich im Kreis.“ Und genau das passiert – Seite A leitet auf B, B leitet zurück auf A, und der Browser bricht irgendwann ab.

Die mit Abstand häufigste Ursache ist die Umstellung auf https. In den WordPress-Einstellungen steht die Adresse noch mit http://, gleichzeitig leitet der Server alles auf https:// um. Ergebnis: Endlosschleife.

Weitere typische Auslöser:

• Ein SSL- oder Caching-Plugin, das zusätzlich umleitet
• Regeln in der .htaccess, die sich mit den WordPress-Einstellungen beißen
• Ein Dienst wie Cloudflare, der noch auf „Flexible SSL“ steht, während der Server bereits https erzwingt
• Ein doppelt gesetzter Umzug von www auf ohne-www und zurück

Was du tun kannst: Prüf zuerst in den WordPress-Einstellungen unter „Allgemein“, ob WordPress-Adresse und Website-Adresse beide mit https:// beginnen und identisch geschrieben sind – entweder beide mit www oder beide ohne. Kommst du nicht mehr ins Backend, lassen sich beide Werte auch direkt in der wp-config.php setzen.

HTTP-Fehler 500: Internal Server Error

Die unspezifischste aller Meldungen. „Internal Server Error“ heißt übersetzt: Es ist etwas schiefgelaufen, und ich sage dir nicht, was.

Der Unterschied zum kritischen Fehler: Ein 500er kommt vom Server, nicht von WordPress. Oft ist WordPress gar nicht mehr zum Zug gekommen.

Woran es meistens liegt:

• Eine fehlerhafte .htaccess – benenne sie testweise um, WordPress legt eine neue an
• Das PHP-Speicherlimit ist erschöpft
• Ein Plugin oder Theme mit fehlerhaftem Code
• Falsche Dateirechte auf dem Server

Auch hier gilt: Das Fehlerprotokoll deines Hosters ist die eigentliche Antwort. Im Hosting-Panel gibt es fast immer einen Punkt „Logs“ oder „Fehlerprotokoll“ – dort steht die konkrete Zeile.

„Ihre Verbindung ist nicht privat“ und abgelaufene Zertifikate

Der Browser blockiert deine Website mit einer Warnung. Für Besucher sieht das aus, als wäre etwas faul – und viele klicken sofort weg.

Meistens ist es simpel: Das SSL-Zertifikat ist abgelaufen. Die kostenlosen Let’s-Encrypt-Zertifikate laufen alle 90 Tage aus und werden normalerweise automatisch verlängert. Wenn diese Automatik einmal klemmt, steht die Warnung da.

Die zweite häufige Variante sind gemischte Inhalte: Die Seite selbst läuft über https, lädt aber einzelne Bilder oder Skripte noch über http. Dann zeigt der Browser statt des Schlosses ein Warndreieck. Das passiert oft nach einer Umstellung, wenn alte Bild-Adressen in der Datenbank stehen geblieben sind.

Bilder werden nicht mehr angezeigt

Alle Bilder weg, stattdessen leere Rahmen oder kaputte Symbole. Das hat fast immer eine von drei Ursachen.

Nach einem Umzug: Die Bilder liegen noch unter der alten Adresse. In der Datenbank stehen die vollständigen alten URLs, und die zeigen ins Leere.

Nach einem Update oder Serverwechsel: Die Dateirechte am Ordner /wp-content/uploads/ stimmen nicht mehr, der Webserver darf die Dateien nicht ausliefern.

Nur bei neuen Uploads: Dann ist meistens der Speicherplatz voll oder das Upload-Limit erreicht. Das siehst du in der Mediathek, wenn beim Hochladen ein Fehler kommt.

Ein Sonderfall, der viele in den Wahnsinn treibt: Die Bilder sind da, werden aber in falscher Größe ausgeliefert. Dann fehlen die generierten Zwischengrößen – ein Plugin wie „Regenerate Thumbnails“ baut sie neu.

„Kurz nicht verfügbar für geplante Wartungsarbeiten“

Diese Meldung gehört eigentlich zum normalen Ablauf: WordPress zeigt sie während eines Updates für ein paar Sekunden. Das Problem ist, wenn sie nicht mehr verschwindet.

Was passiert ist: Das Update wurde unterbrochen – Browser geschlossen, Zeitüberschreitung, Serverfehler. WordPress legt zu Beginn eines Updates eine Datei namens .maintenance im Hauptverzeichnis an und löscht sie danach wieder. Bricht das Update ab, bleibt die Datei liegen.

Die Lösung dauert zehn Sekunden: Datei per Dateizugriff löschen, fertig. Danach solltest du prüfen, ob das Update tatsächlich durchgelaufen ist – im Backend unter „Aktualisierungen“.

502 Bad Gateway, 503 Service Unavailable und Konsorten

Diese drei fasse ich zusammen, weil sie eines gemeinsam haben: Sie kommen meistens nicht von deiner Website.

502 Bad Gateway bedeutet, dass ein Server einen anderen nicht erreicht – typischerweise ein Problem beim Hoster oder bei einem vorgeschalteten Dienst.

503 Service Unavailable heißt, der Server ist überlastet oder in Wartung. Bei WordPress kann es auch bedeuten, dass ein Plugin den Server in die Knie zwingt.

429 Too Many Requests tritt auf, wenn zu viele Anfragen in kurzer Zeit kommen – manchmal durch einen aggressiven Bot, manchmal durch ein Plugin, das im Kreis läuft.

Bei allen dreien lohnt der erste Blick auf die Statusseite deines Hosters. Wenn dort eine Störung gemeldet ist, kannst du dir die Fehlersuche sparen.

Wann es kein Fehler ist, sondern ein Angriff

Die Abgrenzung ist wichtig, weil der Weg ein völlig anderer ist. Ein PHP-Fehler wird repariert. Eine befallene Website muss bereinigt werden – und zwar vollständig, sonst kommt der Code zurück.

Diese Zeichen sprechen für einen Angriff:

• Besucher werden auf fremde Seiten weitergeleitet, besonders wenn es nur auf dem Handy oder nur bei Besuchern über Google passiert
• In der Benutzerliste steht ein Administrator, den niemand angelegt hat
• Google zeigt eine rote Warnung oder listet unter deiner Domain Seiten, die du nie erstellt hast
• Dein Hoster meldet sich, weil von deinem Server Spam verschickt wird
• Im Dateiverzeichnis liegen PHP-Dateien mit kryptischen Namen, besonders im Upload-Ordner

Trifft eines davon zu, hör auf, an Plugins herumzuschrauben. Wie du dann vorgehst – und was du auf keinen Fall tun solltest – steht ausführlich hier: Website gehackt: Soforthilfe und Ablauf.

Wann du besser jemanden holst

Ich bin der Letzte, der dir einredet, du bräuchtest für alles einen Dienstleister. Vieles auf dieser Liste kannst du selbst erledigen, wenn du dich traust, per FTP an die Dateien zu gehen.

Es gibt aber drei Situationen, in denen ich abraten würde, weiterzumachen:

Du hast kein Backup. Ohne Sicherung ist jeder Reparaturversuch ein Risiko. Wenn du an dieser Stelle stehst und nicht weißt, wie du an ein Backup kommst, hör lieber auf.

Es hängt Umsatz dran. Bei einem Shop kostet jede Stunde Ausfall Geld. Da ist es meistens günstiger, jemanden ranzulassen, der den Fehler in einer Stunde findet, als drei Tage selbst zu suchen.

Du hast schon mehrere Sachen geändert und es wird schlimmer. Das ist der Punkt, an dem eine einfache Reparatur zu einer aufwendigen wird. Je mehr Änderungen übereinanderliegen, desto schwerer ist der Ursprungsfehler zu finden.

Wie du die meisten dieser Fehler gar nicht erst bekommst

Ein Muster zieht sich durch fast alle Fälle, die hier landen: Die Website war monatelang sich selbst überlassen. Dann kommen fünf Updates auf einmal, und eines davon zerlegt etwas.

Was tatsächlich hilft, ist wenig spektakulär:

• Regelmäßig aktualisieren, statt einmal im Jahr alles auf einmal. Kleine Schritte sind leichter rückgängig zu machen.
• Vor jedem Update sichern. Automatisch, nicht wenn du dran denkst.
• Weniger Plugins. Jedes Plugin ist eine mögliche Fehlerquelle. Was du nicht brauchst, fliegt raus – gelöscht, nicht nur deaktiviert.
• Eine Testumgebung für größere Änderungen. Viele Hoster bieten das mit einem Klick an.
• PHP aktuell halten. Alte PHP-Versionen bekommen keine Sicherheitsupdates mehr und sind die Ursache vieler Abstürze nach Plugin-Updates.

Mein Fazit

Die meisten WordPress-Fehlermeldungen sehen schlimmer aus, als sie sind. Hinter „kritischer Fehler“, weißer Seite und 500er steckt in aller Regel ein Plugin, das sich verschluckt hat – und das ist in einer halben Stunde gefunden, wenn man das Fehlerprotokoll einschaltet, statt zu raten.

Ernst wird es an zwei Stellen: wenn kein Backup existiert und wenn hinter dem Fehler kein Fehler steckt, sondern ein Angriff. Für beides gilt: lieber einmal zu früh fragen als einmal zu spät.

Häufige Fragen zu WordPress-Fehlern