Initial assessment without passwords Quote before intervention One accountable specialist from start to finish

Verification Recurring Protection

How Often Should WordPress Malware Scans Run?

Choose WordPress malware scan frequency by change rate, business risk, hosting capacity and detection coverage instead of one fixed schedule.

Daily, weekly and real-time scans can all be appropriate. Frequency alone says nothing about whether the scanner sees database injections, external tags, hidden users or selective redirects—and a heavy scan can exhaust shared hosting.

Choose a cadence from risk, change rate, detection delay and server capacity.

Define what each scan covers

List whether the tool checks:

  • WordPress core/vendor package integrity;
  • custom and unknown files;
  • PHP inside uploads;
  • database scripts/spam;
  • administrators/application passwords;
  • WordPress/server cron;
  • public URL behaviour and reputation;
  • hosting/DNS/CDN accounts.

One product rarely covers every layer. Combine complementary low-noise checks rather than assuming “full scan.”

Set frequency by business impact

A WooCommerce checkout or high-volume lead site needs faster detection than an archived brochure. Recent compromise, frequent plugin changes and many administrators increase risk.

Use continuous/sensitive-change alerts for new PHP in uploads, critical file changes and privileged users. Run broader package/database scans daily or weekly according to capacity.

Review public Safe Browsing/redirect/download symptoms externally.

Account for update and deployment events

Run a controlled integrity/security check after plugin/theme/core deployments and significant content/tag-manager changes.

Record the approved change so expected file differences are explainable. Do not refresh the clean baseline automatically before verifying the release.

A monthly scan can miss a malicious file introduced the day after it runs.

Add event-triggered scans

Run focused checks after an unknown administrator/plugin appears, sensitive configuration changes, a provider alert fires, DNS/CDN users change or public monitoring sees a redirect/download.

The event should determine scope: a modified wp-config.php warrants secret/access review, while a changed vendor plugin should trigger package comparison and vulnerability checks.

Avoid launching several full filesystem scans simultaneously during an incident. Preserve evidence first, then coordinate one controlled investigation so I/O pressure does not hide the original timeline.

Protect server performance

Schedule deep scans outside traffic peaks and avoid colliding with backups, imports or malware scans from the host. Limit I/O/CPU through supported settings.

On shared hosting, coordinate with the provider and scan a copy where appropriate. Do not disable scanning permanently because one unthrottled job caused a resource fault.

Monitor PHP workers, I/O and completion status.

Verify scan freshness and failures

Alert when a scheduled scan does not start, times out, skips directories or cannot update signatures. Silence can mean failure, not a clean site.

Record last successful completion, scope, exclusions and tool version. Review exclusions after migrations and new document roots.

Protect scan logs/results from public access.

Include human review

Automatically prioritise exact malware indicators, executable uploads and trusted-package differences. Have a knowledgeable person review ambiguous obfuscation, custom code and account changes.

Do not auto-delete every match. Quarantine/preserve evidence and apply rollback-aware cleanup.

Track false positives so legitimate files are attributed, not globally ignored.

Test detection and response

Use a harmless staging marker or approved test rule to confirm the monitoring notices a sensitive change and routes the alert. Do not upload real malware.

Measure time to acknowledgement and containment, not only scan interval. Define who acts outside business hours for critical sites.

Review cadence over time

Increase observation after cleanup or a major migration, then reduce only when evidence supports a stable lower-risk state. Reassess quarterly and after ownership/hosting changes.

Request recurring monitoring when no one owns coverage, failures and response. A sensible service states what runs when, what it can miss and what happens when it alerts.

Record the next review date and accountable owner instead of relying on a scanner licence renewal.

Keep one recent successful report as the comparison point, with sensitive paths and account details restricted.

BEFORE YOU SEND THE REQUEST

Frequently asked questions.

Do you ask for passwords in the form?+

No. The public form never requests access. Secure credentials are requested only after the scope and quote are approved.

Who reviews the incident?+

The request goes to Jordi Ensenyat, founder of Code Barcelona and a WordPress specialist with more than 15 years of experience.

Is anything changed before the quote?+

No. Visible symptoms and scope are reviewed first. Intervention begins after approval and with a rollback path prepared.

Do you work internationally?+

Yes. WP Repair handles WordPress and WooCommerce incidents in English and Spanish through a remote service.

Assess my incident