WordPress Site Showing a Blank Page? I Found Malware in index.php [Case Study]

If your WordPress site is showing a blank page, the most common causes are plugin conflicts, broken themes, PHP fatal errors, memory problems, or malware. In this case study, I found that the blank page was caused by obfuscated malware injected into the site’s root index.php file, which blocked WordPress from loading normally.

A WordPress site showing a blank page usually makes people think of a plugin conflict, a broken theme, a memory issue, or the classic White Screen of Death.

Sometimes that is true.

But in this case, the blank page had a very different cause.

The site owner first noticed that his website showed nothing but a blank page. No homepage. No useful error. Just an empty screen. Like most website owners, he tried the common advice first and even asked ChatGPT to help troubleshoot the issue. When that did not solve the problem, he contacted me on WhatsApp and asked me to inspect the site directly.

What I found was not a normal WordPress error.

The site’s root index.php file had been infected with obfuscated malware. That single file was enough to block the normal WordPress load process and leave the entire website looking dead.

If your own site is blank, hacked, reinfected, or behaving strangely, you may need a proper WordPress malware removal service rather than basic troubleshooting.

Case Summary

• Symptom: The WordPress site showed a completely blank page.
• Initial assumption: It looked like a normal White Screen of Death or plugin issue.
• Real cause: The root index.php file had been replaced with obfuscated malware.
• Why it happened: The malware intercepted requests and failed to load WordPress normally for standard visitors.
• Fix: Remove the malicious loader, replace the infected file with a clean version, check for persistence, and harden the site.

Why this case matters

This case is important because a blank WordPress page is only a symptom. It does not tell you the real cause.

A blank page can be triggered by:

• a plugin conflict
• a broken theme update
• a PHP fatal error
• memory exhaustion
• file corruption
• bad permissions
• malware

In this cleanup, the visible symptom was simple: the site looked completely blank.

The real cause was far more serious: the attacker had replaced the website’s front entry file with a malicious PHP loader.

What the client actually saw

From the client’s point of view, the problem was straightforward:

• the website opened as a blank page
• there was no useful frontend output
• the site looked broken or dead
• normal troubleshooting did not fix it

This is exactly why symptom-focused SEO matters for a case study like this. Most clients do not search for “index.php cloaking malware” or “obfuscated PHP traffic filter.”

They search for things like:

• WordPress site showing blank page
• WordPress blank homepage
• website shows nothing
• WordPress white screen no error
• homepage suddenly blank

That is the real-world problem they are trying to solve.

What I found in index.php

When I checked the root index.php, it was clearly not a clean WordPress file. A normal WordPress root index.php is very short and simply loads WordPress. This one was packed with obfuscated PHP, goto jumps, encoded strings, and remote request logic.

Here is a defanged and shortened sample that shows the key behavior without reproducing the full payload:

<?php
$vGmqg = 'hxxp://142[.]54[.]188[.]122/z60424_o/';

function gnySF($url, $data = array()) {
    // sends POST requests to a remote server
}

function SKgHu($ua) {
    // checks whether the visitor looks like Googlebot, Bingbot, etc.
}

function LMaEG($referrer) {
    // checks whether the visitor came from a search engine
}

That short excerpt already reveals a lot. This was not damaged core code. It was a malicious loader built to inspect traffic, contact a remote server, and decide what to do next.

If you have seen suspicious PHP in your own root file, this related write-up may also help: Malicious PHP script detected in index.php.

How the malware worked

1. It contacted a remote server

The infected file defined a remote base URL and built requests to endpoints such as:

• robots.php
• map.php
• words.php
• jump.php
• indata.php

That means the malware was not just sitting there passively. It was designed to communicate externally and fetch instructions or output.

2. It checked bots and search traffic

Two of the most revealing functions were the ones that checked:

• whether the visitor looked like a bot or search engine crawler
• whether the referrer appeared to come from Google, Bing, Yahoo, or similar sources

This is a strong sign of cloaking behavior. The script cared about who was visiting and how they arrived.

3. It had logic for sitemap and robots-related requests

The code also handled XML, sitemap-style requests, and robots-related behavior. That is not normal for a clean WordPress index.php.

When malware includes bot detection plus robots/sitemap logic, it often points to:

• SEO spam support
• cloaking
• redirect targeting
• search result poisoning
• selective content delivery

4. It treated different visitors differently

The script appears to separate:

• normal human visitors
• bots and crawlers
• search-engine referrals
• XML or sitemap-related requests
• certain URL patterns

That is a big clue. This file was acting like a traffic filter rather than a normal WordPress bootstrap file.

Why the site showed a blank page

This is the key question.

A clean WordPress root index.php should load the WordPress environment and pass the request to the rest of the site. In this case, the infected file did not behave like a standard WordPress entry file at all.

Instead, it:

• intercepted the request
• checked the visitor type
• built remote requests
• handled special conditions
• did not reliably continue into the normal WordPress load path

So the site went blank because the malware effectively replaced the normal front door of WordPress.

In plain English, this is what happened:

1. a real visitor opened the site
2. the infected index.php ran first
3. the script checked conditions and traffic type
4. it did not properly load WordPress for that request
5. the browser received no meaningful output
6. the visitor saw a blank page

So this was not just a random white screen. It was the visible result of a malicious front-controller replacement.

Why this was more dangerous than “just a blank site”

