A WordPress memory exhausted error means a PHP request reached its allowed allocation. The useful question is not simply which number to increase. Identify the request that failed, the limit it actually used, and the work consuming that memory. A larger allowance can restore a legitimate operation, but it can also postpone the same failure.
Read the complete error before editing configuration
A synthetic example is Allowed memory size of 134217728 bytes exhausted. That allowance is 128 MiB. The final attempted allocation is not the total memory the site needs. Copy the timestamp, full message, file, and line into a private incident record. Remove customer values and server secrets before sharing it.
Identify the action at that time: opening the editor, importing products, generating thumbnails, exporting entries, or serving a public page. One failed export and every public page failing are different incidents. If visitors cannot load the site, use the critical-error recovery guide to recover access before experimenting with capacity.
Check the web request, not just the command line
PHP documents memory_limit as the allocation limit for a script. A CLI process and a web worker may load different configuration. Ask the host for the effective value on the affected PHP pool or inspect it through a restricted diagnostic route. Do not leave a public phpinfo page online.
WordPress memory constants are requests to the PHP environment, not proof that a host accepted a new limit. A value shown in a configuration file is weaker evidence than the value observed in the failing runtime. On managed hosting, the provider may need to change the allowance.
Explanatory worksheet for your own test evidence. No customer results are represented.
Match the failure to an experiment
| Where it fails |
Controlled test |
What the result tells you |
| Product import |
Retry a smaller synthetic batch on staging |
Failure that tracks batch size suggests oversized work |
| Image processing |
Test a modest image and a large original |
Dimensions and transformations may matter more than file size |
| One editor screen |
Compare the same page with the suspected add-on isolated |
A repeatable difference narrows the component |
| Public pages after an update |
Compare the last working package on staging |
A regression is more plausible than suddenly inadequate traffic capacity |
Change one variable. Disabling several plugins while raising limits makes the cause difficult to recover. Keep the original error and record both successful and failed tests. A file named in the fatal error may be where allocation finally failed, not the component responsible for all earlier allocations.
Choose the smallest durable repair
For a large export, use supported pagination or smaller batches. For an image job, reduce unnecessary source dimensions while keeping an original backup. For a plugin regression, use the vendor's supported fix or a verified rollback on staging. Repeated recursion needs a code correction, not an unlimited process.
If the workload is legitimate and bounded, agree a higher limit with the host and verify total worker capacity. More memory per request can reduce the number of simultaneous requests the server can safely support. Do not set an unlimited allowance as an emergency default.
Prove the original task now finishes
Repeat the exact failed operation, then check a normal public request and a second concurrent workflow. Watch the PHP error log for new failures, record peak usage when your tooling exposes it, and remove temporary diagnostics. Keep a bounded follow-up window for scheduled jobs that run later.
If the failure moves to another file or returns with a larger batch, the investigation is not complete. Bring HandL WP the failing action, effective limit, sanitized error, and experiment results through the one-time WordPress fix service. That evidence is much more useful than a screenshot of a higher number in wp-config.php.
References checked September 25, 2026. Illustrations and examples are explanatory, not customer case studies.