WordPress reparieren - Notfall-Anleitung mit Symptom-Check

Deine WordPress-Seite zeigt eine weisse Seite, einen Fehlertext oder lädt einfach nicht mehr. Bevor du in Panik gerätst: in 90 Prozent der Fälle ist die Ursache ein Plugin, eine kaputte Konfigurationsdatei oder ein PHP-Update. Diese Anleitung führt dich Schritt für Schritt durch die Diagnose - vom Symptom bis zur Lösung.

Was siehst du? Symptom-Check

Sag mir, was auf deinem Bildschirm steht - ich sag dir, wo du anfangen solltest. Such die Zeile, die zu deinem Problem passt:

Das 7-Punkte-Notfall-Toolkit

Diese sieben Schritte deckst du in der Reihenfolge ab. Die meisten Probleme sind nach Schritt 1 bis 3 weg. Nach jedem Schritt: Seite neu laden und schauen, ob es besser ist.

Schritt 1: Debug-Modus einschalten

Standardmässig versteckt WordPress Fehlermeldungen, damit Besucher nichts Technisches zu sehen bekommen. Für die Fehlersuche brauchst du die aber. Öffne die Datei wp-config.php im Hauptverzeichnis deiner WordPress-Installation und such die Zeile:

define('WP_DEBUG', false);

Ersetz diesen Block durch:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);

Lade die Seite neu. WordPress schreibt jetzt jeden Fehler in die Datei wp-content/debug.log. Diese kannst du per FTP herunterladen und öffnen. Meistens steht in der letzten Zeile schon der Hinweis: welche Datei, welche Zeile, welcher Fehler. Oft ist das ein Plugin-Pfad wie wp-content/plugins/PLUGINNAME/... - dann weisst du, wo du in Schritt 2 ansetzt.

Wichtig: WP_DEBUG_DISPLAY auf false und display_errors auf 0 sorgen dafür, dass Besucher der Seite nichts von den Fehlermeldungen sehen. Nach der Reparatur stellst du alles wieder auf false zurück, sonst sammelt sich die Datei voll.

Schritt 2: Alle Plugins deaktivieren

Plugins sind mit Abstand die häufigste Ursache für WordPress-Probleme. Wenn du noch ins Backend kommst: gehe auf Plugins, markiere alle, wähle "Deaktivieren" und klick auf "Übernehmen".

Wenn du nicht mehr ins Backend kommst, geht es auch per FTP (Erklärung dazu weiter unten):

1. Verbinde dich mit deinem Webspace.
2. Geh in den Ordner wp-content.
3. Benenne dort den Ordner plugins um in plugins_aus - Rechtsklick, Umbenennen.
4. Lade die Seite neu.

WordPress findet keinen Plugin-Ordner mehr und deaktiviert dadurch automatisch alle Plugins. Wenn die Seite jetzt läuft, weisst du: es war ein Plugin. Benenne den Ordner zurück (wieder in plugins) und aktiviere im Backend ein Plugin nach dem anderen. Sobald die Seite wieder kaputtgeht, hast du den Übeltäter gefunden.

Schritt 3: Theme auf Standard zurücksetzen

Wenn Schritt 2 nicht hilft, ist eventuell das Theme schuld - besonders nach einem PHP-Update auf eine neue Version.

Im Backend: Gehe auf Design → Themes und aktiviere ein Standard-Theme von WordPress (Twenty Twenty-Four oder Twenty Twenty-Five). Diese sind kompatibel mit allen aktuellen PHP-Versionen.

Per FTP: Gehe in wp-content/themes/. Wenn dort ein Standard-Theme wie twentytwentyfive liegt, benenne deinen aktiven Theme-Ordner um (z.B. von mein-theme in mein-theme_aus). WordPress fällt dann automatisch auf das nächstbeste Theme zurück.

Schritt 4: PHP-Speicherlimit erhöhen

Manche Themes oder Seitenbuilder brauchen mehr Speicher, als WordPress standardmässig zugesteht. Erkennbar ist das oft an der Meldung "Allowed memory size of ... bytes exhausted" im Debug-Log. Trage in der wp-config.php diese Zeile ein, direkt nach dem Datenbank-Block:

