To fix the WordPress memory exhausted error, increase the permitted PHP memory where hosting allows, then identify what consumed it. Raising the limit can restore access, but faulty code may exhaust the new allowance too.
For a small business, this failure can interrupt enquiries whilst a cached homepage still looks healthy. Start with evidence and a recoverable backup, then make one controlled change at a time.
Key takeaways
- Read the error’s byte value and compare it with your site’s PHP settings.
- Back up before editing configuration files, and test disruptive changes on staging.
- Increase memory only within available hosting capacity, then investigate plugins, themes and the failing request.
1. Confirm the WordPress memory exhausted error
Read the numbers correctly
The message Fatal error: Allowed memory size of 134217728 bytes exhausted means a PHP request reached its allocation limit.
Divide bytes by 1,048,576 to get the familiar memory figure. These common values help identify the active limit:
| Bytes in the error | Memory limit |
|---|---|
| 67108864 | 64 MB |
| 134217728 | 128 MB |
| 268435456 | 256 MB |
| 536870912 | 512 MB |
The first number is the limit. If the message also says “tried to allocate”, that second number is the next allocation PHP attempted, not total usage.
Compare server settings and browser behaviour
Open Tools > Site Health > Info > Server and note the PHP memory limit. Record the affected URL, action and failure time too.
WordPress’s fallback memory requests are 40 MB for single sites and 64 MB for multisite. Higher existing PHP limits remain in place. Some older or restricted hosting configurations start at 32 MB.
If only one browser fails, try a private window without extensions. A browser’s own out-of-memory message doesn’t establish a server-side PHP failure.
2. Increase memory through wp-config.php
Back up and edit the existing definition
Back up the database and files first. Also download an untouched copy of each configuration file before editing it. A missing quote or semicolon can stop WordPress loading.
Connect with an FTP client or SFTP, or use cPanel File Manager, to open wp-config.php in the WordPress installation directory. Find an existing WP_MEMORY_LIMIT definition and edit it rather than adding a duplicate.
Set:
define('WP_MEMORY_LIMIT', '256M');
Place it above the comment containing “That’s all, stop editing! Happy blogging.”
Save, then repeat the exact failing action. WordPress’s memory troubleshooting guidance covers configuration changes for exhausted memory.
Allow more memory for administration
For demanding dashboard operations, you can also set:
define('WP_MAX_MEMORY_LIMIT', '512M');
WP_MEMORY_LIMIT establishes the ordinary requested allowance across requests. WordPress can raise this to WP_MAX_MEMORY_LIMIT for administration and other memory-intensive operations, such as image processing.
These values request 256 MB normally and up to 512 MB for heavier work. They don’t reserve RAM or override a hosting-enforced ceiling.
If the site recovers, continue investigating. Repeatedly increasing allowances can conceal a plugin memory leak or an excessively large operation.
3. Change PHP settings safely when necessary
Prefer the hosting panel or active php.ini
Where available, use your hosting panel’s PHP settings to change memory_limit to 256M.
Otherwise, edit the website’s active php.ini and set:
memory_limit = 256M
The web server may read a different php.ini from command-line PHP. Ask your hosting provider which file the active web handler uses, as editing the wrong file changes nothing.
If the change doesn’t take effect, PHP-FPM or the web server may need reloading or restarting. On shared or managed hosting, leave service restarts to support. Then inspect Site Health and repeat the failing request.
The PHP memory_limit documentation describes the per-script allocation limit. Avoid removing that protection with an unlimited setting.
Use .htaccess only with Apache’s PHP module
On Apache hosting running PHP as an Apache module, this directive may work:
php_value memory_limit 256M
Add it to the backed-up .htaccess file only when that handler supports PHP directives there.
On PHP-FPM or FastCGI hosting, this line can trigger a 500 error because Apache doesn’t recognise the directive. Nginx doesn’t use .htaccess.
If the site fails immediately afterwards, remove the added line or restore the saved file. Use the hosting panel or the appropriate PHP configuration instead.
4. Read logs without exposing errors publicly
Start with the hosting panel’s PHP error log. Match entries to the recorded failure time rather than chasing unrelated warnings.
If needed, temporarily enable WordPress logging in wp-config.php. Edit existing definitions or add missing ones before the stop-editing comment:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
Reproduce the failure once, then inspect wp-content/debug.log.
Look for the matching fatal error, file path and stack trace. A path containing wp-content/plugins/ identifies a plugin involved in execution, but another component may have called it. The final allocation can fail in WordPress core even when a plugin consumed most memory earlier.
The file named in a memory error shows where allocation failed. It doesn’t automatically identify the component responsible for the growing usage.
Restrict access to diagnostic logs because they can expose server paths and sensitive information. Afterwards, set WP_DEBUG back to false, remove temporary logging settings and securely delete unneeded logs.
5. Isolate plugins, then test the theme
Deactivate without deleting data
Use an isolated staging copy wherever possible. Disconnect copied email marketing integrations and automation systems so tests don’t contact real clients.
If logs identify a suspect, deactivate it first; otherwise, deactivate plugins one at a time using this sequence:
- Record active plugins and versions, then deactivate ordinary plugins through Plugins > Installed Plugins.
- Repeat the exact action that failed.
- If it succeeds, reactivate plugins individually, enabling parent plugins before dependent add-ons.
- Retest after each activation and record when the error returns.
The latest activation identifies a suspect, not necessarily the sole cause. Test its interaction with other active components. Our plugin conflict troubleshooting guide covers that distinction.
Recover access and investigate themes
Without dashboard access, use SFTP or File Manager to rename wp-content/plugins to plugins-deactivated.
If access returns, open the dashboard’s Plugins screen whilst the folder remains renamed. Then restore its name to plugins and reactivate individually. When there’s a clear suspect, rename only that plugin’s folder instead.
Don’t delete folders or run uninstall routines. Must-use plugins and hosting drop-ins require separate investigation.
If ordinary plugins aren’t responsible, switch staging to an installed, compatible default theme, such as Twenty Twenty-Five. Repeat the failure, then restore the original theme. Investigate its child theme and recent web development changes if the test succeeds.
Theme switching can alter web design, so avoid casual live-site experimentation.
6. Diagnose Elementor and other heavy operations
For Elementor sites, open Elementor > System Info and review the reported memory information. Compare it with Site Health rather than assuming a saved setting took effect.
Next, compare a lightweight page with the failing page on staging. Test third-party Elementor add-ons separately. Large nested layouts, extensive dynamic content and complex templates deserve investigation when only particular pages fail.
Elementor Safe Mode helps isolate editor-loading conflicts. It doesn’t prove that public pages or form submissions work.
Also test image processing and imports separately. A compressed photograph can require much more memory when WordPress opens it and generates thumbnails.
Query Monitor can show request memory usage and help trace execution. Server IP and Memory Usage and WP-Memory-Usage are other monitoring tools. Run diagnostic tools on staging where possible, since they add overhead.
For shops, WooCommerce’s memory-limit guidance covers increasing allowances through configuration or hosting support.
7. Address hosting limits and prevent recurrence
If the error still reports 128 MB after you’ve requested 256 MB, the runtime limit hasn’t increased. A hosting ceiling, duplicate definition or different active configuration file may explain it.
Send support the error, timestamp, affected action, Site Health value and changes attempted. Ask for the effective web PHP limit to be raised within the account’s available capacity.
Shared hosting often restricts memory. If legitimate workloads repeatedly exceed the plan’s resources, ask whether you need to upgrade hosting plan resources or move to a suitably sized VPS. Our managed and shared hosting comparison explains the different support responsibilities.
A memory leak can exhaust a larger allowance too. Repair or replace faulty code before treating an upgrade as the complete fix.
Build monitoring, staged updates and rollback ownership into website care and maintenance. After repairs, test mobile-responsive layouts and follow lead generation forms through to their confirmation emails. Keep staging activity out of digital marketing and conversion optimisation reports.
For agencies managing client websites, See how we collaborate with creative agencies when you need technical support alongside your existing team.
Frequently asked questions
Will increasing PHP memory make every page faster?
No. A higher limit allows a request to allocate more memory before failing. It doesn’t directly improve database queries, reduce JavaScript or fix slow external services.
If memory exhaustion has stopped, investigate remaining performance problems separately. Avoid increasing the allowance repeatedly without measuring the failing operation.
What should I do if the homepage works but administration fails?
Repeat the specific dashboard action and inspect its matching log entry. A cached homepage may load without running the PHP operation that’s failing.
Check the effective administration allowance and investigate the relevant task, such as an import, image operation or plugin update. Retest outside your logged-in session afterwards.
Restore the request, then fix the cause
A lasting repair combines an appropriate memory allowance with repeatable diagnosis. Confirm the effective limit, isolate the failing component and preserve a rollback route.
Before closing the incident, repeat the original action and test the customer journey. A working homepage alone doesn’t prove that bookings, enquiries or payments have recovered.
