WordPress Memory Exhausted Error: Raise the Limit

Your site dies with a chillingly specific message: Fatal error: Allowed memory size of 134217728 bytes exhausted. Sometimes it's a white screen backed by that line in the log; sometimes the message prints right on the page. Either way, WordPress is telling you it ran out of working memory halfway through building the page.

This error has a split personality. Often the fix is trivial — a limit set absurdly low for a modern site. But sometimes the limit is a smoke alarm for a real fire: a plugin leaking memory on every post, an autoloaded options table stuffed with megabytes of transients, or a hosting plan that simply can't feed your plugin stack.

This guide covers both personalities. You'll raise WP_MEMORY_LIMIT correctly, check the host ceiling that can silently override you, audit which plugins actually eat memory, and cut per-request usage with caching and autoload cleanup. You'll learn when to raise the number — and when to stop raising and start trimming. The byte figure in the error names your starting point; the steps below tell you which side of the problem you're on.

Read the Exhausted Error Like a Receipt

The message is more useful than it looks: Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes). The first number is the ceiling — 134217728 bytes equals 128M. The second is the straw that broke it, usually tiny. The ceiling tells you which limit to raise; the tiny allocation tells you the code wasn't doing anything crazy, it just ran out of room.

Check who set that ceiling. WordPress asks for WP_MEMORY_LIMIT, but PHP's memory_limit ini value is the hard cap — the lower of the two wins. If the message says 67108864 (64M), your site is running on a deeply outdated default. If it says 134217728 (128M) after you set 256M in wp-config.php, the host is overriding you.

Also note where it fires. Exhaustion on one admin import page points at that importer. Exhaustion on every front-end page points at a globally loaded plugin or autoload bloat. Exhaustion only on search or archive pages points at unbounded queries returning thousands of rows. The log line includes the file and line of the final allocation — that file is where the memory pressure peaked, though not always where it leaked. Record the ceiling figure and the firing URL together; the pair tells the next debugger whether the limit or the page changed.

Raise WP_MEMORY_LIMIT the Right Way

The standard fix is two constants in wp-config.php, placed above the stop-editing comment: WP_MEMORY_LIMIT for the front end and WP_MAX_MEMORY_LIMIT for wp-admin. 256M resolves the large majority of cases on modern stacks — builders, commerce, multilingual — without masking real leaks. Reload the failing page and confirm the error is gone under normal traffic.

Placement matters. Constants must be defined before WordPress boots, so burying them at the bottom of wp-config.php or inside a conditional that doesn't fire silently does nothing. Multisite owners note the front-end constant applies per site load while admin screens use the max constant — set both even if only the storefront errors today. After saving, verify with Site Health > Info > Server, which shows the effective WordPress memory limit. If it still shows the old number, your edit is in the wrong place or the host overrides it.

Don't escalate blindly. Jumping to 512M or 1G on shared hosting can get the account throttled, and it hides leaks that will eat any value. Raise once to 256M; if exhaustion returns at the new ceiling, switch to hunting the eater instead of feeding it. Screenshot the Site Health memory lines before and after; the pair proves the raise landed and dates the change.

// Raise the WordPress memory allowance (before "stop editing" line)
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '256M' );

// Verify under Tools > Site Health > Info > Server.
// If it still shows 128M, the host's PHP memory_limit is overriding you.

Check the Host PHP Ceiling That Overrides You

