A host may suspend a site to stop phishing, malware, spam, resource abuse or attacks on other customers. Repeatedly asking for unsuspension without a remediation plan can delay recovery and allow the same behaviour to resume.
Treat the provider’s report as incident evidence and build a clean copy offline or in an isolated environment.
Obtain the suspension details
Ask for the detected URLs/files, timestamps, abuse type, scanner evidence, mail/network activity and requirements for review. Record the ticket ID and responder.
Do not ask the host to execute suspicious files or send malware through normal email. Request secure access to quarantined evidence where their policy permits.
Clarify whether the entire account or one domain is suspended.
Preserve backups and logs
Request a filesystem/database snapshot plus access, error, PHP, mail and control-panel logs before retention expires. Keep the archive outside the public document root with restricted access.
Do not restore it directly to production or upload it to another public host. A backup is evidence and a source for controlled recovery, not proof of cleanliness.
Record backup date, size and source.
Secure account ownership
From a clean device, rotate hosting, registrar/DNS, primary email and deployment credentials. Revoke unknown users, sessions, API tokens and SSH/SFTP keys; enable MFA.
Confirm billing and account contacts have not changed. Follow the provider’s identity-verification process rather than sharing passwords in tickets.
Check whether a reseller or former developer still has control-plane access.
Build an isolated working copy
Use a local or isolated staging environment without live SMTP, payment or third-party production keys. Prevent public indexing and external callbacks.
Import the database and uploads for inspection, but install WordPress core/plugins/themes from trusted sources. Treat custom code and uploads as untrusted until reviewed.
Do not expose the infected copy on a guessable temporary domain.
Identify cause and scope
Review provider indicators, changed files, users, scheduled tasks, database injections, vulnerable plugin/theme versions and stolen credentials. Inspect sibling sites if the same account or user owns them.
Establish whether outbound spam, phishing pages or resource abuse came from WordPress, another application or a compromised hosting credential.
Removing the named file without finding persistence is insufficient.
Rebuild cleanly
Replace maintained components, validate custom code, import assessed content and media, and recreate configuration through known values. Close the vulnerable route and rotate database, salts, SMTP/API and payment secrets.
Apply supported PHP and WordPress versions, minimal file permissions and controlled administrators.
Keep an inventory of every component retained.
Define a safe reopening gate
Before requesting unsuspension, confirm the malicious behaviour has stopped in the isolated copy, the entry vector is corrected, privileged access is known and outbound mail cannot resume abuse.
Agree which hostname or document root the host will reactivate. Do not point production traffic at an unreviewed archive merely because the provider needs a URL to scan.
Keep a rollback and a rapid containment contact ready for the first live window.
Prepare evidence for the host
Provide a concise remediation summary: affected site, cause if known, removed/replaced components, credential rotations, security updates, spam/queue containment and verification performed.
Do not attach the whole database, customer data or new credentials. Answer the provider’s exact review questions and identify the clean document root.
Ask for a controlled reopening window if further validation requires public routing.
Verify after unsuspension
Test homepage, login, forms, checkout, cron, mail and redirects from clean sessions. Monitor resource usage, outbound traffic, modified files and privileged accounts.
Keep the old infected root isolated and non-executable for the approved retention period. Reconcile missed orders/leads and communicate through the incident owner.
Request emergency recovery when the host supplies only partial indicators or several sites share the account. Provide managed access and the ticket evidence—never post backups or credentials publicly.