When WordPress (or PHP) reports Allowed memory size of X bytes exhausted, that request hit the memory limit in effect for that run. The site may show a fatal error, a critical error screen, or a blank page if display of errors is off. A low allocation, legitimate heavy workload, conflict, or excessive memory use can cause this error. Test smaller batches and isolate recent changes. A measured, host-approved increase may be appropriate for a verified workload; repeated unexplained growth needs investigation.
Work this checklist in order. Prefer staging when you can reproduce the fatal there. Take a backup before editing wp-config.php or asking the host to change PHP settings. Success at a higher limit alone does not establish a leak. If one covered WordPress issue is clearly to blame and you want help, use the $99 one-time fix after you can authorize access.
Define what failed
- Copy the exact fatal line (bytes allowed, file, and line if shown) from the page, recovery email, or host PHP error log.
- Note which action triggers it: Admin screen, plugin page, media upload, import, checkout, or every front request.
- Confirm the site is not simply offline for other reasons—use site down if nothing loads and no memory fatal appears in the log.
- If you only see a blank page with no memory text, start with white screen of death, then return here when the log shows memory exhausted.
How WordPress memory limits relate
| Setting | Where it usually lives | What it does |
|---|
WP_MEMORY_LIMIT | wp-config.php (WordPress constant) | Requests a PHP memory limit for typical front/bootstrap contexts. When runtime changes are permitted, WordPress can raise a lower PHP memory_limit toward this value |
WP_MAX_MEMORY_LIMIT | wp-config.php (WordPress constant) | Higher request used for Admin and other memory-intensive WordPress contexts |
Effective PHP memory_limit | PHP / host panel / pool for this request | What PHP actually enforced when the fatal fired—may differ between front and Admin |
| Host restrictions | Account plan, container, or policy | Enforced maximums or blocked runtime changes that prevent WordPress from raising the limit |
Ask your host for both WordPress constants (as configured), the effective PHP memory_limit for the failing request (front vs Admin if they differ), and any enforced host restrictions. Do not assume a wp-config.php define is ignored solely because a panel value looks lower—WordPress may raise a lower PHP limit when the host allows it.
Quick triage map
| What you observe | Likely layer | First useful check |
|---|
Fatal names a plugin/theme file under wp-content | That product’s code path or conflict | Disable that plugin/theme on staging or via recovery mode; retest the same action |
| Only on import, bulk edit, or huge media | Heavy but possibly legitimate workload | Test smaller batches; consider a measured, host-approved raise for that job |
| Every page after a plugin update | New conflict or excessive use | Roll back or disable the updated plugin; see plugin not working |
Define in wp-config.php seems ignored | Host restriction or wrong request context | Ask host for effective limit on the failing request and whether runtime raises are allowed |
| Blank page; log shows memory exhausted | Fatal with display off | White screen checklist + this article’s limit checks |
Safe resolution order
- Capture the fatal and the triggering action. Save the full error text and which URL or Admin click caused it. That is the regression test after each change.
- Test smaller batches and isolate recent changes. On staging (or via recovery mode / disk disable when Admin is unusable), retry imports or bulk jobs in smaller pieces, disable the newest plugin or the plugin named in the stack trace, and switch to a default theme briefly as a diagnosis if the stack points at the theme. Retest the same action. A low allocation, legitimate heavy workload, conflict, or excessive memory use can cause this error—do not treat the first successful raise as proof of a leak.
- Ask the host for the real numbers on the failing request. Both
WP_MEMORY_LIMIT and WP_MAX_MEMORY_LIMIT (as configured), the effective PHP memory_limit when the fatal fired, and enforced host restrictions (including whether WordPress is allowed to raise a lower PHP limit at runtime).
- Apply a measured, host-approved increase when the workload warrants it. Prefer the host’s documented control (panel, pool, or ticket). If you set
WP_MEMORY_LIMIT and/or WP_MAX_MEMORY_LIMIT in wp-config.php, back up the file first, use values the host already permits, and match Admin-heavy failures to WP_MAX_MEMORY_LIMIT when appropriate. A measured increase may be appropriate for a verified workload (large import, image tools, heavy Admin screens). Repeated unexplained growth—limits that must climb again without a clear job—needs investigation of plugins, queries, or compromise.
- When the host blocks further raises, stop stacking defines. Open a host ticket with the exact fatal, the action that triggers it, and the values they reported. Account changes or running heavy jobs off the web request are host decisions.
- Retest the full path. Repeat the failing Admin or front action, open a normal page, and confirm the fatal is gone. Record whether a smaller batch, an isolation change, or a measured limit increase resolved it. Success at a higher limit alone does not establish a leak—decide next steps from the workload and whether growth continues unexplained.
Choosing the next step
- Smaller batches / schedule off-peak: imports, regenerations, or bulk edits that only fail at full size.
- Isolation: fatals that started after a plugin/theme change, or stack traces naming one product.
- Measured, host-approved increase: verified heavy Admin or job workloads within plan limits, especially when
WP_MAX_MEMORY_LIMIT is the relevant constant.
- Deeper investigation: repeated unexplained growth, every-page fatals after a modest raise, or host-reported abuse/malware signals.
Common causes
- PHP limit too low for a legitimate import, media, or Admin workload.
- Plugin or theme conflict or excessive memory use on a single request.
- Admin-only fatals where
WP_MAX_MEMORY_LIMIT was never set or the host blocks raises.
- Host restrictions preventing WordPress from raising a lower PHP
memory_limit at runtime.
- Unexplained growth after updates that needs product repair—not only another ceiling hike.
When a $99 one-time fix fits
Request the $99 one-time WordPress fix if you want help on one WordPress site with a clear memory-exhausted fatal—reading the log, isolating recent changes or testing smaller batches, coordinating host-confirmed values for WP_MEMORY_LIMIT, WP_MAX_MEMORY_LIMIT, and the effective PHP limit, and applying a measured raise only when the workload warrants it. Paste the exact fatal line and what you were doing when it appeared. We confirm the scope before work begins. Send credentials only through the private access link provided after your request is accepted.
Hosting plan upgrades, multi-site fleets, custom application rewrites, and unrelated feature work are outside this offer. Blank-page paths without a memory line start at white screen of death; recovery-email critical errors at critical error.
Related checks
If isolation, batching, and host-confirmed limits still leave the fatal, send your host the exact error text, the triggering URL or Admin action, the constant and effective PHP values they report, and the start time. Suspected compromise needs a security investigation as well as stopping unexplained growth.