define('WP_MEMORY_LIMIT', '256M');

Wenn das nicht reicht und du Zugriff auf die php.ini oder eine .htaccess hast, kannst du dort auch memory_limit = 256M bzw. php_value memory_limit 256M setzen. Bei Shared Hosting (All-Inkl, IONOS, Strato) findest du die PHP-Einstellungen im Kundenbereich oft als bequemes Menü.

Schritt 5: .htaccess neu erzeugen lassen

Die .htaccess ist eine versteckte Konfigurationsdatei im Hauptverzeichnis deiner WordPress-Installation. Sie steuert unter anderem die schönen URLs (Permalinks). Wenn die kaputt ist, sind oft alle Unterseiten weg oder du bekommst 500er-Fehler.

So machst du sie neu:

1. Verbinde dich per FTP mit dem Server.
2. Aktiviere "versteckte Dateien anzeigen" im FTP-Programm - die .htaccess beginnt mit einem Punkt und ist sonst unsichtbar.
3. Benenne die bestehende .htaccess um in htaccess_alt (so hast du ein Backup).
4. Falls du noch ins Backend kommst: geh auf Einstellungen → Permalinks und klick einmal auf "Änderungen speichern", ohne irgendwas zu ändern. WordPress legt dann eine neue, frische .htaccess an.
5. Falls du nicht ins Backend kommst: leg manuell eine neue .htaccess mit diesem Inhalt an:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Schritt 6: Caches komplett leeren

Das wird oft übersehen und kostet Stunden: deine Seite ist eigentlich repariert, aber du siehst immer noch die kaputte Version. Schuld sind Caches an drei Stellen:

• Browser-Cache: drücke Strg + F5 (Windows) bzw. Cmd + Shift + R (Mac), um die Seite ohne Cache neu zu laden. Im Zweifel den kompletten Browser-Cache leeren.
• WordPress-Cache-Plugin: wenn du WP Rocket, W3 Total Cache, WP Super Cache oder LiteSpeed Cache nutzt - im jeweiligen Menü "Cache leeren" klicken. Wenn du da nicht reinkommst, lösch per FTP den Ordner wp-content/cache/.
• Hoster-Cache: All-Inkl, IONOS und viele andere haben eigene Server-Caches (Varnish, Cloudflare-Layer). Im Kundenbereich nach "Cache leeren" suchen.

Schritt 7: Backup einspielen (letzter Ausweg)

Wenn nichts hilft: spiel ein Backup von vor dem Problem zurück. Die meisten Hoster legen automatisch tägliche Backups an. Bei All-Inkl findest du sie im KAS unter "Tools → Backup", bei IONOS unter "Hosting → Backups". Dort wählst du einen Zeitpunkt vor dem Crash und stellst Dateien und Datenbank wieder her.

Wichtig: notier dir vorher, was du seitdem an Inhalten verändert hast. Neue Beiträge, Bilder oder Bestellungen sind nach dem Rückspielen weg.

Sonderfall: "Es gab einen kritischen Fehler auf deiner Website"

Diese Meldung kommt seit WordPress 5.2 sehr häufig. Sie taucht auf, wenn ein PHP-Fehler die Seite zum Absturz bringt - typischerweise nach einem Plugin- oder PHP-Update. Das Praktische: WordPress schickt dir an die Admin-E-Mail-Adresse eine automatische Nachricht mit Hinweisen, welche Datei den Fehler verursacht hat. Schau zuerst dort rein.

In der E-Mail steht meistens ein Link zum sogenannten Wiederherstellungsmodus. Über diesen Link kommst du auch dann ins Backend, wenn die normale Seite nicht mehr erreichbar ist. Dort kannst du das verursachende Plugin deaktivieren und dann in Ruhe weiterarbeiten.

Sonderfall: "Error establishing a database connection"

WordPress besteht aus zwei Teilen: den Dateien auf dem Webspace und einer Datenbank. Diese Fehlermeldung heißt: WordPress findet die Datenbank nicht oder darf nicht rein. Mögliche Ursachen:

