A white screen during an update, a failed WooCommerce checkout, or the message “Allowed memory size exhausted” usually points to the same underlying issue: a PHP process has reached its memory limit. Knowing how to troubleshoot WordPress memory starts with separating a genuine capacity problem from a plugin conflict or inefficient task that happens to trigger the error.
Memory errors are common on growing WordPress sites because the work required for each request changes over time. A small brochure site may run comfortably with a modest limit. Add a visual builder, a large WooCommerce catalog, multilingual content, security scanning, imports, or scheduled jobs, and the same limit may no longer be sufficient.
What a WordPress Memory Error Actually Means#
WordPress runs on PHP, and PHP receives a memory allowance from the server. Every request needs some of that allowance to load WordPress core, the active theme, plugins, database results, images being processed, and any code required for the current task. When a request exceeds the allowance, PHP stops it to protect the server.
You may see an error similar to this:
`Allowed memory size of 134217728 bytes exhausted`
The number is expressed in bytes. For practical purposes, 134217728 bytes equals 128 MB. The message may also identify the file where PHP finally ran out of memory. That file is useful evidence, but it is not always the original cause. A plugin may consume memory gradually, while the error appears later when WordPress tries to load another component.
A higher limit can be the right fix, especially for legitimate resource-heavy operations. It is not automatically the right fix. If a simple page view consumes hundreds of megabytes because of a faulty plugin, an oversized limit can hide the problem until server load or costs increase.
Confirm the Limit Before Changing Anything#
Start by identifying the active PHP memory limit and the situation that triggers the failure. In the WordPress admin area, open Tools, then Site Health, and review the Info section. The Server area typically reports the PHP memory limit, while the WordPress Constants section can show the WordPress memory setting.
These values can differ. WordPress can request a memory limit through its configuration, but the server’s PHP configuration may impose a lower ceiling. For example, WordPress may request 256 MB while the hosting account only permits 128 MB. In that case, changing WordPress configuration alone will not solve the issue.
Also check the timing of the error. Does it happen only when importing products, generating thumbnails, editing a page, running a backup, or sending a large batch of emails? Or does it occur on ordinary front-end page loads? A repeatable trigger narrows the investigation quickly.
If your host provides PHP error logs, review the entries near the failure time. Enable WordPress debug logging temporarily only when needed and only on a controlled environment. Logs can reveal the plugin, theme function, cron job, or administrative action involved without exposing error details to visitors.
Increase Memory Safely When the Workload Requires It#
For many business sites, 256 MB is a sensible working baseline. Stores with complex product data, large imports, page builders, or image-processing tasks may need more. The correct number depends on available server resources, traffic patterns, and the specific work being performed.
The most reliable place to raise the limit is the server-level PHP configuration. Depending on the hosting setup, this may be done through a hosting control panel, a PHP selector, a custom php.ini file, or an account-level PHP configuration file. Managed WordPress hosts may require a support request instead.
You can also tell WordPress to request more memory by adding the following lines to wp-config.php, before the line that says “That’s all, stop editing!”:
`define(‘WP_MEMORY_LIMIT’, ‘256M’);`
`define(‘WP_MAX_MEMORY_LIMIT’, ‘256M’);`
The first setting applies to normal WordPress requests. The second applies to administrative tasks, where WordPress may need additional memory. These constants do not override a lower server-enforced PHP limit, so verify the result in Site Health after making the change.
Avoid editing core WordPress files to change memory. Core updates will overwrite the change, and it will not address the PHP limit enforced by the host. Similarly, do not increase the number blindly to 512 MB or 1 GB on a small VPS. PHP workers can run simultaneously. A high limit multiplied across several concurrent requests can exhaust the server’s physical RAM and cause slower performance or service instability.
Find the Plugin, Theme, or Task Using Too Much Memory#
If the error began after a change, the newest plugin, theme update, extension, or custom code is the first place to look. Deactivate the suspected plugin and repeat the action that failed. If the error disappears, update the plugin, review its settings, or contact its developer with the precise error and steps to reproduce it.
When the cause is not obvious, use a staging site whenever possible. Temporarily switch to a default WordPress theme and test again. Then disable plugins in groups, testing the same action after each change. Once the issue stops, reactivate the last group one plugin at a time. This is slower than guessing, but it produces a dependable answer.
For a live WooCommerce store, do not deactivate essential payment, cart, or inventory extensions during active sales hours. Use a staging copy or a maintenance window. A troubleshooting step that interrupts orders creates a larger operational problem than the original memory error.
Look beyond plugins as well. Common sources of high memory use include poorly optimized custom queries, plugins loading large data sets at once, bulk product imports, full-site backups running during peak traffic, and image tools processing oversized originals. Scheduled tasks can be particularly misleading because they run without an administrator actively using the site.
Check Hosting Resources and PHP Versions#
A WordPress memory issue is sometimes a hosting plan issue. Shared plans can restrict PHP memory, CPU time, processes, or simultaneous connections. Increasing one setting may not help if the account is hitting another resource limit. Review your hosting dashboard for CPU throttling, entry-process limits, disk space, and PHP worker usage if those metrics are available.
An outdated PHP version can also consume more resources and create compatibility problems. Use a currently supported PHP version that is compatible with your WordPress version, theme, and plugins. Test the upgrade on staging first, particularly for stores and sites with custom functionality.
For sites that regularly perform heavy imports, backups, report generation, or automation, a VPS or managed environment with predictable resources may be more economical than repeatedly working around shared-hosting limits. The goal is not to buy the largest server. It is to match capacity to the workload and keep enough headroom for traffic spikes and administrative tasks.
Reduce the Memory Needed for Routine Work#
A permanent fix often combines an appropriate memory limit with less work per request. Break large product or user imports into smaller batches. Schedule backups, scans, and bulk image processing outside business hours. Remove inactive plugins and replace overlapping tools where practical.
Caching helps reduce repeated PHP work for public pages, although it will not fix every admin-side or background-process error. Keep WordPress, themes, and plugins updated, but test significant updates before applying them to a revenue-producing site. Updates can resolve leaks and compatibility issues, yet they can also change resource requirements.
Database maintenance deserves attention on older sites. Expired transients, oversized options, excessive revisions, and plugin-created tables can add unnecessary overhead. Cleanups should be targeted and backed up first. Deleting data without understanding its purpose can break settings, scheduled tasks, or store functions.
When to Escalate the Problem#
Contact your hosting provider when the server refuses to apply a documented memory limit, logs show account-level resource restrictions, or the issue affects several unrelated sites on the same account. Contact a plugin or theme vendor when you can reliably reproduce the failure with their component active and provide the exact WordPress, PHP, and plugin versions.
Include useful evidence: the full error message, the action that triggers it, the current PHP memory limit, recent changes, and relevant log entries. This saves time and gives support teams enough detail to investigate instead of starting with general advice.
A memory error is most useful when treated as a measurement, not just an obstacle. Set a realistic limit, identify what consumes it, and test changes against the task that failed. That approach keeps WordPress stable while giving your site room to grow without wasting server resources.