Hosting Account Suspended for Malware? The Complete Recovery Playbook (Bluehost, SiteGround, Hostinger & More)

You opened your laptop, typed your domain, and instead of your site you got a page screaming “This Account Has Been Suspended” — or “This site is currently unavailable” on SiteGround, or “Hosting plan is suspended” on Hostinger. Your host pulled the plug. And in most of these cases, the trigger isn’t a missed invoice. It’s malware. I’ve cleaned more than 4,500 hacked WordPress sites, and a sizable chunk of them came to me after the host had already suspended the account. The recovery process is very different from a normal malware cleanup — you’re racing against deletion timers, you have to talk to an abuse team that doesn’t trust you yet, and any wrong move can get your account terminated for good. This is the playbook.

What “This Account Has Been Suspended” Actually Means

When a hosting provider suspends an account, they stop serving your website at the web-server level. The DNS still resolves to your hosting IP, but instead of routing the request to your WordPress install, the server returns a static suspension page. Your files are not deleted — yet. They sit on disk, frozen, until the abuse team or billing team marks the account as resolved. The exact wording on that page depends on the hosting stack. cPanel-based hosts (Bluehost, HostGator, Namecheap shared, A2, many resellers) show the classic “This Account has been Suspended” page served from /cgi-sys/suspendedpage.cgi. SiteGround shows a rain cloud illustration with “This site is currently unavailable.” Hostinger shows a pink “Hosting plan is suspended” banner inside hPanel. WP Engine and Kinsta send you to a maintenance-style page through their custom stacks.

What does /cgi-sys/suspendedpage.cgi mean?

suspendedpage.cgi is a built-in cPanel/WHM script that displays a default suspension page to every visitor. The path /cgi-sys/suspendedpage.cgi in the browser address bar is not from your WordPress site — it’s the cPanel server intercepting the request before WordPress ever loads. If you see that URL, your host is using cPanel and has explicitly run the “Suspend Account” action against your username. Only the hosting company can clear it.

Why Malware Is the Most Likely Cause (Even If the Page Doesn’t Say So)

The suspension page is deliberately vague. Hosts don’t broadcast malware details on a public URL because it would tip off attackers and embarrass you. The real reason lives in a ticket or email — usually titled something like “Account suspended – Malicious content detected,” “Abuse notification,” “AUP violation – Malware,” or “Urgent: action required on your hosting account.” In the cleanups I’ve done after a hosting suspension, the trigger usually falls into one of these categories:

• • SEO spam / Japanese keyword hack generating tens of thousands of cloaked pages and burning CPU. See my Japanese keyword hack guide for what the host actually sees in your error logs.

• • PHP webshells and backdoors — files like wp-tmp.php, radio.php, files with names that look legitimate (wp-blog-header.php dropped in the wrong folder) or with random eight-letter names in /wp-content/uploads/. Hosts run YARA/ClamAV signatures and flag these on contact.

• • JavaScript redirect malware sending mobile users to scam landing pages. Hosts catch this via abuse reports from visitors or from Google Safe Browsing notifications forwarded to them.

• • Outbound spam from a compromised wp-mail setup — your site is now part of a botnet sending phishing email, and the host’s mail logs lit up like a Christmas tree.

• • Phishing pages — hackers drop a fake Microsoft/PayPal/banking login form inside a deep folder. One PhishTank report and the host suspends you within hours.

• • Excessive resource usage caused by malware — the malware itself isn’t the citation, the CPU/inode/IO bill is, but the underlying cause is still a hacked site.

If your suspension email mentions any of those terms — “malicious file,” “abuse report,” “phishing,” “spam complaint,” “malware signature,” “abuse@” — you are dealing with a security incident, not a billing problem. Treat it that way.

Decoding the Suspension Page by Host

Different hosts behave very differently after a suspension. Knowing your host’s playbook is half the battle. Here’s what I’ve seen across hundreds of suspensions.

Bluehost (cPanel)

