Can a scan prove a site is not hacked?

No, and that limit is worth being clear about. A scan reports observable signals, and a well-hidden backdoor produces none of them from outside. A clean result lowers the probability and never reaches proof, which is why the admin-side signals are checked alongside it.

The site was cleaned but got reinfected. Why?

Almost always because the way in stayed open, or because a scheduled task or a second backdoor survived the cleanup and restored the rest. Reinfection within days points at the entry point rather than at the cleaning.

Is a compromise the host's responsibility?

Rarely on shared hosting. The common causes are an outdated plugin or core and reused credentials, both on the site owner's side of the line. Hosts do sometimes cause it through a shared-account compromise, so it is worth asking, but it is not where to start.

How long does a Safe Browsing warning last after cleanup?

The review is usually processed within a day or two once the site is genuinely clean, and browsers stop warning shortly after. The clock starts when the cause is removed, not when the request is submitted.

← All guides

How to tell if a WordPress site has been hacked

Most compromised sites do not look compromised. Defacement is rare, because it ends the intrusion; the profitable outcome is a site that keeps working normally while it serves spam pages to search engines, redirects visitors arriving from search, or quietly collects what gets typed into its forms.

Short answer

The signals that settle it, from outside and from the admin

The fastest reliable signals come from outside, because that is where the payload is aimed. A browser warning or a blocklist entry, unknown domains loading in the page source, and pages indexed on the site that nobody wrote are all strong evidence, and none of them requires logging in.

Inside the admin, the ones that matter are administrator accounts nobody created, plugins nobody installed, modified core files, and scheduled tasks with names nothing recognizes. One of these signals is worth investigating; two together usually settle it.

Signals visible from outside

These are worth checking first because they are quick, they need no access, and they reflect what visitors and search engines actually get served.

A browser interstitial or a blocklist entry. This is the strongest single signal, and it means the compromise has been confirmed by a third party rather than suspected. (Blacklisting & Safe Browsing)
Unknown scripts in the page source. View the served HTML and look for script tags pointing at domains that have nothing to do with the site, and for long encoded strings in the markup.
Pages in search results that were never written, typically pharmacy, streaming, or gambling keywords on a site about something else. Searching for the domain plus an unrelated keyword surfaces them.
A redirect that only fires for search traffic. Arriving from a search result lands somewhere else, while typing the address directly works normally, which is why owners are the last to see it.
Sudden mail deliverability problems, which usually mean the server has been used to send spam and the domain or its address has been listed.

Signals inside the admin

If anything above looks wrong, the admin confirms it. These are checked in order of how clearly they point at an intrusion.

Administrator accounts nobody created, or an existing account whose email address changed. Persistence is the first thing an intruder arranges.
Plugins present but not listed in the plugins screen, or a plugin with no author and no version. Malicious code frequently ships as a plausible-looking plugin directory.
Modified core files. Core files should match the release exactly, and a reinstall of the same version from the dashboard overwrites anything that does not.
Unexpected scheduled tasks, which is how an intrusion re-installs itself after a partial cleanup and why a site keeps getting reinfected.
Recently modified files with dates that match no deployment, especially inside the uploads directory, which should hold media and nothing executable.

Why a hacked site looks fine to its owner

Injected code is written specifically to avoid the person most likely to remove it. The common pattern serves the malicious version only to visitors arriving from a search engine, only on mobile, or only to users who are not logged in, and shows the normal page to everyone else. An owner visiting their own site while logged in matches every exclusion at once.

The practical consequence is that a site cannot be cleared by looking at it in the usual way. What the search engine's crawler saw is the view that matters, and Search Console records it under Security Issues, including the sample URLs that triggered a flag.

What to do first, in order

The order matters more than the speed. Deleting the visible symptom before finding the way in is what produces a site that gets reinfected within days, which then looks like the cleanup failed.

Take a full copy of the site and database before changing anything, and label it as evidence rather than as a backup. It is the only record of how the intrusion worked, and cleanup destroys it.
Rotate every credential: hosting panel, SFTP, database, and all administrator accounts. Assume the intruder has current copies of all of them.
Find the way in before cleaning. Usually it is a plugin or core version with a published CVE, occasionally a password that leaked elsewhere. (WordPress security check reports the version side of this from outside.)
Remove the malicious content and reinstall core, plugins, and themes from clean sources rather than editing the infected files.
Request the review only once the cause is closed. Requesting it earlier produces a re-flag and makes later reviews slower.

What CheckWeb does not do

CheckWeb detects signals from outside: a blacklisting or Safe Browsing flag, software versions with known CVEs, a certificate that stopped being valid. That answers whether something is wrong and often points at how it got in.

It does not clean a compromised site, remove malware, restore backups, or provide incident response, and no scan can confirm a site is free of a backdoor. Cleanup is specialist work, handled by Sucuri, Wordfence, or MalCare among others, and a site with confirmed injected content is better handed to one of them than scanned again.

Check what a site looks like from outside

Paste the address for the view an attacker and a search engine both start from: blocklist and Safe Browsing status, known CVEs in the detected versions, certificate, and headers. Free, no signup.

Check my website

FAQ

Can a scan prove a site is not hacked?: No, and that limit is worth being clear about. A scan reports observable signals, and a well-hidden backdoor produces none of them from outside. A clean result lowers the probability and never reaches proof, which is why the admin-side signals are checked alongside it.
The site was cleaned but got reinfected. Why?: Almost always because the way in stayed open, or because a scheduled task or a second backdoor survived the cleanup and restored the rest. Reinfection within days points at the entry point rather than at the cleaning.
Is a compromise the host's responsibility?: Rarely on shared hosting. The common causes are an outdated plugin or core and reused credentials, both on the site owner's side of the line. Hosts do sometimes cause it through a shared-account compromise, so it is worth asking, but it is not where to start.
How long does a Safe Browsing warning last after cleanup?: The review is usually processed within a day or two once the site is genuinely clean, and browsers stop warning shortly after. The clock starts when the cause is removed, not when the request is submitted.