• Falsche Zugangsdaten in der wp-config.php. Öffne die Datei und prüf die Zeilen DB_NAME, DB_USER, DB_PASSWORD und DB_HOST. Die musst du mit den Daten aus deinem Hoster-Account abgleichen.
• Datenbank-Server beim Hoster ist down. Check die Status-Seite deines Hosters (z.B. status.all-inkl.com, status.ionos.de). Wenn alle anderen WordPress-Seiten beim selben Hoster auch hängen, wartest du einfach kurz ab.
• Datenbank ist beschädigt. Füg in der wp-config.php die Zeile define('WP_ALLOW_REPAIR', true); ein und ruf deine-domain.de/wp-admin/maint/repair.php auf. Dort kannst du die Datenbank reparieren lassen. Danach die Zeile unbedingt wieder löschen, sonst kann jeder die Reparatur ausführen.

Sonderfall: "500 Internal Server Error" und "503 Service Unavailable"

Der HTTP-Fehlercode 500 heißt: der Server konnte die Anfrage nicht abarbeiten, weiß aber selbst nicht genau warum. Bei WordPress kommt das fast immer aus einer von drei Ecken: eine kaputte .htaccess, ein Plugin oder Theme das mit der aktuellen PHP-Version nicht klarkommt, oder zu wenig PHP-Arbeitsspeicher. Geh die Schritte 1 (Debug-Modus), 4 (Speicher erhöhen) und 5 (.htaccess neu erzeugen) aus dem Toolkit oben durch - in der Reihenfolge.

Der Fehlercode 503 heißt: der Server ist gerade nicht erreichbar. Bei WordPress steckt dahinter meistens der Wartungsmodus (siehe nächste Sektion) oder ein temporärer Engpass beim Hoster. Wenn 503 länger als zehn Minuten anhält, schau zuerst nach der .maintenance-Datei.

Bei beiden Fehlern lohnt sich ein Blick in das Server-Error-Log. Bei den meisten Hostern findest du es im Kunden-Account unter "Logs" oder "Statistik" - oft sogar im Webspace selbst als error_log-Datei. Dort steht meistens die echte Ursache mit Datei und Zeilennummer.

Sonderfall: Wartungsmodus dauert ewig

Du siehst die Meldung "Wegen geplanter Wartungsarbeiten ist die Seite gerade nicht erreichbar. Schau in einer Minute noch einmal vorbei." - und das schon seit Stunden. Ursache ist eine zurückgebliebene Datei mit dem Namen .maintenance im WordPress-Hauptverzeichnis. WordPress legt sie während eines Updates an und löscht sie normalerweise nach wenigen Sekunden wieder. Wenn das Update unterbrochen wird (Browser geschlossen, Server-Timeout, Verbindungsabbruch), bleibt die Datei liegen.

Lösung: per FTP oder Datei-Manager ins Hauptverzeichnis deiner Installation, die Datei .maintenance finden (Punkt am Anfang, oft versteckt - "versteckte Dateien anzeigen" einschalten) und löschen. Danach ist die Seite sofort wieder erreichbar. Anschließend solltest du das abgebrochene Update über das Backend nachholen, sonst läufst du in einen halbfertigen Update-Zustand.

debug.log lesen und verstehen

Wenn du Schritt 1 aus dem Toolkit umgesetzt hast, schreibt WordPress alle PHP-Fehler in die Datei wp-content/debug.log. Diese Datei ist deine wichtigste Diagnose-Quelle - sie sagt dir nicht nur, dass etwas kaputt ist, sondern auch wo und warum. Öffne sie mit einem Texteditor und scrolle ans Ende, dort stehen die neuesten Einträge.

Drei typische Meldungen und was sie heißen:

• PHP Fatal error: Call to undefined function xyz() - Ein Plugin oder Theme ruft eine Funktion auf, die nicht existiert. Häufiger Grund: das Plugin ist nicht mit deiner WordPress- oder PHP-Version kompatibel. Direkt nach der Fehlerzeile steht der Pfad zur verursachenden Datei (z.B. /wp-content/plugins/ein-plugin/ein-plugin.php) - das ist dein Schuldiger.
• Allowed memory size of 134217728 bytes exhausted - PHP hatte zu wenig Speicher. Lösung: Schritt 4 aus dem Toolkit, WP_MEMORY_LIMIT in der wp-config.php erhöhen.
• Maximum execution time of 30 seconds exceeded - Ein Vorgang braucht zu lange. Bei Import-/Export-Vorgängen oder großen Datenbank-Abfragen normal. In der php.ini oder .htaccess kannst du max_execution_time hochsetzen.

Nach erfolgreicher Diagnose: debug.log löschen oder den Debug-Modus wieder deaktivieren. Sonst wächst die Datei und liefert Angreifern bei einem Einbruch Hinweise auf interne Pfade.

Sonderfall: Hack-Verdacht - erst sichern, dann reparieren

Wenn du Anzeichen siehst, dass jemand fremder Zugriff hatte (unbekannte Admin-User, fremde Werbe-Skripte, automatische Weiterleitungen, "Diese Seite kann Ihren Computer schädigen"-Warnung von Google), dann ist Reparieren der zweite Schritt. Der erste ist: die Lücke schließen. Sonst reparierst du eine Seite, die danach sofort wieder kompromittiert wird.

Reihenfolge:

1. Seite vorläufig offline nehmen. Per .htaccess mit Deny from all oder über die Wartungs-Funktion deines Hosters. So kann der Angreifer in der Reparaturphase nichts Neues installieren.
2. Alle Passwörter rotieren. WordPress-Admin, FTP/SFTP, Datenbank-User, Hoster-Account, eventuell auch verknüpfte Dienste (Mailchimp, Stripe, etc.). Nicht nur das WP-Admin-Passwort.
3. Sicherheitsschlüssel erneuern. In der wp-config.php die Zeilen AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY sowie die vier Salts ersetzen. Frische Werte holst du dir per Klick von api.wordpress.org/secret-key/1.1/salt/. Damit werden alle bestehenden Sessions ungültig - auch die des Angreifers.
4. Core, Plugins und Themes komplett austauschen. Lokal frische Kopien herunterladen (WordPress.org, Original-Quellen der Plugins) und die kompletten Ordner wp-admin, wp-includes und einzelne Plugin-/Theme-Ordner überschreiben. Verlass dich nicht aufs "Update" - manipulierte Dateien bleiben sonst liegen.
5. Uploads-Ordner durchsuchen. Im Ordner wp-content/uploads hat nichts ausser Bildern und PDFs zu suchen. Dateien mit Endungen wie .php, .phtml oder .html dort sind verdächtig und gehören gelöscht (vorher prüfen ob sie wirklich nicht gebraucht werden).
6. Datenbank kontrollieren. In wp_users prüfen ob nur erwartete Benutzer drin sind. In wp_options nach verdächtigen Skript-Schnipseln suchen (besonders siteurl und home sollten deine echte Domain enthalten).

Wenn du an einem dieser Punkte unsicher bist, hol dir professionelle Hilfe. Eine schlecht ausgeführte Hack-Reparatur kann mehr Schaden anrichten als der ursprüngliche Angriff - vor allem wenn dabei kompromittierte Backdoors übersehen werden.

FTP - was ist das eigentlich?

Falls dir das Wort FTP unklar ist: das ist die Methode, mit der du Dateien zwischen deinem Computer und dem Webspace hin- und herschiebst. Ohne FTP kommst du an die wp-config.php oder den Plugin-Ordner nicht ran - ausser dein Hoster bietet einen Datei-Manager im Browser an (haben fast alle).

Wichtig: pass auf, was du löschst oder verschiebst. Die WordPress-Hauptordner heissen wp-admin, wp-content und wp-includes. Im Hauptverzeichnis liegen ausserdem Dateien wie index.php, wp-config.php und .htaccess. Diese Dateien sind das Herzstück - lösch nichts davon, ohne ein Backup zu haben.

Wie verhindere ich das nächste Mal?

Die meisten WordPress-Notfälle entstehen aus denselben Gründen. Vier Gewohnheiten ersparen dir 90 Prozent der Zwischenfälle:

