Is it really necessary to contact your host after a website hack?

Why does Google emphasize the host's role in dealing with a hack?

When Google detects a hacked site, the priority is to stop the spread of malicious content before lifting ranking penalties. However, cleaning the site from the CMS side (WordPress, Joomla, etc.) is not always sufficient.

If the server itself is compromised, malicious files can regenerate automatically. An informed host can verify the integrity of the system stack (Apache, PHP, MySQL), spot suspicious processes, and restore a clean version from an infrastructure snapshot.

Another reason: your site might not be the only one affected. Hackers often target vulnerabilities in shared environments. Notifying the host allows them to protect all their clients and fix the breach upstream.

What immediate corrective actions can a host take?

A good host has automated anomaly detection tools: spikes in suspicious traffic, abnormal SQL queries, modifications of core files outside maintenance windows. Once alerted, they can isolate your account in a temporary container to prevent further spread.

On the corrective side, they can restore file permissions (often modified to execute arbitrary code), reset FTP/SSH passwords, and scan for malicious cron jobs. Some premium hosts even offer a cleaning service included in their SLA.

Does the host always have the skills to handle advanced hacking?

Let's be honest: not all hosts are equal. Low-cost shared hosting often responds with a generic ticket advising to "check your plugins". Managed infrastructures (WP Engine, Kinsta, etc.) have specialized security teams for WordPress.

In complex cases (persistent SQL injection, rootkits, hidden cryptomining), the host sometimes limits itself to providing access logs. This is already valuable for identifying the intrusion vector, but the cleanup remains your responsibility.

• Contact your host as soon as you detect the hack, even before touching any files (to preserve forensic traces).
• Request a clean infrastructure snapshot if available, instead of manually restoring file by file.
• Check if your plan includes security support: some hosts charge for this service on demand.
• Ask for the Apache/Nginx logs from the last 7 days to analyze suspicious requests and identify the backdoor.
• Isolate the hacked site in a temporary subdomain during the cleanup to prevent Google from indexing additional malicious content.

Is this recommendation aligned with practices observed in the field?

Yes, and this is one of the rare occasions where Google and SEO practitioners agree without reservation. Hosts have access to logs and system tools that you do not have from cPanel or Plesk. Ignoring this step risks cleaning the surface while the malware regenerates from a hidden cron job.

However, the effectiveness of this approach depends entirely on your host. Field reports show that shared hosting at 3€/month often merely suggests a complete reinstallation. Specialized hosts (especially those with security SLAs) can block the attack in under an hour. [To be checked]: Google never specifies what level of support to expect, which complicates sizing the effort.

What are the limits of this approach in complex environments?

If you are on an unmanaged VPS or dedicated server, contacting "the host" means sending a ticket to OVH or AWS which will respond: "it’s your responsibility". In this case, Google's recommendation is moot: you either need sysadmin skills or must hire a specialized provider.

Another limit: distributed cloud architectures (CloudFlare Workers, Vercel, Netlify). The hack may originate from a misconfigured S3 bucket or a compromised third-party API. Your front-end host can't help with that. Google remains vague on these modern use cases, which reflects a very "classic LAMP stack" view of the web.

Should you really wait for the host to act before cleaning yourself?

No, and this is where Google's phrasing can be misleading. "Contacting the host" does not mean "waiting passively". If you have the skills, start the cleanup in parallel: delete suspicious files, change all passwords, disable unknown user accounts.

The host primarily intervenes to secure the infrastructure layer (firewall, IDS, system snapshot restoration). You clean the application layer (CMS, database, themes/plugins). Both actions are complementary, not sequential. Waiting 48 hours for a host to respond while Google indexes pharma spam is a tactical error.

What should you concretely do in the first hours after detecting a hack?

Open a priority ticket with your host immediately, even if you think you can handle it alone. Mention the precise symptoms: unwanted 301 redirects, suspicious .php files in /wp-content, Search Console warnings "Site hacked". The more precise you are, the faster the response will be.

In the meantime, put the site in maintenance mode via a plugin or an .htaccess file to stop the SEO bleed. Google will continue to crawl, but at least it won’t find new spam pages. Then, download a complete copy of the site (files + database) before any modifications: you will need this "evidence" for forensic analysis.

How to check if the host has actually taken corrective measures?

Explicitly ask them: which logs did they consult, which IP did they block, which suspicious processes did they kill. A serious host will provide you with an intervention report (even if summarized). If they respond "we have strengthened security" without details, consider that nothing concrete has been done.

Check server side: the permissions of critical folders should be 755 (for folders) and 644 (for files). If you find 777 everywhere, the host has not corrected anything. Also inspect cron jobs (the command `crontab -l` in SSH): malware often schedules automatic reinfections there.

What mistakes should you absolutely avoid when managing a hack with the host?

Never restore a backup without having identified the intrusion vector. If the vulnerability is still present (outdated plugin, weak password), you will be hacked again within 72 hours. The host can restore a clean system snapshot, but it’s up to you to fix the application vulnerability.

Another common mistake: only changing the WordPress admin password. Hackers often create hidden administrator accounts, change FTP credentials, and inject backdoors into the code. A complete cleanup involves resetting ALL passwords (database, FTP, SSH, domain email accounts) and scanning each recently modified file.

• Open a ticket with the host including screenshots of the symptoms and Search Console logs
• Ask explicitly: is a snapshot available? Access logs from the last 7 days? Suspicious IPs blocked?
• Put the site in public maintenance mode during the cleanup (to prevent indexing new spam pages)
• Download a complete copy (files + database) BEFORE any modifications for analysis
• Check file/folder permissions after host intervention (644/755 expected)
• Scan cron jobs and system user accounts to detect persistent backdoors