You’re editing a post, hit save, and boom: Fatal error: Allowed memory size of xxx bytes exhausted. WordPress just froze and you can’t do anything. I’ve seen this error kill sites mid-campaign, and it always starts with a PHP memory_limit that’s way too low for what you’re actually asking WordPress to do.
What the WordPress memory exhausted error actually means
PHP assigns a memory cap to every script it runs. WordPress is a PHP script. When a single request — loading the admin, saving a post, running a plugin — tries to use more than that cap, PHP halts execution and throws the WordPress memory exhausted error.
Two culprits cause 90% of cases: a badly coded plugin doing something stupid in a loop, or a host that set memory_limit to 64M or 128M back in 2015 and never updated it.
Step 1: Raise the limit in wp-config.php (the real fix)
Edit wp-config.php in your WordPress root. Just before the line that says That’s all, stop editing, drop this in:
define(‘WP_MEMORY_LIMIT’, ‘256M’);
define(‘WP_MAX_MEMORY_LIMIT’, ‘512M’);
WP_MEMORY_LIMIT controls the front-end. WP_MAX_MEMORY_LIMIT controls the admin area, and that’s where you actually need more. Image editors, page builders like Elementor, and backup plugins eat 300-500MB in the admin without blinking. If you only set the first one, you’ll still crash in wp-admin.
One catch: this only works if your host’s PHP memory_limit is already higher than what you’re declaring. If your server caps PHP at 128M, telling WordPress to use 512M does nothing. Check with your host first.
Step 2: Bump PHP memory_limit at the server level
If wp-config isn’t enough, you need to raise memory_limit in your php.ini or via .htaccess. On cPanel hosts, most let you edit this in MultiPHP INI Editor. On Apache you can add php_value memory_limit 512M inside the .htaccess. On Nginx or PHP-FPM, it’s a pool config change your host has to make.
Shared hosting is the worst offender here. They oversell and cap PHP memory hard. If you’re stuck at 128M and the host won’t budge, that’s a sign to migrate — no amount of code tinkering fixes a bad server config.
Step 3: Find what’s actually eating memory
Don’t just throw more RAM at it. Diagnose. Install Query Monitor or WP Server Stats and check which plugin is spiking. Then deactivate plugins one by one — starting with the heavy ones: page builders, security suites, backup tools, SEO plugins with heavy indexing.
Switch to a default theme (Twenty Twenty-Four) temporarily. If the error vanishes, your theme is the memory hog. I’ve seen premium themes load 200MB of useless crap on every admin page.
Step 4: Clean up the WordPress database
A bloated wp_options table is a silent killer of WordPress performance. Autoloaded options get loaded on every single request. If you’ve got 3MB of autoloaded junk from old plugins, that’s memory burned before WordPress even runs.
Run a plugin like WP-Optimize or Advanced Database Cleaner to purge:
- Expired transients (_transient_*)
- Orphaned postmeta and usermeta
- Old revisions (keep 5-10, delete the rest)
- Spam and trashed comments
On a site I cleaned last month, deleting 180,000 postmeta rows cut the memory footprint by 40%. Same code, same plugins, just less garbage to load.
Step 5: Disable or fix the offending plugin
If a specific plugin is the trigger, you have options: update it (devs sometimes fix memory leaks), replace it with a lighter alternative, or fork it if you know PHP. Don’t keep a plugin that crashes your site just because you like its UI.
Common memory hogs in 2026: some page builders with nested dynamic content, certain backup plugins that load the entire DB into memory, and old gallery plugins that haven’t been updated in 3 years.
Step 6: When nothing works, escalate
If you’ve raised every limit, cleaned the DB, swapped the theme, and disabled every plugin — and the error persists — it’s time to call your host. Give them the exact stack trace from your error log. Ask them to run strace or check PHP-FPM logs to see which syscall is ballooning.
Sometimes the fix is a PHP version upgrade. PHP 7.4 to 8.3 changes memory behavior drastically. Running old PHP on a modern WordPress install is asking for trouble.
Prevention: don’t wait for the next crash
Set WP_MEMORY_LIMIT to 256M and WP_MAX_MEMORY_LIMIT to 512M on every WordPress site you build. Cheap insurance. Also enable WP_DEBUG_LOG so PHP warnings land in wp-content/debug.log instead of being invisible until something explodes.
And if you’re on a host that caps you at 128M with no option to change it in 2026, move. Seriously. SiteGround, Kinsta, Cloudways, and similar managed hosts give you 256M-1G out of the box. Staying on a $2/month shared plan that crashes weekly is not saving money — it’s costing you traffic.
