WordPress Memory Limit erhöhen: Symptome erkennen und richtig setzen

Wenn WordPress mitten in einer Aufgabe abbricht, beim Bildupload, beim Plugin-Update oder einfach beim Aufruf einer Seite, steckt überraschend oft dasselbe dahinter: Der zugewiesene Arbeitsspeicher reicht nicht. Die gute Nachricht: Das Limit lässt sich in den meisten Fällen in zwei Minuten erhöhen. Die ehrliche Nachricht: Manchmal ist ein zu niedriges Limit nur das Symptom, nicht die Ursache. Beides klären wir hier.

Woran du ein zu niedriges Memory Limit erkennst

Das deutlichste Signal ist eine konkrete Fehlermeldung, im Frontend, im Backend oder in der Logdatei:

Fatal error: Allowed memory size of 134217728 bytes exhausted
(tried to allocate 20480 bytes) in /wp-includes/...

Oft siehst du diese Meldung aber gar nicht, weil WP_DEBUG aus ist. Dann äußert sich dasselbe Problem als Verhalten:

• Weißer Bildschirm (White Screen of Death), häufig nur auf bestimmten Seiten, etwa in der Mediathek, im Page-Builder oder auf rechenintensiven WooCommerce-Seiten. Wie du dem allgemein auf den Grund gehst, steht im Artikel zum White Screen of Death.
• Abbrüche bei Updates oder Importen: Das Update läuft an und hängt, der Import großer Dateien bricht ohne Meldung ab.
• Backend zäh oder teilweise leer, während das Frontend normal lädt. Das Backend darf mehr Speicher nutzen, kippt also später. Wenn es trotzdem kippt, bist du knapp dran.
• Fatal Error beim Aktivieren eines speicherhungrigen Plugins. In neueren WordPress-Versionen erscheint dann oft die Meldung über einen kritischen Fehler, siehe Kritischer Fehler und Wiederherstellungsmodus.

Die Fehlermeldung lesen: Bytes in Megabyte umrechnen

Die Zahl in „Allowed memory size of … bytes exhausted“ ist das Limit, das gerade galt. Sie sagt nicht, wie viel Speicher du brauchst. PHP hat dieses Limit erreicht und das Skript beendet. Teile die Zahl durch 1.048.576 (1024 mal 1024), dann hast du Megabyte:

Das hilft bei der Diagnose, weil du daran siehst, welches Limit zugeschlagen hat. Steht in der Meldung 134217728, obwohl du 256M in die wp-config.php geschrieben hast, hat dein Wert nie gegriffen (dazu unten mehr). Steht dort 268435456, ist dein Limit angekommen, und der Prozess wollte trotzdem mehr.

Die Angabe „tried to allocate“ nennt nur die letzte Anforderung, an der PHP gescheitert ist, meist ein paar Kilobyte. Auch der Dateipfad dahinter zeigt dir lediglich, an welcher Stelle der Speicher ausging. Er muss nicht der Verursacher sein: Wenn ein Plugin schon 120 MB belegt hat, scheitert eben die nächste harmlose Funktion im Core. Aus dem Pfad allein darfst du also kein Plugin verurteilen.

Wie viel Arbeitsspeicher WordPress wirklich braucht

WordPress bringt eigene Standardwerte mit. Laut WordPress-Quellcode (wp-includes/default-constants.php) sieht das so aus:

• WP_MEMORY_LIMIT – Standard 40 MB (Single-Site) bzw. 64 MB (Multisite). Das ist der Wert für normale Seitenaufrufe im Frontend.
• WP_MAX_MEMORY_LIMIT – Standard 256 MB, oder das PHP-Limit des Servers, falls das höher ist. Diesen Wert zieht WordPress im Backend heran, etwa für Updates, und bei der Bildverarbeitung. Seit WordPress 6.3 gilt er auch für WP-Cron-Aufgaben.

