Skip to content
Website Rescue Rescue

WordPress Errors

WordPress Memory Exhausted

Intermediate Risk: medium

Last reviewed

Hosting access often needed Database access usually not needed

Graphic options · pick what to keep

statusBadge

decisionTree

browserMock

requestTimeline

Direct answer

WordPress memory exhausted means a PHP request ran out of RAM while WordPress was loading—raise the host memory_limit and align WP_MEMORY_LIMIT / WP_MAX_MEMORY_LIMIT in wp-config.php, then find the plugin, builder, or import that is consuming memory instead of endlessly raising the ceiling.

WordPress often surfaces memory exhaustion as a critical-error screen, white screen, failed wp-admin task, or HTTP 500 with “Allowed memory size exhausted” in the log. Page builders, WooCommerce, backup plugins, and bulk imports are frequent triggers. This guide explains how WordPress memory constants relate to php.ini, how to recover safely, and how to tell a memory fatal apart from other WordPress crashes.

Intermediate

What the error means

Every WordPress page load runs inside a single PHP worker with a memory budget set by the host’s memory_limit directive. When WordPress, a theme, or a plugin tries to allocate past that ceiling, PHP stops the request with a fatal: “Allowed memory size of X bytes exhausted.” WordPress can ask for more headroom through WP_MEMORY_LIMIT (front-end and general requests) and WP_MAX_MEMORY_LIMIT (admin and elevated contexts) in wp-config.php—but those defines cannot exceed what php.ini allows. A host capped at 128M will still stop at 128M even if wp-config says 512M. Memory exhaustion is a resource failure, not a syntax or compatibility error: the code may be fine in principle but the request tried to hold too much data at once. On shared hosting, repeated memory fatals can also trigger account-level resource suspensions that look like a broader “site down” problem.

Common symptoms

  • Error log or wp-content/debug.log shows “Allowed memory size of … bytes exhausted” with a path under wp-content/plugins or wp-content/themes
  • Critical error screen or white screen on heavy pages (builders, cart, reports) while simpler pages still load
  • wp-admin fails during plugin updates, media bulk uploads, WooCommerce exports, or Site Health checks
  • Elementor, Divi, Beaver Builder, or similar editors crash mid-load while the public homepage mostly works
  • HTTP 500 or a generic host error page timed to the same memory fatal in logs
  • Raising memory_limit temporarily restores the page; lowering it reproduces the crash on the same URL
  • Symptoms worsen after adding a plugin, enlarging a page, importing products, or enabling a new backup/sync job

Most likely causes

  1. 01 Host PHP memory_limit too low for the current WordPress plugin and builder stack
  2. 02 WP_MEMORY_LIMIT unset or lower than admin-heavy workflows require
  3. 03 Page builder, WooCommerce, analytics, or related-products plugins loading oversized datasets in one request
  4. 04 Runaway loop, unbounded query, or memory leak in a custom snippet, mu-plugin, or poorly written extension
  5. 05 Image, XML, or CSV import processing huge files in a single PHP worker without batching
  6. 06 Object-cache or opcode-cache issues amplifying memory use after a partial plugin or PHP update
  7. 07 MultiPHP INI or plan downgrade that reset memory_limit after a PHP version change

What changed before the problem started

  • New or updated page builder, WooCommerce extension, backup, or migration plugin
  • PHP version or MultiPHP INI change that lowered memory_limit on the account
  • Large product, media, or page import run from wp-admin or a migration tool
  • Theme customization or code snippet that queries too many posts or meta rows at once
  • Traffic or cron spike hitting a heavy admin-ajax, REST, or Action Scheduler endpoint
  • Host plan change or resource enforcement after the site outgrew shared limits

