What matters first: The host may disable HTTP, PHP, mail or the entire account after detecting malware, phishing, spam or resource abuse. The provider’s sample paths and timestamps are starting evidence, not a complete inventory.
What this symptom actually tells you
Restoring one website from an old backup can overwrite useful logs or reintroduce the vulnerable component. Coordinate evidence, clean source and account-wide scope.
Capture evidence before changing anything
- Request the provider’s exact detection reason, sample paths and timestamps.
- Obtain a full file/database backup and relevant access/mail logs before deletion.
- Inventory every site, subdomain, cron job and user under the hosting account.
- Identify whether the suspension also blocks database, SFTP or outbound mail.
Most common causes
- Malicious files: Scanner signatures or behaviour identify web shells, phishing or spam code.
- Abuse traffic: The account sends spam, attacks or excessive requests.
- Shared-account spread: One compromised site modifies others under the same user.
- Unpatched entry point: A vulnerable component remains installed across backups.
Safe diagnostic and repair sequence
- Work from a preserved copy and trusted clean packages.
- Clean all sites and server-level persistence under the account.
- Rotate hosting, SFTP, database, WordPress and mail credentials.
- Submit the provider’s requested evidence and keep monitoring after reactivation.
How to choose between the likely causes
Do not treat Malicious files and Abuse traffic as interchangeable. Scanner signatures or behaviour identify web shells, phishing or spam code. By contrast, the account sends spam, attacks or excessive requests. Use two checks to separate them: Request the provider’s exact detection reason, sample paths and timestamps; and obtain a full file/database backup and relevant access/mail logs before deletion. Those observations usually show whether the next safe move is to work from a preserved copy and trusted clean packages or to preserve the current state and widen the investigation.
On a compromised site, containment and cleanup are separate decisions. Preserve the suspicious artefact and access logs before removing persistence, then rotate credentials only after the active path has been closed. Record the exact timestamp, affected URL or transaction, last known good state and every change made during diagnosis. That handover is often what separates a repeatable repair from a temporary disappearance of the symptom.
What not to do
Do not ask for reactivation while unexplained files, users or vulnerable packages remain. A second suspension can arrive quickly and reduce provider trust.
How to verify the repair
- The provider confirms the account is clean and reactivated.
- All hosted sites pass integrity and user/cron review.
- No malware, spam or resource-abuse signal returns.
A visible symptom disappearing is not enough. Close the incident only when the original failing action, the surrounding business journey and the relevant logs all agree that the fault is gone.
WP REPAIR INCIDENT STANDARD
Reconstruct the incident before fixing it
Restoring one website from an old backup can overwrite useful logs or reintroduce the vulnerable component. Coordinate evidence, clean source and account-wide scope.
- 1
Request the provider’s exact detection reason, sample paths and timestamps.
- 2
Obtain a full file/database backup and relevant access/mail logs before deletion.
- 3
Inventory every site, subdomain, cron job and user under the hosting account.
- 4
Identify whether the suspension also blocks database, SFTP or outbound mail.
What must be verified
- The provider confirms the account is clean and reactivated.
- All hosted sites pass integrity and user/cron review.
- No malware, spam or resource-abuse signal returns.
Official technical sources
This guide explains the diagnosis. If the site is affected now, the intervention should preserve a rollback path and verify the real business journey.
See the emergency repair service →ABOUT THIS SYMPTOM
Frequently asked questions about this guide.
Should I restore the site from an old backup right after suspension to get back online quickly?+
Not immediately. Restoring from an old backup can overwrite logs needed to identify the entry point or reintroduce the same vulnerable component that caused the suspension in the first place, so evidence should be preserved before any restore happens.
Is it enough to clean just the one site the host flagged as malicious?+
No. The provider's sample paths and timestamps are a starting point, not a complete inventory, and other sites, subdomains, cron jobs, or users under the same hosting account can also be compromised or spreading the infection.
How soon should reactivation be requested after cleaning the flagged files?+
Only after confirming no unexplained files, users, or vulnerable packages remain anywhere on the account. Requesting reactivation while any of those are still present risks a second suspension arriving quickly, which also reduces the provider's trust for future incidents.
Does a hosting suspension always mean malicious files were found, rather than something like sending too much spam?+
No. Hosts can suspend an account for several distinct reasons, including malicious files, abuse traffic like spam or attack requests, or resource abuse, and the exact detection reason should be requested from the provider rather than assumed.