WordPress-Fehlermeldungen: was sie heißen, was zu tun ist

Eine WordPress-Fehlermeldung ist fast nie die Ursache, sondern der Ort, an dem WordPress gemerkt hat, dass etwas nicht stimmt. „Fehler beim Aufbau einer Datenbankverbindung“ sagt, dass die Datenbank nicht antwortet, nicht warum. „Der Link, dem du gefolgt bist, ist abgelaufen“ klingt nach einem veralteten Lesezeichen und heißt beim Hochladen meist, dass die Datei zu groß war. Dieses Lexikon ordnet die Meldungen, die im Alltag am häufigsten auftauchen, im deutschen Wortlaut der Übersetzung von WordPress 7.1 und nennt zu jeder den ersten Griff und den Beitrag, in dem der ganze Weg steht.

Lies den Wortlaut genau, bevor du etwas änderst. Zwei Meldungen, die ähnlich klingen, haben oft völlig verschiedene Ursachen, und der Griff, der bei der einen hilft, macht die andere schlimmer.

Die Meldungen auf einen Blick#

Steht die Seite? Die WordPress-Soforthilfe: Fehlerdiagnose und Reparatur 149 € übernimmt, Preis vorab fest, die erste Einschätzung ist kostenlos.

Die Spalte „Ausführlich“ führt zu den Anleitungen mit allen Befehlen. Die übrigen Meldungen sind kürzer zu lösen und stehen hier vollständig.

Fehler aus PHP: kritischer Fehler, weiße Seite, Speicher#

„Auf dieser Website ist ein kritischer Fehler aufgetreten.“ und im Backend „Es gab einen kritischen Fehler auf dieser Website. Prüfe bitte den Posteingang der administrativen E-Mail-Adresse der Website auf Anweisungen.“ Ein fataler PHP-Fehler hat WordPress gestoppt, und der Fehlerschutz, den es seit Version 5.2 gibt, hat ihn abgefangen. Besucher sehen die kurze Fassung; die lange mit dem Hinweis auf die Mail erscheint auf der Anmeldeseite und im Backend, sobald WordPress eine Mail mit einem Link in den Wiederherstellungsmodus an die Administrator-Adresse geschickt hat. Viele Anleitungen zitieren sie als „Es gab einen kritischen Fehler auf deiner Website“; gemeint ist dasselbe. Sofortmaßnahme:

1. Postfach der Administrator-Adresse samt Spam nach der Mail durchsuchen.
2. Ohne Mail WP_DEBUG_LOG einschalten und wp-content/debug.log lesen; die letzte Zeile mit PHP Fatal error nennt Plugin oder Theme.
3. Den genannten Ordner per SFTP umbenennen oder mit wp plugin deactivate name --skip-plugins abschalten.

Der ganze Weg, auch wenn die Mail nie ankommt, steht in Kritischer Fehler auf deiner Website.

„Es gab einen kritischen Fehler auf dieser Website, der sie in den Wiederherstellungsmodus versetzt hat.“ Das sieht nur, wer über den Link aus der Mail angemeldet ist. Die Seite läuft für dich, für Besucher steht sie weiter. Unter „Plugins“ ist das fehlerhafte Plugin markiert. Deaktivieren, dann läuft die Seite auch für Besucher wieder; danach den Wiederherstellungsmodus über die Werkzeugleiste beenden.

Weiße Seite oder 500 ohne jeden Text. Hier hat der Fehlerschutz nicht gegriffen: Der Fehler sitzt in der wp-config.php, der Schutz ist abgeschaltet, der Server hat PHP hart beendet, oder ein Cache liefert eine leere Antwort aus. Erster Griff ist eine Messung, kein Eingriff: curl -sI https://deine-domain.at/ | head -1. Was die Statuscodes heißen und wie es weitergeht, steht in WordPress zeigt eine weiße Seite.

