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 →