WordPress Site Suspended by Its Host for Malware: Recovery Order

A WordPress site stops loading. The hosting panel says “suspended” or “malware detected”, and the provider’s email says the service will return after the issue is fixed. A common first reaction is to point DNS elsewhere, delete the file that looks most suspicious, and ask the host to switch the site back on. That order can destroy evidence while leaving the entry point open.

The short answer is: do not bypass the host’s restriction and do not delete evidence blindly. Read the notice, ask for the findings and restoration requirements, preserve the copies and logs you are allowed to access, clean the root cause on a safe copy, close persistence, and only then request a rescan and reactivation. Each provider has its own process; there is no universal button or turnaround time.

This guide focuses on coordinating with a hosting provider and recovering after a suspension. For common technical symptoms, see our guide to signs of malware on a WordPress site. If you need incident response from the beginning, start with what to do when a website is hacked.

What “suspended for malware” means—and what it does not tell you

A suspension notice is an operational action by the provider, not a complete diagnosis. A provider may limit one website, disable a hosting account, quarantine files, restrict processes, or block public access. The exact action and reason depend on the provider’s infrastructure and policy. Do not assume that the email identifies one known malicious file.

A suspension also does not automatically mean that every database record was stolen or every site in the account is infected. Still, treat the site as an incident until you know the scope. Establish four things:

• What was detected? Ask for the finding category, file or URL examples, traffic pattern, and time range if the provider can share them.
• What is restricted? Ask whether file access, databases, backups, logs, the panel, email, and subdomains remain available, and what must not be bypassed.
• What is required for restoration? Request the actions that must be completed before a rescan or reactivation; do not guess what the provider accepts.
• Who is responsible? Identify the technical contact, account owner, developer, and CDN provider, and agree who can approve changes.

Use the official support channel shown in the hosting dashboard or the provider’s known website. Do not send a WordPress password or payment details through an unverified email. If a suspension message asks you to log in using an unusual link, open the panel using an address you already know instead.

Step 1: read the notice and do not fight the quarantine

Save the email, ticket number, suspension screen, incident time, named domain, and recent changes. Record whether the issue began after an update, migration, plugin installation, or account change. These events are clues, not proof that one change caused the infection.

Do not try another server IP, create a new hosting account to evade the restriction, or change DNS so visitors reach an unexamined copy. That can expose visitors to harmful content, complicate the provider’s logs, violate its service rules, or disrupt the investigation. If the site is still serving a harmful page, use an isolation option approved by the provider.

Reply with precise questions: ask for sample files or URLs, the detection time and method that can be shared, which account areas are restricted, how to export a backup or logs safely, what the rescan process requires, and what evidence the provider needs before reactivation. A provider may not share certain details to protect a shared system; follow the limits it sets.

Step 2: preserve evidence and a working copy

Before cleaning, inventory the material you can access legitimately:

1. Take a snapshot of files and the database as they were found; store it separately with limited access.
2. Export logs made available by the host, such as web access or error logs, file-change records, panel logins, or relevant security notices. Ask how long they are retained.
3. Record affected URLs, timestamps, authorised WordPress users, active plugin and theme versions, and the last changes you know about.
4. Ask whether a provider backup is from before or after the compromise. “Daily backup” does not prove that a copy is clean.
5. Choose the working copy to investigate, ideally on staging or an isolated environment that does not serve visitors.

Do not overwrite the only current copy with a restore. Keep one copy for analysis and one recovery copy that can be tested. If panel access is closed, ask the provider for an approved export route or whether it can supply a controlled copy and logs. Do not try to break out of isolation using a script or alternate credentials.

Step 3: decide whether a clean restore or manual cleanup is appropriate

Choose the path based on evidence, not because a restore feels faster.

Restore from a backup

A backup is a candidate only if it predates the signs of compromise, uses supported components, and you know what data will be lost or changed. Preserve the original backup; restore it to staging first, scan its content, and compare it with the host’s findings. The database and files should represent one consistent recovery point.

Do not restore a provider snapshot taken after malware arrived without inspecting it. Do not copy back the plugin, theme, or credentials that formed the entry point. After a restore, update vulnerable components, rotate access, and test before requesting reactivation.

Manual cleanup or rebuilding from trusted sources

If there is no trustworthy backup or the compromise spans several areas, a technician may need to compare files with official packages, inspect plugins and themes and the uploads directory, and investigate the database, users, redirects, and scheduled tasks. WP-CLI’s documentation for core checksum verification and official plugin checksum verification can help identify unexpected changes, but neither covers every custom or paid theme, database record, or server rule. Someone familiar with the site must interpret the findings.

Also review administrator accounts, application passwords, active sessions, SFTP/SSH, database, hosting-panel access, and recovery email. Removing one file named by the provider will not close the source if another account or backdoor can recreate it. If the finding is spam posts or comments, distinguish user-generated spam from a compromise; our article on WordPress spam comments and unknown posts explains when the issue needs a security audit.

Step 4: close the entry point before asking the host to reopen the site

Before requesting a rescan, confirm that each entry path you found has been addressed:

