Short answer: PHP reached its memory ceiling while building the page and stopped. Raising the limit sometimes restores service, but if something is consuming memory abnormally, a higher ceiling only delays the same failure.
Read the message properly
The error names the number of bytes PHP tried to allocate and the file that asked for them — for example Allowed memory size of 268435456 bytes exhausted (tried to allocate …) in /wp-content/plugins/…. That path is a strong clue. A few megabytes over the limit suggests a genuinely tight setting; an attempt to allocate an enormous block points at a loop or an unbounded query.
Raise the limit correctly
Add to wp-config.php, above the stop-editing line: define('WP_MEMORY_LIMIT', '256M'); and for admin-side operations define('WP_MAX_MEMORY_LIMIT', '512M');. Many hosts cap PHP memory at server level, so also confirm the effective value in Tools › Site Health › Info › Server. If the host caps it, editing the file will not override it and you will chase a change that never applied.
Find what is actually consuming it
- Note whether the error appears everywhere or only on one screen. A single failing report or import points at that feature, not the whole site.
- Enable
WP_DEBUG_LOGand read the file and line requesting the allocation. - Test with the plugins-folder rename over SFTP: if the error disappears with plugins off, re-enable one by one to find the memory-hungry one.
- Correlate with recent changes — a new plugin, a large media upload, a data import, a traffic increase.
Verify with the real operation
Re-run the exact task that failed — the import, the report, the media upload — and watch whether memory use is now stable or merely under the new ceiling. If a single request still consumes hundreds of megabytes, the underlying inefficiency remains and the site will fail again under load. Genuinely heavy jobs (large imports, backups) belong on the command line via WP-CLI, not a browser request.
WP REPAIR INCIDENT STANDARD
How to narrow the fault without guessing
Memory exhaustion names a ceiling and the allocation that crossed it. The useful question is whether the limit is genuinely too low or one request is growing without bound.
Record the allowed bytes, attempted allocation and file path from the fatal message.
Confirm the effective PHP and WordPress limits rather than assuming wp-config.php overrode the host.
Identify whether one report, import or media operation triggers the growth.
Compare memory use with plugins disabled in staging or with the named component isolated.
What must be verified
- The exact operation completes with stable peak memory.
- Normal traffic leaves headroom for concurrent requests.
- No new memory fatal appears in PHP or WordPress logs.
Official technical sources
This guide explains the diagnosis. If the site is affected now, the intervention should preserve a rollback path and verify the real business journey.
See the emergency repair service →ABOUT THIS SYMPTOM
Frequently asked questions about this guide.
How can I tell from the error message alone whether this is a genuinely tight limit or a bug consuming memory abnormally?+
Look at how much memory it tried to allocate relative to your limit. An attempt to grab just a few megabytes over the ceiling suggests a genuinely tight setting; an attempt to allocate an enormous block points at a loop or an unbounded query somewhere in the code, which raising the limit won't actually fix.
I raised WP_MEMORY_LIMIT in wp-config.php but the error persists, why?+
Many hosts cap PHP memory at the server level, which overrides what you set in wp-config.php. Check the effective value under Tools > Site Health > Info > Server — if the host's cap is lower than your setting, editing the file alone won't change anything and you need to raise it with your host instead.
Does the error appearing on only one admin screen mean something different than if it happens everywhere?+
Yes — an error confined to a single report, import, or screen points at that specific feature, not a site-wide memory shortage. An error appearing everywhere suggests a broader issue worth investigating before simply raising the ceiling.
After raising the memory limit, how do I know the underlying problem is actually solved?+
Re-run the exact task that failed — the import, the report, the upload — and check whether memory use is now stable rather than just squeezing under a higher ceiling. If a single request still consumes hundreds of megabytes, the inefficiency remains and the site will fail again under load; genuinely heavy jobs belong on WP-CLI, not a browser request.