Skip to content

SiteRepairManual

WordPress repairs run on a throwaway install before they are written down.

Fix “Allowed memory size exhausted” in WordPress

Checked 10 November 2026 · WordPress 7.1.4 · PHP 8.3.6 · MariaDB 10.11.14 · WP-CLI · Read time: 6 minutes

Case file

Symptom
Critical error page, HTTP 500, and a fatal error naming a byte limit
Cause
One request needed more memory than the 40 MB WordPress default allows
Fix
Raise WP_MEMORY_LIMIT to 256M in wp-config.php
Result
The homepage returns HTTP 200 again

The break · What you need · The diagnosis · The fix · Verify · If that didn’t work · What happened · Where this came from

The break

PHP gives every WordPress request a fixed amount of memory. When a request needs more than that amount, PHP stops it with a fatal error and WordPress shows the critical error page instead of the site. The official list of common errors puts it plainly: an “Allowed memory size exhausted” error means the installation does not have enough memory to do what was asked, and the fix is to increase the memory limit in wp-config.php or in php.ini.

This guide reproduces the break first. A disposable install ran with PHP’s memory_limit at 32M, the kind of low ceiling a cheap host ships with, so WordPress raised it to its own 40M default. A test plugin then allocated 64 MB in one request. The homepage went from HTTP 200 to HTTP 500, and the log named the limit, the allocation, and the file.

What you need

The diagnosis

1. Confirm the symptom

Load the homepage and note the status code, not just what the browser shows. In the reproduction, the healthy site returned HTTP 200. With the memory-hungry plugin active it returned HTTP 500 with the critical error page:

Output — homepage with the memory-hungry plugin active

HTTP 500
<title>WordPress &rsaquo; Error</title>
There has been a critical error on this website.

Key result: HTTP 500 plus the critical error page is the modern form of this failure. The page itself names no limit — the numbers are in the log, which is the next step.

2. Read the fatal error in debug.log

Turn on WP_DEBUG and WP_DEBUG_LOG as described in the white screen guide, load the homepage once so the error is written, and read wp-content/debug.log:

Output — wp-content/debug.log

[10-Nov-2026 15:56:55 UTC] PHP Fatal error:  Allowed memory size of
41943040 bytes exhausted (tried to allocate 67112960 bytes) in
.../wp-content/plugins/srm-memory-hog/srm-memory-hog.php on line 8

41,943,040 bytes is 40 MB — WordPress’s default WP_MEMORY_LIMIT for a single site. The official wp-config.php documentation says the WP_MEMORY_LIMIT option sets the maximum amount of memory PHP may consume, and that it is the setting to change when this message appears. The file and line name where the limit happened to be hit, not necessarily the cause: a plugin that allocates 64 MB in one go is the cause here, but on a real site the file in the log is only the starting point for finding what is actually eating the memory.

Key result: the log gives the limit (40 MB), the size of the allocation that failed (about 64 MB), and the file and line. That is enough to fix it — the limit is too low for what the site is being asked to do.

The fix

3. Raise WP_MEMORY_LIMIT to 256M

Add this line to wp-config.php, before the line that reads /* That's all, stop editing! Happy blogging. */:

Code — wp-config.php

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

With WP-CLI, the same change is one command. Note the quotes — the value is a string, so there is no --raw flag:

Command — raise the limit with WP-CLI

wp config set WP_MEMORY_LIMIT '256M'

Trap: wp config set WP_MEMORY_LIMIT 256M --raw writes the value unquoted — define( 'WP_MEMORY_LIMIT', 256M ); — which is a PHP parse error, and the site stays at HTTP 500. The reproduction hit this exact mistake and the fix was to run the command again without --raw. Use --raw only for values that are not strings, such as true.

Verify the site is back

Load the homepage again and check the status code. In the reproduction the homepage returned HTTP 200 with the memory-hungry plugin still active, which proves the new limit — not the plugin being switched off — is what fixed it. The test plugin was deactivated afterwards and the homepage stayed at HTTP 200.

Output — homepage after raising the limit

HTTP 200
<title>SRM Test</title>
StepHomepage status
Healthy siteHTTP 200
Plugin allocates 64 MB, limit 40MHTTP 500 — critical error page
After WP_MEMORY_LIMIT 256MHTTP 200

If that didn’t work

Raise the PHP limit, not just the WordPress one

WordPress asks PHP for more memory with ini_set, but it cannot exceed PHP’s own memory_limit. If the host has PHP capped at 64M, setting WP_MEMORY_LIMIT to 256M changes nothing. Raise memory_limit in php.ini — the official common-errors guide lists this as the second step — or ask the host to raise it. On shared hosting you may have to ask the host either way.

Find what is eating the memory

Raising the limit is a valid immediate fix and a poor permanent one. A normal site renders a page in well under 128 MB. If the error comes back, the debug log names the file where the limit was hit; deactivate plugins one by one from there, and check the admin side separately — admin tasks such as image processing and imports use WP_MAX_MEMORY_LIMIT instead of WP_MEMORY_LIMIT, and the official documentation says to define that one for administration work.

What happened

One request needed 64 MB and the site only allowed 40 MB, so PHP stopped it with a fatal error and the homepage returned HTTP 500. The debug log gave the limit in bytes, WP_MEMORY_LIMIT was raised to 256M in wp-config.php, and the homepage returned HTTP 200 with the same plugin still active.

Where this came from