Practical security advice for website owners
WordPress Hosting Suspended for Malware? Prepare a Recovery Request
Security guidance · References checked 2 November 2026
In this guide
A hosting suspension can leave you unable to open your WordPress dashboard or inspect the public website. The next step is not necessarily to buy another server or restore the newest backup. First establish what the host has restricted, why it was restricted and which authorised recovery methods remain available.
This guide focuses on communication and recovery planning when a provider reports malware or abuse. A suspension is an operational state, not a diagnosis of the exact vulnerability or proof that every file is infected. Your host controls its own reinstatement decision and review process.
Verify the notice and the scope
Sign in through your usual bookmarked hosting portal rather than an unexpected email link. Confirm that the notice is genuine and record the ticket reference. Distinguish a suspended website from an inactive hosting plan, an expired domain, a billing problem, a resource restriction or an application error.
For example, Hostinger documents that an individual website can be suspended while the broader hosting plan remains active, and directs owners to support for the reason and resolution. Other providers may use different terminology and processes. Hostinger’s inactive-plan and suspension guidance.
Ask which domains, directories and services are affected. Find out whether email, backups, database access, SFTP/SSH and the control panel remain available. A clear scope prevents you from assuming that one disabled website means all your records are gone.
Ask for information that can guide the investigation
Request the available detection details: affected paths, scan timestamps, category of concern, relevant non-sensitive log excerpts and any actions the host already took. Ask whether suspicious files were quarantined, modified or removed, and whether a pre-action copy is available.
A filename or scanner label is a lead. It may identify a useful starting point, but it does not necessarily explain the original entry route or every affected component. Preserve the original report alongside your own findings so later reviewers can distinguish the host’s observations from the cleanup work.
Do not ask support to email passwords or an entire customer database. Arrange protected access or an approved export method. If access is unavailable, ask what limited recovery access or host-assisted copying they can provide and under what conditions.
Preserve what remains available
Where possible, keep a private copy of current files, the database, available logs and relevant configuration before repairs begin. Label the snapshot with its source and time. A snapshot is evidence of that state; it is not automatically a clean recovery point.
Record earlier backups separately and find out whether the host can make them available without overwriting the current site. An archive made after an infection began may contain the same problem. The backup restoration guide explains how to assess this decision more carefully.
If the provider has already cleaned or quarantined files, document that limitation. Avoid claiming a complete historical account of an incident when some original material is missing. Ask the responder to state what could be investigated and what could not.
Agree an authorised route for repair
Your developer may need hosting-level access rather than a WordPress administrator login. Agree who will perform the work, the affected website, the access required and how that access will end afterwards. Use named temporary access where the provider supports it.
Do not try to evade a suspension by pointing the domain at an unreviewed copy or moving the same infected archive to another host. That can recreate the problem and leave the underlying compromise unresolved. If a migration is part of an approved recovery plan, include cleanup, validation and the receiving provider’s requirements.
Keep the host informed about the planned method. They may require a rescan, specific evidence or other checks before reopening access. Ask for those criteria early so the recovery team is not guessing at the final step.
Treat scanner results as part of the evidence
Provider scanning can help identify suspicious files, but its coverage and features vary by plan and product. Hostinger’s malware-scanner documentation describes its own file-scanning workflow and cleanup options. Check the current provider guidance for your account instead of assuming another host has the same capabilities.
A clean result from one scanner does not prove that credentials, database content, custom code and neighbouring sites were all investigated. Likewise, a flagged file should be reviewed in context rather than deleted blindly when it may contain required business functionality.
Use trusted-reference comparisons where appropriate, and record the areas they exclude. The WordPress file-integrity guide explains how to interpret successful checks, mismatches and missing references.
Prepare a concise reinstatement request
Keep the message factual and easy for support to review. A useful structure is:
- The website and original ticket reference.
- The reported symptoms and the host’s detection reference.
- The affected components that were reviewed.
- Confirmed malicious material removed or repaired, without exposing private code.
- Approved software updates, access changes and other relevant improvements.
- Verification performed and any remaining limitations.
- A request for the host’s rescan and the next reinstatement step.
This is a communication template, not a substitute for technical investigation. Avoid statements such as “100% safe forever” or “all data definitely untouched” unless the evidence could support the relevant claim—and permanent protection is not something a cleanup can establish.
If the issue involves spam, phishing, payment behaviour or customer records, involve the relevant provider or qualified adviser. A reinstatement ticket alone does not resolve every consequence of an incident.
Check the site after the restriction is lifted
Once the host permits the agreed return to service, verify the website from normal visitor and authorised staff perspectives. Test the relevant forms, login, key pages, scheduled tasks and supported store integrations using a safe method. Confirm that the correct files and database are serving the domain.
Review whether old compromised credentials, unused deployments or another affected website in the same account still need attention. A publicly visible homepage is not proof that every recovery task has finished.
Keep the final host response, scan results and recovery report together. Assign a follow-up owner for the remaining recommendations. The useful outcome is a documented recovery and a clearer operational process, while recognising that only the host can confirm its own restrictions have been removed.
Published by NithuDev. About Nithu / Suthakaran Nithursan, website developer and security recovery specialist. Featured artwork is an AI-generated editorial illustration, not a photograph of a client, a real security incident or a verified tool result.