• update WordPress core, plugins, and themes from trusted sources; remove unused or unsupported components;
• revoke accounts and tokens you cannot authorise after confirming ownership;
• change WordPress, hosting-panel, SFTP/SSH, database, email, CDN, and related integration credentials from a trusted device;
• end old sessions and revoke application passwords or API keys that are no longer needed;
• review configuration files, redirect rules, must-use plugins, cron tasks, and directory permissions;
• enable protections approved by the host without hiding malicious behaviour from its scanner.

Credential rotation must be coordinated if the application uses a database password or shared secrets across environments. Changing a password without updating the configuration that depends on it can leave the site broken. Record who receives each new secret and store it only in an approved password manager or team mechanism.

Step 5: request a rescan with a verifiable summary

After cleanup and internal testing, reply in the host’s ticket with:

1. the ticket or affected domain;
2. what you found and what you changed;
3. the update, credential rotation, and cleanup of relevant accounts, files, and database records;
4. the URLs and services you tested;
5. a clear question about whether the host needs to run a rescan or perform another verification.

Do not claim “100% malware-free” if you checked only one directory. Ask the provider to explain the next test result and any remaining evidence it needs. Wait for its instructions before restoring public traffic. Timing depends on the host’s process, available access, and incident scope; do not assume an emergency ticket is completed by a particular time.

Step 6: test the site after the host reactivates service

Reactivation is not the finish line. Test the site in a safe order:

• Open the homepage and host-named URLs in an anonymous browser. Record HTTP status, redirects, and TLS certificate behaviour.
• Test affected URLs and host variants; confirm that phishing or malware is not being served by the origin, CDN, or cache.
• Sign in to WordPress only after the rotated credentials work; review users, roles, plugins, scheduled posts, and expected changes.
• Test forms, notification email, checkout, webhooks, and transactions in a controlled way. Do not make a real payment as a test without an approved process.
• Check error logs and provider reports after reopening, then enable monitoring and tested backups.

If the host still finds an issue, isolate the site again as instructed and ask for more detail. If the site works but a browser warning remains, check Google Safe Browsing and the Search Console Security issues report using the appropriate process. Neither is proof that the hosting provider has reopened every service.

Mistakes that extend a suspension

• Deleting files based on their name alone. Malware can use ordinary filenames, and a legitimate file can look unfamiliar to a new owner.
• Restoring a backup without checking its date and contents. A snapshot that contains persistence can lead to another suspension.
• Changing DNS to bypass a restriction. Visitors may reach an unexamined copy while the provider still sees the same account.
• Changing only the WordPress password. Hosting, email, tokens, and file access can remain exposed.
• Sending passwords to someone claiming to be the host. Use the official channel and grant limited access only when approved.
• Demanding reactivation without evidence of cleanup. The host may have to repeat its checks or may decline to reopen the site.
• Treating one scanner result as certainty. A scanner has a scope and limits; compare its result with URLs, logs, files, and configuration.
• Assuming Google and the host share one process. The host decides its service status; Google manages its own Search and security reports.

Prevent another suspension after recovery

Assign owners to hosting and WordPress accounts, use MFA where available, review developer access after a project ends, and use unique credentials. Update core, plugins, and themes through a tested routine; remove unused plugins; limit file access; and ensure public forms do not create an abuse path. Keep an off-site backup that can be restored and record versions and configuration before updates.

Keep technical contacts on the hosting account current and make sure alerts do not go to an inbox no one checks. Write a short incident procedure: who contacts the host, where logs are stored, who can approve a restore, and how customer communications are handled. For routine safeguards, see our guide to securing a small-business WordPress site.

When to escalate

Contact a specialist if the host has locked access, the database or core files contain widespread changes, unknown admin accounts return, the site processes orders, or the logs may involve other websites in the same account. Escalation is also appropriate when there is no copy that can be tested or you cannot distinguish malware from legitimate files without risking the service.

Rawat Web offers initial diagnosis through Website Emergency Assistance and a Free Audit. Start with the URL and a copy of the suspension notice with sensitive details removed; do not send a password. If cleanup is required, access and scope are agreed before work begins, changes are recorded, and we coordinate verification with the host. We cannot control the provider’s decision or activation timeline.

Frequently asked questions

Can I change DNS as soon as hosting suspends the site?

Do not use a DNS change to bypass the suspension. Speak with the host first and isolate the site in an approved way. A DNS change does not clean files or a database and can direct visitors to a copy that has not been checked.

Is a provider backup safe to restore?

Not automatically. Check its date against the first signs of the incident and restore it to staging to inspect files and database records. A backup taken after the compromise may contain malware or an account created by an attacker.

Does an active website mean Safe Browsing is clear too?

No. Hosting reactivation and Google’s status are separate processes. Test the website, check the Search Console Security issues report and Safe Browsing status if there is a warning, and follow each service’s own review process.

What should I send to the hosting provider?

Use the official ticket number, a summary of findings and corrective work, URLs tested, and a question about its rescan requirements. Do not send passwords through ordinary email; use an access method the provider approves.