WordPress can only spend what PHP allows. The memory_limit in php.ini (or the host's panel) caps every request, and WP_MEMORY_LIMIT values above it are silently ignored. This is the number-one reason raises mysteriously fail on shared hosting: wp-config.php says 256M while PHP enforces 128M.

Find the real value in Tools > Site Health > Info > Server, which lists both the PHP memory limit and the WordPress limit side by side. If PHP shows 128M, your options are asking the host to raise it, switching to a plan with a higher allowance, or cutting usage to fit. Some hosts let you set memory_limit via .user.ini or the panel — try memory_limit = 256M there and re-check Site Health. Note .user.ini caches for several minutes, so wait before retesting or you'll condemn a fix that hasn't loaded yet. When the panel lacks a memory control, ask support for the exact ini scope — per-domain values beat global requests.

VPS owners edit php.ini directly and restart PHP-FPM, but match the change to real RAM — promising 1G per request on a 2G server means two concurrent requests can OOM the box. On any plan, the honest fix for a stack that needs 512M per page is trimming the stack, not renting a bigger box to feed it.

# What does PHP itself allow? (VPS / SSH)
php -i | grep -i memory_limit

# Or create a 10-second info page, check it, then DELETE it:
# <?php phpinfo();
# Look for memory_limit in Core settings.

# Shared hosts: try .user.ini in the WordPress root
# memory_limit = 256M

Audit Hungry Plugins With Query Monitor

When the ceiling is fine and memory still dies, something is eating. Query Monitor on staging shows per-page memory, slow queries, and the components behind them. Load the failing page, read the memory figure in the admin bar, then deactivate suspects one by one and re-measure. The delta per plugin is the evidence — no guessing.

Usual suspects have patterns. Page builders inflate memory on every page they touch, even via widgets. Multilingual plugins duplicate queries per language. Security scanners hook into every request. Backup and stats plugins run heavy jobs inside page loads instead of cron. Two plugins doing the same job (two sliders, two SEO packs) double the cost for zero benefit.

Judge by numbers, not reputation. A well-coded builder at 40MB is fine; a abandoned widget at 120MB is not. Snapshot the Query Monitor memory figure before and after each deactivation so deltas are comparable — eyeballing consecutive loads without notes invents patterns. Options for the eater: update it (leaks get fixed), restrict it to needed pages with a plugin organizer, replace it with a lighter alternative, or drop the feature. Record the before/after figures so the next person doesn't re-install the hog.

# Staging-only bisect: measure, deactivate, re-measure
wp plugin list --status=active --field=name
wp plugin deactivate suspect-slider
# reload the failing page, note Query Monitor memory
wp plugin deactivate old-stats-pack
# reload again — compare the deltas

# Back on production, remove only the proven eater
wp plugin deactivate proven-hog

Trim Autoloaded Options and Transients

Every WordPress request loads all autoload=yes options into memory before anything renders. Healthy sites keep this under 1MB; neglected ones carry 5–10MB of expired transients, abandoned plugin settings, and logged junk. That weight lands inside every single page load, pushing hungry pages over the edge.

Diagnose with two queries: sum the autoloaded size, then list the 20 biggest rows. Expired _transient_ rows from dead plugins are the classic find — safe to delete. Abandoned plugin settings (rows from plugins you removed years ago) are next — also deletable. Active plugin data should be set to autoload no rather than deleted.

Clean carefully. Never delete rows for active plugins or anything with _site_transient_timeout companions you don't understand. Schedule weekly deletion of expired transients with a housekeeping plugin so the table can't regrow silently between manual cleanups. Recheck the 20-biggest list monthly; new plugins add new autoload rows quietly. Take a database backup first, clean in small batches, and re-measure the autoload total after each round. Sites have dropped 8MB of autoload to under 1MB in one session — that's 7MB back on every request, often enough to end the exhaustion without touching any limit.

-- How heavy is the autoloaded payload on every request?
SELECT SUM(LENGTH(option_value)) AS autoload_bytes
FROM wp_options WHERE autoload = 'yes';

-- The 20 biggest rows (usual suspects for bloat)
SELECT option_name, LENGTH(option_value) AS size
FROM wp_options WHERE autoload = 'yes'
ORDER BY size DESC LIMIT 20;

-- Stop a junk row from loading on every request
UPDATE wp_options SET autoload = 'no' WHERE option_name = 'dead_plugin_cache';

Cut Per-Request Work With Caching and Batches

The durable fix is needing less memory per request. Full-page caching is the biggest lever: a cached page serves without booting the heavy plugin path at all, so the hungry builder code never runs for anonymous visitors. Object caching moves repeated queries out of PHP memory into Redis or Memcached. Either can halve peak usage alone.

Next, stop loading everything at once. Huge archives should paginate or lazy-load instead of querying hundreds of posts per page. Imports and image regeneration belong in small WP-CLI batches at 03:00, not in admin page loads at noon — the Black Friday incident was exactly this mistake. WP-Cron jobs should stagger so two heavy tasks never share a minute.

Re-measure after each change with the same failing page and the same tool. Object caching helps the logged-in paths page caches skip — members and carts still boot the heavy stack, so keep auditing those separately. Log peak memory per template monthly; slow growth over quarters signals a leak long before users notice. Caching first, then batching, then trimming — each step lowers the ceiling your site genuinely needs. The goal isn't the biggest limit you can set; it's a stack comfortable at 256M with headroom to spare.