Die Meldung „Allowed memory size of … bytes exhausted“ im Fehlerprotokoll oder eine weiße Seite beim Hochladen großer Bilder, beim Import oder im Seitenbaukasten deuten auf ein zu knappes Speicherlimit hin. In WordPress wirken dabei zwei Ebenen zusammen: die PHP-Einstellung memory_limit, die der Server vorgibt, und die WordPress-Konstanten WP_MEMORY_LIMIT und WP_MAX_MEMORY_LIMIT. Wer nur eine Ebene ändert, wundert sich oft, warum nichts passiert. Diese Anleitung erklärt, wie beide Ebenen zusammenspielen, wo Sie den aktuellen Wert ablesen und auf welchem Weg Sie das Limit bei Ihrem Hosting tatsächlich anheben. Alle Kombinationen haben wir in einer Testinstanz mit WordPress 7.1.2 und PHP 8.4 unter Apache nachgestellt.

Voraussetzungen

WordPress: eine aktuelle Version, getestet mit 7.1.2.
PHP: mindestens 7.4, wie von WordPress empfohlen; getestet mit PHP 8.4.
Zugriff: SFTP, FTP oder SSH auf das WordPress-Hauptverzeichnis, alternativ das Kundenmenü Ihres Hosters für die PHP-Einstellungen.
Rolle: Administrator im Backend, damit Sie den Website-Zustand aufrufen können.
Backup: eine Sicherung von wp-config.php und .htaccess. Ein Tippfehler in einer dieser Dateien legt die Website sofort lahm.
Arbeitsspeicher des Servers: Auf einem eigenen Server bestimmt der freie RAM, wie weit Sie gehen können. Das Limit gilt pro PHP-Prozess; 10 gleichzeitige Prozesse mit je 256 MB können bis zu 2,5 GB belegen.

Schritt 1: Zusammenspiel der drei Werte verstehen

Laut PHP-Handbuch legt memory_limit fest, wie viel Speicher ein einzelnes Skript höchstens belegen darf; der Wert -1 bedeutet ohne Grenze. WordPress setzt darauf auf. Aus dem Quelltext von wp-includes/default-constants.php ergibt sich folgendes Verhalten:

Wert	Standard	Wirkung
`memory_limit` (PHP)	vom Hoster	harte Obergrenze pro Aufruf
`WP_MEMORY_LIMIT`	40M (Multisite 64M)	Ziel für Frontend und normale Aufrufe
`WP_MAX_MEMORY_LIMIT`	256M	Ziel im Backend, bei Bildbearbeitung und Cron

Entscheidend ist die Regel: WordPress hebt memory_limit per ini_set() nur an, wenn der Konstantenwert höher ist als der aktuelle PHP-Wert. Senken kann WP_MEMORY_LIMIT das Limit nicht. Das Handbuch zur wp-config.php formuliert es so: Hat PHP bereits 64 MB, ist ein Eintrag von 64M überflüssig. In unserem Test mit PHP-Standard 128M blieb es bei WP_MEMORY_LIMIT 40M und 64M jeweils bei memory_limit=128M.

Im Backend ruft WordPress zusätzlich wp_raise_memory_limit( 'admin' ) auf und hebt das Limit auf WP_MAX_MEMORY_LIMIT an. Deshalb laufen Aktionen im Backend oft noch, während dieselbe Last im Frontend scheitert.

Verbietet der Hoster das Ändern von memory_limit zur Laufzeit, übernimmt WordPress den PHP-Wert für beide Konstanten und ändert nichts. Dann hilft nur ein Weg aus Schritt 4.

Verifizieren: Sie können für Ihre Fehlermeldung sagen, ob sie im Frontend (gilt WP_MEMORY_LIMIT) oder im Backend (gilt WP_MAX_MEMORY_LIMIT) auftritt.

Schritt 2: Aktuelle Werte ablesen

Öffnen Sie Werkzeuge > Website-Zustand und dort den Reiter Bericht. Klappen Sie den Abschnitt Server auf. In unserer Testinstanz standen dort nach der Änderung aus Schritt 3:

PHP-Arbeitsspeichergrenze (memory_limit)                    256M
PHP-Arbeitsspeichergrenze (nur für die Administration)      512M

Die zweite Zeile erscheint nur, wenn sich der Wert im Backend vom normalen Wert unterscheidet. Im Abschnitt WordPress-Konstanten finden Sie WP_MEMORY_LIMIT und WP_MAX_MEMORY_LIMIT.

Mit SSH und WP-CLI lesen Sie die Konstanten so aus:

wp eval 'echo WP_MEMORY_LIMIT, " ", WP_MAX_MEMORY_LIMIT, "\n";'