Bluehost is the most aggressive of the mainstream shared hosts. They suspend on the first confirmed malware hit and the suspension page lives at /cgi-sys/suspendedpage.cgi. They will email you a list of infected file paths, often hundreds of lines long. The cPanel itself usually remains accessible at yourdomain.com/cpanel or my.bluehost.com, so you can still get into File Manager and phpMyAdmin while the public site is down. I’ve documented a real Bluehost suspension recovery in this case study about hidden executable files, and a full account restoration in this Bluehost recovery case study.

SiteGround

SiteGround shows the “This site is currently unavailable” rain-cloud page. They are far less trigger-happy — they tend to quarantine the site rather than nuke access, and the User Area stays usable so you can pull a backup, run their Site Scanner, and use SFTP. They will whitelist your IP on request via chat. SiteGround’s malware policy is documented and predictable. I recommend them to clients for that reason — I explained why in my SiteGround review.

Hostinger

Hostinger’s hPanel shows a pink “Hosting plan is suspended – Contact us” banner on the affected site card. The rest of your hPanel still works. Their abuse team replies through the live chat widget; they usually share a JSON or CSV file with the list of detected malicious files and the timestamps they were last modified. Hostinger gives you a fixed window (typically 7 days) to clean before they delete data.

HostGator, Namecheap Shared, A2, InMotion

All cPanel-based, all serve the standard /cgi-sys/suspendedpage.cgi. Behavior varies by reseller — some keep cPanel open, some kill the whole account login. Always start with chat support to get cPanel access restored under a “cleanup window.”

GoDaddy

GoDaddy’s suspension flow goes through their “Sucuri-by-GoDaddy” or “Express Malware Removal” upsell. They will quote you a price to clean the site for you. You’re not obligated to take that path — you can request a self-clean window. Document everything in the ticket, because GoDaddy abuse reps rotate and context gets lost between handoffs.

WP Engine, Kinsta, Cloudways (managed WP)

Managed WordPress hosts rarely “suspend” in the cPanel sense — they put the site into maintenance/staging mode or take it offline behind a holding page. They almost always include cleanup in their support, though they may charge extra for emergency response. SSH/SFTP access usually stays open.

Step-by-Step: Getting Unsuspended Without Getting Re-Suspended

This is the sequence I follow on every suspended-account cleanup. Skipping steps is how you end up permanently terminated.

Step 1 — Read the abuse ticket carefully (don’t skim)

The abuse ticket has three things you need: the suspension reason, the list of file paths the scanner flagged, and the deletion deadline. Save a copy of the email and the file list locally before doing anything. If the list is missing, reply and ask: “Please send the full list of files flagged by your security scanner, including paths, timestamps, and the signature name (e.g., php.malware.backdoor.generic).”

Step 2 — Request IP whitelisting and a cleanup window

You can’t fix what you can’t reach. Most hosts will whitelist your public IP so you can access the suspended site for cleanup. Use this exact wording — it works because it tells the abuse team you understand the protocol:

Step 3 — Take a full backup before you touch anything

Yes, even when the site is hacked. You need the dirty backup for two reasons: forensics (so you can study which entry point was used) and rollback safety (so you don’t accidentally delete a “malicious” file the host flagged as a false positive — it happens). Pull a full file zip and a database dump via SSH or File Manager. If you need a refresher, my UpdraftPlus backup guide walks through it.

Step 4 — Process the host’s file list properly

Don’t just bulk-delete the list. For each flagged path: open it, confirm it’s actually malicious (compare to a fresh WordPress install for core files, compare to the original plugin/theme zip for plugin/theme files), then either remove or replace. Most lists fall into three buckets:

• • Pure malware drops — files that shouldn’t exist. Delete.

• • Infected core/plugin/theme files — replace with the original from the WordPress repo or the vendor.

• • Database injections — usually in wp_options (rogue rows in active_plugins, siteurl overrides), wp_posts (spam content), and wp_users (hidden admins). My guide on finding hidden admin users covers the user-table angle.

Step 5 — Find the backdoors the host’s scanner missed

