How can you recover a hacked site without losing your SEO rankings?

Why does Google enforce a specific order in the recovery process?

The reasoning behind this sequence is not arbitrary. Google categorically refuses to review a site until proof of ownership is established via Search Console. Without this verification, anyone could request the lifting of a penalty on any domain.

Timing is incredibly important. Bringing a site back online before fixing the security breach guarantees a new hack within 48 hours. Malicious bots continuously scan freshly cleaned sites to verify if the vulnerability persists. A reinfected site loses all credibility in Google's eyes, making the recovery process three times longer.

What does 'cleaned of vandalism' really mean?

A superficial cleanup is never enough. Hackers typically plant multiple backdoors: hidden PHP files in /wp-content/uploads/, obfuscated code in functions.php, phantom admin accounts, malicious cron jobs. Removing visible spam pages without tracking these secondary entry points guarantees a quick reinfection.

In practical terms, this involves a complete diff between your installation and a clean version of the CMS. Every modified file must be inspected manually, not just restored from a backup that may already be compromised. WordPress databases, for example, often contain malicious code injected into post_content fields or custom tables created by the hacker.

What are the real risks if you skip a step?

Google instantly detects shortcuts. Requesting a review with traces of hacking still present extends the processing time by a minimum of 3 to 6 weeks. The Google security team will reject the request with a terse message, and your site will remain blacklisted.

Worse: a partially cleaned site continues to infect visitors during this time. If Search Console detects residual malware after your review request, Google may harden the penalty and move the domain to an extended blacklist, showing red warnings in Chrome for all users. Recovering from this becomes a months-long nightmare.

• Mandatory ownership verification in Search Console before any action
• Thorough cleaning including files, database, user accounts, and scheduled tasks
• Mandatory fix of the initially exploited vulnerability (outdated plugin, 777 permissions, weak password)
• Post-cleaning security tests with professional scanners like Sucuri or Wordfence before going back online
• Documentation of the process for the review request (screenshots, logs, corrective actions)

Is this procedure consistent with what is observed in the field?

Absolutely. Failed rehabilitation cases all follow the same pattern: an impatient webmaster requesting a review 24 hours after removing visible spam pages, without having identified the initial attack vector. Google systematically rejects these requests.

What’s even more surprising is the absolute rigor of the security team during the review process. They do not simply check the homepage. Their bots crawl deeply, inspect subdirectories, analyze HTTP headers, and test forms. A single forgotten malicious PHP file in /cache/ is enough to block the recovery. No tolerance.

Where does Google remain vague in this statement?

The term 'cleaned online' lacks a crucial operational definition. Clean according to which exact criteria? Absence of malware detected by Safe Browsing? Validation by an external scanner? Compliance with official CMS checksums? Google never clarifies this clearly.

Another gray area: the time gap between cleaning and the review request. Some experts recommend waiting 48-72 hours after going back online to allow Google to naturally recrawl the cleaned site. Others advocate for an immediate request. [To be verified] — Google does not communicate any official best practices on this timing, and field feedback varies significantly depending on the cases.

What pitfalls escape this official checklist?

Restoring from a backup often poses problems. Many webmasters restore a backup from three weeks ago, thinking they are returning to a clean state. However, the hack may date back six months, with the backdoor lying dormant without visible activity until recently activated. The restored backup thus contains the initial entry point.

Another classic pitfall: CDNs and intermediate caches. You clean your server, but Cloudflare or your reverse proxy continues to serve hacked pages from cache for 24-48 hours. Google crawls these cached versions, detects spam, and rejects the review request even though your origin server is totally clean. You must aggressively purge all caches before requesting the review.

What should you practically do before any review request?

Start by documenting the incident methodically. Capture screenshots from Search Console showing the initial security alerts. Note the detection date, type of attack identified (SQL injection, pharma hack, malware, etc.), and the extent of the compromise (number of affected pages). This documentation will serve during the formal request.

Next, completely isolate the site: put it into maintenance mode, block indexing via a temporary robots.txt, and work on a local copy or staging environment. Analyzing a hacked site in production while it continues to be crawled worsens the damage. During this blackout, conduct a complete forensic scan with several tools (Sucuri SiteCheck, VirusTotal, Quttera) to identify all modified files.

How can you ensure that the vulnerability is truly fixed?

Identifying the attack vector takes precedence over everything else. 80% of WordPress hacks come from outdated plugins or nulled themes. Check the Apache/Nginx access logs for suspicious requests just before the initial compromise. Look for patterns like /wp-content/plugins/old-plugin/upload.php or unusual POSTs.

Once the entry point is identified, the fix must be radical: complete removal of the vulnerable plugin (not just an update), rotation of all passwords (admin, FTP, database, hosting), revocation of potentially exfiltrated third-party API keys, and tightening file permissions (644 for .php, 755 for folders, never 777). Then install a WAF like Sucuri or Cloudflare to block attempts to exploit the same vulnerability again.

What is the proper sequence for going back online?

Never reactivate indexing before full validation. Bring the site back online with a robots.txt blocking all bots (User-agent: * / Disallow: /), then conduct a final security scan 24 hours later. If everything is clean, submit the review request in Search Console with a detailed description of corrective actions, then only reactivate the normal robots.txt.

The timing of reindexing matters greatly. Use the URL Inspection tool to force the crawl of strategic pages once the site is validated clean. Submit a freshly generated XML sitemap. Monitor the Search Console security reports daily for a minimum of 2 weeks. Residual hacking usually manifests within 5-7 days if the cleanup was incomplete.

These technical operations require deep expertise in web security and SEO. A sloppy cleanup can destroy years of SEO rankings in just a few days. If you lack internal resources or experience in this type of crisis, hiring an SEO agency specializing in recovering hacked sites can make the difference between a quick recovery and months of struggle. Professionals have advanced forensic tools and know the intricacies of Google's review procedures.

• Verify and secure access to Search Console (rotate credentials)
• Thoroughly scan files AND the database with a minimum of 3 different tools
• Compare modified files with a clean installation of the CMS via diff
• Fix the initial vulnerability (update, remove, security patch)
• Purge all caches (server, CDN, proxy) before going back online
• Document each corrective action for the review request
• Monitor Search Console reports daily for 15 days post-rehabilitation