How can you detect code injection and limit the damage to your infected site?

Why is Search Console the starting point for injection detection?

Search Console centralizes the security alerts reported by Google's automatic detection system. When the crawler identifies suspicious code, cloaking, or malicious redirects, it reports the affected URLs in the Security and Manual Actions section.

Your first instinct should be to check this property for an initial list of compromised pages. This saves considerable time compared to manually scanning thousands of pages. But beware: this list is never exhaustive when you consult it.

Why are wget or curl essential for confirming the infection?

Modern code injections often detect Google's user-agent and hide malicious content from standard browsers. You might see a clean page in Chrome while Google crawls pharmaceutical spam.

wget or curl allow you to retrieve the raw source code as served to the bot, without JavaScript interpretation or browser caching. This is the only way to see what Google actually sees. If you find obfuscated scripts, hidden iframes, or suspicious external links, you have your confirmation.

What does it mean to explore the file system to assess the damage?

Once the injection is confirmed on the frontend, you need to trace back to the source in the server hierarchy. Modified .htaccess files, PHP scripts injected into the WordPress theme, compromised JavaScript libraries: everything must be audited.

This exploration phase reveals the true extent of the attack. Some injections only affect a few templates, while others infect the database or create thousands of ghost pages in hidden directories. Without this complete mapping, you risk cleaning up superficially and leaving the door open for immediate reinfection.

• Search Console provides the initial list of compromised URLs detected by Google
• wget or curl confirm the injection by retrieving the actual source code served to the crawler
• Server exploration identifies all files modified or added by the attack
• The delay between infection and detection may allow the attacker to increase the entry points
• Never rely solely on browser display: cloaking completely distorts the diagnosis

Is this methodology sufficient against recent injections?

The procedure described by Google remains valid as a starting point, but it assumes the injection has already been detected. However, modern obfuscation techniques can delay this detection by several days or even weeks. In the meantime, your site serves spam, loses rankings, and accumulates manual penalties.

The most sophisticated injections now target legitimate files that are rarely audited: third-party JavaScript libraries, abandoned plugins, cache files. Wget alone is no longer sufficient if the malicious code is conditionally loaded based on IP or referrer. [To be verified]: Google does not specify how to handle injections that only trigger for specific traffic segments.

What are the limitations of Search Console in this context?

Search Console only reports the URLs that Googlebot has actually crawled AND analyzed as suspicious. If your site has 50,000 pages and only 200 are crawled each week, a recent injection may remain invisible for months in non-priority sections.

Worse: attackers often create thousands of orphan pages with noindex initially, then switch to index after a few days. These pages never appear in Search Console before they've caused damage. Therefore, you must cross-check with server logs and active monitoring of file changes.

Does cleaning alone resolve the underlying issue?

Cleaning the injection without correcting the initial security flaw guarantees rapid reinfection. Most WordPress infections exploit outdated plugins or pirated themes. Removing the malicious code without patching the CMS is like leaving the door open.

Specifically, exploring the file system must identify not only modified files but also entry vectors: abusive 777 permissions, forms without CSRF tokens, unvalidated file uploads. Without this analysis, you will lose days repeatedly cleaning the same site. And the lost time translates to lost traffic and revenue.

What should you do immediately after detecting an injection?

Your first action: isolate the site if the infection is massive. Temporarily switch to maintenance mode to halt the spread of malicious content limits Google penalties. Simultaneously, export all server logs from the last 30 days to trace the initial entry point.

Then, use wget with the Googlebot user-agent on a sample of URLs flagged in Search Console. Compare the source code obtained with what your browser displays. If you see significant differences, cloaking is confirmed and the attack is likely more extensive than what Google detected.

How do you accurately map the extent of the damage?

Log in via SSH and run a recursive search for recently modified files: find . -type f -mtime -7 for the last 7 days. Cross-reference this list with a diff against a clean backup if you have one. Suspect files often have identical timestamps or generic names: config.php, loader.php, cache.tmp.

Also analyze the database: injections in WordPress frequently target wp_posts to insert hidden links or wp_options to alter rewrite rules. A simple SELECT searching for 'eval(', 'base64_decode(' or 'gzinflate(' reveals 80% of common infections. Attackers do not always operate subtly.

What mistakes should be avoided during cleaning and recovery?

Never delete files before you have documented their presence and content. You will need this evidence to understand the attack vector and avoid reinfection. Many SEOs panic and delete everything, only to find themselves with the same problem the following week.

Another pitfall: restoring a backup that is too old. If your backup is from before the infection but also before several security updates, you reintroduce the initial flaws. Prefer a surgical clean-up file by file with manual validation.

• Check Search Console daily to detect new compromised URLs
• Test suspicious pages with wget and the Googlebot user-agent to confirm cloaking
• Identify recently modified files with find and compare with a clean version
• Look in the database for classic obfuscation patterns (base64, eval, gzinflate)
• Immediately patch the entry vector before cleaning the malicious code
• Submit a reconsideration request in Search Console after complete cleaning