This is the step that separates a permanent fix from a 48-hour re-suspension. Host-side scanners catch maybe 60–80% of what’s there. They miss heavily obfuscated webshells, sleeper backdoors with no signature, and database-resident malware. If you only delete what the host listed, the attacker walks back in within hours through a backdoor that was never flagged, the site gets re-infected, the host re-scans, and you’re suspended again — this time with much less goodwill from the abuse team. Run a manual hunt across wp-content/uploads/, wp-content/plugins/, and the WordPress root. Look for recently modified PHP files in folders that shouldn’t have PHP at all (the uploads folder), files with random names, files with base64_decode, gzinflate, eval, str_rot13, or assert in unusual contexts. I cover this in depth in my obfuscated PHP malware detection guide and this writeup on a hidden backdoor I found in a client’s site.

Step 6 — Patch the entry point, not just the symptom

If you don’t fix how they got in, they get back in. The usual entry points: an outdated plugin with a known vulnerability, a nulled theme, a leaked admin password, exposed wp-config.php from a public backup, or cross-site contamination from another infected site on the same hosting account. Identify it, close it, then rotate every credential the site touches — WordPress admin users, database password, SFTP password, hosting account password, and any API keys in wp-config.php or .env. This is the step most owners skip, which is why I wrote “Why WordPress malware keeps coming back.”

Step 7 — Reply to the ticket with proof, then request reactivation

This is where most owners blow it. They reply “all clean, please reactivate,” the host re-scans, finds the missed backdoor, and slams the door shut. Instead, send a structured report:

1. 1. Confirmation that every file on their list was removed or replaced (one-line per file is fine).

1. 1. A summary of additional backdoors you found and removed that weren’t on their list.

1. 1. A statement of the entry point you patched (e.g., “Outdated [plugin name] 1.4.2 upgraded to 1.5.7; CVE-XXXX patched”).

1. 1. A clean scan report — Wordfence, Sucuri SiteCheck, or the host’s own scanner.

1. 1. A short “future prevention” line (WAF enabled, 2FA on admins, backups configured).

That report converts the abuse team from skeptic to ally. Reactivation usually happens within hours instead of days.

The Hidden Trap Most Posts Don’t Mention: Premature Reactivation Requests

Every hosting abuse team gets the same volume of “it’s clean now, please reactivate” replies that are obviously not clean. Their scanners catch this on re-scan, and from that point you are flagged as a high-risk account. A second strike usually means a much longer suspension window and a real conversation about termination. On Bluehost, I’ve seen accounts go straight to “30 days to migrate, then deletion” after a botched re-scan. The rule is: never ask for reactivation until you can pass the host’s scan yourself. Most cPanel hosts run ImunifyAV or similar tools and let you re-scan from cPanel before submitting. Use that. If you don’t have access, run Wordfence + a fresh manual file integrity check against the WordPress.org checksums and only then submit.

When the Malware Keeps Reappearing After You Clean It

Some infections regenerate. You delete a file, refresh, and it’s back. This is a sign of a persistence mechanism — a hidden cron job, a watchdog process, a “regenerator” hook in a database option, or a compromised must-use plugin. If that’s happening, stop deleting files in a loop and isolate the regenerator first. I documented one of these in the regenerating WordPress malware case study and another in the wp-blog-header.php regeneration case. Hosts will not be patient with a site that re-infects itself during a cleanup window — find the regenerator, kill it, then resume.

If Your Host Has Already Deleted the Account

Worst case: deadline passed, you didn’t act, account is gone. Your options shrink fast but they’re not zero:

• • Ask for a final backup. Many hosts keep a short window (7–30 days) of internal backups even after deletion. Open a billing ticket and request a one-time data export. It’s not advertised but it often works.

• • Check your own backups — UpdraftPlus to Google Drive, All-in-One WP Migration files, server snapshot from a managed host, or even an old staging copy. Any of these can be the seed for a rebuild.

• • Reconstruct from Google’s cache and the Wayback Machine for content; the database and theme can be partially rebuilt this way if you have nothing else.

• • Move to a different host before restoring — if the old host terminated for AUP violation, restoring on the same account is usually blocked. Restore on a clean account, clean the backup as you go.

