Fix 'Allowed memory size of X bytes exhausted' Error in WordPress

The Error

WordPress dies mid-request and throws this:

Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in /var/www/html/wp-includes/class-wp-query.php on line 3492

That number — 134217728 bytes — is exactly 128 MB. PHP hit its ceiling and killed the process. You'll typically see this after activating a plugin, running a WooCommerce checkout, importing a 10,000-row CSV, or right after a major plugin update added heavier code paths.

Root Cause

PHP enforces a hard memory cap per process. WordPress itself requests 40 MB by default. Most shared hosts set memory_limit to 64–128 MB. The moment a plugin or theme pushes past that ceiling — crash.

The usual suspects:

WooCommerce with 5+ active extensions loaded simultaneously
Page builders (Elementor, Divi) rendering complex layouts with many nested widgets
Bulk operations: importing posts, regenerating thumbnails, running scheduled cron jobs
A memory leak introduced in a plugin's latest update

Fix

Method 1: wp-config.php (fastest, works on most hosts)

Open wp-config.php and add this before the /* That's all, stop editing! */ comment:

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

Getting the error in wp-admin too? Add the admin memory limit as well:

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

One important caveat: this only works up to PHP's own memory_limit. If PHP is capped at 128 MB, WordPress can't go higher no matter what you put here.

Method 2: php.ini

This is the direct approach — change the PHP ceiling itself.

memory_limit = 256M

On a VPS or dedicated server, edit /etc/php/8.1/fpm/php.ini (adjust the version number in the path). On shared hosting, drop a php.ini file in your WordPress root — same directory as wp-config.php. Some hosts look for it in public_html or the home directory instead.

After saving, restart the relevant service:

# PHP-FPM
sudo systemctl restart php8.1-fpm

# Apache with mod_php
sudo systemctl restart apache2

Method 3: .htaccess (Apache only)

Add one line to your WordPress .htaccess:

php_value memory_limit 256M

Works on Apache + mod_php. On Nginx or PHP-FPM, this directive is silently ignored — use php.ini instead.

Method 4: WP-CLI (diagnose before you change anything)

Check what limits are actually in effect:

# What WordPress thinks it can use
wp eval 'echo WP_MEMORY_LIMIT;'

# What PHP actually allows
wp eval 'echo ini_get("memory_limit");'

If those two numbers differ — say, WordPress expects 256M but PHP reports 128M — you need Method 2 to raise the PHP ceiling. Editing wp-config.php alone won't cut it.

Method 5: cPanel / Plesk GUI

On managed hosting, skip the file editing entirely:

cPanel: MultiPHP INI Editor → select your PHP version → set memory_limit
Plesk: Domains → PHP Settings → memory_limit
Kinsta / WP Engine / Flywheel: Contact support. They control PHP at the infrastructure level and can raise it for you.

What value should you use?

256M: Solid default for most WordPress sites
512M: WooCommerce stores running 10+ extensions simultaneously
1024M: Only during bulk imports or thumbnail regeneration — raise it temporarily, then drop it back down

Resist the urge to set -1 (unlimited) on production. One leaky plugin and your server's entire RAM disappears.

Verification

Create a temporary file at wp-content/check-memory.php:

<?php
echo 'PHP memory_limit: ' . ini_get('memory_limit') . "\n";
echo 'WP_MEMORY_LIMIT: ' . WP_MEMORY_LIMIT . "\n";

Load it in your browser, confirm the values match what you set, then delete it immediately. Leaving debug files in a public directory is a real security risk.

Prefer WP-CLI? One command does the same thing:

wp eval 'echo "PHP: " . ini_get("memory_limit") . " | WP: " . WP_MEMORY_LIMIT;'

Then trigger whatever caused the original error — activate that plugin, run the import, reload the problematic page. No fatal error means you're done.

If Raising Memory Doesn't Help

Already at 512M and still crashing? You're dealing with a memory leak, not just a low limit.

Deactivate all plugins. Reactivate them one at a time until the error returns — that's your culprit.
Read the file path in the error message carefully. It often points directly to the offending plugin's code.
Check the plugin's bug tracker or changelog for known memory issues since the last update.

Also check wp-content/debug.log if WP_DEBUG_LOG is enabled. Seeing the same file path repeated dozens of times? That's the leak.

Prevention

Set WP_MEMORY_LIMIT to 256M in every new WordPress install — don't wait for the crash
Install Query Monitor and watch memory usage after each plugin update
Keep one page builder per site. Running Elementor and Divi on the same install is asking for trouble.
On VPS/dedicated servers, configure per-site PHP-FPM pool limits — don't let one heavy site starve the others