In this project, I detected a severe technical SEO issue caused by a malware infection that resulted in over 20,000 fraudulent URLs being indexed on my website. The infection originated from a compromised PHP file within a shared hosting environment and caused thousands of spam pages to appear in Google Search.
After migrating my WordPress website from a local environment to a hosting provider, I discovered a massive indexing issue caused by a malware infection. More than 20,000 fake URLs were indexed, and over 100,000 were pending indexing in Google Search Console.
The client is one of my own projects (I will use it in many examples): Travel Agency siguiendoelnorte.com
A malicious PHP file from another infected project on the same hosting account spread to my site. This cause:
I started a deep manual inspection of my server files and ran Wordfence, a security plugin, to assist with scanning. After a couple of days of digging, I finally located the infected PHP file. Once deleted, I began planning how to clean up the thousands of bad URLs and protect the site’s SEO health.
Cleaning up wasn’t just a matter of deleting a file, the real damage had already been done in Google’s index. I took different estrategies in several phases:
1. Manual Removals
I manually submitted close to 200 removal requests in Search Console, targeting key examples of the spam URLs. This served two purposes: reduce visibility of the malicious content and alert Google that something was off.
2. Server-Level Blocking
Since most of the malicious URLs followed just three root paths, I was able to block them using 410 Gone directives in the .htaccess file. This response code tells search engines that the content is permanently gone and should be removed from the index.
3. Crawling Restrictions
To reinforce the cleanup, I disallowed these paths in my robots.txt file:
User-agent: *
Disallow: /spam-urls-root/
Doing this, Google’s crawlers are prevented from indexing the URLs, and when they encounter the 410 status code in the .htaccess file, they recognize that the pages are permanently gone and proceed to remove them from the index.
Within weeks, the number of indexed fake URLs dropped drastically from over 20.000 indexed to hundred, later weeks just over 60. But I wanted to go further and faster, so I created a dedicated XML sitemap containing only the remaining bad URLs and removed the robots.txt disallows temporarily, this forced Google to recrawl the pages, detect the 410 status and deindex them more quickly.
Right now, only 8 malicious URLs (9 of 17 indexed URLs are correct) remain indexed and I expect full recovery very soon. Meanwhile, there are 138.000 URLs that have not been indexed because I blocked them in time, but they have to be gradually removed by Google from my Search Console. When I test it on Google doing site:my domain, only those 12 are detected.
*Update 08/23/2025: just 4 URLs remain.
Of course, cleanup wasn’t enough. I needed to make sure this wouldn’t happen again, I did next steps to prevention:
Inspected all other projects hosted on the same server.
Identified and removed additional infected files.
Changed all FTP, hosting and database passwords.
Added daily scan automation with a pluging.
Once all URLs have been deleted, I will indicate disallow in the robot.txt file with the URLs roots and delete the sitemap with the 410 gone URLs.
It has been a slow and methodical process, but one that proves how powerful SEO can be when applied beyond keywords at the foundation of a site’s architecture.
This case also reflects how security and SEO are tightly connected. Without constant monitoring and control over server environments, even a cleanly built site can suffer reputational damage.
