The Attack That Only Google Could See

How a Japanese keyword hack damaged years of SEO work, and why the hosting response became part of the problem.

For roughly three weeks, a website I work with was serving two versions of itself. Visitors saw the familiar pages, articles and product information. Google received unrelated Japanese retail content.

The website looked normal while its organic visibility deteriorated.

We had spent years developing useful specialist content and improving the site’s presence in search. That work was still online, but its ability to reach prospective customers was being damaged. Meanwhile, tens of thousands of spam URLs were appearing under the same domain.

The incident also exposed a second problem: having a hosting provider that advertises malware protection and cleanup support does not tell you how effectively it will respond when you need those services.

I am keeping both the business and provider anonymous. This account reflects our findings and the response status documented on 6 September 2026. The original entry point remained under investigation.

What a Japanese keyword hack actually does

A Japanese keyword hack is a form of search spam in which attackers use a compromised website to publish Japanese-language pages, often promoting unrelated retail products. The name describes the content pattern; it does not establish who carried out the attack.

In this case, the injected URLs followed a repetitive query-parameter pattern. Google had indexed roughly 45,000 pages on a website whose legitimate content ran to only a few hundred.

The attack also used cloaking, which means serving different content to search engines and ordinary visitors. Google explicitly describes cloaking as a technique attackers use to make compromised sites harder for their owners to detect. Its guidance also warns that injected pages can damage search performance even when existing pages show no obvious signs of compromise. Google’s guidance on cloaking and hacked content

That was precisely what made this incident difficult to spot. Opening the website showed us the legitimate version. The unfamiliar content appeared when we examined what Google was receiving.

The damage behind the traffic numbers

We discovered the incident on 3 September through Google Search Console.

The indexed-page count was the first obvious warning. The unfamiliar URLs, Japanese product titles and unexpected traffic from Japan made the pattern clearer.

Yet one headline comparison showed total clicks up six percent.

The aggregate was counting clicks to injected pages alongside clicks to legitimate content. As a result, it offered reassurance at exactly the moment we needed to investigate.

Separately, our GA4 analysis recorded a 36.5 percent decline in organic sessions. That figure needs context: a tracking change and adjustments to paid search activity also affected channel comparisons during the period. It would be misleading to attribute every missing session to the attack with mathematical certainty.

What we could establish was that the site was serving spam to Google, that tens of thousands of unrelated URLs had entered the index, and that organic performance had deteriorated substantially during the same period.

For the business, this affected a route to customers that had taken years to develop. Specialist articles and useful product information were still available, but fewer relevant visitors were reaching them.

That is the part of an SEO attack that a file count cannot capture. Behind a declining search curve are the research, writing, optimisation and maintenance that made those pages worth finding.

Why a normal browser check missed it

We tested the difference directly.

An external request using a Googlebot user agent received the legitimate website. Search Console’s live URL test, fetching through Google’s infrastructure, received the Japanese retail content.

Simply changing the browser’s identification string did not reproduce the problem. Our investigation identified IP-based discrimination in the cloaking behaviour.

The practical consequence was straightforward: a normal page check could not establish that the site was clean. The version we could see was different from the version being supplied to Google.

Search Console became an investigative tool because it exposed that difference.

What the scanner left behind

The technical investigation identified eight PHP backdoors disguised with extensions associated with text, images, audio or video. The code provided a means of executing additional remote code.

Checks of three files against independent antivirus engines corroborated the web-shell findings. One was identified as malicious by 22 of 61 engines.

We also found several files with genuine .php extensions that had been emptied. They shared a timestamp from 17 August and were owned by root. Our incident assessment attributed this pattern to an intervention by the hosting provider’s scanner. The underlying scanner logs were still needed to establish exactly what it had detected and done.

The eight disguised backdoors remained active.

One also loaded code from a ZIP archive through PHP’s stream-wrapper mechanism. That added another layer to the investigation, although it would be too strong to claim that archived code is inherently invisible to security scanners.

The clear finding was that the apparent intervention had not removed the compromise. No notification of that earlier activity had reached us.

There were seventeen days between the apparent scanner intervention and our own discovery.

Credit where it is due

