My WordPress Website Was Hacked: PHP Backdoors, SEO Spam and the Recovery Timeline

How I Realized Something Was Wrong

On the morning of October 23, 2026, at approximately 5:00 AM Pakistan time, I was running routine checks across my personal infrastructure. As someone whose work centers on business growth systems, organic search architecture, and website engineering, I routinely inspect HTTP headers, crawl responses, and search health.

Nothing was visibly broken on the homepage. The WordPress theme rendered, the design looked crisp, and there was no visual defacement. But when I began probing query parameters and server responses, the system behaved abnormally. Clean URLs were behaving as expected, but certain unusual request paths were triggering unexpected server executions rather than standard 404 responses.

Most website hacks today do not announce themselves with neon spray-paint or homepage graffiti. Modern compromises are commercial attacks: they operate silently, inject doorway URLs into search engines, and hide from human visitors while serving spam to search engine crawlers. My immediate priority was to verify whether search engines were seeing pages that I had never created.

What Google Search Console Showed

When I logged into Google Search Console for hussainjatoi.com and opened the Sitemaps report, the anomaly was confirmed immediately.

My legitimate sitemap was present:

Directly below it, however, were two submissions I had never created:

In addition, a submission for /sitemap_index.xml was shown as successful with 1,001 discovered pages, indicating that whatever script had been uploaded was actively generating XML feeds specifically structured to trigger Googlebot crawling.

Why the URLs Were a Serious Warning Sign

The presence of manga.php and shop.php as sitemap endpoints is a textbook signature of automated SEO spam injection, commonly referred to in the web security community as search poisoning or doorway attacks.

In these campaigns, attackers do not want to destroy the site. They want to exploit the clean domain reputation and search authority of established websites. By generating hundreds or thousands of programmatic URLs containing Japanese manga titles, streaming keywords, or counterfeit goods terms, attackers attempt to rank high-intent commercial queries on Google using the victim's domain authority.

When a human visits the URL from a desktop browser, the script often displays a 404 or redirects to a harmless page. But when a search engine crawler visits with a Googlebot user-agent from a Google IP range, the script executes conditional cloaking, returning spam text, keyword-stuffed links, and affiliate redirects. This cloaking behavior is why many website owners remain unaware of compromises for months until Google issues a manual action for cloaking or hacked content.

What the Hostinger VPS Investigation Found

Armed with the Search Console evidence, I immediately accessed the hosting environment. The site was previously running on a Virtual Private Server (VPS) hosted at Hostinger, configured with Ubuntu 24.04 and the OpenLiteSpeed web server.

I connected to the server via secure terminal and began inspecting the web document root at /var/www/html/. A directory listing ordered by modification time revealed the exact files responsible:

Two foreign standalone PHP scripts were sitting directly in the root directory alongside legitimate WordPress files like index.php and wp-config.php. Both had been written to disk within minutes of each other on October 22, 2026, at approximately 03:13 UTC.

The PHP Backdoor Evidence

Each file was approximately 90 KB in size. In typical WordPress core installations, standalone root scripts do not reach 90 KB unless they contain bundled libraries or heavily obfuscated payloads.

Inspecting the contents of manga.php and shop.php revealed classic webshell architecture:

• Obfuscated Execution Layers: Layers of base64 encoding, string compression, and character manipulation used to bypass basic pattern scanners.
• User-Agent Detection Filters: Logic dedicated to examining the HTTP_USER_AGENT header to differentiate between Googlebot, Bingbot, and normal desktop browsers.
• Dynamic Sitemap Generation: Code routines that generated valid XML response headers when requested with the query string ?sitemap.xml, producing hundreds of programmatic URL targets on the fly.
• Command and Control Capabilities: Secondary functions capable of downloading remote code updates and modifying permissions if the server user had write access.

The Modified .htaccess File

Finding malicious PHP files is only half the picture. The second critical component was how those files were being triggered.

A standard WordPress .htaccess file contains a simple rewrite rule block that directs non-file requests to index.php. During my inspection, I found foreign rewrite conditions injected above the WordPress block.

These injected rules were designed to intercept incoming requests matching specific query patterns or URL parameters and route them silently into manga.php and shop.php, preventing WordPress core from handling the request or logging it as a 404. This configuration allowed the backdoor scripts to operate independently of the WordPress application layer.

Why I Didn't Just Delete the PHP Files

When less experienced site owners find unauthorized files, their instinctive reaction is to click "Delete" and assume the crisis is over. In real server security, deleting surface artifacts without addressing persistence is dangerous.