„Allowed memory size of … bytes exhausted“. Ein Plugin oder Theme braucht mehr Speicher, als PHP ihm gibt. WordPress setzt WP_MEMORY_LIMIT ab Werk auf 40 MB (Multisite 64 MB) und für das Backend WP_MAX_MEMORY_LIMIT auf 256 MB, sofern der Hoster nicht schon mehr erlaubt. Sofortmaßnahme:

1. In der wp-config.php define( 'WP_MEMORY_LIMIT', '256M' ); über die Zeile „stop editing“ setzen.
2. Kommt der Fehler wieder, liegt die Obergrenze beim Hoster (memory_limit in PHP); dort erhöhen lassen.
3. Steigt der Verbrauch weiter, ist ein Plugin der Grund, nicht das Limit.

Wie die beiden Konstanten zusammenspielen und warum auch die PHP-Version eine Rolle spielt, steht in WordPress PHP-Version.

Fehler aus der Datenbank#

„Fehler beim Aufbau einer Datenbankverbindung“. Die Meldung kommt, bevor Plugins und Theme überhaupt geladen sind. Sie hat drei Ursachen: Benutzername, Passwort, Datenbankname oder Host in der wp-config.php stimmen nicht (oft nach einem Umzug oder Passwortwechsel beim Hoster), der Datenbankserver läuft nicht, oder er ist überlastet. Sofortmaßnahme:

1. WP_DEBUG kurz einschalten und die echte MySQL-Meldung lesen: 1045 heißt Zugangsdaten, 2002 und 2005 heißen Server oder Hostname.
2. Die vier Zeilen DB_NAME, DB_USER, DB_PASSWORD, DB_HOST mit dem Kundenmenü des Hosters abgleichen.
3. Stimmen sie, beim Hoster nach dem Datenbankserver fragen.

Die Fehlernummern im Einzelnen und die Reparatur beschädigter Tabellen: Fehler beim Aufbau einer Datenbankverbindung beheben. Diese Meldung ist auch die häufigste, die sich mit einem Handgriff beheben lässt; die Reparatur kostet 149 € fix, wenn der Handgriff nicht reicht.

Fehler aus der Update-Mechanik#

„Diese Website ist aufgrund planmäßiger Wartungsarbeiten vorübergehend nicht verfügbar. Bitte versuche es in wenigen Minuten erneut.“ Im englischen Original „Briefly unavailable for scheduled maintenance. Check back in a minute.“ WordPress legt während jedes Updates eine Datei .maintenance ins Hauptverzeichnis und antwortet so lange mit 503 und Retry-After: 600. Bricht das Update ab, bleibt die Datei liegen. Im Quelltext steht dazu eine Sicherung: Ist der Zeitstempel in der Datei älter als zehn Minuten, gilt der Wartungsmodus als beendet. In der Praxis hängen Seiten trotzdem, weil ein Cache die 503-Antwort festhält oder die Datei einen fehlerhaften Zeitstempel trägt. Sofortmaßnahme:

1. .maintenance per SFTP löschen oder wp maintenance-mode deactivate.
2. Cache von Plugin, Hoster und CDN leeren.
3. Unter „Dashboard → Aktualisierungen“ nachsehen, welches Update unvollständig ist, und es neu anstoßen.

Mehr dazu, auch wie man die Seite absichtlich und richtig vom Netz nimmt: WordPress-Wartungsmodus.

„Momentan wird eine andere Aktualisierung durchgeführt.“ Ein Kern-Update setzt in der Tabelle wp_options eine Sperre namens core_updater.lock, damit nicht zwei Updates gleichzeitig laufen. Bricht das Update ab, bleibt die Sperre stehen; WordPress gibt sie nach 15 Minuten selbst frei. Wer nicht warten will: wp option delete core_updater.lock, dann das Update erneut starten. Vorher sicherstellen, dass wirklich kein Update mehr läuft, sonst überschreiben sich zwei Vorgänge gegenseitig.

„Der Zielordner existiert bereits.“ und „Das Verzeichnis konnte nicht erstellt werden.“ Beim Installieren oder Aktualisieren eines Plugins liegt entweder ein Rest einer früheren Installation im Ordner wp-content/plugins/, oder WordPress darf dort nicht schreiben. Im ersten Fall den alten Ordner prüfen und entfernen (vorher sichern, falls es das aktive Plugin ist), im zweiten die Dateirechte von wp-content/ und wp-content/upgrade/ beim Hoster richten lassen. Welcher Benutzer dort schreibt, entscheidet die Serverkonfiguration, nicht WordPress.

Fehler im Editor und beim Hochladen#

„Die Antwort ist keine gültige JSON-Antwort.“ Die Meldung kommt aus dem Block-Editor. Er spricht mit WordPress über die REST-API unter /wp-json/ und erwartet JSON zurück; bekommt er HTML, eine Fehlerseite oder gar nichts, zeigt er genau diesen Satz. Die Ursache liegt also zwischen Editor und Server, nicht im Beitrag. Sofortmaßnahme:

1. Unter „Werkzeuge → Website-Zustand“ nachsehen; steht dort „Bei der REST-API ist ein Fehler aufgetreten“, ist die Schnittstelle selbst gestört.
2. https://deine-domain.at/wp-json/ im Browser aufrufen: Es muss JSON kommen, keine HTML-Seite und keine Sperrseite einer Firewall.
3. Unter „Einstellungen → Permalinks“ einmal speichern, ohne etwas zu ändern; das schreibt die Umschreibregeln neu.
4. Prüfen, ob „WordPress-Adresse“ und „Website-Adresse“ unter „Einstellungen → Allgemein“ beide mit https:// beginnen.

Bleibt die Meldung, liefert oft ein Sicherheits-Plugin oder die Firewall des Hosters eine Sperrseite statt der Antwort, oder ein Plugin schreibt eine PHP-Warnung vor das JSON. Beides steht im debug.log oder im Netzwerk-Reiter der Entwicklerwerkzeuge des Browsers.

„Der Link, dem du gefolgt bist, ist abgelaufen.“ Der englische Text lautet „The link you followed has expired.“, er kommt aus der Funktion wp_nonce_ays() und antwortet mit 403. Gemeint ist: Der Sicherheitsschlüssel (Nonce) des Formulars fehlt oder ist ungültig. Nach langem Warten auf einer Seite stimmt das wörtlich. Beim Hochladen eines Themes, Plugins oder einer großen Mediendatei ist der Grund aber fast immer ein anderer: Ist die Anfrage größer als post_max_size, leert PHP laut Handbuch $_POST und $_FILES vollständig. Damit fehlt auch der Schlüssel, und WordPress meldet einen abgelaufenen Link. Sofortmaßnahme:

1. Unter „Werkzeuge → Website-Zustand → Info → Server“ die Werte für upload_max_filesize und post_max_size ablesen.
2. Beim Hoster beide erhöhen, post_max_size größer als upload_max_filesize, wie es das PHP-Handbuch verlangt.
3. Alternativ das Theme oder Plugin per SFTP nach wp-content/themes/ oder wp-content/plugins/ hochladen.

Verwandt ist „… überschreitet das Upload-Limit für diese Website.“: dieselbe Grenze, nur hat WordPress sie vor dem Hochladen bemerkt.

„Es fehlt ein temporärer Ordner.“ PHP konnte die hochgeladene Datei nicht zwischenspeichern; im PHP-Handbuch ist das der Fehler UPLOAD_ERR_NO_TMP_DIR. Das ist eine Einstellung des Servers (upload_tmp_dir), die nur der Hoster richten kann. Kommt die Meldung nach einem Umzug, hat der neue Server meist einen anderen Pfad.

Fehler bei Anmeldung und Rechten#

