How to Fix “Allowed Memory Size Exhausted” in WordPress

What the Error Actually Means

A typical WordPress fatal error looks like this:

Fatal error: Allowed memory size of 134217728 bytes exhausted
(tried to allocate 20480 bytes) in /wp-content/plugins/example/plugin.php on line 317

PHP gives every request a memory budget. When one request crosses that budget, PHP stops execution and WordPress may show a critical error, blank screen, broken admin page, failed import, stuck backup, or failed image upload. The number in bytes tells you the active limit. For example, 134217728 bytes is 128 MB.

The important part is not only the limit. The file path and task context tell you what was happening when memory ran out. A WooCommerce report, Elementor edit screen, image resize, malware scan, database import, cache warmer, or scheduled backup can all exhaust memory for different reasons.

Safe First Steps Before Editing Files

If the site is down, the goal is to restore access without making the root cause harder to find. Do these checks first:

• Open the latest PHP error log or WordPress debug log and copy the full fatal error line.
• Note whether it happens on the front end, wp-admin, checkout, media upload, import, backup, or cron.
• Check whether a plugin, theme, PHP version, WooCommerce extension, or page builder was updated recently.
• Take a file/database backup before editing wp-config.php or PHP settings.

Fix 1: Increase WordPress Memory in wp-config.php

For many normal WordPress sites, raising the application memory limit is the correct first fix. WordPress reads WP_MEMORY_LIMIT for front-end and general requests, and WP_MAX_MEMORY_LIMIT for admin tasks such as updates, imports, and image processing.

/* WordPress memory limits */
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

Put those constants before the final stop-editing line in wp-config.php. Do not put them at the bottom after WordPress has already loaded. If a constant already exists, edit the existing value instead of adding a duplicate.

Fix 2: Raise the Server PHP memory_limit

WordPress cannot always raise memory by itself. Hosting accounts often enforce a PHP-level memory_limit. If PHP is capped at 128M, WordPress asking for 512M may do nothing.

Depending on your host, raise PHP memory in one of these places:

• Hosting control panel PHP settings.
• php.ini on VPS or dedicated hosting.
• .user.ini on many shared PHP-FPM hosts.
• Apache .htaccess only if your host supports PHP directives there.

; php.ini or .user.ini
memory_limit = 256M
max_execution_time = 120
max_input_vars = 3000

On managed hosting, the cleanest route is often the host control panel. On Hostinger and similar shared hosts, look for PHP Options or PHP Configuration. If you cannot raise the limit, ask support what the maximum account-level PHP memory is.

Fix 3: Find the Plugin, Theme, or Process Using Memory

Raising memory can restore the site, but it should not end the investigation. If a single request uses 512M or more, something may be looping, querying too much data, processing too many images, or loading a huge object into memory.

Common causes

• Page builders: complex templates, global widgets, and revision-heavy pages can use large memory during editing.
• WooCommerce: reports, exports, checkout extensions, subscriptions, and product imports can load large datasets.
• Backup plugins: archive creation and cloud uploads can exhaust memory on shared hosting.
• Security scanners: file integrity scans may hit memory limits on large installs.
• Image optimization: resizing large images can require more memory than the final image file size suggests.
• Custom code: unbounded WP_Query, recursive hooks, or loading all posts/users at once can trigger fatal errors.

If the log points to a plugin file, disable that plugin temporarily, reproduce the action, then test again. If the error disappears, update the plugin, reduce its workload, adjust its settings, or replace it. If the path points to the active theme, switch to a default theme on staging and test the same request.

Scenario-Based Fixes

The right fix depends on where the memory exhausted error appears. A fatal error during checkout is a different problem from a fatal error during a one-time CSV import. Use the location of the failure to choose the next step instead of changing random settings.

If the error happens in wp-admin

Admin screens often load more code than public pages. Builders, analytics dashboards, WooCommerce reports, SEO audits, and plugin update screens can all run large queries. Increase WP_MAX_MEMORY_LIMIT, then disable dashboard widgets or plugin panels that load heavy reports on every admin request.

If the error happens during media upload

Large image uploads are deceptively expensive. PHP may need to decode the full image into memory before WordPress creates thumbnails, even if the final compressed file is small. Resize very large images before upload, reduce generated image sizes, check image optimization plugins, and test with one known-good JPEG to separate file-size problems from plugin conflicts.

If the error happens in WooCommerce

WooCommerce stores can exhaust memory during cart calculation, report generation, product imports, subscription renewal jobs, or email generation. Start by checking whether the fatal error appears on checkout, product edit screens, scheduled actions, or exports. For scheduled action failures, reduce batch sizes where possible and avoid running backups, imports, and report generation at the same time.

If the error happens during import, export, or backup

One-time operations may legitimately need more memory, but they should still be batched. Split imports into smaller files, lower backup archive size, exclude cache folders, and run CLI-based jobs where your host supports it. If every import fails at the same row or object type, the issue may be malformed data rather than raw memory.

How to Debug Memory Exhaustion Without Guessing

Turn on logging long enough to capture the failing request. Do not leave public error display enabled on production.

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

After reproducing the problem, check wp-content/debug.log and your hosting PHP error log. The best clue is usually the first fatal error, not the last warning after the request is already broken.

Look for patterns: the same plugin path, the same admin screen, the same cron hook, or the same import endpoint. A memory error that happens only during scheduled tasks may be a WP-Cron problem, not a normal page-load problem.

What Memory Limit Is Right?

There is no single perfect WordPress memory limit. The correct value depends on site size, plugins, admin workflows, traffic, and hosting plan. Use this as a practical baseline:

If a simple front-end request needs 512M, investigate. If a one-time import needs 512M, that may be normal. The context matters more than the number.

When Raising Memory Is Not Enough

A higher memory limit gives WordPress more room, but it does not fix inefficient code. If the same request keeps consuming whatever memory you give it, look for an unbounded query, a recursive hook, a stuck background process, or a plugin trying to load an entire table into memory.

Watch for these warning signs:

• The error returns immediately after raising memory from 256M to 512M.
• Only one plugin screen or one cron hook triggers the fatal error.
• The failure started after a plugin update, theme change, or custom code deployment.
• The database is unusually large, especially options, postmeta, action scheduler, or logs tables.
• The site runs several heavy background jobs at the same time.

At that point, treat memory exhaustion as a symptom. Reduce batch sizes, clean stale transients and logs carefully, review custom queries, and profile the request if you have access to developer tools like Query Monitor, Xdebug, New Relic, or your host’s application monitoring.

Production Checklist

• Raise WP_MEMORY_LIMIT and WP_MAX_MEMORY_LIMIT intentionally, not blindly.
• Confirm PHP memory_limit at the server level matches or exceeds the WordPress request.
• Capture the exact fatal error path before clearing logs.
• Disable or isolate the plugin/theme/process named in the fatal error.
• Retest the original action: admin screen, checkout, import, media upload, backup, or cron job.
• Remove public debug display after troubleshooting.
• Document the final memory values and the reason for the change.

FAQs