A scanner can confirm that its current signatures did not match the files it inspected. It cannot by itself prove that database injections, unknown users, scheduled persistence, stolen panel access or selective visitor behaviour are gone.
Verification should answer four questions: was the payload removed, was persistence removed, was the entry route closed and does the site still work?
Revisit the original symptom
Repeat the condition that exposed the incident: search referrer, mobile first visit, affected path, clean cookies or checkout. Use an isolated browser profile and preserve network logs.
Confirm no redirect, download, injected script, fake prompt or spam content occurs. Do not contact the old payload destination.
If the symptom cannot be safely reproduced, use saved indicators and response comparisons instead.
Verify trusted file provenance
Compare WordPress core with official checksums and reinstall vendor plugins/themes from verified sources. Review custom code manually against its repository/baseline.
Search for incident-specific hashes, strings and external domains. Inspect executable files in uploads, must-use plugins, root files and PHP prepend settings.
Record explained differences rather than forcing every custom file to match a vendor package.
Inspect database and identities
Review posts/widgets/options for injected scripts or links, spam records, administrators, role capabilities and application passwords.
Inspect WordPress cron, Action Scheduler and hosting cron. Attribute suspicious entries to code before removal.
Use WordPress-aware methods with a database backup; avoid raw edits to serialised options.
Check account and infrastructure layers
Audit hosting/SFTP/SSH/deployment, recovery email, DNS/CDN/tag-manager and mail accounts. Revoke unknown sessions/tokens and rotate affected secrets after backdoors are removed.
Inspect sibling and forgotten installations that share filesystem ownership. One clean site cannot remain clean beside an active writer.
Preserve provider/audit evidence with secrets redacted.
Compare with independent evidence
Do not rely on the same compromised WordPress installation to declare itself clean. Compare official package checksums, repository releases, hosting authentication history, CDN requests and external public-response monitoring.
Where a host scanner and application scanner disagree, establish what each product actually inspected and at what time. One may cover files only while another checks reputation or database content.
Keep an explicit evidence matrix: requirement, source, timestamp, result and limitation. Missing logs should be marked missing rather than converted into a confident conclusion.
Test normal operational cycles
Run authorised cron, cache regeneration, backups, deployments and a safe update. Save settings that previously regenerated malware in staging.
Monitor sensitive file hashes, users and options beyond the longest observed recurrence interval. A dormant weekly task will not be disproved by one clean hour.
Check every origin/node and relevant CDN variant.
Validate business functionality
Test login/password reset, navigation, search, forms, SMTP delivery and multilingual pages. For WooCommerce, use sandbox payments and verify cart, totals, stock, webhooks and order email.
Security cleanup can break dependencies, permissions or credentials. Functional failure is not an acceptable proof of containment.
Inspect PHP/JavaScript errors after replacement.
Review search and reputation
Check Safe Browsing, Search Console security issues, indexed spam patterns and public status codes. Removed spam URLs should return 404/410.
Reputation warnings may persist until review/recrawl; they do not necessarily indicate live malware. Submit reconsideration only with a genuinely clean site and evidence.
Produce a verification record
Document cause/limitations, removed and replaced components, credential actions, tests, observation period and remaining monitoring. Include hashes/paths without payload or secrets.
Request an independent assessment when the entry route remains uncertain, checkout was affected or several sites shared access.
A green scanner is one useful result. Confidence comes from converging evidence across code, data, accounts, infrastructure and the original visitor journey.