When a WordPress site is hacked, most teams reach for the fastest fix: delete suspicious files, restore a backup, let the host “clean things up.” It feels decisive—and it quietly erases the only clues that explain what actually happened.
Before cleaning WordPress malware, pause all changes and preserve a full backup, key logs, plugin and user lists, access details, and firewall or CDN settings so you can restore, investigate, and harden safely.
Think of the current, compromised state of your site as a crime scene. Cleanup is important, but the very first job is to capture reality before it’s overwritten by backups, auto-rotating logs, and rushed changes.
In support work, we often see this go wrong. A marketing lead notices spam redirects, the host restores a “clean” backup, and by the time security help arrives there are no logs, no access history, and no plugin version details left to examine. The incident becomes guesswork.
This guide focuses on that narrow window before anyone starts cleaning. You’ll walk through four categories of evidence to preserve so you can:
- Contain the damage without destroying the trail
- Restore the site with confidence in what changed
- Learn enough from the incident to reduce the odds of a repeat
We’ll also show how this connects to broader security monitoring decisions and your overall Maintenance Maturity—not just today’s fire drill.
You Only Get One Chance to Capture Malware Evidence
The first instinct during a malware incident is speed. Leadership wants the site “fixed by lunch.” Hosting support wants to restore yesterday’s backup and close the ticket.
The problem: every change you make without preserving evidence first is a decision to live with uncertainty later.
Common questions that become impossible to answer after a rushed cleanup:
- How did the attacker get in—weak password, vulnerable plugin, reused credentials, something else?
- What exactly changed—files, database entries, user roles, redirects, settings?
- How long was the site compromised and which visitors were affected?
- Are we actually safe now, or did we just hide the symptoms?
Without real evidence, leadership ends up approving more of the same: the same hosting setup, the same support model, the same blind spots.
To avoid that, capture four categories of evidence before you or any vendor start changing things:
- Scope Snapshot – A full, inspectable backup of files and database
- Access & Authentication – Every way someone can sign in or connect
- Configuration & Code Surface – Plugins, themes, customizations, schedules
- Logs & Traffic – Server, application, firewall, and CDN visibility
The rest of this article is about how to capture each category under time pressure without turning your team into security engineers overnight.
Pause the Cleanup: Immediate Moves in the First 30 Minutes
When you first suspect malware—strange redirects, spam pages, or security warnings—use the first 30 minutes for stabilization and preservation, not improvisational fixes.
1. Stop changes and coordinate
In a typical regional services company, the marketing lead is usually first to notice something’s wrong (“Why are some visitors seeing a casino site?”). The natural response is to ask the host or an internal IT contact to “just fix it.”
Instead, do this:
- Tell everyone to pause non-essential changes. No plugin updates, theme edits, content pushes, or restores yet.
- Name a single incident coordinator. Often the marketing or digital lead, even if they’re non-technical. Their job is to track decisions, timing, and what’s captured.
- Write down the symptoms and timestamps. What exactly are you seeing, and when did it start? Include URLs, screenshots, and who reported what.
This is basic, but we have noticed that even a simple written timeline becomes crucial when you start correlating logs later.
2. Protect visitors while preserving evidence
You might need to limit exposure without wiping the scene:
- If the site is actively serving malicious content, consider using a simple temporary splash page or enabling a maintenance mode at the edge (via CDN or firewall) rather than editing WordPress directly.
- Avoid blanket file deletions or mass plugin removals at this stage. Those can wait until you’ve captured backups and logs.
3. Trigger a controlled, full-site backup
Before anyone “cleans up,” initiate a full, point-in-time backup (files and database). We’ll detail what this means next, but the first 30 minutes should at least:
- Ensure a fresh backup is running
- Confirm where it will be stored
- Make sure it won’t overwrite your only recent restore point
Once that backup is safely captured, you can move more confidently into deeper evidence preservation.
Category 1 – Preserve a Clean, Inspectable Snapshot of the Site
Goal: Capture what the site looks like right now—compromised or not—in a way you can restore or analyze later.
What this snapshot should include
A useful snapshot is more than “someone clicked backup” in a hosting panel. Aim for:
- All web files: WordPress core,
wp-content, themes, plugins, uploads, custom code - Full database: Every table, not just posts and pages
- Configuration files:
.htaccess,wp-config.php, and any environment-specific config
If you already follow the backup practices outlined in posts like How to Backup a WordPress Site, this step should feel familiar but higher-stakes—you’re preserving evidence, not just disaster insurance.
Avoid overwriting your most valuable evidence
Hidden failure mode: backup tools that keep only the “latest” copy.
In many incidents, by the time we’re asked to review a breach, the only backup left is a post-cleanup snapshot. Earlier, more revealing backups were silently overwritten by automated retention rules.
To avoid this:
- Store at least two relevant restore points: one from before you noticed problems (if available) and one at the time of discovery.
- Label the incident backup clearly with a timestamp and “pre-cleanup compromised copy.”
- Export a downloadable copy outside your main hosting platform if possible, to protect it from accidental deletion.
Checklist: Snapshot preservation
Before cleanup begins, ensure you have:
- Full file backup of the WordPress install
- Full database backup, including all tables
- Copies of
.htaccess,wp-config.php, and other config files - At least one pre-incident and one incident-time restore point
- A safely stored copy that won’t be auto-overwritten
This snapshot is your baseline for everything that follows.
Category 2 – Capture Access, Users, and Authentication Details
Goal: Understand every door into your site and hosting, so you can identify likely entry points and close them properly after cleanup.
When teams call for help mid-incident, it’s common that no one can produce a current list of admins or access methods. That turns security remediation into speculation.
WordPress user and role overview
Within WordPress itself, capture:
- Current list of all users, especially Administrators, Editors, and any user with
manage_optionscapabilities - User creation and last-login information where available
- Any suspicious or unknown accounts (e.g., new Admin users no one recognizes)
Even a simple export or screenshot of the users list—with date and time noted—creates a record you can compare against post-cleanup.
Hosting, SFTP, and database access
Next, document access at the infrastructure level:
- Control panel accounts for hosting
- SFTP/FTP users, SSH keys, and any database login accounts
- Who actually knows or shares these credentials inside your organization or vendors
This is where Governance Collapse shows up during incidents: years of ad-hoc access grants, no central log, and no clear owner who can say, “these are our legitimate access paths.”
API keys and third-party integrations
Finally, capture all the “side doors” that can change your site:
- API keys stored in WordPress or config files (marketing tools, CRMs, payment gateways, etc.)
- Webhooks that can trigger content or user updates
- Any remote management services connected to your site
You’re not revoking or rotating keys yet; you’re making sure you know what exists so you can secure them intentionally later.
Checklist: Access and authentication
Before cleanup changes anything, you should have:
- Export or screenshots of WordPress user list and roles
- Notes on suspicious or unknown admin-level accounts
- List of hosting control panel, SFTP/FTP, SSH, and database access accounts
- Inventory of API keys and third-party integrations that can modify the site
- Named owner responsible for each major access layer
Category 3 – Save Configuration, Plugins, Themes, and Scheduled Tasks
Goal: Capture what’s actually running on your WordPress site—the full “code and configuration surface” an attacker might have used.
Backups cover files and database, but they don’t always give you a clear, human-readable view of how your stack looked at incident time. You want that view before updates or deletions hide it.
Active plugins and versions
Many WordPress compromises trace back to vulnerable, outdated, or abandoned plugins. Before you change anything:
- Export or capture a list of all active plugins and their versions
- Note recently installed or updated plugins, especially in the weeks before you noticed problems
- Highlight plugins with broad permissions (security tools, form builders, file managers, page builders)
Even if you later remove or replace them, this list helps reconstruct the likely vulnerability.
Themes, child themes, and custom code
Next, capture theme-related details:
- Which theme is active and whether it’s a child theme
- Version numbers of active and inactive themes
- Locations of custom code, such as
functions.php, mu-plugins, or custom plugins unique to your site
Attackers often hide payloads in child themes or little-used template files where nobody looks. Knowing your legitimate code footprint matters when you compare against the snapshot later.
Configuration settings and options
WordPress configuration isn’t just in wp-config.php. Before changes:
- Note site URLs and home URLs (especially if redirects are suspicious)
- Capture key settings around registration, comments, and file uploads
- Document any hard-coded credentials or external endpoints in config files
You don’t need to publish this internally; you just need a secure, time-stamped record.
Scheduled tasks and automations
Compromised sites sometimes hide persistence mechanisms in scheduled jobs:
- WordPress cron tasks (recurring jobs that run via WP-Cron)
- Server-level cron jobs, if applicable
- Any scheduled syncs or imports from external systems
Documenting these tasks helps you spot unwanted jobs that re-infect the site after apparent cleanup.
Checklist: Configuration and code surface
Before cleanup, capture:
- List of all active plugins with versions
- Notes on newly added or recently updated plugins
- Active theme, child theme, and all theme versions
- Locations of custom code and must-use plugins
- Key WordPress settings and external endpoints
- WordPress cron tasks and any server-level scheduled jobs
Category 4 – Preserve Logs, Traffic Patterns, and Firewall or CDN Rules
Goal: Keep the timeline and traffic evidence that explains how the incident unfolded.
This is where many teams have the weakest visibility. Earlier choices about logging and monitoring directly control how much you can preserve now. If you haven’t considered those decisions before, the post Security Monitoring Decisions That Keep a WordPress Site Stable Between Major Releases is a useful prerequisite for understanding why certain logs exist—or don’t.
As a prerequisite to this decision, Security Monitoring Decisions That Keep a WordPress Site Stable Between Major Releases explains the adjacent issue in more detail.
Server and application logs
Start with whatever logging your environment already has in place:
- Web server access logs (requests, IP addresses, timestamps, user agents)
- Error logs related to PHP, database connections, or application-level errors
- Any WordPress-specific logs your security or performance plugins may be keeping
Because logs often auto-rotate or purge on short schedules, export as much relevant history as you can before daily or hourly jobs overwrite it.
Firewall and CDN activity
If you use a web application firewall (WAF) or CDN:
- Export recent security events, especially blocked or challenged requests
- Capture rule sets and custom rules in place at incident time
- Note any recent rule changes that might have opened or closed doors
This information is critical later when you want to know whether the firewall missed something, was misconfigured, or simply didn’t have visibility into certain paths.
Traffic patterns and anomalies
Even basic analytics and traffic summaries can support the investigation:
- Spikes in traffic from specific countries or IP ranges
- Unusual bots or user agents hitting login or admin URLs
- Sudden increases in 404 errors or direct hits to weird-looking URLs
You don’t need perfect analytics modeling; you need enough pattern recognition to align with your logs and timeline notes.
Checklist: Logs and traffic evidence
Before cleanup changes the environment, preserve:
- Web server access logs for the suspected incident window
- Error logs covering the same period
- Security plugin or WordPress-specific log exports
- Firewall or CDN security events and current rule set
- Notes on obvious traffic spikes or anomalies
Hidden Failure Modes: Evidence You Lose When Cleanup Starts Too Soon
Malware incidents aren’t just about the attacker; they also expose weaknesses in your own operating habits.
A few failure modes we repeatedly see:
1. Auto-rotating logs erase the story
Many hosting platforms rotate logs daily or weekly. If your first move is a restore and your second move is “wait a few days,” you may discover that all the relevant history has already rolled off.
Preserving logs in the first hour is often the difference between a clear root cause and permanent uncertainty.
2. Reactive restores overwrite the evidence
A well-intentioned support agent might restore an earlier backup before anyone captures an incident-time snapshot. That can:
- Remove malicious files
- Reset database entries
- Change user lists and permissions
On the surface, everything looks “better.” In reality, you just destroyed the clearest view of what the attacker did.
This is why we say: malware cleanup is phase two; phase one is preserving the only version of reality you can still interrogate.
3. Plugin cleanups quietly change the environment
Security plugins with “one-click cleanup” tools can be helpful, but they can also:
- Delete or quarantine files without a clear record
- Modify
.htaccessand other config - Reset rules or disable suspicious users
If those tools run before you preserve your evidence, you end up with a partially cleaned, partially compromised environment that’s harder—not easier—to understand.
4. Governance gaps surface at the worst moment
When no one can answer basic questions like “Who has admin access?” or “Where are our logs stored?” you’re looking at Maintenance Maturity issues, not just a one-off breach.
Incidents reveal Governance Collapse in slow motion—a tangle of vendors, shared passwords, and undocumented changes that make proper evidence preservation nearly impossible.
From One-Off Incident to Maintenance Maturity
Treat this malware event as more than an emergency; use it as a maintenance audit under pressure.
Maintenance Maturity is a useful lens here: organizations move from reactive fixes (“get the site back up”) toward proactive ownership (clear logging, regular reviews, documented runbooks).
In a low-maturity model:
- Backups exist, but no one knows how often or where they’re stored
- Logs are on by default, but no one checks retention or access
- Plugin updates and admin access are ad hoc and undocumented
Higher-maturity teams:
- Maintain documented incident playbooks that include checklists like the ones above
- Know exactly which logs and backups exist and how long they’re retained
- Review access lists and critical plugins on a recurring basis
If your current incident feels chaotic, that’s not a personal failure; it’s a signal about your Maintenance Maturity. Posts like How to Put Maintenance Maturity on the Calendar: Practical Review Rhythms for WordPress Security and Support go deeper into how to turn today’s chaos into recurring governance habits.
For broader background on this decision, the Website Support articles hub collects related context.
To operationalize this decision, how our Website Security & Monitoring work supports this decision explains the adjacent issue in more detail.
Deciding When to Bring in Outside Security Help
Not every malware incident requires a full security engagement, but there are clear thresholds where outside help is less a luxury and more a risk-management decision.
Consider escalating to professional support if:
- You can’t confidently preserve the four evidence categories described here
- Revenue, lead generation, or reputation depends heavily on your WordPress site
- You’ve had recurring security issues (re-infections, repeated spam, unexplained admin accounts)
- There is internal disagreement between marketing, IT, and leadership on how serious the incident is
From an ownership standpoint, the real question is: Do we want to treat this as a one-off fire, or as the moment we upgrade how we monitor and govern the site?
A structured service can:
- Help you standardize evidence preservation before and during incidents
- Design the logging and monitoring that make future investigations faster and clearer
- Reduce the odds that you’re ever in the dark about access, configuration, or root cause again
If this article feels like more than your team can own alone, it’s time to consider that escalation.
Next Steps: Turn This Preservation Checklist Into a Standing Playbook
You now have a focused checklist for what to preserve before you—or anyone else—starts cleaning WordPress malware. The next move is to turn it into something your team can actually follow under stress.
Concretely, that means:
- Writing a short incident runbook that spells out the first 30 minutes and the four evidence categories
- Training the people most likely to notice problems—often marketing and content owners—to follow that runbook before opening a generic “please fix” ticket
- Reviewing your existing backups, logging, and access controls against the expectations in this article
If malware has already exposed deeper weaknesses in your support model, it’s worth looking more broadly at how you maintain and govern the site day to day; the curated Website Support articles can help you expand from incident response into healthier ongoing maintenance habits.
From there, the key decision is whether you want to keep relying on best-effort reactions, or formalize security monitoring as an ongoing responsibility. Our Website Security & Monitoring service is built to operationalize exactly the preservation and review practices described here—standardizing backups and logs, clarifying ownership of access and configuration, and providing structured incident support instead of improvised heroics.
To apply this decision to your own website, discuss the next step with our team.
Leaving that decision unresolved creates avoidable delay, rework, and production risk.