You update a plugin, install a new theme, or just load a media-heavy page, and instead of your site you get a white screen with one line of text: "Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 20480 bytes)." The number after "of" changes depending on your account, but the message is always the same shape — PHP ran out of the memory it was allowed to use, and it gave up mid-request.
This one's easy to fix once you know where the limit actually lives, because on shared hosting there are usually two or three limits stacked on top of each other, and raising the wrong one does nothing.
Symptom: What This Error Looks Like
It shows up in a few places depending on what triggered it:
- A blank white page on the front end with the "Allowed memory size exhausted" line in plain text
- The WordPress admin dashboard failing to load, or a specific screen (Plugins, Media Library, an import tool) dying while the rest of the site works fine
- A partial page — header and sidebar render, then it cuts off mid-content
- The error appearing only during specific actions: bulk plugin updates, large CSV imports, PDF generation, or image processing with a lot of thumbnails
If the error only fires during heavy operations (imports, bulk edits, report generation) and the rest of the site is fine, that's a strong clue you're right up against a limit rather than dealing with a broken plugin.
Cause: Why PHP Runs Out of Memory
WordPress needs memory the same way a browser needs RAM — the more plugins, the bigger the page, the more data being processed in one request, the more it needs. PHP enforces a hard ceiling per request, and once a script tries to allocate more than that ceiling allows, it dies immediately rather than slowing down.
On a typical cPanel WordPress install, there isn't just one memory limit — there are usually three, and the lowest one wins:
| Limit | Where it lives | Typical default |
|---|---|---|
| PHP memory_limit | php.ini, MultiPHP INI Editor, or .user.ini | 128MB–256MB |
| WordPress WP_MEMORY_LIMIT | wp-config.php | 40MB (WordPress' own internal default, often lower than PHP's) |
| WordPress WP_MAX_MEMORY_LIMIT | wp-config.php | 256MB, applies to wp-admin only |
If your host's PHP allows 512MB but wp-config.php never raises WP_MEMORY_LIMIT past the WordPress default, WordPress will still cap itself well below what's actually available. That mismatch is the single most common cause of this error on hosting that otherwise has plenty of headroom.
The other common cause isn't a limit at all — it's a plugin or theme leaking memory. A poorly coded plugin that loads the entire post table into an array, an image editor processing an oversized upload, or two caching plugins fighting each other can all balloon memory usage on a single request regardless of how high your limit is set.
Fix: Raise the Right Limit, Then Find the Real Hog
1. Check your current limit
In wp-admin, go to Tools → Site Health → Info → Server and look for "PHP memory limit." This tells you what WordPress is actually seeing right now, before you change anything.
2. Raise WP_MEMORY_LIMIT in wp-config.php
Open wp-config.php via File Manager or FTP and add these two lines just above the line that says /* That's all, stop editing! Happy publishing. */:
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );WP_MEMORY_LIMIT covers regular front-end and back-end requests. WP_MAX_MEMORY_LIMIT is a separate, higher ceiling WordPress applies specifically inside wp-admin, where memory-hungry tasks like plugin updates and media processing happen.
3. Raise the underlying PHP limit too
Bumping WP_MEMORY_LIMIT past what PHP itself allows does nothing — WordPress can't grant itself more than the server hands out. In cPanel, go to Software → MultiPHP INI Editor, select your domain, and set:
memory_limit = 512MNo MultiPHP INI Editor on your account? Add a .user.ini file in your site's root with the same line, or drop this into wp-config.php near the top (before the wp-settings.php include):
ini_set( 'memory_limit', '512M' );Note that ini_set() only works if your PHP handler allows runtime overrides — most cPanel accounts running PHP-FPM do, but if you see no change, MultiPHP INI Editor or .user.ini is the more reliable route.
4. If raising the limit doesn't fix it, find the actual memory hog
Sometimes the error keeps coming back even at 512MB or 1GB — that's your sign it's a leak, not a genuine shortage. Deactivate all plugins, then reactivate them one at a time, reproducing whatever action triggered the error after each one. The plugin that brings the error back is your culprit. Import tools, PDF generators, backup plugins running during a page load, and "all in one" SEO/analytics plugins are frequent offenders.
You can also check the PHP error log for the exact file and line the crash happened on — in cPanel, look under Metrics → Errors, or check error_log in your site's root. A line like wp-content/plugins/some-plugin/includes/importer.php on line 214 tells you exactly where to point the finger before you start deactivating things blind.
5. Check whether your hosting plan caps memory regardless of php.ini
On CloudLinux-based shared hosting (most cPanel shared plans), there's an LVE (Lightweight Virtual Environment) resource cap sitting above php.ini. If you set memory_limit to 1GB but your plan's LVE cap is 512MB, PHP will still be killed at 512MB — php.ini settings can't override an account-level resource limit. If you're consistently hitting the ceiling even after raising every setting above, that's a sign the site has outgrown shared hosting and needs a VPS with dedicated resources.
Prevention: Keep This From Coming Back
- Set WP_MEMORY_LIMIT and WP_MAX_MEMORY_LIMIT once, proactively, rather than waiting for the error to show up during a client's busiest week
- Keep plugins to what you actually use — audit and remove inactive ones instead of leaving them installed "just in case"
- Run bulk operations (large imports, migrations, batch image processing) via WP-CLI over SSH instead of through the browser — CLI requests aren't bound by the same execution limits as web requests
- Watch Site Health's PHP memory limit reading after every hosting plan change or PHP version upgrade — a downgrade can silently reintroduce the problem
- If a specific plugin is a repeat offender, look for a lighter alternative rather than continuing to raise limits to accommodate it
Frequently Asked Questions
What memory limit should I actually set?
256M is enough for most WordPress sites with a normal plugin count. Page builders, WooCommerce with many extensions, or sites doing heavy imports often need 512M. Going much higher than that without finding the actual cause usually just delays the same error rather than fixing it.
Why does the error mention a different number than what I set?
If wp-config.php says 512M but the error still reports exhausting 268435456 bytes (256MB), the PHP-level memory_limit is overriding your WordPress setting. Fix it in MultiPHP INI Editor or .user.ini — that's the value actually being enforced.
Can a theme cause this, not just plugins?
Yes. Heavy page builder themes and demo-import routines are common culprits, especially during the initial import of demo content. Deactivate to a default theme like Twenty Twenty-Four temporarily to confirm before ruling it out.
Does raising memory_limit cost me anything or slow the site down?
No — it's a ceiling, not an allocation. A higher memory_limit just means PHP is allowed to use more if a request needs it; a normal page load that only needs 60MB still only uses 60MB.
I'm on a SkyServer VPS — where do I set this instead of MultiPHP INI Editor?
If you're running WHM/cPanel on the VPS, the same MultiPHP INI Editor path applies. On a plain LEMP/LAMP stack without cPanel, edit memory_limit directly in your PHP-FPM pool's php.ini (commonly under /etc/php/8.x/fpm/php.ini) and restart php-fpm afterward for the change to take effect.
