How to fix WordPress allowed memory size exhausted error (step by step)

Short answer

Running into Allowed memory size of X bytes exhausted (tried to allocate Y bytes) on WordPress means your site, or your admin dashboard, used up the memory limit PHP is allowed to use. It isn’t a crash and it doesn’t mean lost data.

PHP simply stops the script the moment it runs out of the memory it was given. The short version of how to fix WordPress allowed memory size exhausted error is this: raise the WP_MEMORY_LIMIT constant in wp-config.php first, and if the error persists, raise the server-side PHP memory limit from your hosting panel or php.ini.

For most sites, that’s a configuration change that takes under five minutes. If the error keeps coming back, the real cause is usually a single memory-hungry plugin or a badly written query, pushing the limit higher over and over just hides the thing that actually needs fixing.

Why does the “Allowed memory size” error happen?

PHP enforces a hard ceiling called memory_limit on every request it runs, precisely so one broken piece of code can’t eat all the memory on a shared server. WordPress core manages its own default on top of that: 40M on a single site, 64M on a multisite network. Those defaults aren’t a guess: they’re set directly in the project’s own source code.

A modern theme, a handful of popular plugins and a page builder running at once will often push past 40M without much effort. The error tends to show up specifically when:

• A plugin is bulk-resizing large images
• A WooCommerce or similar plugin is processing many orders or products at once
• A backup plugin tries to compress the entire site in one pass
• A buggy plugin has a memory leak or runs into an infinite loop
• The hosting plan started with a low server-side memory limit to begin with

What links all of these is that the error rarely appears out of nowhere. A small blog may never hit it; the same setup under a growing product catalog or real traffic can start throwing it without warning.

How to fix WordPress allowed memory size exhausted error

Deleting files at random before you understand what’s happening tends to make things worse. Diagnose first without changing anything, raise the memory limit next, and only then go hunting for whatever is actually consuming the memory.

Start by opening wp-config.php with FTP or your host’s file manager and adding the following lines (or flipping existing false values to true):

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

Keeping WP_DEBUG_DISPLAY set to false is deliberate: otherwise the raw error becomes visible to every visitor while the site is live.

What to look for in debug.log

Trigger the error again (reloading the same page is usually enough) and open wp-content/debug.log. The line you want typically starts with something like PHP Fatal error: Allowed memory size of 41943040 bytes exhausted. It often names the exact file that ran out of memory. If it does, you can skip straight to disabling that plugin instead of working through every step below.

Raise WP_MEMORY_LIMIT in wp-config.php

If debug.log doesn’t point at anything specific, or you just want the error gone quickly, raise WordPress’s own memory ceiling first. Add this line to wp-config.php, above the “stop editing” comment:

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

256M is a sensible starting point for most small and mid-sized sites. Save the change and reload the page that was failing. If the error stops there, you’re done. If the exact same message keeps appearing, a lower PHP limit on the server side is likely overriding it.

What is WP_MAX_MEMORY_LIMIT, the separate admin-side limit?

The admin dashboard usually needs more memory than the front end; plugin updates, the media library and dashboard widgets can all load at once. That’s why WordPress keeps a second, higher constant just for admin requests:

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

Don’t confuse the two: WP_MEMORY_LIMIT governs the site’s general runtime, while WP_MAX_MEMORY_LIMIT only kicks in inside wp-admin. If the error only shows up while updating a plugin or running an import, raising this second constant is the more targeted move.

Raising the server-side limit with php.ini or .htaccess

The value in wp-config.php can never exceed the server’s own PHP configuration. If the server caps memory at 128M, telling WordPress to use 256M changes nothing. If you have access, find memory_limit = 256M in php.ini and update it there. Without direct access, some shared hosts let you add the following line to the .htaccess file in your site’s root:

php_value memory_limit 256M

Whether that line actually works depends entirely on your host’s server configuration; some hosts block PHP settings from being changed through .htaccess at all. If it makes no difference, contacting support directly is the next step.

How do you find the plugin or theme eating memory?

Raising the limit makes the error stop showing, but it treats the symptom, not the cause. To find what’s actually consuming memory, the reliable method is still deactivating plugins one at a time: rename the wp-content/plugins folder temporarily, and WordPress treats every plugin as deactivated at once, so the site usually comes back.

Rename the folder back, then reactivate plugins one by one from the dashboard, checking the site after each one. Whichever plugin brings the error back is the one responsible: update it, swap it for a lighter alternative, or reach out to its developer directly. The same process is useful when you’re chasing other unexplained slowdowns; our guide to the WordPress white screen of death covers a closely related diagnosis routine.

When should you contact your hosting provider?

If none of the steps above fix it for good, the problem is almost certainly a fixed resource cap on a shared hosting plan. Give support the exact line from debug.log, the WP_MEMORY_LIMIT value you already tried, and a short list of the plugins your site runs. That context speeds up the fix considerably. On some plans, the memory ceiling is tied to the package tier, and the only real fix is moving to a higher one.

How this error relates to other WordPress errors

Memory exhaustion is a common hidden cause behind several other WordPress errors. The table below maps the connection.

Error	How memory plays a role	First check
500 Internal Server Error	Memory exhaustion sometimes surfaces as this generic error instead	debug.log and the server error log
White screen with no message at all	With WP_DEBUG_DISPLAY off, a memory error fails silently	Turn on WP_DEBUG_LOG and read debug.log
A plugin update times out	Updates often need a temporary spike in memory above normal	The WP_MAX_MEMORY_LIMIT value
Media uploads or bulk imports freeze	Processing large files can exhaust memory in one pass	File size and the plugin’s batch-processing settings

Every row in that table traces back to the same root cause: PHP couldn’t find the memory the request needed. That’s why checking the memory limit is worth doing early, even if the message you actually saw was something else. If you ran into the generic server error instead, our 500 Internal Server Error guide covers that specific case.

Avoiding it next time

The WordPress allowed memory size error is largely preventable. Keeping the plugin count limited to what’s genuinely in use, testing updates on a staging environment first, and matching your hosting plan to the site’s real traffic all meaningfully cut the odds of hitting it again. If the site runs a large product catalog, its memory needs will sit above average, so the hosting choice should reflect that from the start.

Next step

The practical answer to how to fix WordPress allowed memory size exhausted error is to raise the memory limit in the right order first, then track down and fix whichever plugin is actually consuming it. If the problem keeps coming back on the server side, or it’s a recurring sign the site has outgrown its hosting, a proper technical review saves more time than repeatedly bumping the limit. For businesses that want WordPress infrastructure planned around real capacity, our group company Web Tasarım Ofisi supports WordPress technical maintenance and infrastructure consulting.

To talk through your site’s technical setup or a custom software need, take a look at our custom software service or get in touch with Argo Ajans.