"Allowed Memory Size Exhausted" in WordPress beheben

Wenn deine Website Fatal error: Allowed memory size of 268435456 bytes exhausted anzeigt, füge diese Zeile in wp-config.php oberhalb des Kommentars /* That's all, stop editing! */ ein: define( 'WP_MEMORY_LIMIT', '256M' );. Damit sind die meisten Websites in unter einer Minute wieder online. Lies aber den Rest dieser Seite, bevor du dich zurücklehnst, denn das Speicherlimit anzuheben ist eine Diagnose, keine Heilung. Wenn der Absturz bei einer höheren Zahl wiederkommt, ist das eigentliche Problem Code, der unbegrenzt Speicher frisst — eine höhere Obergrenze gibt ihm nur mehr Spielraum.

Was der Fehler wirklich bedeutet

PHP verfolgt, wie viel Speicher jeder Request belegt. Sobald ein einzelner Request über das in php.ini gesetzte (oder von WordPress überschriebene) memory_limit hinaus Speicher anfordert, bricht PHP den Request sofort mit einem kritischen Fehler ab und gibt die Byte-Zahl aus, bei der er gescheitert ist. 268435456 bytes sind 256M. 134217728 sind 128M. 536870912 sind 512M. Die Zahl nach “tried to allocate” verrät dir die Größe des letzten Tropfens, nicht die Größe des Problems.

WordPress legt seine eigenen Limits über die von PHP. WP_MEMORY_LIMIT (Standard 40M, oder das PHP-Limit, falls höher) steuert das Frontend. WP_MAX_MEMORY_LIMIT (Standard 256M) steuert Vorgänge im Backend wie die Mediathek und Plugin-Updates, die zu Recht mehr benötigen. WordPress ruft beim Laden ini_set('memory_limit', ...) auf Basis dieser Konstanten auf — allerdings nur, wenn dein Hoster ini_set erlaubt, und nur bis zur harten Obergrenze, die dein Hoster festlegt. Genau dieser letzte Punkt ist der Grund, warum das Bearbeiten der wp-config.php manchmal scheinbar gar nichts bringt.

Der Reihe nach beheben

1. Das WordPress-Limit in wp-config.php anheben. Das probierst du zuerst, weil es reversibel ist und nichts anderes berührt.

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

Wenn du nicht sicher bist, wohin diese Zeilen gehören, oder gleich die anderen üblichen Konstanten korrekt gesetzt haben willst, schreibt dir unser wp-config-Generator einen sauberen Block zum Einfügen. Die Platzierung ist entscheidend — alles unterhalb der “stop editing”-Zeile wird ignoriert.

2. Wenn das nichts bringt, deckelt dein Hoster PHP. Hebe memory_limit auf PHP-Ebene an. In php.ini:

memory_limit = 256M

Bei vielen Shared-Hostern kannst du die php.ini nicht direkt bearbeiten. Versuche stattdessen eine .user.ini-Datei in deinem Web-Root, oder setze den Wert per .htaccess bei einem Apache/mod_php-Setup:

php_value memory_limit 256M

Beachte, dass php_value in der .htaccess bei nginx oder PHP-FPM-Setups einen 500er-Fehler auslöst, weil es eine Apache/mod_php-Direktive ist. Wenn du nach dem Hinzufügen einen 500er bekommst, ist das der Grund — entferne die Zeile und nutze .user.ini.

3. Prüfe den Wert, der tatsächlich aktiv ist. Vertraue nicht darauf, was du bearbeitet hast, sondern darauf, was PHP meldet. Lege eine einzeilige Datei in deinen Web-Root:

<?php echo ini_get('memory_limit');

Ruf sie im Browser auf, lies den Wert ab und lösche die Datei anschließend. Wenn dort immer noch 128M steht, obwohl du 256M gesetzt hast, überschreibt dein Hoster deine Einstellung, und du musst ihn kontaktieren oder die Einstellung im Control Panel deines Hosters nutzen.

Der Teil, den die meisten Anleitungen auslassen

