SEO Spam Attack: What Happened & How to Fix It

The Day a Routine Check Stopped Being Routine

It started as one of those low-key January intentions. I had a personal website that I had quietly abandoned for a while, and on January 13, 2026, I finally sat down to update it. Nothing dramatic. Just cleaning things up, maybe refreshing a few pages, and while I was at it, I figured I would look at my Google Search Console dashboard to learn a bit more about SEO and how my site was doing.

My website has around ten pages. Maybe a handful more if you count everything. So I opened the coverage report expecting to see, I do not know, maybe fifteen entries. Twenty at most.

What I saw instead was 235,000 pages not indexed, and over 68,000 pages that had been successfully indexed.

I just stared at the screen for a moment. Those numbers did not make any sense. I did not have 68,000 pages. I had ten.

What Is an SEO Spam Attack and Why Should You Care

Before I get into what happened next, it helps to understand what an SEO spam attack actually is, because I had only a vague idea at the time.

An SEO spam attack, sometimes called SEO poisoning or spamdexing, is when an attacker secretly injects unauthorized content into your website. This content is usually stuffed with keywords in foreign languages, links to shady external websites, or entire fake pages designed to rank in search engines. The goal is not to hurt your website specifically. The goal is to use your website as a vehicle. Your domain has history, trust, and authority in Google's eyes. Attackers want to borrow that trust to rank their own content without doing any legitimate work.

The reason this is so dangerous for website owners is that it happens silently. You might not notice anything wrong when you visit your own site. The attack is often designed to show your normal content to regular visitors while serving completely different pages to search engine crawlers. By the time you find out, thousands of fake pages may already be indexed in your name.

Something Was Very Wrong

After staring at those numbers, I started clicking through the indexed pages to see what they actually contained. The URL preview snippets in Search Console told me everything I needed to know: Japanese characters, everywhere, in pages that were supposedly part of my website.

I opened one of the indexed URLs directly in my browser. What I expected to see was some kind of injected page with foreign content plastered all over it. What I actually saw was my own search page. Just a plain search box, sitting there. No header. No navigation. No menu. Nothing else. The page looked completely empty to me as a regular visitor.

That was when it clicked. The attack was not showing its content to me. It was showing it to Google.

I went to Google and searched for my own website. The results that came back were a long list of pages in Japanese that I had never created, with a favicon I did not recognize, belonging to a site that was supposed to be mine.

At that point, I knew exactly what was happening. My website was under a website SEO spam attack. Someone had hijacked my search presence and was using my domain to rank their content in Google.

Going Deeper Into the Damage

Step one: cut off the immediate access point

The first thing I did was disable the search page on my website. It was the attack's main entry point for serving fake content to crawlers, and taking it down was the quickest way to stop more spam pages from being accessible.

Then I opened my .htaccess file.

I was not prepared for what I saw.

The attacker had modified my server configuration to redirect robot and crawler requests away from my actual robots.txt file and toward a PHP file instead. One of the lines that stood out immediately was this:

This meant that every time Google's crawler visited my site and asked for the robots.txt file, it was being sent to a custom PHP file controlled by the attacker. My actual robots.txt was being ignored entirely. Google was operating on the attacker's rules, not mine.

Step two: finding the files left behind

I searched for wp22.php on my server. I found it. The timestamp on the file said November 18, 2025, which meant the attacker had been on my server for nearly two months before I noticed anything. The file itself was empty, zero bytes, which is actually a known technique used in these attacks. Empty files can serve as placeholders, hooks, or shells that get activated later.

There were other suspicious files nearby as well. All empty. All planted without my knowledge.

The Detail That Made It Real

While I was going through everything, I noticed something strange. My website had two Google site verification files. I had only ever created one.

I opened my Google Search Console and checked the domain ownership settings. Right there, listed as an owner of my own domain, was an email address I did not recognize. It had been added on November 11, 2025, a full week before the PHP file was planted. The second verification file belonged to this person.

That was the moment I felt the full weight of it. This was not just an automated script targeting random websites. Someone had deliberately added themselves as a verified owner of my Google Search Console property. They had the same level of access I did. They could submit sitemaps, remove pages from index, view all my traffic data, and control how Google saw my site.

I removed their verification file from the server. I removed them from the ownership list in Search Console. Then I cleaned up the .htaccess file and removed every suspicious line I could find.

The Cleanup That Is Still Ongoing

Once the immediate threats were dealt with, I submitted a request to Google to remove the fake indexed pages. I also created a clean, accurate sitemap and submitted it through Search Console so Google would have a clear picture of what my website actually contains.

Then I ran into the next problem.

Google had indexed tens of thousands of pages linked to my domain. Every time its crawlers came back to re-evaluate those pages, the sheer volume of requests was enough to crash my website and make it temporarily inaccessible. My hosting had access limits, and Google hitting 68,000 indexed URLs in repeated crawl cycles was slamming right into those limits.

There was not much I could do except wait and keep monitoring.

By the time I am writing this article in April 2026, the indexed page count has dropped from 68,000 to just under 2,000. It is still going down. Google is slowly working through the cleanup on its end, and my website is gradually being restored to what it actually is.

What I Learned From All of This

Looking back, I had every sign of a compromised site sitting right in front of me, but I had no reason to look. The website appeared normal when I visited it. My homepage loaded fine. My pages were there. Nothing on the surface suggested that anything was wrong.

That is the design of this kind of attack. It is built to be invisible to the person who owns the site, while being very visible to search engines.

Here are the things I wish I had been doing before any of this happened:

• Check Google Search Console regularly, even for websites you are not actively managing. The indexed page count alone can tell you when something is off.
• Review domain ownership in Search Console occasionally. You should be the only verified owner unless you have explicitly added someone.
• Keep an eye on your .htaccess file if your site runs on Apache. Unexpected rewrite rules are a serious red flag.
• Monitor your server files for anything you did not put there, especially PHP files with generic or suspicious names.
• Look at your site verification files. If there are more than you created, one of them belongs to someone else.
• Search for your own website on Google occasionally. If you see content in languages you do not use or pages you do not recognize, that is worth investigating immediately.

None of these steps require technical expertise. They just require the habit of occasionally checking in on a website you own, even when things seem quiet.

A Quiet Lesson About Neglect and Visibility

I think the honest part of this story is that I left my website alone for a long time. I was not monitoring it, not updating it, and not paying attention to it. That created an opening, and someone found it.

I am not sharing this to alarm anyone. Most website owners will never deal with something like this. But the fact that it happened quietly, over months, without triggering any obvious alarm, is worth understanding. A website you own is a piece of infrastructure with your name on it. If someone takes it over, they take over a piece of your online identity too.

The recovery process has been tedious and slow, but it has also been educational in ways I did not expect. I now understand how Google indexes pages, how crawlers interpret server files, how domain verification works, and how attackers exploit small gaps in site security. None of that was on my learning agenda when I sat down to do a quick website update in January.