Resolving The WordPress Memory Exhausted Error

Your site was fine an hour ago. Now it serves a blank page, and the log holds one line: Fatal error: Allowed memory size of 268435456 bytes exhausted.

The WordPress memory exhausted error means a PHP script asked for more RAM than the server’s memorylimit allows. PHP stops mid-request.

Raising the limit fixes some cases. Not all of them.

This guide covers:

• What each byte value in the message tells you
• How much memory WooCommerce, Elementor, and Multisite need
• The 4 methods to raise the limit, and when each fails
• Finding the plugin, theme, or query burning the memory
• Getting back into wp-admin when you are locked out

What Is the WordPress Memory Exhausted Error

The WordPress memory exhausted error is a PHP fatal error thrown when a single script requests more RAM than the server’s memorylimit directive allows. PHP kills the process on the spot. WordPress stops rendering mid-request, and the visitor gets a blank page or an HTTP 500 response.

The full message looks like this:

“ Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 20480 bytes) `

Both numbers carry information. The first is your ceiling expressed in raw bytes, and the second is the small chunk PHP could not squeeze in before it gave up.

Byte values decoded:

The limit applies per script, not per site. Every request gets its own fresh allocation, and that allocation resets the moment the request finishes.

Which is why a site can serve 40 visitors happily and still die on one bulk import.

What PHP memory is not:

• Server RAM: the total physical memory across all processes, usually 1GB to 8GB depending on plan
• Disk space: storage for files and uploads, completely unrelated
• MySQL memory: allocated separately by the database engine

The error class is EERROR. Non-recoverable, non-catchable, execution halts. This is the same severity tier as any other fatal error thrown by WordPress, and the shutdown behaviour is identical.

Some hosts and plugins surface the same condition with different wording. A WordPress out of memory message and an allowed memory size message describe the same allocation failure.

What Causes PHP Memory Exhaustion on a WordPress Site?

PHP memory exhaustion on WordPress has 7 recurring causes: low host-set defaults, plugin load, image processing, unbounded database queries, recursive hooks, WP-Cron stacking, and outdated PHP versions. Plugin load accounts for the majority of real-world cases.

Host-set defaults. WordPress core requests only 40MB for single sites and 64MB for Multisite (SiteGround, 2025). Neither number has aged well.

Plugin count. Dev4Press data from 2024 shows an average of 20 active plugins pushes baseline memory to 48MB to 64MB before any page-specific logic runs. The average WordPress site carries 12 to 15 plugins (Magecomp, 2026).

Page builders. Elementor’s own system requirements list 256MB as the minimum, 512MB as recommended, and 768MB for best performance. Elementor appears on 31.2% of live WordPress sites (W3Techs, 2026), which explains why this error shows up so often in support forums.

Image processing. GD and Imagick both load the full uncompressed bitmap into memory during upload and thumbnail regeneration. A 12MP JPEG can expand past 140MB while being resized.

Unbounded queries are the quiet one. postsperpage => -1 inside a custom loop pulls every matching post object into memory at once, which works fine on 200 posts and detonates on 40,000.

Recursive hooks in theme code cause the same outcome faster. If you have ever added a filter that fires the same action it listens to, you already know how quickly PHP burns through 512MB. Anyone editing the functions.php file directly should test on staging first.

PHP version matters more than people expect. PHP 7.4 still powers 19.288% of WordPress installs (WordPress.org Statistics API, 2026), and its memory allocator is measurably less efficient than PHP 8.2 and 8.3.

How Autoloaded Options Silently Consume Memory

WordPress pulls every option flagged autoload = yes from wpoptions on every single request, in one query, before anything else runs.

The thresholds that matter:

• 800KB combined autoload size triggers a critical Site Health warning (WordPress 6.6+)
• 150KB per-option ceiling governed by the wpmaxautoloadedoptionsize filter

• 3MB to 5MB indicates real optimization work is needed (WPMU DEV)
• 10MB or more is an active performance problem

WP Engine documentation notes that excess autoload data is responsible for many performance issues and frequently surfaces as 502 gateway failures rather than clean memory errors.

Abandoned plugins are the usual culprit. Deleting a plugin rarely removes its option rows, so the data keeps loading on every page view for years.

Where Does the Memory Exhausted Error Appear on a WordPress Site?

The error surfaces in 6 places: the front end as a blank page, the admin dashboard, media uploads, plugin updates, REST API responses, and the server error log. Most site owners never see the actual message because displayerrors is off in production.

That is the frustrating part. PHP writes a perfectly clear fatal error, and the browser shows nothing.

Front end: a completely blank page, better known as the WordPress white screen of death, or a 500 internal server error depending on server configuration.

Admin side: WordPress 5.2 and later replaces the blank screen with the critical error notice, which is friendlier and roughly as informative.

Media Library: uploads fail partway through resizing. Images that refuse to upload are one of the most common first symptoms on image-heavy sites.

Updates: core and plugin updates that fail mid-process, sometimes leaving the site in maintenance mode.

Block Editor: REST API endpoints return truncated or malformed JSON because PHP died before finishing the response. The editor then throws a generic “updating failed” notice that names nothing useful.

To read the actual message, look in these locations:

• /wp-content/debug.log after enabling WPDEBUGLOG

• The cPanel or Plesk error log for the account
• errorlog in the site root or the affected directory

Enabling PHP error display in WordPress is the fastest route to the raw message. Reading the WordPress error log gives you the file path of the offending script, which usually names the plugin directly.

How Much PHP Memory Does a WordPress Site Require?

WordPress.org lists 64MB as the technical floor and 256MB as the recommended memorylimit for 2026 installs. Real requirements scale with plugin count and workload, not traffic. WooCommerce stores and page builder sites need 512MB.

Kinsta ships 256MB by default on standard plans and 512MB on higher tiers. SiteGround raised its platform-wide WordPress default to 256MB, with a server ceiling of 768MB.

To check what you actually have, go to Tools, then Site Health, then Info, then expand Server. The PHP memory limit sits in that panel.

For measured numbers rather than configured ones, memorygetpeakusage(true) returns the real peak for the current request. Query Monitor prints the same value in its admin bar panel on every page load.

There is a point where raising the limit stops helping. If a template peaks at 90MB on a 512MB limit and still throws fatals, the problem is a runaway loop, not a ceiling.

How to Increase the PHP Memory Limit in WordPress?

There are 4 methods to raise the PHP memory limit: editing wp-config.php, editing php.ini or .user.ini, adding a directive to .htaccess, and changing the value in the hosting control panel. The control panel method has the highest success rate.

After every method, verify in Tools, Site Health, Info, Server. If the number has not moved, the change did not apply.

Editing wp-config.php

The most common fix, and the one most likely to be undone by the host.

` define( 'WPMEMORYLIMIT', '256M' ); `

• Place the line above the / That’s all, stop editing! / comment

• Remove any duplicate WPMEMORYLIMIT lines to avoid conflicts (WPML support guidance)

This raises WordPress’s internal request only. The server still has final say.

Editing php.ini or .user.ini

This changes the actual PHP environment rather than asking WordPress to request more.

` memorylimit = 256M `

File location depends on the stack. Apache with modphp reads a global php.ini, PHP-FPM reads a pool-specific ini, and most shared hosts honour a per-directory .user.ini.

Watch out: .user.ini changes take up to 5 minutes to apply because of PHP's userini.cachettl default of 300 seconds. If you are unsure which file your install reads, this guide on locating php.ini in WordPress covers each stack.

Editing .htaccess

Try this last. On anything running PHP-FPM it will take the site down with a 500 error the moment you save.

` phpvalue memorylimit 256M `

• Works only on Apache running modphp
• Throws an immediate 500 on FastCGI, CGI, LiteSpeed, and Nginx setups
• Remove the line via FTP to recover

Using the Hosting Control Panel

Fastest route, zero file editing, and the value sticks.

• cPanel: MultiPHP INI Editor, select the domain, set memorylimit

• Plesk: PHP Settings under the subscription
• SiteGround: Site Tools, Devs, PHP Manager, PHP Variables
• Kinsta: Sites, Info, PHP performance, slider up to 768MB on most plans

Managed hosts including WP Engine and Flywheel tie the ceiling to the plan and require a support ticket to exceed it. Most handle the request in minutes.

Shared plans almost always have a hard maximum the panel will accept. On budget hosts that ceiling is commonly 256MB.

What Is the Difference Between WPMEMORYLIMIT, WPMAXMEMORYLIMIT, and memorylimit?

memorylimit is the server-level PHP ceiling. WPMEMORYLIMIT is the front-end allocation WordPress requests, defaulting to 40MB. WPMAXMEMORYLIMIT is the admin-side allocation for heavy operations, defaulting to 256MB. WordPress constants never exceed the server ceiling.

The hierarchy rule: WordPress constants raise the value up to the server’s memorylimit and never past it.

Setting WPMEMORYLIMIT to 512M on a host capped at 128M changes nothing. WordPress cannot grant itself memory the server refuses to hand over.

The diagnostic shortcut: an error that appears only in wp-admin and never on the front end is a WPMAXMEMORYLIMIT problem, not a WPMEMORYLIMIT problem.

Admin tasks routinely need more than page loads because file operations, plugin updates, media processing, and bulk database actions all happen inside a single PHP process.

This distinction resolves a large share of cases where the allowed memory size exhausted message keeps returning after a wp-config edit that looked correct.

Why Does Increasing the Memory Limit Fail to Fix the Error?

Raising the limit fails for 5 reasons: a host-level hard cap set with phpadminvalue, the wrong ini file being edited, OPcache serving stale configuration, Suhosin blocking runtime changes, and runaway code that would exhaust any limit.

Host hard caps. phpadminvalue memorylimit in the Apache virtual host cannot be overridden from user space. No wp-config edit, no .htaccess line, no iniset() call will touch it.

Wrong ini file. The CLI ini and the FPM ini are separate files. Editing the CLI one changes WP-CLI behaviour and leaves web requests untouched, which is a fun 40 minutes to lose.

OPcache. Precompiled bytecode keeps serving the old configuration until the cache clears or PHP-FPM restarts.

Suhosin. The hardening patch blocks runtime memory changes outright on some older shared stacks.

Runaway code. An infinite loop exhausts 4096M as fast as it exhausts 128M. Doubling the limit buys a few hundred milliseconds and nothing else.

Here is the diagnostic that separates the two situations. Raise the limit, reload, and read the new error.

• The byte value in the message changed to match the new limit, and the error persists: code problem
• The byte value did not change at all: the new limit never applied

That single check saves more troubleshooting time than any other step in this article. Most people skip it and go straight to deactivating plugins at random.

How to Identify the Plugin, Theme, or Query Consuming the Memory?

Identifying the memory consumer takes 3 steps: read the file path in the fatal error, profile peak memory with Query Monitor, then isolate by deactivating plugins in batches. The error message names the offending file in most cases, which skips the guesswork entirely.

Start with debug logging. Add these lines to wp-config.php above the stop-editing comment:

` define( 'WPDEBUG', true ); define( 'WPDEBUGLOG', true ); define( 'WPDEBUGDISPLAY', false ); `

The stack trace lands in /wp-content/debug.log. Read the file path on the fatal error line, because it usually points straight at a plugin directory.

Profiling tools worth having:

Query Monitor’s Overview panel prints peak memory usage next to the limit on every page load. The Queries by Component tab attributes database work to specific plugins, which is where the culprit usually surfaces.

One caveat worth knowing. Query Monitor itself adds 10 to 100 milliseconds per page and raises PHP memory consumption by roughly 10% (Oxygen, 2026), so read the numbers as approximate.

For code-level profiling, wrap the suspect function in doaction( ‘qm/start’, ‘name’ ) and doaction( ‘qm/stop’, ‘name’ ). The Timings panel then reports memory used between the two markers.

Isolation workflow when the log gives you nothing:

• Rename /wp-content/plugins to plugins-off via SFTP to deactivate everything at once

• Rename it back, then reactivate in batches of 5 rather than one at a time
• Switch to Twenty Twenty-Four to rule out theme code and confirm whether it is a theme-level error
• Run wp plugin deactivate –all over SSH if WP-CLI is available

Unbounded queries hide from all of this. If Query Monitor reports a single query returning 40,000 rows, you have found the problem without needing to touch a plugin, and the fix belongs in the code rather than the database layer.

How to Fix the Memory Exhausted Error Without Increasing the Limit?

Reducing consumption works when the host caps memory and refuses to raise it. The 6 highest-impact reductions are plugin removal, autoload cleanup, WP-Cron replacement, Heartbeat throttling, offloaded image processing, and a persistent object cache.

Delete, do not deactivate. Deactivated plugins still load their files during PHP initialization on some configurations. Deleted plugins do not, and the same applies to inactive themes sitting in the themes directory.

Clean autoloaded options. Run wp option list –autoload=on –format=count to get a baseline, then disable autoload on abandoned plugin rows through the Performance Lab plugin or phpMyAdmin.

Replace WP-Cron with a real cron job. WP-Cron fires on HTTP requests rather than on a schedule, so a site taking 1,000 visits per hour can spawn hundreds of extra PHP processes in that same hour (AsiaGB, 2026).

` define( 'DISABLEWPCRON', true ); `

Then add a server cron hitting wp-cron.php every 5 or 15 minutes from cPanel or crontab.

Throttle the Heartbeat API. Default polling runs every 15 to 60 seconds through admin-ajax.php and cannot be page-cached because the request is a logged-in POST. Raising the interval to 60 seconds cuts admin-ajax load by roughly 75% (AHosting, 2026).

WooCommerce cart fragments deserve a separate mention. They alone generate 20,000 or more AJAX requests per hour on busy stores (WPThrill, 2026).

Offload image processing. Resize before upload, or push compression to an external service like ShortPixel or Imagify so PHP never holds the full bitmap. Sites already fighting Media Library failures usually see them stop once this changes.

Add a persistent object cache. Redis or Memcached stores query results across requests instead of rebuilding them per page load.

Sites with a persistent in-memory store cut database queries by up to 80% during peak traffic, though real-world gains land closer to 20% to 30% when themes and plugins issue uncacheable queries (WebHostMost, 2026).

Upgrade PHP. PHP 8.2 uses about 5% less memory per request than 8.1 for typical workloads (MassiveGRID, 2026), and OPcache changes in the 8.x series cut memory overhead by an average of 8% across tested WordPress workloads.

Bulk imports are the last common offender. WP All Import processes records in chunks, which keeps a 60,000-row CSV from loading into a single request and throwing a timeout or memory failure halfway through.

How to Regain Access to wp-admin When the Error Locks the Dashboard?

There are 5 routes back into wp-admin after a fatal memory error: the Recovery Mode email, SFTP plugin folder renaming, cPanel File Manager, phpMyAdmin database edits, and WP-CLI over SSH. Recovery Mode is fastest when the email arrives.

Recovery Mode. Introduced in WordPress 5.2 and still core as of 2026, it pauses the extension that triggered the fatal error and emails the admin address a secret login link.

That link expires after 24 hours. A fresh one gets sent if the error recurs after expiry (WordPress core documentation).

The catch: the token is encrypted before it hits the database, so it exists only in that email. No email delivery, no Recovery Mode, which is a common failure on sites without SMTP configured.

SFTP. Connect with FileZilla or Cyberduck, rename /wp-content/plugins, and log in. Watch file ownership afterward, because renaming through some clients breaks WordPress file permissions and creates a second problem.

phpMyAdmin. Open wpoptions, find the activeplugins row, and replace the serialized value with a:0:{}. Back up the table first. Broken serialization locks you out harder than the memory error did.

WP-CLI. If the host provides SSH, this is the cleanest option:

` wp plugin deactivate --all --skip-plugins `

A memory fatal thrown mid-update sometimes strands the site behind a .maintenance file. Deleting that file from the root resolves a site stuck in maintenance mode, and it takes 10 seconds.

If you can reach the login screen but cannot get past it, the problem has shifted from memory exhaustion to a standard login failure, which is a different diagnostic path.

How to Prevent the WordPress Memory Exhausted Error from Recurring?

Prevention comes down to a measured baseline plus a fixed audit cadence. Track peak memory per template monthly, cap plugin count, test every change on staging, and keep PHP current. Sites that do this stop seeing the error entirely.

Start with numbers you actually recorded rather than numbers you assume.

Plugin discipline. An average of 20 active plugins pushes baseline memory to 48MB to 64MB before page logic runs, and 40 plugins roughly doubles that (Dev4Press, 2024).

Remove what you stopped using. Deactivating is not removing, and dormant plugins leave option rows behind that keep loading on every request.

Staging, every time. Teams using staging environments report 72% fewer deployment-related outages and resolve issues 3x faster when problems do appear (WP Engine, 2025 developer survey).

Update one plugin at a time on staging. Bulk updates make it impossible to trace which change caused the memory spike.

PHP currency. PHP 7.4 still runs 19.288% of WordPress installs (WordPress.org Statistics API, 2026) despite being years past end of life. PHP 8.3 processes 447 requests per second against PHP 8.1’s 386, a 15.6% gain (Kinsta benchmarks).

Run the PHP Compatibility Checker before switching versions. Managing several installs at once makes this heavier than it sounds, and the workflow for running multiple WordPress sites matters more than the individual checks.

Monitoring. UptimeRobot or Better Uptime catches the 500s. Sentry catches PHP fatals with stack traces before a client notices anything.

Rotate debug.log on a schedule. Left alone, it grows into a disk problem of its own, and a full disk produces failures that look nothing like memory exhaustion.

Two habits close the loop. Pick a host that publishes its memory ceiling instead of hiding it in a support ticket, and treat direct edits to core files as something you never do outside a documented emergency.

Everything else is downstream of those two, including most upgrade failures people blame on WordPress itself.

FAQ on WordPress Memory Exhausted Error

Is the memory exhausted error the same as running out of disk space?

No. PHP memory is RAM allocated per script, and disk space stores files. A site with 40GB free still throws the memory exhausted error, because the two limits are measured by completely separate systems.

Why does the error appear only in wp-admin?

WPMAXMEMORYLIMIT governs admin operations and defaults to 256MB, separate from the 40MB front-end default. Plugin updates, media processing, and bulk database actions all run inside one PHP process, so wp-admin hits the ceiling first.

Can I just set the memory limit to 1024M?

You can. Avoid it. A runaway loop then consumes a full gigabyte before dying and can drag the whole server down with it. 256M or 512M covers almost every legitimate WordPress workload.

Does the memory limit control the maximum upload file size?

No. uploadmaxfilesize and postmaxsize handle uploads independently. A rejected 20MB file is a size directive problem, and it often surfaces as a request entity too large error instead.

Will a caching plugin fix the memory exhausted error?

Page caching helps anonymous traffic only. Logged-in requests, admin-ajax calls, and REST API endpoints bypass it entirely. A persistent object cache like Redis cuts repeated query memory, which is the version that actually helps here.

How do I check my current PHP memory limit without FTP?

Go to Tools, then Site Health, then Info, then expand Server. The PHP memory limit sits in that panel next to the PHP version. Query Monitor displays the same value plus live peak usage.

Does deactivating a plugin free up memory?

Partly. Deactivation stops the plugin’s hooks from firing, though some WordPress configurations still load plugin files during PHP initialization. Deleting removes the code from disk completely, which is the cleaner outcome.

Why does the error hit only one page on my site?

That template runs a heavier query or instantiates more post objects than the rest of the site. Archive pages, product listings, and search results are the usual suspects because they build large object sets at once.

Is this the same as other WordPress fatal errors?

No. Memory exhaustion is an allocation failure at the PHP level. Other fatals come from missing functions or duplicate declarations, like a cannot redeclare error, and those are code conflicts rather than resource ceilings.

Do I need a VPS to fix this permanently?

Rarely. Most shared hosts allow 256M or 512M through cPanel, which covers WooCommerce and page builders. A VPS matters when you need direct control over php.ini or the host caps memory below 256M.

Conclusion

The WordPress memory exhausted error is a diagnostic problem before it is a configuration problem. Read the byte value first, then decide whether to raise WPMEMORY_LIMIT or go hunting for the script.

Most sites never needed more memory. They needed fewer autoloaded options, a deleted page builder, and a real server cron job.

Keep debug.log` enabled on staging permanently. It costs nothing and turns the next fatal into a file path instead of a mystery.

One thing worth doing this week: open Query Monitor, load your heaviest template, and write down the peak memory number.

That figure is your real baseline. Everything after it, php.ini edits included, is guesswork until you have it.