Wichtig ist, wie diese Werte mit dem PHP-Limit zusammenspielen. WordPress hebt das Limit per ini_set nur an, wenn der eigene Wert höher ist als das, was PHP schon hat. Gesenkt wird nie. Hat dein Server also memory_limit = 128M (das ist laut PHP-Handbuch der Standardwert) und WordPress hat 40M als Default, dann arbeitet dein Frontend faktisch mit 128 MB. Die 40 MB sind dann ein Mindestwert, kein Deckel. Erlaubt der Hoster ini_set für memory_limit nicht, übernimmt WordPress einfach den Serverwert, und deine Konstanten bleiben wirkungslos.

40 MB wären für eine moderne Installation mit Theme, einigen Plugins und WooCommerce zu wenig. Ein realistischer Richtwert:

• 256 MB als solide Basis für die meisten Seiten.
• 512 MB für WooCommerce-Shops, Page-Builder oder Seiten mit vielen aktiven Plugins.

WP_MEMORY_LIMIT oder WP_MAX_MEMORY_LIMIT?

Kurz gesagt: Setze WP_MEMORY_LIMIT für alles, was Besucher auslöst, und WP_MAX_MEMORY_LIMIT für das, was nur Administratoren oder interne Prozesse auslösen. In der wp-config.php sieht das so aus:

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

Warum zwei Werte? Ein Seitenaufruf im Frontend läuft parallel zu vielen anderen. Sitzen viele Besucher gleichzeitig auf der Seite, summiert sich der Verbrauch aller PHP-Prozesse. Das Backend ist selten von vielen Personen gleichzeitig belegt, darf also großzügiger sein. Auf Multisite-Installationen gilt der niedrigere Standard von 64 MB für WP_MEMORY_LIMIT, der Rest funktioniert gleich.

Setzt du nur WP_MEMORY_LIMIT auf einen Wert über 256 MB, übernimmt WordPress diesen Wert auch für WP_MAX_MEMORY_LIMIT, sofern du das nicht selbst definierst. Willst du im Backend mehr als im Frontend, setzt du beide Konstanten.

Erst messen: Wie hoch ist dein Limit gerade?

Bevor du etwas änderst, schau nach dem Ist-Wert. In WordPress: Werkzeuge → Website-Zustand → Bericht → Server. Dort steht der aktuelle PHP-Memory-Limit-Wert. Weichen Frontend- und Backend-Wert voneinander ab, zeigt WordPress zwei Zeilen an, eine davon gilt nur für die Admin-Bildschirme. Unter WordPress-Konstanten in demselben Tab findest du außerdem, was WP_MEMORY_LIMIT und WP_MAX_MEMORY_LIMIT aktuell sind. So weißt du hinterher auch, ob deine Änderung tatsächlich gegriffen hat.

Das Limit erhöhen: die vier Wege

Welcher Weg funktioniert, hängt von deinem Hosting ab. Geh die Reihenfolge von oben nach unten durch: wp-config.php klappt fast überall, der Rest ist für speziellere Setups. Stell deinen Wert ein, kopier das passende Snippet:

Auch als eigenständige Seite mit allen Anleitungen: PHP-Limits-Generator.

Kurz zur Einordnung der vier Dateien:

1. wp-config.php – der erste Versuch. Liegt im Hauptverzeichnis deiner Installation. Die Zeile(n) kommen vor den Kommentar „That’s all, stop editing!“. Hier kannst du als Einziges Frontend- und Backend-Limit getrennt setzen. Das Ganze funktioniert aber nur, wenn der Server ini_set für das Memory Limit zulässt.
2. php.ini – wenn du den Server selbst kontrollierst (eigener Server/VPS). Wirkt global, nicht nur für WordPress. Die Direktive heißt memory_limit. Danach braucht PHP bzw. der Webserver einen Neustart.
3. .htaccess – nur bei Apache mit mod_php. Laut PHP-Handbuch führt php_value in der .htaccess bei einem Server mit CGI/FastCGI zu einem 500er. Läuft dein Server unter PHP-FPM oder FastCGI, nimm stattdessen die .user.ini.
4. .user.ini – für PHP-FPM/FastCGI/CGI. Liegt ebenfalls im Hauptverzeichnis. PHP liest diese Dateien nur alle user_ini.cache_ttl Sekunden neu ein, der Standard sind 300 Sekunden. Warte also bis zu fünf Minuten, bevor du dich wunderst.

