How We Fixed a Memory Exhaustion Crash on a Large WordPress Site (1.700+ Pages, 20.000+ Posts)

—

How We Fixed a Memory Exhaustion Crash on a Large WordPress Site (1.700+ Pages, 350+ Posts)

If you run a WordPress site with thousands of pages and hundreds of blog posts, you may eventually run into a white screen of death (WSOD). This is exactly what happened on berndpulch.org – and here’s how we tracked it down and fixed it, step by step.

—

The Symptom
The front page of the site suddenly displayed a blank white screen, while the WordPress dashboard (backend) remained fully accessible. Site Health reported a fatal PHP error:
“Allowed memory size of 536870912 bytes exhausted” – meaning the server ran out of memory while trying to render the homepage.

—

The Timeline

1. The original homepage crashed.
2. We duplicated it and set the copy as the new homepage – it worked for about two hours.
3. Then we activated the SEO plugin RankMath. Immediately, the white screen returned.
4. Even after deactivating all plugins, resetting permalinks, and switching to a default theme (Twenty Twenty-Two), the homepage remained broken.
5. A brand-new, empty test page set as the homepage also triggered the same memory error – proving that the issue was not caused by page content itself.

—

The Root Cause (Identified with WordPress.com Support)
After thorough investigation, the support team found two major performance killers:

1. A sidebar widget listing all pages – Our site had over 1,700 pages, and the classic “Pages” widget tried to generate a complete list on every homepage visit. That alone consumed massive memory.
2. Too many posts per page – The blog archive was set to display 350 posts at once. With 350+ published posts and featured images, the server simply ran out of memory.

Additionally, the theme we were using – Independent Publisher 2 – is not optimised for such large content volumes, making the situation worse.

—

The Fix
The support team tested a copy of the site with the following changes:

· Removed the “Pages” widget from the sidebar (moved to inactive widgets).
· Reduced the number of posts per page from 350 to 50 (and later to 10 for extra safety).
· Switched back to Independent Publisher 2 – and it loaded cleanly without crashes.

This confirmed that the problem was not the theme itself, but the overwhelming amount of data it was forced to display.

—

Current Status & Next Steps
As of today, the site is temporarily running on the default Twenty Twenty-Two theme while we wait for the support team to permanently delete the oversized sidebar widget on the backend (since block themes like TT2 hide classic widget areas from the user interface).

Once the widget is removed, we will reactivate Independent Publisher 2 – and the site will run stable again.

For the long term, we are considering migrating to Twenty Twenty-Four or Twenty Twenty-Five, both of which are block-based, memory-efficient, and officially maintained by WordPress – ideal for large sites with hundreds of posts and pages.

—

Key Takeaways

· A white screen of death is often caused by memory limits, not broken code.
· Large sidebar widgets (especially page lists) can overload your server.
· Reducing “posts per page” to a reasonable number (10–20) significantly reduces memory usage.
· Switching to a modern block theme (like TT4 or TT5) can prevent these issues entirely.

If you’re experiencing similar problems, check your widgets and archive settings first – you might save yourself hours of troubleshooting.

—

This article will be updated once the final theme switch is completed and the site is fully restored.