Should you submit multiple review requests for a hacked and infected site?

Why does Google merge these two review processes?

Hacked sites often face two distinct yet related issues: the injection of malicious code on one hand, and the insertion of spam (outbound links, doorway pages, redirects) on the other. Historically, these two issues fell under separate systems in Search Console, forcing webmasters to submit two distinct requests.

This fragmented approach created confusion. A site cleaned of malware but still flagged for spam remained penalized. Conversely, a site rid of spam but still infected did not regain its visibility. The merging of processes addresses a real-world scenario: when a site is compromised, attackers typically exploit multiple vectors simultaneously.

What actually changes in Search Console?

Before this change, you had to navigate through different sections of Search Console to address each type of issue. Now, a single button initiates analysis from both detection systems. Google simultaneously examines the presence of malicious code and injected spam.

This unification does not mean that both teams use the same evaluation criteria. The anti-malware system scans for infected files, suspicious scripts, and malicious redirects. The anti-spam system focuses on abusive content, cloaking, and link farms. But the triggering action is shared, and that's where the practical gain lies.

Does this simplification really speed up processing?

Google does not provide any official timeline, but logic suggests a faster processing. If both teams are notified simultaneously, they can validate in parallel rather than sequentially. This eliminates the risk of one team waiting for validation from the other before acting.

On the other hand, the time for human review remains unavoidable. A site with 10,000 infected pages will not be cleaned overnight, regardless of the submission method. Administrative simplification does not replace the need for a thorough security audit.

• A single button in Search Console triggers malware + spam review
• Processing remains distinct internally but is initiated simultaneously
• Validation timelines depend on the extent of the infection and the quality of the cleanup
• Notifications for lifting penalties may arrive separately if a problem persists on the malware or spam side
• No change in evaluation criteria for either system

Is this statement consistent with field observations?

Yes, and it’s even a logical evolution. Practitioners managing hacked sites have long noticed that malware and spam coexist on the same compromised sites. Hackers often inject pharmaceutical spam and malicious redirects in the same attack. Artificially separating these two issues no longer made operational sense.

What remains unclear is the weighting of the criteria. If Google detects that the malware is 100% cleaned but 5% of spam pages remain, will it partially lift the penalty? [To be verified]. Field reports suggest a binary functioning: as long as a problem persists, the site remains flagged. The merging of the button does not change this logic.

What nuances should be added to this announcement?

First point: this simplification only concerns hacked sites. If you intentionally created spam pages or your site willingly hosts malware (unlikely but possible), the procedure remains different and much stricter. Google clearly distinguishes between a victim and an accomplice.

Second nuance: the single button does not exempt you from a thorough diagnosis. Before clicking, you must have identified and eradicated all infected files, backdoors, compromised accounts, and spam content. Submitting a request for a partially cleaned site is futile. Google will reject the review, and you will have to start over.

In what cases does this simplification make no difference?

If your site suffers from a manual penalty for spam created intentionally (not injected through hacking), you will still go through the Manual Actions section of Search Console. This process remains separate. Additionally, if you are listed in Safe Browsing for phishing rather than classic malware, other teams will intervene.

Another case where it makes no difference is sites that accumulate multiple issues beyond malware and spam. If you also have catastrophic Core Web Vitals, duplicate content, or toxic links, the single button will only address the security aspect. The rest of the SEO project is still waiting for you.

What should you do after a hacking incident?

Before even thinking about the review request, conduct a complete security audit. Scan all files, check user accounts, search for backdoors in wp-config.php or .htaccess if you're using WordPress. Hackers often insert multiple entry points to ensure their return even after initial cleaning.

On the injected spam side, look for automatically created parasite pages, outgoing links hidden in footers, and JavaScript redirects. Use the site: operator in Google to spot indexed pages you never created. Compare your FTP structure with what Google has cached. Discrepancies often reveal the extent of the damage.

How can you maximize the chances of quick validation?

Once the site is cleaned, document your actions in a text file. List the deleted files, disabled accounts, modified passwords, and updated plugins. This documentation will not be submitted to Google, but it will help you avoid missing an element during a second wave of infection.

In Search Console, write a factual description of what you have fixed. No need for a novel, but avoid the terse "everything is fixed." Mention the types of malware eliminated, spam pages removed, and security measures taken (WAF, permissions hardening, strong authentication). Google appreciates webmasters who demonstrate their understanding of what happened.

What mistakes should be absolutely avoided?

A classic mistake: submitting the request too early. You just deleted 50 spam pages, you click the button immediately, and three days later you discover 200 other infected pages in a forgotten subdirectory. The result: request rejected, extended timeline, damaged credibility with Google.

Another trap: neglecting reinfection. If you clean without fixing the initial vulnerability, the site will be compromised again within 48 hours. The bots that exploited your vulnerability the first time will return automatically. Update CMS, plugins, and change all FTP and database access. Without this, you will enter a vicious cycle of cleaning-reinfection-penalty.

• Scan all server files with a professional anti-malware tool (Wordfence, Sucuri, or equivalent)
• Remove all suspicious files, backdoors, and unknown user accounts
• Identify and eliminate all spam pages, redirects, and injected outgoing links
• Update CMS, themes, and plugins and fix the original vulnerability
• Change all passwords (admin, FTP, database, hosting)
• Submit a single review request through the single button in Search Console
• Monitor server logs daily for any signs of reinfection