Viele Hoster bieten außerdem im Kundenpanel eine PHP-Einstellung an (je nach Anbieter heißt sie PHP-Optionen oder PHP-Konfiguration). Dort ein höheres memory_limit zu wählen ist oft der sauberste Weg, weil der Hoster die Einstellung in seine eigene Konfiguration übernimmt. Wenn du ohnehin ins Panel schaust, probier es dort zuerst, bevor du Dateien bearbeitest.

Nach der Änderung lädst du die Seite neu und prüfst den Wert noch einmal im Website-Zustand.

Es greift trotzdem nicht? Dann kappt dein Hoster

Alles, was WordPress selbst setzt, kann das PHP-Limit nur anheben, solange dein Hoster Spielraum lässt. Hat der Server ein hartes Limit gesetzt, das niedriger liegt als dein Wunschwert, gewinnt der Server, egal, was in der wp-config.php steht.

Wenn keiner der vier Wege etwas ändert:

• Prüfe im Website-Zustand, ob der Wert sich überhaupt bewegt hat. Bleibt die Zahl im Bericht gleich, kommt dein Wert nicht an.
• Schau in die Fehlermeldung. Taucht weiter die alte Byte-Zahl auf, ist es dasselbe Limit wie vorher.
• Frag deinen Hoster nach dem maximal erlaubten memory_limit. Bei vielen Shared-Hosting-Tarifen ist bei 128 oder 256 MB Schluss.
• Im Zweifel ist es eine Tarif-Frage, keine Konfigurationsfrage.

Welcher Wert ist sinnvoll, und warum „einfach 1G“ eine schlechte Idee ist

Die häufigste Abkürzung lautet: Wenn 256 MB nicht reichen, setze ich 1G oder gleich -1 (unbegrenzt). Das funktioniert, behebt aber nichts. Laut PHP-Handbuch ist das Limit dafür da, schlecht geschriebene Skripte daran zu hindern, den gesamten Speicher des Servers aufzufressen. Genau diese Schutzfunktion schaltest du damit ab.

Drei Gründe, es nicht zu tun:

• Das Problem wird größer, nicht kleiner. Ein Plugin mit einem Speicherleck verbraucht dann eben 900 statt 250 MB, bevor es abbricht, und bremst in der Zwischenzeit den ganzen Server.
• Mehrere Prozesse laufen parallel. Wenn jeder Seitenaufruf großzügig Speicher ziehen darf, summiert sich das bei vielen gleichzeitigen Besuchern. Der Server hat insgesamt nur begrenzt Arbeitsspeicher.
• Du verlierst das Warnsignal. Ein Fehler bei 256 MB zeigt dir ein Problem, das du lösen kannst. Bei 1 GB fällt dasselbe Problem erst viel später auf.

Meine Faustregel: Starte bei 256 MB. Gehe auf 512 MB, wenn ein konkreter, wiederholbarer Vorgang scheitert (ein Import, ein Page-Builder-Aufruf, ein großer Shop-Export) und du den Verbrauch gemessen hast. Alles darüber braucht einen Grund, den du benennen kannst.

Ursache statt Symptom: Was frisst den Speicher?

Ein höheres Limit ist die richtige Antwort, wenn deine Seite schlicht gewachsen ist. Es ist die falsche Antwort, wenn ein einzelnes Plugin oder eine entgleiste Datenbankabfrage den Speicher auffrisst. Anzeichen dafür: Der Bedarf steigt immer weiter, du musst das Limit regelmäßig nachschrauben, oder der Fehler tritt reproduzierbar bei einer bestimmten Aktion auf.