Preventing the Next Suspension

Once you’re back online, the work isn’t done. Hosts watch reinstated accounts more closely than first-time ones. Burn through this checklist:

• • Update WordPress core, every plugin, every theme — even the ones you don’t use, then delete the unused ones.

• • Remove any nulled or pirated plugins/themes. They are the #1 source of repeat infections; see the risks of nulled plugins.

• • Enable 2FA on every WordPress admin. Force a password reset for all users with publishing rights.

• • Install a security plugin with file integrity monitoring (Wordfence, Solid Security, or Sucuri).

• • Set up automatic off-site backups — daily for active sites — to a separate provider than the host. If your host deletes you, an on-host backup won’t help.

• • Tighten file permissions (644 files, 755 folders, 440 on wp-config.php where allowed).

• • Disable PHP execution in /wp-content/uploads/ via .htaccess or NGINX rules. This single change kills most uploaded webshells.

For the full post-cleanup checklist I use on every recovered site, see “What to do after fixing a hacked WordPress site.”

FAQ

How long does a malware suspension last?

From a few hours to indefinitely. If you respond fast with a clean re-scan, most hosts reactivate within 2–24 hours. If you ignore the ticket, the typical window before account deletion is 7–30 days depending on the provider.

Can I just move to a new host instead of cleaning?

Technically yes, practically no. If you migrate an infected site to a new host, the new host’s scanner will catch the same malware within days and suspend you again — often faster, because the malware is already known to security vendors. Clean first, then migrate if you want to.

My host says I need to pay them for malware removal. Do I have to?

No. The host’s own cleanup service (often labeled “Express Malware Removal” or routed through their security partner) is one option among many. You are free to clean the site yourself or hire an independent specialist. The host is obligated to give you a reasonable cleanup window either way.

Why was my account suspended without warning?

For malware-related suspensions, most hosts skip the warning step on purpose. A delay would let the infection spread to other accounts on the same server, or let phishing pages collect more victims. Billing-related suspensions normally come with multiple warnings; malware-related ones do not.

Does a hosting suspension affect my Google rankings?

Yes, but indirectly. Google can’t crawl a suspended site, so cached pages get devalued and ranking signals decay. Worse, if the malware that triggered the suspension also caused a Google Safe Browsing flag, you’ll need to file a reconsideration request through Search Console after cleanup. My blacklist removal guide walks through that process.

Will my email work while my hosting account is suspended?

Usually no, if your email runs through the same hosting account (cPanel mail). Outbound spam is one of the common suspension triggers, so hosts typically kill mail along with web service. Use a separate email provider (Google Workspace, Microsoft 365, Zoho) for business email to avoid losing communication during a hosting incident.

Is “your page is at risk of being suspended” the same warning?

That’s the pre-suspension notification. The host has detected something — usually elevated resource usage or a low-severity malware hit — and is giving you a short window to fix it before pulling the trigger. Treat this email as if the suspension already happened: scan, clean, and reply with proof.

When to Get Professional Help

A malware suspension is one of the few scenarios where speed has a measurable price tag — every hour your site is down is lost traffic, lost sales, and lost trust. If any of the following are true, get a specialist on it now, not in three days:

• • The host’s flagged list is 100+ files, or includes core WordPress files.

• • You’ve cleaned once and the malware came back.

• • You don’t have a recent clean backup.

• • You’re seeing the Japanese keyword hack, pharma hack, or mobile-redirect symptoms — these always have multi-layer persistence.

• • Your deletion deadline is less than 72 hours away.

I’ve handled 4,500+ hacked WordPress cleanups — including dozens of mid-suspension recoveries on Bluehost, SiteGround, Hostinger, HostGator, GoDaddy, and managed WP hosts. If you’re staring at a suspended-account page right now and a ticking deletion clock, you can request a malware cleanup here or contact me directly. I respond to incident-mode requests within the hour. Related reading: The complete WordPress malware removal expert guide · How to detect WordPress malware · What 4,500 site cleanups taught me · JavaScript redirect malware removal · How to secure a WordPress site