Den PHP-Wert fragen Sie über WP-CLI nicht zuverlässig ab: Die Kommandozeile nutzt oft eine eigene Konfiguration. In unserem Test meldete ini_get( 'memory_limit' ) über WP-CLI -1, der Webserver dagegen 128M. Maßgeblich ist der Wert im Website-Zustand.

Die Fehlermeldung selbst nennt die Grenze in Byte. 268435456 Byte sind 256 MB, 134217728 Byte sind 128 MB. So sehen Sie, welches Limit gegriffen hat. Wie Sie das Fehlerprotokoll aktivieren und lesen, zeigt die Anleitung WordPress Debug-Modus aktivieren und Error-Logs analysieren.

Verifizieren: Sie haben den aktuellen Wert von memory_limit und beiden Konstanten notiert.

Schritt 3: WP_MEMORY_LIMIT in der wp-config.php setzen

Das ist der erste Weg, weil er nur WordPress betrifft und keine Serverkonfiguration braucht. Sichern Sie die wp-config.php, öffnen Sie sie und fügen Sie oberhalb der Zeile /* That's all, stop editing! Happy publishing. */ ein:

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' ); // optional, nur wenn das Backend mehr braucht

Mit WP-CLI geht es ohne Editor; der Befehl setzt die Konstante an die richtige Stelle:

wp config set WP_MEMORY_LIMIT 256M

Die Position zählt: Nach der Zeile mit wp-settings.php hat WordPress seine Standardwerte schon gesetzt, und Ihre Konstante wirkt nicht mehr. Nehmen Sie keine Werte „auf Vorrat“. Erhöhen Sie nur so weit, wie die Fehlermeldung es belegt.

In unserem Test lieferte ein Prüfskript nach dem Eintrag WP_MEMORY_LIMIT=256M memory_limit=256M. Ein Skript, das absichtlich Speicher füllte, brach danach mit dieser Meldung im Serverprotokoll ab:

PHP Fatal error:  Allowed memory size of 268435456 bytes exhausted (tried to allocate 1052672 bytes)

Verifizieren: Im Bericht des Website-Zustands zeigt „PHP-Arbeitsspeichergrenze (memory_limit)“ den neuen Wert. Bleibt der alte Wert stehen, lässt Ihr Hoster keine Änderung zur Laufzeit zu oder memory_limit liegt schon höher. Weiter mit Schritt 4.

Schritt 4: memory_limit direkt beim Server anheben

Liegt die Obergrenze beim Hoster, ändern Sie memory_limit selbst. Welcher Weg funktioniert, hängt davon ab, wie PHP bei Ihnen läuft. Den Typ zeigt der Bericht im Abschnitt Server in der Zeile „PHP-SAPI“: apache2handler steht für mod_php, fpm-fcgi für PHP-FPM.

Kundenmenü des Hosters: Viele Hoster bieten PHP-Einstellungen im Kundenmenü an. Das ist der sauberste Weg, weil er auch Updates überlebt.
.user.ini im WordPress-Verzeichnis: Laut PHP-Handbuch liest PHP diese Datei nur unter CGI/FastCGI, also typisch bei PHP-FPM. Inhalt: memory_limit = 256M. Änderungen greifen erst nach Ablauf von user_ini.cache_ttl, standardmäßig 300 Sekunden.
.htaccess: nur bei Apache mit PHP als Modul (mod_php). Zeile oberhalb von # BEGIN WordPress: php_value memory_limit 256M.
Eigener Server: eine eigene INI-Datei im Konfigurationsverzeichnis von PHP, danach Webserver oder PHP-FPM neu laden.

; .user.ini (PHP-FPM / CGI)
memory_limit = 256M

# .htaccess (nur Apache mit mod_php), oberhalb von # BEGIN WordPress
php_value memory_limit 256M

In der Testinstanz (Apache mit mod_php) wirkten die Wege unterschiedlich: Eine Zeile php_value memory_limit 64M in der .htaccess setzte das Limit auf 64M. Eine .user.ini mit 512M blieb ohne Wirkung, wie im Handbuch beschrieben. Eine eigene INI-Datei im Verzeichnis conf.d setzte nach Neuladen von Apache 512M; WordPress übernahm diesen Wert auch als WP_MAX_MEMORY_LIMIT, weil er über 256M lag.

Ein Sonderfall zeigte sich ebenfalls: Mit .htaccess-Wert 64M und WP_MEMORY_LIMIT 256M in der wp-config.php lief WordPress mit 256M. Ein Wert per php_value lässt sich also zur Laufzeit überschreiben. Hoster, die ein Limit festschreiben wollen, nutzen dafür andere Mittel.

Verifizieren: Der Website-Zustand zeigt den neuen Wert. Nach einer Änderung an der .htaccess laden Sie die Startseite und das Backend: Beide müssen ohne Fehler 500 erscheinen.

