A redirect, browser warning or broken page can come from malware, but also from cache, DNS, an expired certificate or a plugin error. Taking a shop offline has real cost, so confirm the security signal while protecting visitors from further exposure.
Use independent evidence and contain immediately when customer or payment risk is credible.
Record the original report
Ask for the exact URL, time, device, referral source, screenshot and action that produced the symptom. Preserve the report before asking the person to retry.
Do not request passwords, payment details or a copy of a suspicious downloaded file through ordinary email. Record whether the report came from a browser, search engine, host, payment provider or security scanner.
Build a timeline in one timezone.
Reproduce from a clean context
Use an isolated browser or safe external request from a clean device. Do not visit the suspect page while authenticated to WordPress, hosting, email or payment accounts.
Compare direct navigation, search-result navigation, mobile and desktop user agents where the report depends on context. Record response status and redirect chain without executing unknown downloads.
One failed reproduction does not disprove conditional malware.
Compare DNS and origin responses
Confirm the domain’s authoritative DNS, current A/AAAA records, CDN/proxy and TLS certificate. A compromised DNS or Cloudflare account can redirect traffic without changing WordPress files.
Where authorised and safe, compare the proxied response with the known origin using a controlled Host header and no browser execution. Do not expose or broadly publish the origin address.
Record unexpected nameserver or redirect changes.
Inspect hosting and application logs
Search access, error, PHP and security logs around the reported time. Look for unexpected POST requests, new administrative actions, modified plugin/theme files, outbound spam or unfamiliar scheduled tasks.
Preserve log copies before rotation. Redact visitor data and avoid treating one scanner request or failed login as proof of compromise.
Correlate multiple events by time, IP only where lawful, and affected path.
Check users and sessions
Review WordPress administrators, application passwords, active sessions and recent account changes. Inspect hosting users, SSH keys, FTP accounts and control-panel sessions.
An unknown privileged account or key is strong evidence even if the front end looks normal. Disable or contain it after preserving identifying details.
Use a clean control account; do not trust a password changed from a possibly infected browser.
Assess file integrity
Compare WordPress core against the matching official release. Verify plugin and theme files against trusted vendor packages where available. Treat custom code separately because no public checksum exists.
Look for executable PHP in upload/cache directories, unexplained bootstrap changes and persistence outside the visible theme. Modification time alone is not conclusive.
Do not run unknown files to see what they do.
Review database indicators
Check for injected administrator users, malicious JavaScript in options/widgets, altered site URLs, suspicious scheduled events and unexpected redirect content.
Query through read-only or backed-up access where practical. Avoid broad search-and-replace or deleting rows before their relationships are understood.
Preserve a database snapshot and note table prefix and multisite context.
Choose proportionate containment
Confirmed malicious checkout code, credential theft, drive-by downloads or active redirects justify immediate public containment. A questionable isolated file with no execution may allow a narrower block while evidence is collected.
Serve maintenance outside WordPress and protect responder access. Notify the host/payment provider under the established incident process where relevant.
Do not reopen after removing only the first indicator.
Define proof for recovery
A clean result requires more than a scanner saying no malware. Rebuild or replace untrusted code, inspect accounts/database, close the entry vector, rotate secrets and verify logs, forms, checkout and scheduled tasks.
Retain the incident timeline and indicators for monitoring after release.
Request emergency assessment when evidence spans DNS, hosting and WordPress or when customer data may be involved. Share redacted logs and managed access—not public credentials, database dumps or suspicious archives.