Das Limit anzuheben ist Diagnose. So liest du das Ergebnis.

Wenn du 256M setzt und die Website bei normalem Traffic stabil bleibt, hattest du eine legitime Obergrenze, die zu niedrig war — verbreitet bei Websites mit großen Mediatheken, WooCommerce oder Page-Buildern. Dann bist du fertig.

Wenn du 256M setzt und es wieder abstürzt, dann 512M und es wieder abstürzt, hör auf, das Limit weiter anzuheben. Ein normaler WordPress-Request braucht keine 512M. Wenn der Speicherverbrauch ohne Obergrenze immer weiter klettert, läuft irgendwo etwas in einer Schleife oder häuft sich an: ein Plugin, das eine ganze Datenbanktabelle in ein Array lädt, ein add_action, das sich rekursiv selbst auslöst, eine Import-Routine, die jede Zeile gleichzeitig im Speicher hält, oder zwei Plugins, die sich im selben Hook in die Quere kommen. Das Limit anzuheben behebt keine unbegrenzte Schleife — es verschiebt den Absturz nur um ein paar Sekunden und macht ihn schwerer reproduzierbar.

Um den Übeltäter zu finden, deaktiviere alle Plugins und wechsle zu einem Standard-Theme wie Twenty Twenty-Four. Wenn der Fehler aufhört, aktiviere die Plugins eines nach dem anderen, bis er wiederkommt. Schalte den Debug-Modus ein, um festzuhalten, wo es scheitert:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Die Fatal-Zeile in wp-content/debug.log nennt die Datei und die Zeilennummer, die den letzten Speicherblock angefordert hat. Das ist meist die Schleife selbst oder nur einen Funktionsaufruf davon entfernt.

Was du nicht tun solltest

Setze WP_MEMORY_LIMIT nicht auf -1 oder 1024M und vergiss es dann. Unbegrenzter Speicher behebt kein Leck; er lässt einen außer Kontrolle geratenen Request den gesamten Server auffressen, was jede andere Website auf derselben Maschine lahmlegen und dir einen Anruf von deinem Hoster einbringen kann. Eine Obergrenze ist eine Sicherheitsfunktion. Behalte eine.

Füge ini_set('memory_limit', '512M') nicht als primäre Lösung in die functions.php ein. Bei manchen Fehlern läuft das zu spät — wenn der Absturz während des Ladens des WordPress-Cores passiert, bevor die functions.php deines Themes ausgeführt wird, läuft die Zeile nie. Die wp-config.php lädt früher und ist der richtige Ort.

Geh nicht davon aus, dass es ein Hosting-Problem ist, und rüste deinen Tarif nicht einfach auf. Manchmal ist das Hosting tatsächlich zu klein dimensioniert. Oft folgt dir aber genau derselbe Absturz in den größeren Tarif, weil die Ursache in deinen Plugins mitgereist ist. Schließe zuerst die Schleife aus; das kostet nichts.

Hebe nicht das memory_limit an, um einen max_execution_time-Fehler zu beheben. Das sind unterschiedliche Limits mit unterschiedlichen Meldungen. Speichererschöpfung meldet “Allowed memory size … exhausted.” Ein Timeout meldet “Maximum execution time … exceeded.” Das falsche Limit anzuheben kostet dich einen ganzen Nachmittag.

Kommst du trotzdem nicht weiter?

Wenn du bestätigt hast, dass das aktive Limit wirklich 256M oder höher ist, mit allen Plugins deaktiviert und einem Standard-Theme getestet hast und der Speicher trotzdem erschöpft wird, hast du ein echtes Leck, das du im debug.log verfolgen solltest, statt eine Obergrenze, die es anzuheben lohnt. Halte die Fatal-Zeile fest, notiere dir, in welches Plugin-Verzeichnis sie verweist — das ist dein Fehlerbericht. Bring zuerst deine grundlegenden wp-config.php-Konstanten mit dem wp-config-Generator in Ordnung, damit du sicher bist, dass die Limits dort gesetzt sind, wo du es glaubst — und dann lies das Log.