Schritt 5: Ursache prüfen statt Limit immer weiter erhöhen

Das Handbuch zur wp-config.php warnt ausdrücklich: Ein höheres Limit kann die eigentliche Ursache verdecken, bis sie mit dem nächsten Plugin wieder auftritt. Tritt der Fehler trotz 256M erneut auf, prüfen Sie die Datei und Zeile in der Fehlermeldung. Liegt sie in einem bestimmten Plugin, testen Sie in einer Kopie der Website ohne dieses Plugin. Wie Sie eine solche Kopie anlegen, zeigt WordPress-Staging-Umgebung mit WP-CLI einrichten. Typische Auslöser sind Importe großer Dateien, Bildbearbeitung sehr großer Fotos und Berichte, die alle Bestellungen oder Beiträge auf einmal laden.

Speicherfehler kommen häufig nach Updates von Plugins oder PHP. Wer Updates und die Kontrolle danach nicht selbst übernehmen möchte, kann sie abgeben: Die WordPress-Wartung von wordpressupdate.de spielt Updates von WordPress, Plugins und Themes innerhalb von 48 Stunden mit Kompatibilitätsprüfung ein und sichert die Website wöchentlich auf externen Speicher.

Verifizieren: Die Aktion, die vorher scheiterte, läuft durch, und im Fehlerprotokoll erscheint keine neue Zeile „Allowed memory size“.

Typische Fehler

Konstante unter „stop editing“ eingetragen: WordPress hat seine Werte dann schon gesetzt, der Eintrag bleibt wirkungslos.
Wert ohne Einheit: 256 statt 256M bedeutet 256 Byte. Schreiben Sie immer M oder G dahinter.
Fehler 500 nach Änderung der .htaccess: Läuft PHP als FPM, versteht Apache php_value nicht. Im Test führte bereits php_admin_value in der .htaccess zu HTTP 500 mit dem Protokolleintrag /var/www/html/.htaccess: php_admin_value not allowed here. Entfernen Sie die Zeile per SFTP und nutzen Sie .user.ini.
.user.ini ohne Wirkung: Entweder läuft PHP als Apache-Modul (dann .htaccess) oder der Cache von 300 Sekunden ist noch nicht abgelaufen.
WP_MEMORY_LIMIT kleiner als das PHP-Limit: Senkt nichts. Im Test blieb es mit 64M bei 128M.
Limit auf -1 gesetzt: ohne Grenze. Ein fehlerhaftes Plugin kann dann den gesamten Arbeitsspeicher des Servers belegen. Nutzen Sie feste Werte.

Häufige Fragen

Welcher Wert ist sinnvoll?

Einen festen Wert nennt die WordPress-Dokumentation nicht. Starten Sie mit dem Wert, der den konkreten Fehler behebt, häufig 256M, und erhöhen Sie nur mit Begründung. Auf einem Server mit wenig RAM zählt, wie viele PHP-Prozesse gleichzeitig laufen.

Warum läuft es im Backend, aber nicht im Frontend?

Im Backend hebt WordPress das Limit auf WP_MAX_MEMORY_LIMIT an, standardmäßig 256M. Im Frontend gilt WP_MEMORY_LIMIT beziehungsweise der PHP-Wert.

Hilft ein Plugin zum Erhöhen des Speicherlimits?

Solche Plugins setzen dieselben Konstanten oder Einträge wie oben. Sie unterliegen denselben Grenzen des Hosters. Der direkte Eintrag ist nachvollziehbarer und braucht kein weiteres Plugin.

Testumfang

Getestet in einer Laborinstanz mit WordPress 7.1.2, PHP 8.4 und Apache mit mod_php: Standardwerte gelesen, WP_MEMORY_LIMIT und WP_MAX_MEMORY_LIMIT per wp config set gesetzt, Wirkung per Prüfskript und im Website-Zustand abgelesen, Speicherüberlauf provoziert, .htaccess mit php_value und php_admin_value, .user.ini und eigene INI-Datei verglichen. Nicht getestet: PHP-FPM, nginx, Kundenmenüs einzelner Hoster.

Fazit

Das Speicherlimit in WordPress hat zwei Ebenen. WP_MEMORY_LIMIT in der wp-config.php hebt an, was PHP zulässt; reicht das nicht, ändern Sie memory_limit über den Weg, der zu Ihrer PHP-Variante passt. Prüfen Sie jede Änderung im Website-Zustand und suchen Sie bei wiederkehrenden Fehlern die Ursache, statt das Limit weiter zu erhöhen. Wenn Sie Updates und die Kontrolle danach auslagern möchten, übernimmt das die WordPress-Wartung.

Weiterführende Anleitungen und Quellen

Quellen: