How can you recover a hacked WordPress site without losing its ranking?

Why does Google emphasize the need for a review process?

Cleaning a hacked site is not enough to restore visibility. Google maintains a temporary blacklist of compromised sites, and only a formal review request can remove them from it.

This step of manual validation is essential to confirm that the vulnerability is truly patched. Many owners delete malicious content without addressing the root exploit, leading to a re-hack in the following days. Google thus seeks proof that the problem is resolved thoroughly.

What’s the difference between cleaning the hack and completing recovery?

Cleaning involves the removal of infected files, PHP backdoors, SQL injections, or malicious scripts. This is the immediate technical aspect, typically visible in the source code or server logs.

Completing recovery involves the Search Console: submitting a security review request, fixing crawl errors, and re-submitting the sitemap. Without this administrative step, the red warning remains displayed in search results even if the site is clean on the server side.

Is it really necessary to consult a specialist?

Google presents two options: internal resolution if there are sufficient technical skills, or hiring an expert. The distinction is important: an inexperienced owner might overlook the true vulnerability.

The most common hacks exploit outdated WordPress plugins, misconfigured server permissions, or weak passwords. Identifying the initial entry point requires a forensic analysis of Apache logs, suspicious POST requests, and dated file modifications. A superficial cleaning often leaves an active backdoor.

• Identify the vulnerability = complete audit of plugins, themes, CHMOD permissions, FTP/SSH accounts
• Fix the issue = update components, harden server configuration, rotate credentials
• Finalize the review = submit a review in Search Console, verify absence of malware via Safe Browsing, resubmit the clean sitemap
• Document the hack = keep a record of the exploited vulnerability to prevent recurrence on other projects
• Monitor post-recovery = alerts for file changes, log monitoring to detect any residual intrusion attempts

Does this procedure reflect the on-the-ground reality of recoveries?

Yes, but Google underestimates the processing time for review requests. In reality, a manual review can take anywhere from 48 hours to two weeks depending on Safe Browsing team workload. During this period, the site remains blacklisted, which kills organic traffic.

Another point: Google does not clarify that some hacks leave invisible traces in the Search Console. Mass-injected pages (like pharma hacks) may remain indexed even after cleaning. One must then go through a manual URL removal for each polluted page, significantly extending the process. [To verify]: Google claims that finalization is enough, but experience shows that manual de-indexing is often necessary.

Is the advice to consult an expert sincere or just CYA?

It's a legal disclaimer as much as a practical tip. Google avoids any liability if an owner fails the cleaning process. However, in reality, 80% of WordPress hacks are recoverable without an agency if one knows where to look.

The issue is the waste of time: a beginner might spend a week fumbling around while an expert resolves it in 3 hours. The real cost is not the intervention, it's the lost revenue during traffic interruption. An e-commerce site with 500 visits/day that remains blacklisted for 10 days could potentially lose several thousand euros in revenue.

What happens if the vulnerability is never truly identified?

Many recoveries fail because the owner cleans up the symptoms without diagnosing the root cause. The result is often a re-hack within a week, sometimes with a more aggressive variant.

Google does not validate the quality of your forensic investigation. If you submit a review request while an active backdoor remains, Google temporarily lifts the alert. Two weeks later, the Safe Browsing bot redetects malicious content and you’re back to square one. At this point, the unblocking time extends because you are marked as a repeat offender.

What should you do immediately after detecting the hack?

The first action: stop the bleeding. Put the site in maintenance mode (not just a simple WP plugin, a real .htaccess file that blocks everything except your IP). This halts the indexing of new polluted pages and protects visitors.

Next, backup the current state before any cleaning. Paradoxical but essential: you will need to compare the infected files with a clean version to understand the injection method. Download a complete copy of the site (files + database) and archive it off the server.

How to identify the entry point of the hack without forensic skills?

Start with the classic attack vectors: outdated WordPress plugins (compare your list with recent CVEs), a pirated theme downloaded from a torrent site, weak admin passwords (admin/admin, still common in 2025).

On the server side, look for recently modified PHP files with find . -name "*.php" -mtime -7. Backdoors often hide in /wp-includes/ or /wp-content/uploads/ with generic names like class-wp-widget.php. Any PHP file in the uploads folder is always suspicious.

What mistakes should be avoided during recovery?

Error #1: restoring an infected backup. Many hacks remain dormant for several weeks before activation. If you revert to a backup from 15 days ago, you may be reinstalling the backdoor. Always test the backup with an anti-malware scanner before restoration.

Error #2: forgetting to change all credentials. After cleaning, regenerate WordPress security keys (wp-config.php), change FTP, SSH, database passwords, and all WP admin accounts. An attacker who gained root access often retains a dormant account for later access.

• Put the site in strict maintenance mode (htaccess, not WP plugin)
• Backup the infected state for post-mortem analysis
• Scan all PHP files with a tool like Wordfence CLI or grep to look for base64_decode, eval, gzinflate
• Compare WordPress core files with a clean installation (via WP-CLI: wp core verify-checksums)
• Regenerate wp-config.php salts and force all users to log back in
• Submit a review request in Search Console with a precise description of the fixed vulnerability
• Monitor access logs for 30 days to detect any residual suspicious activity