I owe particular thanks to Fabian Weiss, founder of FW Delta, with whom I regularly collaborate on tracking projects. He stepped in at short notice and quickly carried out the forensic investigation, identifying the hidden backdoors, examining the cloaking behaviour and documenting the evidence of an earlier, incomplete intervention.

His findings gave us a concrete basis for escalating the incident with the hosting provider and understanding what needed to be addressed. Having a trusted colleague who could provide that level of technical help so quickly was a real piece of good fortune in a difficult situation. I am grateful for his expertise and the support he provided when it mattered.

Where the hosting support fell short

The provider advertised malware protection and a cleanup service. We reported the incident, supplied detailed findings and identified the malicious files.

As of the documented status on 6 September, the cleanup had not been completed.

This was especially frustrating because the work required cooperation from the provider. We did not have root access, and the investigation identified remediation steps that could not be completed with the permissions available to us.

The logs accessible to us started on 31 August, after the suspected initial compromise. We requested older server or firewall logs because the available history could not explain how the attacker had entered.

The result was a difficult dependency: we had identified an active compromise and supplied evidence, but were still waiting for the provider to complete the work within its control.

From the customer side, that was an inadequate incident response. A report containing active backdoors and confirmed cloaking needed an effective route to containment, investigation and verified cleanup. At the documented cutoff, we did not have a completed resolution.

The initial breach may have involved an outdated plugin on our side. That possibility deserves investigation. It also leaves a separate question unanswered: how effectively did the provider respond once the incident had been detected and reported?

Those are distinct responsibilities. An unresolved entry point does not make the subsequent response unimportant.

Why the backups were not enough

Daily backups existed, but the available history did not extend beyond the suspected beginning of the compromise.

The oldest restore point accessible to us was dated 21 August. The earliest backdoor timestamp we had found was 11 August, consistent with suspicious indexing activity around that period.

We therefore had no available restore point we could confidently treat as predating the attack.

The backups had run as configured. Their retention period was too short to provide a known clean starting point for this incident.

The limited log history compounded the problem. We lacked both a clearly pre-incident backup and accessible server records covering the likely entry period.

Backup frequency, retention and log availability need to be considered together. A daily backup is useful, but its value during a hidden compromise depends on how far back the history reaches.

What website owners should watch for

You do not need to recognise a web shell to notice the first signs of this kind of attack. The most useful checks start with the website’s search presence.

Investigate unfamiliar indexed URLs. A sudden increase in page count should have an explanation. Repeated parameters, random identifiers and pages nobody created deserve immediate attention. A query parameter alone is not evidence of a hack; the unexplained content is what matters.

Check search queries, countries and destination pages together. Unexpected languages or markets are a reason to investigate. Look at which URLs receive those clicks before treating the additional traffic as growth.

Inspect what Google receives. Use Search Console’s live URL test on affected pages and examine the returned content. A normal result in your own browser does not rule out cloaking.

Report a security incident with concrete evidence. Include example URLs, screenshots, timestamps and any technical findings. Ask who owns the investigation, what containment is underway and how completion will be verified.

Clarify the provider’s role before you need it. Ask how malware alerts reach you, what cleanup covers, how urgent cases are escalated and which actions require provider access. These details determine whether the service can help you act quickly.

Check backup and log retention against delayed discovery. Consider what would happen if a compromise remained unnoticed for several weeks. Establish whether you could recover an earlier state and investigate the likely entry period.

These checks do not replace a technical security investigation. They can help initiate one before an apparently healthy website loses more of its search presence.

The cost continues beyond cleanup

The incident diverted time into technical investigation, coordination and recovery planning. It also disrupted planned marketing work.

Removing the malicious code is one milestone. Establishing that legitimate pages are being served correctly, that injected URLs are being addressed and that relevant search traffic is recovering requires further verification.

I am sharing this because businesses put considerable effort into building organic visibility. They commission content, improve websites and develop useful resources over years. A hidden compromise can undermine the return on that work while the site continues to look entirely normal.

The hosting response is part of that story. When customers depend on a provider’s permissions and security service to resolve an incident, the quality and speed of that response have direct consequences.

Good SEO and content work need a technical environment that protects them, monitoring that makes unusual changes visible, and people who act when the evidence appears. This case showed how costly the gaps between those things can become.