WordPress Showing “Allowed Memory Size Exhausted”? Here's What's Actually Wrong.

What is the problem?

“Fatal error: Allowed memory size of X bytes exhausted (tried to allocate Y bytes)” is PHP itself stopping a script the instant it crosses a memory ceiling — the memory_limit setting, applied per request. This isn't a WordPress bug or a corrupted file; it's PHP doing exactly what it's configured to do, which is refuse to let one script consume unlimited server RAM. WordPress asks for a reasonable amount of memory via its own WP_MEMORY_LIMIT and WP_MAX_MEMORY_LIMIT constants, but the host's own php.ini ceiling always wins if it's set lower than what WordPress requests.

Quick answer: this almost always comes down to one of three things — a plugin or theme doing something memory-heavy (an import, image processing, an unpaginated query), a hosting plan with a memory_limit set too low for a modern WordPress site, or a long-running task like a cron job that never releases the memory it's using.

Because this is a hard ceiling rather than a gradual slowdown, the failure is abrupt and total: whatever page or process was running stops instantly, right at the line of code that happened to be running when the limit was crossed. That's why the file and line number named in the error message aren't necessarily the actual cause — they're just wherever the ceiling was reached, often deep inside WordPress core or a library the real culprit called into.

Common symptoms

• The exact error text, naming a specific byte count — e.g. “Allowed memory size of 268435456 bytes exhausted (tried to allocate 20480 bytes)”
• It happens consistently doing one specific thing — always during an import, always on one plugin's admin screen, always when opening one particular large page
• Can also appear as a blank white page instead of the error text, if display_errors is switched off on your host — the fatal still happened, it's just not being shown
• Started, or got noticeably more frequent, right after installing a new plugin, updating a theme, or a genuine jump in content or traffic
• wp-admin actions — Import, bulk edit, a page builder rendering a heavy layout — trigger it more than ordinary front-end browsing does
• Uploading or processing a very large image is a common single trigger, since WordPress generates multiple resized copies of every upload

Why does this happen?

PHP's memory_limit exists to stop one runaway script from consuming all the RAM on a server and taking every other site on that machine down with it — a real concern on shared hosting, where dozens of sites run on the same box. WordPress sets its own preferred defaults (40MB for the front end, 256MB for wp-admin, via WP_MEMORY_LIMIT and WP_MAX_MEMORY_LIMIT) if nothing else defines them first, but it can only ever ask — it can raise the limit up to whatever the server's own php.ini allows, never past it.

This is also why the same site can run fine for months and then suddenly hit this error: nothing has to be newly “broken” for it to appear. A product catalog that grows, a report that processes more rows each month, or a page builder rendering an increasingly complex layout can all quietly push memory use upward until one ordinary request finally crosses a ceiling that was always there.

Common technical causes

• A plugin or theme loading a large dataset into memory at once — an export, import or report tool processing thousands of rows without chunking
• Image processing at full, uncompressed resolution — a large source image triggers WordPress's automatic generation of every registered thumbnail size in one request
• A poorly written custom query pulling an entire table instead of paginating results with a LIMIT clause
• A hosting plan with an unusually low memory_limit — some budget shared hosts cap it at 64MB or 128MB, well below what a modern page-builder or WooCommerce site typically needs
• WP_MEMORY_LIMIT being requested but not actually granted, because the host's own php.ini sets a lower ceiling that WordPress has no ability to override from wp-config.php
• A long-running WP-CLI command or cron job that keeps accumulating objects in memory across a large batch instead of releasing them as it goes
• An object cache (Redis or Memcached) misconfigured to cache oversized objects, inflating per-request memory use beyond what the underlying page actually needs

How to diagnose it

1. Note exactly what action triggers it, and whether it's consistent — a specific plugin screen, a specific import, or general browsing across the whole site.
2. Check your current memory_limit via Tools → Site Health → Info → Server in wp-admin, which shows the actual, host-enforced value in effect right now.
3. Compare that against WP_MEMORY_LIMIT and WP_MAX_MEMORY_LIMIT set in wp-config.php, to see whether WordPress is even asking for more than the host allows.
4. Isolate plugins by renaming wp-content/plugins via FTP to deactivate everything at once, confirming the action succeeds, then renaming plugin folders back one at a time to find the specific one responsible.
5. Check the error log's file and line reference — it won't always be the root cause, but it confirms which code path was actually executing when the ceiling was crossed.
6. Test with a default theme (Twenty Twenty-Five or similar) temporarily, to rule out theme-side memory use if a plugin isn't the obvious trigger.

How to fix it, step by step

1. Raise WP_MEMORY_LIMIT and WP_MAX_MEMORY_LIMIT in wp-config.php, near the top before the “That's all, stop editing!” line — for example define('WP_MEMORY_LIMIT', '256M'); and define('WP_MAX_MEMORY_LIMIT', '512M');.
2. If the host's php.ini ceiling is lower than that, wp-config.php alone won't help — raise memory_limit via your hosting panel's PHP settings, a .user.ini file, or by asking your host directly if you don't have file-level access.
3. If a specific plugin's import or export action is the trigger, look for a batch size or chunk size setting — lowering it means each request processes less data and needs less memory per run.
4. Optimize an oversized image before uploading it, rather than relying on WordPress's automatic resizing to compensate for a source file that's far larger than it needs to be.
5. If a custom query is the cause, add pagination or a LIMIT clause instead of pulling an entire table into memory at once.
6. Break a long-running WP-CLI or cron task into smaller batches instead of one continuous run that keeps accumulating memory.
7. Re-test the exact action that originally failed, watching the error log to confirm the fatal genuinely doesn't recur, not just that the page happens to load once.
8. Treat a raised limit as headroom, not a permanent fix, if the real cause is a wasteful plugin or query — the underlying inefficiency will resurface as the site grows unless it's actually addressed.

When this needs professional help

Raising WP_MEMORY_LIMIT is a two-minute edit once you know that's the right lever. It's worth bringing in a developer when:

• You've already raised WP_MEMORY_LIMIT and the error persists, meaning the host's own php.ini ceiling is the real block and you can't change it yourself
• The trigger is a core WordPress action rather than one specific plugin, pointing to a genuine hosting-resource mismatch for the site's actual size
• You don't want to just raise the limit and hope — you want the actual memory-hungry code path identified and fixed
• It's happening during something time-sensitive, like an import with a deadline or a migration, where repeated trial and error isn't a realistic option

How I can help

A memory-exhausted fatal is one of the more mechanical WordPress errors to diagnose properly, but that only helps if someone actually traces which code path is consuming the memory rather than treating a higher limit as the fix. Over eleven years of freelance WordPress work I've isolated this down to the specific plugin, query or import setting causing it more times than I can count — and raised limits where that genuinely is the right call, rather than leaving a site permanently running at a number well past what it should need.