Troubleshooting steps

  1. 01

    Confirm the fatal is memory exhaustion

    Open the host error log or wp-content/debug.log and search for “Allowed memory size” or “exhausted.” Note the file path—it often names the plugin, theme, or core include. If the fatal mentions undefined functions, parse errors, or type errors, treat that as a different WordPress crash playbook.

  2. 02

    Raise the host PHP memory_limit first

    In cPanel MultiPHP INI, Plesk PHP settings, or your host’s PHP manager, set memory_limit to at least 256M for typical WordPress sites (512M when builders and WooCommerce run together, if the plan allows). Save, wait a minute for the change to apply, and retest the failing URL in a private window.

  3. 03

    Align WordPress memory constants in wp-config.php

    Add or update `define('WP_MEMORY_LIMIT', '256M');` and, for stubborn wp-admin tasks, `define('WP_MAX_MEMORY_LIMIT', '512M');` above the “That’s all, stop editing!” line. These cannot exceed the host memory_limit—verify both layers match.

  4. 04

    Isolate the heavy plugin or builder

    If a reasonable limit still exhausts, rename the plugins folder via FTP or file manager, or disable likely offenders (builder, backup, feed/sync, statistical plugins) one at a time. Restore service with a sane limit, then re-enable extensions while watching the log for the next fatal line.

  5. 05

    Retest the specific heavy workflow

    Reproduce the same action: open the builder, run the import, load the WooCommerce report, or save the large page. Confirm the memory fatal is gone and that lighter pages still behave. Purge page cache and CDN cache so you are not viewing a cached success or failure.

  6. 06

    Enable WP_DEBUG_LOG without displaying errors

    Set WP_DEBUG and WP_DEBUG_LOG true with WP_DEBUG_DISPLAY false while reproducing once. Capture the stack trace, then turn debug display off so visitors never see paths, queries, or other internals on a live site.

When to stop troubleshooting

Escalate if the host hard-caps memory below what your stack needs, logs point to encoded or core files you cannot safely replace, exhaustion continues at 512M+, checkout or wp-admin stay down during business hours, or the host suspended the account for resource abuse. Bring the exact fatal line, phpinfo memory_limit, WP_MEMORY_LIMIT values, and a list of builder and WooCommerce plugins.

Information to collect before requesting help

  • 01 Exact “Allowed memory size … exhausted” log line with file path
  • 02 Effective memory_limit from phpinfo or host PHP settings
  • 03 Current WP_MEMORY_LIMIT and WP_MAX_MEMORY_LIMIT values if set
  • 04 Whether failure is front end, wp-admin, builder preview, REST, or cron
  • 05 Recent plugin, theme, PHP, import, or traffic changes
  • 06 WordPress, WooCommerce, and page-builder versions
  • 07 Hosting provider, plan type, and any resource-limit notices from the host

How a professional repairs the problem

We confirm the fatal is memory exhaustion—not a generic critical error—then raise host and WordPress limits to a safe baseline for your stack. We isolate the plugin, builder view, import job, or cron task consuming RAM, reconfigure or replace leaky components, and leave limits high enough for legitimate workloads without masking runaway processes. When the host enforces account caps, we document what the site actually needs and coordinate a plan or optimization path so the next traffic spike does not trigger another suspension.

Frequently asked questions

Is WordPress memory exhausted the same as a critical error? +
A memory fatal often triggers the critical-error screen on modern WordPress, but not every critical error is memory-related. Read the log: only “Allowed memory size exhausted” confirms this playbook. Other fatals need plugin conflict or compatibility fixes instead.
Why did raising WP_MEMORY_LIMIT do nothing? +
WordPress cannot exceed the server memory_limit in php.ini. Update the host PHP setting or MultiPHP INI first, then align wp-config constants. If both match and it still fails, a plugin is consuming more than any reasonable ceiling.
How much memory does WordPress need? +
Simple brochure sites may run at 128M; builder-heavy and WooCommerce stacks often need 256M–512M. If one plugin alone needs far more, fix, replace, or batch its work rather than treating megabytes as unlimited.
Can Elementor, Divi, or WooCommerce alone trigger this? +
Yes. Editor loads, large catalogs, cart/checkout with many extensions, and report screens are common triggers. Raise limits reasonably, update the extension, and reduce overlapping heavy plugins that all load on the same request.
Will more memory hide a bad plugin forever? +
Only temporarily. A leaky or unbounded process will eventually hit any ceiling and can violate shared-host neighbor policies. Use a higher limit to recover, then repair or replace the culprit.
Does a white screen always mean memory exhaustion? +
No. White screens and critical errors have many causes. Trust the “Allowed memory size exhausted” wording in debug.log or the host error log before focusing on memory_limit and wp-config defines.

Repair dispatch

Still Need Help Fixing Your Website?

If you are not comfortable editing website files, changing server settings, repairing a database, or troubleshooting a live website, professional help may prevent additional damage or downtime. We will review the problem before accepting the repair.

  • You will receive a clear explanation of the likely cause.
  • We will tell you if the issue falls outside our repair scope.
  • No additional work will be performed without approval.
  • A backup should be created whenever access and website condition allow it.
Emergency repair Request diagnosis

Do not share passwords through an unencrypted contact form.

Written by Website Rescue

Last reviewed

Platform note: Full rescue available for WordPress and self-hosted sites. Wix, Squarespace, Webflow, Weebly, and similar closed builders have very limited backend access — fixes may not be possible. I will tell you honestly before we start.