An antivirus or browser security product blocks the site, but another device opens it normally. The warning may reflect a current payload, a selective redirect, an external script, a compromised downloadable file or reputation from a recently removed infection.
Do not dismiss it as a false positive and do not request that customers disable protection.
Preserve the exact warning
Record the security product, detection name, blocked URL, timestamp and screenshot. Note whether the warning appeared on navigation, after clicking, during a download or only on one page.
The detection label can be broad. “Trojan,” “phishing” or “suspicious script” is a lead, not proof of the infected file.
Do not post licence details, user identifiers or full diagnostic logs publicly.
Check authoritative reputation sources
Review Google Safe Browsing/Search Console, the hosting provider and the named security vendor’s site-owner process. Use official lookup or appeal routes.
Avoid submitting the whole site or customer information to random online scanners. Public scanning services can retain URLs and samples.
A clean reputation result does not override a concrete endpoint detection; selective malware may not appear in every scan.
Reproduce safely
Use an isolated browser profile or analysis environment without administrator sessions. Test the exact page, referrer, device class and first-visit state reported.
Record the network request chain. Stop if a file download or credential prompt appears. Do not proceed through a fake CAPTCHA or enable browser notifications.
Compare a direct visit with a search-result referral. Some infections avoid administrators and repeat visitors.
Identify the resource being blocked
The antivirus may block:
- the main HTML document;
- an injected external script;
- an iframe or redirect destination;
- a JavaScript file in the theme/plugin;
- an executable or archive download;
- a domain loaded by advertising or tag manager.
Inspect browser developer logs and security-product details to connect the warning to one request. If the blocked domain comes from a legitimate third-party widget, contact that provider and disable the integration until its safety is established.
Do not simply allow-list the domain.
Examine WordPress and hosting persistence
Preserve filesystem and database copies. Review modified files, plugins, themes, uploads, configuration, database scripts, users, scheduled tasks and hosting-panel redirects.
Compare WordPress core against the matching official release. Replace confirmed modified trusted files from verified packages, but inspect how they changed first.
Check neighbouring sites and shared credentials. A reinfection route outside the visible WordPress installation can restore malicious code.
Distinguish live malware from stale reputation
If the original request chain is clean and thorough file/database review finds no payload, the warning may persist from historical reputation or a cached response.
Verify from clean sessions and CDN regions, then use the security vendor’s official re-evaluation process. Provide concise cleanup evidence without uploading credentials or private backups.
Do not submit a review before the site is actually clean. Repeated failed reviews can delay recovery and reduce trust.
Verify after remediation
Retest the exact blocked URL and trigger, scan from the origin and public CDN path, and check that no unknown requests or downloads remain. Monitor security logs and file changes for recurrence.
Check forms, checkout and analytics after removing scripts; a malicious loader may have been mixed into an otherwise important asset.
When to ask for malware cleanup
Request urgent assessment when the warning names a download, appears only to visitors or continues across several pages. Share the screenshot, URL and timestamp—not the suspicious file or account passwords.
The outcome should include evidence of cause, cleaned components, closed entry route, vendor review where needed and a repeatable verification.