How does Google actually handle review requests after a site hack?

Why does Google enforce a formalized process for hacked sites?

A site infected with malware, phishing, or spam injections poses a direct threat to users. Google penalizes these sites by significantly downgrading their rankings or displaying a red warning in the SERPs.

Requesting a review through the Search Console is not merely an administrative formality. It compels the webmaster to document the corrections made and to prove that the vulnerability has been patched. Without this safeguard, infected sites could regain their ranking merely by superficially cleaning visible content while ignoring the underlying vulnerabilities.

What actually happens during a security review?

Google's security team (Safe Browsing) manually checks or uses targeted crawls to ensure that malicious content has been removed and that backdoors have been closed. The stated timeframe varies from a few days to several weeks, but in practice, some webmasters may experience delays of a month or more without feedback.

If the review is rejected, Google sends a generic message pointing to help resources, rarely providing specifics about the infected files. This is where turning to the Search Console help forums becomes necessary: volunteer Product Experts can offer a more detailed diagnosis, although their ability to take action remains limited.

What common pitfalls delay the lifting of penalties?

The first pitfall: cleaning infected pages without addressing the original vulnerability (outdated WordPress plugins, compromised FTP credentials, unpatched SQL injections). Google often detects a reinfection within days of the review request, leading to an automatic rejection.

The second pitfall: overlooking subdomains or infected secondary directories. A single forgotten malicious file in /wp-includes/ or on a staging subdomain is sufficient to maintain the penalty. The review must encompass the entire domain and all its publicly accessible variations.

• Go to Search Console > Security & Manual Actions to submit the review request
• Accurately document the corrective actions in the form (deleted files, updated plugins, changed passwords)
• Check subdomains, hidden directories, and temporary files before submitting
• If no response within 10 days, post on the Search Console help forum with the URL and request number
• Never remove a site from Search Console while a review is in progress, as this cancels the request

Is this procedure truly effective in protecting users?

On paper, yes. Forcing a manual pass through the Search Console prevents infected sites from regaining visibility through sheer negligence. However, in practice, the process suffers from a lack of transparency: Google never specifies which files are problematic or what type of malware has been detected.

A webmaster can diligently clean their site, submit a review, receive a terse rejection, and find themselves sifting through thousands of files with no concrete leads. Third-party malware detection tools (like Sucuri, Wordfence, Maldet) become essential, but their reliability varies. [To be verified]: Google does not disclose the false positive rate of Safe Browsing, nor the precise criteria for lifting a penalty.

Is turning to help forums really an escalation solution?

Let’s be honest: Product Experts in the forums are volunteers, not Google employees with access to internal systems. Their role is limited to directing users towards official resources, suggesting diagnostic paths, and occasionally escalating a blocked case to Google teams.

In the majority of situations, a forum post leads to generic advice already found in documentation. The cases where a Product Expert obtains direct Google intervention remain marginal. If the review takes longer than three weeks without feedback, escalating via Twitter (@GoogleSearchC) or paid support channels might be more effective, but there are no guarantees.

What are the shortcomings of this process from the webmaster's perspective?

Many webmasters submit a review request before truly fixing the vulnerability. They clean visible infected files, change the WordPress admin password, and consider the job done. The result: reinfection within 48 hours, rejection of the review, and a loss of several additional weeks.

Another common mistake: not checking for malicious 301 redirects injected into .htaccess or DNS settings, nor for obfuscated scripts in theme files. A proper security audit entails a complete scan of the file system, a review of server logs, and verification of FTP/SSH access. Without this rigor, the Google review is bound to fail.

What should you do immediately after detecting an infection?

The first action: isolate the site by putting it in maintenance mode or taking it offline temporarily, especially if it's distributing active malware. Each additional hour of infection worsens the Google penalty and endangers visitors. Simultaneously, change all passwords (FTP, SSH, database, hosting panel, CMS admin).

Next, run a complete scan using specialized tools (Wordfence for WordPress, Maldet via command line, or a service like Sucuri). Don’t limit yourself to the public directory: check cron jobs, configuration files, and temporary directories. Backdoors often hide in innocuously named files (error_log.php, cache.php) or in less frequently accessed directories.

How to effectively document a review request?

Google requires a description of the corrective actions taken. Don’t settle for a vague “site cleaned.” List specifically: which files were deleted or restored, which plugins/themes were updated or uninstalled, and what vulnerabilities were patched (e.g., “SQL injection in plugin XYZ v2.1, upgraded to v2.3”).

Also mention preventive measures: activating a web application firewall (Cloudflare, Sucuri), tightening file permissions (chmod 644 for files, 755 for directories), implementing daily automated backups. The more you demonstrate that the site is now securely managed in the long term, the more likely the review is to be accepted quickly.

What if the review is rejected or remains unanswered?

A rejection indicates that Google still detects malicious content or an active vulnerability. Go back to the Search Console, security issues section: Google sometimes lists examples of infected URLs. Scan these specific URLs, as well as all related pages (redirects, hidden iframes).

If no details are provided, post on the Search Console help forum including your domain, the review request number, and a summary of the actions taken. A Product Expert may sometimes identify a blind spot. Concurrently, check the server logs from the past weeks for any suspicious requests or unauthorized access attempts.

These tasks can quickly become time-consuming and technical, especially on complex infrastructures or custom CMS platforms. If you lack internal resources to conduct a thorough security audit, or if review rejections are piling up without clear explanations, reaching out to a specialized SEO agency in web security can quickly resolve the situation. External expertise often helps identify invisible backdoors and optimizes review documentation to maximize acceptance chances.

• Isolate the site and change all passwords as soon as the infection is detected
• Conduct a comprehensive scan of the file system, including hidden directories and subdomains
• Document each corrective action precisely in the Search Console review request
• Verify 301 redirects, .htaccess, DNS settings, and obfuscated scripts
• Wait 7-10 days after submission before escalating to the help forum
• Never submit multiple simultaneous reviews or remove the Search Console property during the review process