PHP memory_limit on WordPress: What It Should Be and How to Raise It Correctly

PHP memory_limit caps how much RAM a single PHP request may use. The moment a request crosses it, PHP throws a fatal: Allowed memory size of N bytes exhausted. For WordPress, a single-plugin install consumes 32-64MB. Add Elementor, WooCommerce, Backup, or image optimization and 128-256MB becomes the floor. A 50-plugin site running heavy admin work (importing 1,000 posts, a backup, regenerating thumbnails) needs 512MB.

Why this matters

Direct effect: when the limit is low, operations die mid-flight. A backup that stops at 70%, an XML import that finishes half, or a post editor that refuses to load - all classic memory exhaustion symptoms. Tasks that worked yesterday can fail tomorrow when a new plugin ratchets up baseline usage.

Indirect effect: it is your safety net. A site with 256MB tolerates one outlier request (a REST endpoint returning 5,000 items). A 64MB site dies. WooCommerce export/import on a large catalog frequently needs 1GB+; without that headroom, you cannot edit large catalogs at all.

That said, infinite memory is dangerous. A 2GB limit on a leaky request means each worker holds 2GB; ten workers means 20GB of RAM. The server collapses. The right value is the smallest that still covers your real workload - usually 256MB.

How to detect

Current value: Tools > Site Health > Info > Server shows PHP memory limit. With WP-CLI: wp config get WP_MEMORY_LIMIT and php -i | grep memory_limit.

Memory errors: search wp-content/debug.log for Allowed memory size of. Each match is a failed request. The server's PHP error log (typically /var/log/php_error.log or visible in cPanel's error_log) catches the rest.

Indirect symptom: an admin page that returns "500 Internal Server Error" mid-action is often a memory exhaustion. Cross-check the log.

How to fix

Two limits exist. WordPress sets one in wp-config.php; PHP sets one in php.ini. The lower of the two wins, and WordPress never exceeds the PHP cap. So if PHP allows 64MB, raising WP_MEMORY_LIMIT to 256MB changes nothing.

Step 1: WordPress. In wp-config.php, before /* That's all */:

define('WP_MEMORY_LIMIT', '256M');
define('WP_MAX_MEMORY_LIMIT', '512M'); // applies to wp-admin only

WP_MEMORY_LIMIT covers the front end; WP_MAX_MEMORY_LIMIT applies to wp-admin (heavier work).

Step 2: PHP. cPanel: "Select PHP Version" or "MultiPHP INI Editor" > memory_limit = 256M. Plesk: Domain > PHP Settings > memory_limit. On a VPS with shell access edit /etc/php/8.2/fpm/php.ini:

memory_limit = 256M

Restart PHP-FPM: systemctl restart php8.2-fpm.

If php.ini is unreachable, drop .user.ini in the site root:

memory_limit = 256M

Wait 5-10 minutes for PHP-FPM to refresh and test again.

Common mistakes

Mistake one: setting only WP_MEMORY_LIMIT and assuming the problem is solved. If PHP is lower, nothing changes. Always verify with phpinfo(). Mistake two: setting unlimited memory (-1) to "never worry again". This hides leaks. A buggy plugin keeps growing, and one busy hour eventually has 100 concurrent requests using 100GB and toppling the server. Mistake three: forgetting max_execution_time and max_input_vars - on stretched sites all three thresholds usually fall together.

Verifying the fix

Confirm Site Health > Server reflects the new value. Re-run the action that previously failed (backup, import, regenerate) and verify it completes. Watch debug.log for new entries - none means the fix landed. cPanel's "Resource Usage" should not show memory pegged at the plan ceiling.