Automated compromise toolkits rarely rely on a single file. They routinely install multiple persistence mechanisms:

• Scheduled Cron Jobs: Hidden cron tasks in /etc/cron.* or user crontabs that re-download the payload every few hours if deleted.
• Core File Injections: Malicious functions appended to legitimate core files like wp-settings.php or wp-blog-header.php.
• Database Payloads: Serialized scripts stored inside the wp_options table under autoloaded keys.
• Alternative Webshells: Obfuscated files buried inside deep upload subdirectories with randomized names.

Simply deleting manga.php and shop.php would have created a false sense of security while leaving potential persistence intact. Complete host isolation was the only responsible first step.

Why I Stopped the VPS

Rather than attempting a live, unverified clean-up on a production server, I logged into Hostinger's control panel and shut down the Virtual Private Server completely.

Stopping the server achieved four vital containment objectives:

1. Severed Outbound Connectivity: It immediately halted any potential command-and-control communications or automated data exfiltration.
2. Stopped Search Spam Crawling: It prevented Googlebot or Bingbot from continuing to fetch cloaked spam pages from the backdoor scripts.
3. Preserved Forensic Evidence: Powering off the machine preserved file timestamps, system logs, and shell history in their exact state at discovery.
4. Prevented Lateral Movement: It eliminated the risk of the compromised environment attacking other network services or sending outbound email spam.

Why I Moved the Public Website

My priority for visitors and clients was immediate, uncompromised integrity. I had already been developing a decoupled, high-performance static architecture for HussainJatoi.com built on modern static site generation (SSG) hosted on Lovable's infrastructure.

By repointing the domain's DNS away from the Hostinger VPS to the new decoupled hosting stack, I achieved immediate security separation. The new architecture does not use WordPress, does not execute PHP scripts on the web tier, has no SQL database attached to public request handlers, and contains no file-write permissions for incoming web visitors.

Within minutes of DNS propagation, visitors were served from a clean, high-performance static environment, eliminating any possibility of malware execution on client browsers.

What Moving Hosting Did Not Solve

It is crucial to be honest about the limitations of migrating a website during a security incident. Moving DNS solved the immediate public presentation problem, but it did not resolve everything:

• The Old Server Was Not Cleaned: The legacy VPS remains stopped and contained. Moving away does not prove what happened or sanitize the operating system.
• Historical Backups May Be Contaminated: Any backups generated between October 22 and October 23 potentially contain the infected files and cannot be restored without rigorous file-by-file sanitization.
• Search Engines Retain Memory: Moving hosting does nothing to erase search engine index records or crawl queues already registered in Google's index.

The SEO Problem Did Not End When the Server Went Offline

Many webmasters believe that once the infected server is dead, the SEO recovery is complete. In reality, that is when the search remediation begins.

Googlebot retains discovered URLs in its crawl scheduling pipeline for weeks or months. When Googlebot attempts to re-crawl those 1,001 URLs on the new hosting environment:

• If the server returns soft 404s or redirects them to the homepage, Google interprets the spam URLs as legitimate pages and retains them in index calculations.
• If Google continues finding spam snippets in search results, user click-through rates and brand trust plummet.
• If Google's algorithms detect substantial search spam on the domain, algorithmic quality penalties can suppress organic impressions across legitimate service and case study pages.

How I Started Removing the Hacked URLs From Google

To protect brand visibility and accelerate index cleansing, I executed a structured, multi-layer search cleanup workflow:

1. Search Console URL Removals: I used Google Search Console's Removals tool to submit urgent prefix removal requests for the malicious paths. Temporary removals mask the URLs from appearing in Google Search results within hours while permanent de-indexing takes place.
2. Hard HTTP 404 / 410 Response Configuration: On the new hosting stack, I ensured that any request matching the unauthorized scripts or legacy spam parameters returns a clean HTTP 404 Not Found status code rather than redirecting to the homepage.
3. Clean XML Sitemap Resubmission: I verified that /sitemap.xml contained strictly valid, canonical HTTP 200 URLs and resubmitted it to Google to guide crawl priority toward legitimate pages.
4. Index Coverage Monitoring: I established daily tracking inside Search Console's Pages report to monitor the transition of spam URLs into the "Not indexed (404)" bucket.

Security and Recovery Lessons: Technical Warnings

Incidents like this highlight critical technical distinctions that are frequently misunderstood in online tutorials and generic security advice:

Where My Website Stands Now

As of October 24, 2026, HussainJatoi.com is operating in an entirely secure, decoupled production environment:

References & Technical Sources

Authoritative first-party technical documentation referenced throughout this incident recovery: