Fixing the WordPress “Death Loop”: When Missing Files slow down your site

You’ve just launched your new WordPress site or pushed a big update. In your staging environment, everything ran perfectly. But the moment you go live and real traffic hits, the site grinds to a halt. You check your control panel and see your RAM and CPU usage are maxed out, affecting every other domain on your account.

What’s going on? You might be a victim of what we call the WordPress Death Loop.

What is the WordPress Death Loop?

To understand the Death Loop, you have to understand how WordPress handles missing files (404 errors).

Normally, if a browser asks for an image that doesn’t exist, a standard web server just says “File Not Found” and moves on. It takes almost zero server power. But WordPress is designed to catch those missing file requests. Instead of a simple “Not Found” message, WordPress fires up its core engine (index.php) to generate a fully themed, heavy 404 error page.

Now, imagine your homepage has a broken link to one CSS file and one image. That means every single time a visitor loads your homepage, WordPress actually runs three times: once for the actual page, once for the missing CSS, and once for the missing image.

If you have 10 missing assets, one page load becomes 11 full WordPress executions. Combine this with normal daily traffic, or worse, automated bots scanning your site for vulnerabilities, and your server will quickly buckle under the weight of hundreds of unnecessary PHP processes.

The Symptoms: A Overwhelmed Server

When this happens, your server process list will look like a traffic jam of index.php calls. Bots and scrapers often trigger this by probing your site for files that don’t exist, like random sitemaps in your wp-includes folder.

If you look at your server logs or process monitor, you’ll see something like this eating up your RAM and CPU:

username   53369  4.5  0.0 485676 150976 ?  Rs  12:54  0:56 lsphp:s/yourdomain.com/public_html/index.php
username   62223  4.4  0.0 485268 145212 ?  Ss  13:01  0:33 lsphp:s/yourdomain.com/public_html/index.php
username   63068  4.4  0.0 485244 148588 ?  Ss  13:02  0:32 lsphp:s/yourdomain.com/public_html/index.php
username   64409  4.5  0.0 485436 164472 ?  Rs  13:03  0:30 lsphp:s/yourdomain.com/public_html/index.php
username   68910  4.4  0.0 485100 149412 ?  Ss  13:07  0:19 lsphp:s/yourdomain.com/public_html/index.php
...[dozens or hundreds more]...

A common culprit we see in the logs is bots making tons of calls to paths like:
https://www.yourdomain.com/wp-includes/assets/sitemap_index.xml

Because that file doesn’t exist there, WordPress intercepts the request, loads index.php to build a 404 page, and the Death Loop begins.

How to Fix It

The solution is straightforward: we need to stop WordPress from handling 404 errors for certain directories and let the web server handle them quickly and efficiently instead.

If bots are hammering your wp-includes directory (a very common target), you can turn off WordPress’s routing rules for that specific folder.

Step-by-Step Fix

1. Log into your InterServer account and open your File Manager (or connect via FTP).
2. Navigate to your website’s root directory (usually /home/username/domains/yourdomain.com/public_html/).
3. Open the wp-includes folder.
4. Create a new file and name it exactly .htaccess (don’t forget the dot at the beginning).
5. Edit the file and add this single line of code:

   RewriteEngine off

6. Save the file.

Why this works: Adding RewriteEngine off turns off WordPress’s ability to rewrite URLs in that folder. Now, when a bot requests /wp-includes/assets/sitemap_index.xml, the server immediately sees the file isn’t there and returns a lightweight, standard server 404 error. It bypasses WordPress completely, saving your CPU and RAM, and breaking the Death Loop.

Note: You can apply this same fix to your wp-content/uploads folder if you find that broken image links are causing similar resource spikes.