If your website is redirecting visitors, showing content you did not publish, or triggering browser warnings, you need a clear answer quickly. Submit the site and we will review the warning signs visible publicly, explain what they suggest, and set out sensible next steps.
A public check can identify warning signs. It cannot guarantee a site is malware-free, and it is not a clean-up service.
This is a review of the warning signs your public website shows. It is useful for answering one question quickly: is there visible evidence that something is wrong, and does this warrant proper investigation?
It cannot certify that a website is clean, and it is not a malware removal service. Compromises can exist without any outward symptom, and confirming the state of a site requires access to its files, database and server logs.
We also try not to escalate ordinary problems into emergencies. Plenty of odd website behaviour turns out to be a misconfigured plugin, a caching layer or a broken script rather than an attack.
The more of these you recognise, the more likely it is that a proper investigation is warranted.
That last one is common and worth knowing about: injected redirects are often selective, triggering only for search visitors, mobile devices or first-time users.
Whether pages redirect unexpectedly, including behaviour that differs by device or by how the visitor arrived.
Whether browsers or search results flag the site, which usually indicates something already detected externally.
Whether spam pages, foreign-language content or unrelated products appear indexed under your domain.
Scripts, iframes or content in your pages that do not appear to belong to your website or its known tools.
Publicly reachable pages or files that do not fit the structure of your site.
Signs of unusual server load or slowness that do not match any change you made.
Signals suggesting the site may be involved in sending spam, and the distinction between that and ordinary form spam.
Where you tell us about unfamiliar administrator accounts or changed files, we factor that in — though we cannot verify it from outside.
Most compromised business websites are not individually targeted. Automated scripts scan the web for known problems in unmaintained plugins and themes, or try credentials leaked from elsewhere.
That is why the effective defences are unexciting: keep components updated, remove what you do not use, use strong unique passwords with two-factor authentication, and keep tested backups.
Injected code frequently avoids logged-in users and repeat visitors, precisely so the owner does not notice. Customers see redirects and spam; you see a normal website.
If people are reporting behaviour you cannot reproduce, believe them and investigate rather than assuming a browser problem on their side.
Removing visible damage feels like resolution, but if the entry point remains open the same thing tends to return, sometimes within days.
Proper remediation is sequenced: understand how it happened, close that route, then clean, then rotate credentials, then verify.
An offsite backup from before the problem started makes recovery a manageable task. A backup nobody has tested restoring, or one that has already been overwritten with a compromised copy, does not.
This is why the first advice in any incident is to preserve existing backups rather than run a new one over them.
Once a site has been flagged, cleaning it does not automatically remove the warning. Search engines and browsers need to re-check the site, which is normally requested through Search Console after remediation.
Skipping this step leaves customers seeing a warning long after the underlying problem is gone.
Tell us what you or your customers have noticed, and when it started. If a browser, host or search engine has flagged something, include the exact wording if you can.
This is deliberately high level. The aim is to avoid making the situation harder to recover from while you get proper help.
Contact your hosting provider. They can often see server-level evidence quickly and may already have relevant logs.
Preserve existing backups. Do not overwrite them with a fresh backup of the current state.
Change administrative, hosting and email passwords from a device you trust, and enable two-factor authentication where available.
Engage someone who can investigate with proper access to identify how it happened before anything is cleaned.
Clean the site, then close the underlying cause — updating or replacing the vulnerable component rather than only removing symptoms.
Review user accounts, then confirm afterwards that browser and search warnings have cleared through Search Console.
We do not attempt to exploit or probe websites, and we do not provide instructions for doing so. This review is observational.
We will not tell you a site is definitely clean, definitely compromised, or certified secure on the basis of a public check. Where the evidence is ambiguous, we will say that plainly and explain what would resolve it.
And we will not use the situation to push a website rebuild. Sometimes a compromise does reveal that a site is running on components too old to secure sensibly — but that is a conclusion to reach with evidence, after the immediate problem is handled.
The broader security signals review, without an active incident.
WordPress Website AuditTechnical health, including the components most often exploited.
Website Speed TestUnexplained slowness is sometimes the first symptom noticed.
Outdated WordPress CheckUnmaintained themes and plugins are the usual route in.
Not sure which one fits? Browse all website checks.
Submit your website and we will tell you what the public warning signs suggest, in plain English, along with the sensible next step.