„Du bist leider nicht berechtigt, auf diese Seite zuzugreifen.“ Der angemeldete Benutzer hat die Fähigkeit nicht, die diese Seite verlangt. Normal ist das bei einem Redakteur, der die Plugin-Seite öffnet. Ungewöhnlich ist es, wenn ein Administrator es plötzlich sieht, und dafür gibt es einen typischen Grund: WordPress speichert die Rolle eines Benutzers unter einem Schlüssel, der das Tabellenpräfix enthält, also wp_capabilities oder xyz_capabilities. Wird nach einem Umzug $table_prefix in der wp-config.php geändert, ohne die Einträge in der Datenbank mitzuziehen, hat plötzlich niemand mehr eine Rolle. Prüfen:

wp user list --fields=user_login,roles
wp config get table_prefix

Steht bei allen Benutzern eine leere Rolle, passt das Präfix nicht. Ist dagegen nur dein Konto betroffen und ein unbekanntes Administratorkonto aufgetaucht, ist das kein Rechtefehler, sondern ein Hinweis auf einen Angriff; dann weiter mit WordPress gehackt – was tun.

„Fehler: Cookies sind gesperrt oder werden von deinem Browser nicht unterstützt.“ Bei der Anmeldung setzt WordPress ein Test-Cookie. Kommt es nicht zurück, erscheint diese Meldung. Abgesehen vom Browser selbst sind die üblichen Gründe ein Wechsel zwischen www und ohne, oder zwischen http und https, während der Anmeldung. Die Variante „wegen einer unerwarteten Ausgabe gesperrt“ heißt dagegen: Irgendeine Datei hat Text ausgegeben, bevor WordPress die Kopfzeilen schicken konnte, oft ein Leerzeichen vor <?php in der wp-config.php oder in der functions.php des Themes.

Keine Meldung, aber ein Fehler#

Zwei Fälle zeigen keine WordPress-Meldung und landen trotzdem hier. Erstens Mails aus Kontaktformular, Shop und Passwort-Vergessen, die nicht ankommen. WordPress meldet dabei nichts, weil es die Mail aus seiner Sicht erfolgreich abgegeben hat; die Ursache liegt bei Absender, SPF und DKIM, siehe WordPress-Mails kommen nicht an. Zweitens Weiterleitungen auf fremde Seiten, japanische Seiten unter deiner Domain in Google oder eine Warnung im Browser. Das ist kein Fehler der Software, sondern ein Befall. Hier nichts reparieren, sondern zuerst in WordPress gehackt – was tun nachlesen, in welcher Reihenfolge vorzugehen ist.

Was nicht hilft#

WordPress neu installieren. Die meisten Meldungen haben ihre Ursache in einem Plugin, in der wp-config.php oder beim Hoster. Ein frischer Kern ändert an keinem davon etwas.

Ein altes Backup zurückspielen, ohne die Meldung zu verstehen. Bei einem Upload-Limit oder einem Datenbankpasswort kommt der Fehler mit dem alten Stand zurück. Bei einem Befall kommt der Angreifer mit zurück.

Fehlermeldungen auf der Seite anzeigen lassen. WP_DEBUG_DISPLAY oder display_errors auf einer erreichbaren Seite zeigen jedem Besucher Pfade und Versionen. Das Protokoll sagt dasselbe, nur dir.

Plugins wild löschen. Umbenennen oder deaktivieren genügt, um den Verursacher zu finden. Gelöscht ist auch die Einstellung, und manche Plugins räumen beim Löschen ihre Tabellen ab.

Wenn du es nicht selbst machen willst#

In eigener Sache: cyberscale bin ich, Stefan Haun aus Tirol. Steht die Seite wegen einer dieser Meldungen, übernimmt die WordPress-Soforthilfe für 149 € fix: Sicherung vorher, Ursache finden, reparieren, Prüfung danach. Damit die nächste Meldung gar nicht erst auftaucht, hält die WordPress-Wartung für 49 € im Monat Updates, Sicherungen und die Überwachung am Laufen.

Häufige Fragen#

Stand 13.10.2026. Deutscher Wortlaut aus dem Sprachpaket de_DE für WordPress 7.1.3 (downloads.wordpress.org), englische Originale und Verhalten aus dem WordPress-Quelltext, Grenzen aus dem PHP-Handbuch, alles an diesem Tag gelesen.