• Updates regelmässig, aber nie ungetestet. Plugins, Themes und WordPress-Core einmal pro Woche prüfen. Vor jedem Update ein Backup machen (oder die automatische Backup-Funktion deines Hosters aktivieren).
• Staging-Umgebung nutzen. Viele Hoster (All-Inkl, Raidboxes, Kinsta) bieten einen "Klon" deiner Seite, auf dem du Updates testen kannst, bevor sie live gehen. Wenn etwas schiefgeht, hat es keinen Einfluss auf den echten Auftritt.
• Plugins ausmisten. Jedes nicht-aktive Plugin ist eine Sicherheitslücke. Was du nicht brauchst, deinstallierst du komplett (nicht nur deaktivieren).
• PHP-Version aktuell halten. WordPress empfiehlt aktuell PHP 8.2 oder höher. Alte PHP-Versionen bekommen keine Sicherheitsupdates mehr. Im Hoster-Kundenbereich kannst du die PHP-Version selbst umstellen - siehe dazu auch die All-Inkl PHP-Versionen-Anleitung.

Wann du jemanden rufen solltest

Es gibt Momente, in denen Selbsthilfe mehr Schaden anrichtet als Nutzen bringt. Wenn einer dieser Punkte auf dich zutrifft, hol dir Hilfe:

• Du hast kein aktuelles Backup und die Seite ist geschäftskritisch (Shop, Buchungssystem, Kundendaten).
• Du siehst Hinweise auf einen Hack (fremde Werbung, unbekannte Admin-User, Weiterleitungen). Hier ist Reparieren erst der zweite Schritt - zuerst muss die Sicherheitslücke geschlossen werden.
• Du kommst weder ins Backend noch per FTP an den Webspace.
• Du hast schon Stunden investiert und drehst dich im Kreis.

Häufige Fragen

Wo finde ich die wp-config.php?

Im Hauptverzeichnis deiner WordPress-Installation - dem gleichen Ordner, in dem auch wp-admin, wp-content und wp-includes liegen. Per FTP erreichbar, bei manchen Hostern auch über den Datei-Manager im Browser.

Ich komme nicht mehr ins WordPress-Backend, was tun?

Lösch den Browser-Cache und die Cookies für deine Domain. Wenn das nichts bringt, deaktivier alle Plugins per FTP (Ordner wp-content/plugins umbenennen). Hilft auch das nicht, setz das Theme auf Standard zurück.

Hilft es, WordPress neu zu installieren?

Manchmal ja, aber nur die Core-Dateien (wp-admin und wp-includes). Niemals den Ordner wp-content ersetzen - dort liegen deine Inhalte, Plugins, Themes und Bilder. Datenbank bleibt immer unangetastet.

Mein Hoster sagt, alles ist okay - aber die Seite läuft trotzdem nicht.

Dann liegt das Problem in deinen WordPress-Dateien oder der Datenbank, nicht am Server. Geh die sieben Schritte oben durch - in 95 Prozent der Fälle findest du die Ursache.

Kann ich WordPress reparieren, ohne FTP zu nutzen?

Eingeschränkt ja. Die meisten Hoster bieten einen Datei-Manager im Browser an, mit dem du dieselben Aktionen ausführen kannst wie per FTP. Manche Probleme (z.B. zerstörte wp-config.php) sind allerdings ohne Dateizugriff nicht zu lösen.

Hilft ein Backup, wenn ich gehackt wurde?

Nur bedingt. Das Backup könnte die Hintertür enthalten, durch die der Angreifer reingekommen ist. Nach einem Hack muss erst die Sicherheitslücke geschlossen werden (alte Plugins entfernen, Passwörter ändern, Core-Dateien austauschen), bevor ein Rückspielen sinnvoll ist.

Quellen und weiterführende Anleitungen

• WordPress.org: Debugging in WordPress
• WordPress.org: Common WordPress Errors
• Kinsta: 500 Internal Server Error beheben

Verwandte Artikel

• WordPress Update fehlgeschlagen - wenn das Update nicht durchläuft
• WordPress absichern - Login und .htaccess härten
• All-Inkl: PHP-Version wechseln - mit einer aktuellen PHP-Version vermeidest du viele Probleme
• .htaccess - Anleitung mit Beispielen