The blank page was only the obvious symptom.

The bigger risk was what the malware was trying to do behind the scenes. Based on its behavior, this script could potentially support:

• cloaked spam pages
• manipulated sitemap or robots responses
• search-engine targeting
• redirect behavior
• SEO poisoning
• selective content delivery

So even if the owner only noticed “my site is blank,” the actual risk could include search visibility damage, spam indexing, or hidden traffic abuse.

If you are investigating suspicious indexing or hidden spam, also see:

• How to detect WordPress malware
• Why WordPress malware keeps coming back

How I approached the cleanup

Once I confirmed that index.php was infected, I handled it as a malware incident, not just a blank-page debugging issue.

1. I confirmed the visible symptom

I verified that the site was genuinely serving a blank page and treated it as a live outage.

2. I inspected the root entry file early

Because the site showed no useful output, I checked the root file path early instead of wasting too much time on plugin-only assumptions.

3. I compared the file against a clean WordPress baseline

A clean WordPress index.php is tiny and predictable. This one clearly was not.

4. I removed the malicious loader

The visible infected file had to be removed and replaced with a known-clean version.

5. I checked for persistence

When index.php is infected, I never assume that file is the only problem. I also check for:

• hidden droppers
• recently modified PHP files
• malicious mu-plugins
• suspicious cron jobs
• database injections
• rogue admin users
• theme and plugin tampering

This is where many quick cleanups fail. The visible file gets replaced, but the hidden source remains.

6. I hardened the site after cleanup

Once the infection was removed, the next job was to reduce the chance of reinfection by tightening the site’s security posture.

What made this different from a normal White Screen of Death fix

Many WordPress blank page issues really are caused by plugin conflicts, memory limits, or failed updates. That is why blank-page guides often start with standard troubleshooting.

But this case was different because the blank page was caused by intentional malicious logic.

A normal fix might involve:

• disabling plugins
• switching themes
• increasing PHP memory
• enabling debugging

A malware cleanup requires something deeper:

• file integrity verification
• code review
• persistence hunting
• credential review
• log inspection
• hardening after cleanup

If you want to compare this with a more classic malware-triggered white-screen scenario, read: How to fix the WordPress white screen of death caused by Zeura malware.

Signs your “blank page” may actually be malware

If your WordPress site is blank and any of the following are also true, malware should be on your shortlist:

• the root index.php is longer than expected or heavily obfuscated
• you see goto chains, encoded strings, or strange cURL logic
• the site behaves differently for bots or certain URLs
• robots.txt or sitemap behavior suddenly changes
• the blank page appeared without a clear plugin/theme explanation
• the site comes back briefly and then breaks again
• the infection returns after a quick file replacement

If that sounds familiar, the problem may be bigger than a routine frontend error.

The SEO lesson from this case

This site owner did what most people do first: he searched for help based on the symptom.

That is why case studies like this should be written around what real clients experience, not just the malware label.

People do not usually search for:

• obfuscated cloaking loader in index.php
• bot-aware PHP SEO malware
• remote content loader in WordPress root

They search for:

• WordPress site showing blank page
• WordPress site shows nothing
• homepage blank no error
• WordPress white screen
• website suddenly blank

That is the search intent this case study is built for.

What to do if your WordPress site shows a blank page

If you are dealing with this right now, do not assume it is only a plugin conflict.

Start with this order:

1. take a backup of the current state
2. check whether wp-admin is also affected
3. inspect the root index.php
4. enable debugging if needed
5. compare suspicious core files against clean WordPress originals
6. review recent modifications and access logs
7. look for persistence before calling the site clean

If the site is business-critical, it is often safer to get a manual cleanup than to keep guessing.

For a related example of recurring root-file infections, see: Case study: fixing regenerating index.php malware in WordPress.

Final thoughts

This case started with a simple symptom: a WordPress site showing a blank page.

But the real issue was malware inside index.php.

That single infected file changed the site’s front door into a traffic filter, a remote-content loader, and a cloaking component. For normal visitors, the result was a blank screen. For bots or selected traffic, the behavior could be very different.

That is why I always say this:

A blank page is a symptom. The real job is finding the code path that created it.

If your WordPress site is blank and the usual troubleshooting steps are not solving it, there is a real chance you are dealing with file-level compromise, not just a harmless error.

Need help cleaning a hacked or blank WordPress site? Check my WordPress malware removal service.

FAQ

Why is my WordPress site showing a blank page with no error?

The most common causes are plugin conflicts, theme issues, PHP fatal errors, failed updates, or memory limits. But in some cases, malware replaces important files like index.php, which can blank the site without showing a normal error.

Can malware cause a WordPress blank page?

Yes. Malware can break rendering directly, replace the normal WordPress load path, or interfere with output so the browser receives nothing useful.

How do I know if my blank page is malware or just a plugin issue?

Check whether core files look normal, especially index.php. If you see obfuscated code, remote URLs, bot checks, encoded strings, or unusual cURL logic, treat it as a malware incident.

Why would malware infect index.php?

Because index.php is one of the first files involved in handling frontend requests. If an attacker controls it, they can interfere with what the site serves to visitors and crawlers.

Should I just replace index.php and move on?

Not unless you are sure there is no persistence. In many WordPress infections, the visible file is only the symptom. Another hidden script may simply rewrite it again.