The message is long and looks alarming, but it is one of the more honest errors WordPress gives you. It usually reads something like this:
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in /home/user/public_html/wp-content/plugins/some-plugin/includes/file.php on line 512
On newer WordPress installs you may not see that text at all. Visitors get “There has been a critical error on this website”, and the full line ends up in the error log or in the recovery mode email sent to the admin address. Either way, the meaning is the same: PHP hit its memory ceiling partway through building the page, and the server stopped it there.
Reading the message properly
Most people skip straight to “raise the memory limit”. The message holds more than that, so read it in three parts.
- “Allowed memory size of … bytes”. This is the ceiling PHP was working under. 134217728 bytes is 128M; 268435456 is 256M; 67108864 is 64M. Dividing by 1,048,576 gives you megabytes.
- “tried to allocate … bytes”. This is the small extra amount that tipped it over. It is almost always tiny, which is the point: the process had already used everything else.
- “in /path/to/file.php on line …”. This is where it happened to be when memory ran out. It is a strong clue, but not proof. A plugin can fill memory and a different file, sometimes core, can be the one that asks for the last few bytes.
If the path runs through wp-content/plugins/ and names the same plugin every time, that plugin is your prime suspect. If the path changes each time, or points into wp-includes, the load is more general and the ceiling itself may simply be too low for what the site does.
Why it happens
A single heavy task
The most common pattern is an error that appears only during one action: importing products, running a backup plugin, regenerating thumbnails, exporting orders, building an XML sitemap, or uploading a large image. These jobs load a lot into memory at once. Image processing in particular uses far more memory than the file size suggests, because the image is decoded to raw pixels before resizing.
A plugin with a leak or a bad loop
Sometimes a plugin, often right after an update, gets stuck loading the same data repeatedly, or loads every post on the site into memory to do something simple. No sensible limit will satisfy it. Raising the ceiling just delays the crash.
Too much autoloaded data
WordPress loads every option marked “autoload” on every single request. Plugins that store large amounts of data there, or leftovers from plugins you deleted long ago, can make each page load heavier before any of your content is touched. Our post on cleaning up and optimising the WordPress database covers how that data piles up.
A low default on the hosting plan
Some shared hosting plans set PHP’s memory_limit low. A brochure site might be fine with it; a WooCommerce store with a page builder, a multilingual plugin and a few marketing integrations often is not.
How the memory settings fit together
This is where most confusion comes from, so it is worth being precise. There are two separate layers.
PHP’s own limit (memory_limit) is set by the server: in php.ini, in the hosting control panel, or by the host’s configuration. It is the real ceiling.
WordPress’s constants, set in wp-config.php, ask PHP for a particular amount:
WP_MEMORY_LIMITapplies to normal requests, including the public site. If you don’t set it, WordPress uses 40M on a single site (64M on multisite), but it never lowers a higher limit the server already provides.WP_MAX_MEMORY_LIMITapplies to admin screens and certain heavy tasks such as image editing. By default it is 256M, or the server’s own limit if that is higher.
WordPress can only raise memory to a level the server allows it to change to. If the host has locked memory_limit or caps it at a certain value, putting a larger number in wp-config.php does nothing. That is the reason people “increase the memory” and see no change at all.
You can see the current values without touching any file. Go to Tools → Site Health → Info. The Server section shows the PHP memory limit, and the WordPress Constants section shows WP_MEMORY_LIMIT and WP_MAX_MEMORY_LIMIT. Note those three values before you change anything.
Fixing it, in a sensible order
Download a copy of wp-config.php before you edit it, and make sure you have a recent full backup you know how to restore. A missing semicolon in that file takes the whole site down, so the copy is your undo button.
1. Get back in if you are locked out
If the error appears on every page, check the admin email for WordPress’s recovery mode message. It contains a special link that logs you in with the faulty plugin or theme paused, so you can deactivate it from the dashboard. If there’s no email, rename the plugin’s folder named in the error path (inside wp-content/plugins/) using your host’s file manager. That deactivates it and usually brings the site back.
2. Note exactly when it happens
Every page, only the admin, only one action, or only at a certain time of day? An error that appears at 2 a.m. points at a scheduled backup or import. One that appears when you click “Update” on a product points at whatever runs on save.
3. Raise the WordPress limit modestly
If the ceiling is genuinely low for the site, add or adjust this line in wp-config.php, above the “That’s all, stop editing!” comment:
define( 'WP_MEMORY_LIMIT', '256M' );
If the error is admin-only, you can also set WP_MAX_MEMORY_LIMIT higher. Then reload Site Health and check that the number actually changed. If it didn’t, the server is overriding it.
4. Ask the host to raise PHP’s limit
When WordPress cannot raise the value itself, the host can, or the hosting panel may have a PHP settings screen where you choose memory_limit. Some hosts allow a php_value memory_limit line in .htaccess or a .user.ini file, but this depends entirely on how PHP is run on that server, and a wrong line in .htaccess can cause a 500 error. Ask the host which method they support before guessing.
5. Find what is eating the memory
If the error comes back even at a generous limit, the limit is not the problem. Turn on logging so you can see the pattern over several occurrences. Our guide to switching on WordPress debug mode safely shows the three lines to use, and the companion post on reading debug.log and the server error log explains what to look for. The free Query Monitor plugin also shows peak memory use for each page load in the admin bar, which helps you compare pages with and without a particular plugin active.
6. Test plugins on a copy
Disable plugins one at a time, ideally on a staging copy, and repeat the action that triggers the error. When it stops, you have found the plugin. The fix is then to update it, report it to its developer, replace it, or change how it runs (for example, a smaller batch size in an import tool).
7. Clean up heavy data
Large autoloaded options, huge revision tables and old transients all add weight. Removing them is database work, so it needs a backup first and some care about what each entry belongs to.
What not to do
- Don’t set memory to an enormous value “just in case”. On shared hosting it can simply move the problem to the host’s process limits, and it hides a plugin that is misbehaving.
- Don’t copy random snippets into
.htaccess. Directives that the server doesn’t understand produce a different, worse error. - Don’t keep re-running the import or backup that crashed. Each failed run can leave half-finished data behind.
Preventing a repeat
Keep the plugin list lean, and remove the ones you no longer use rather than just deactivating them. Schedule heavy jobs like backups and imports for quiet hours, and give them sensible batch sizes. Watch the PHP memory value in Site Health after you change hosting plans or PHP versions, because a new plan can come with a lower default than the old one. When a site has outgrown its plan, moving to a better one is often cheaper than fighting the limit every month.
If memory errors keep returning after updates, they are usually part of a wider pattern; why a WordPress site keeps breaking looks at that bigger picture. Memory errors also sit in a family with other fatal errors, and our WordPress errors and fixes guide shows how they relate.
When to get help
Raising a limit is a five-minute job. Working out why a site needs three times the memory it needed last month is not, and on a live store you may not want to test plugins one by one in front of customers. If the error came with WordPress’s “critical error” screen and you can’t get past it, our critical error fix service is the right starting point. Send us the full error line from the log or the recovery email, and we’ll tell you plainly whether it’s a limit, a plugin or the plan.
Next in this series: WordPress “Sorry, You Are Not Allowed” Error Fixed