So gehst du vor:

1. Verbrauch messen. Das Plugin Query Monitor zeigt im Admin-Toolbar-Menü eine Übersicht der aktuellen Seite. Dazu zählt der Spitzenverbrauch an Speicher im Verhältnis zum PHP-Limit (laut Quellcode des Plugins auf Basis von memory_get_peak_usage). Ruf damit die Seite oder Aktion auf, die scheitert. Liegt der Peak bei 90 Prozent vom Limit, ist die Aktion tatsächlich speicherhungrig. Liegt er bei 30 Prozent und der Fehler tritt trotzdem auf, stimmt etwas anderes nicht.
2. Fehler protokollieren. Mit WP_DEBUG und WP_DEBUG_LOG auf true schreibt WordPress Fehler nach wp-content/debug.log. Dort siehst du, wann und bei welcher Aktion der Fehler auftrat. Zeige Fehler dabei nicht Besuchern an (WP_DEBUG_DISPLAY auf false) und schalte das Debugging danach wieder ab.
3. Plugins bisektieren. Deaktiviere alle Plugins, dann aktiviere sie in Hälften wieder, bis der Fehler zurückkommt. Wenn dir das Backend dafür nicht mehr zugänglich ist, benenne den Ordner wp-content/plugins per FTP um. Bei Live-Seiten machst du das besser auf einer Staging-Kopie.
4. Theme prüfen. Ein Wechsel auf ein Standard-Theme zeigt, ob die Ursache dort liegt.

Wird der Speicher erst nach vielen Wochen knapp, obwohl nichts Neues dazukam, lohnt der Blick in die Datenbank: Sehr große Optionen-Tabellen mit geladenen Daten (autoload) können jeden Seitenaufruf aufblähen. Wie du sie findest, steht unter WordPress-Datenbank optimieren. Genau diese Abgrenzung, „mehr Speicher“ gegen „echte Ursache“, ist Teil dessen, was wir in der WordPress-Wartung übernehmen, statt das Limit immer weiter hochzudrehen. Eine Einordnung anderer Fehlerbilder liefert der Überblick zu WordPress-Fehlern.

Memory Limit, Max Execution Time und Upload-Limit auseinanderhalten

Diese drei Limits werden ständig verwechselt, weil sie alle in derselben Ecke der Konfiguration sitzen und alle in „WordPress bricht ab“ münden. Sie begrenzen aber unterschiedliche Dinge:

• Memory Limit (memory_limit): wie viel Arbeitsspeicher ein PHP-Prozess belegen darf. Fehler: „Allowed memory size … exhausted“.
• Max Execution Time (max_execution_time): wie lange ein Skript laufen darf. Fehler: „Maximum execution time exceeded“. Eine Anleitung dazu: Maximum execution time exceeded beheben.
• Upload-Limit (upload_max_filesize und post_max_size): wie groß eine hochgeladene Datei sein darf. Hier hilft WordPress Upload-Limit erhöhen.

Ein Beispiel für das Zusammenspiel: Du lädst ein großes Bild hoch, das Upload-Limit passt, aber die Bildverarbeitung (WordPress erzeugt mehrere Größen) braucht mehr Speicher, als PHP erlaubt. Ergebnis: Memory-Fehler, obwohl der Upload selbst durch war. Umgekehrt bringt ein höheres Memory Limit nichts, wenn die Datei schon am Upload-Limit scheitert. Lies deshalb die Fehlermeldung, bevor du am erstbesten Wert drehst.

Kommt deine Seite immer wieder ans Speicherlimit oder bricht an wechselnden Stellen ab, steckt selten der Wert dahinter, sondern ein konkreter Verursacher. Wenn du das nicht selbst eingrenzen willst: Schreib uns kurz – wir schauen uns an, was den Speicher zieht.