When to Raise PHP Memory for WordPress

The white screen says nothing. The error log says Allowed memory size of 134217728 bytes exhausted. Someone on the team suggests cranking PHP memory to 512M and calling it fixed.

Sometimes that is the right move. Sometimes you are paying RAM to hide a plugin that loads half the internet on every page view. Here is how we decide when to raise PHP memory for WordPress and when to fix the site instead.

What PHP memory limit actually controls

Each PHP request (front page, admin save, cron, REST call) can use up to the configured memory_limit. WordPress also defines WP_MEMORY_LIMIT in wp-config.php (default 40M front, 256M admin unless changed) but PHP's ceiling still wins if it is lower.

Shared hosts often cap you at 128M or 256M per process. VPS plans let you raise limits in php.ini or PHP-FPM pool config. More memory per request means fewer concurrent requests fit in the same RAM, so "unlimited" is not free.

Signs you genuinely need more memory

• Fatal error logs explicitly mention memory exhausted on legitimate actions (saving a large page, running WooCommerce report, exporting orders)
• Memory use scales with real workload (big catalog, many variations) not random plugins
• Staging with the same plugins needs the same bump to function
• Your host documents a higher tier for WooCommerce or page builders and you are below that baseline
• PHP 8.x with a modern stack where 128M is simply too tight for admin (256M is a common floor for busy sites)

Read choosing PHP version for WordPress alongside memory: newer PHP can be more efficient, but plugins still dominate.

Signs you should fix code or plugins first

• Memory errors started right after installing or updating one plugin
• Front page needs 512M but is mostly static content
• Query Monitor shows one plugin loading huge autoloaded options
• Memory climbs on every request because of recursive hooks or debug plugins left on in production
• You are at 512M and still crashing (more RAM is not the answer)

See WordPress admin slow before you upgrade the server for profiling before you buy a bigger plan.

Reasonable targets (starting points, not laws)

Small brochure site: 128M often enough if plugins are light.

Typical business WordPress: 256M front, ensure admin can hit 256M via WP_MAX_MEMORY_LIMIT if needed.

WooCommerce or heavy builder: 256M to 512M for admin tasks; front may stay lower with good caching.

Document what you set and why. Future you will forget.

How to raise it safely

1. Check current limit: Site Health, phpinfo in panel, or php -i on SSH.
2. Raise in the right layer: host panel PHP settings, php.ini, PHP-FPM pool php_admin_value[memory_limit], or wp-config.php constants (WordPress cannot exceed PHP's hard cap).
3. Change one layer at a time and retest the action that failed.
4. Watch PHP-FPM pool size: doubling memory per worker halves how many workers fit in RAM.

Example in wp-config (only helps if PHP allows it):

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

What not to do

• Set 1024M on shared hosting because a forum post said so (host may kill the process anyway)
• Leave WP_DEBUG and query logging on production
• Ignore autoloaded options bloat in wp_options
• Raise memory instead of fixing a broken cron job that runs imports in a web request

Canadian hosting context

On VPS in Edmonton or Montreal you control php.ini. On managed WordPress, ask support for the plan's ceiling before you promise a client a heavy plugin stack. Memory per site affects how many sites you pack on reseller plans too.

Bottom line

Raise PHP memory when real WordPress workloads hit a documented ceiling and the stack is sane. Do not use memory as a bandage for one bad plugin or missing cache. Measure, bump modestly, retest, and fix the underlying hog if errors continue.

Hitting limits on Canadian hosting and not sure if it is plan or plugins? Talk with Swift Host. We will read the error log with you before upselling RAM.