Contents
- 01
Understand what each check actually tells you
- 02
Run the checks
- 03
Know what still isn’t covered
The short answer
Checking whether a website is secure means running four separate signals, not one. Each covers a different layer, and a clean result on any one of them is not a clean bill of health for the other three.
| Signal | What it checks | What it misses |
|---|---|---|
|
Google Safe Browsing status
|
Whether Google’s crawler classified the URL as malware, phishing, unwanted software or deceptive content on a recent pass | Anything injected since that pass, or anything on a page the crawler never reached |
|
Blacklist (DNSBL) check
|
Whether the domain or IP has been reported to a third-party list such as Spamhaus or Barracuda | A fresh compromise nobody has reported yet |
|
Certificate validity (the padlock)
|
That the connection is encrypted and that whoever requested the certificate controlled the server at issuance | Patched software, server-side validation, or malware already on the site |
|
File-level malware and vulnerability scan
|
The actual files and database for injected code, plus installed versions against known disclosures | Nothing, but it is the one check none of the URL-only tools can run |
How it actually works
Google Safe Browsing
Google’s Safe Browsing technology scans its own web index daily. As Google puts it, “Our Safe Browsing technology scans our web index on a daily basis to identify unsafe websites.” A URL that turns up gets classified as malware, phishing, unwanted software or deceptive content. Malware detection works by scanning sections of the index and testing pages in a virtual machine to see if it gets infected. Phishing detection runs on statistical models instead.
Once a site is flagged, the warning is added within minutes of detection, and it takes about half an hour on average to show up externally. That speed cuts both ways.
A site that was actively serving bad content at its last crawl.
Anything injected after that crawl, anything on a page the crawler never reached (behind a login, or blocked by robots.txt), and a vulnerable plugin sitting on the site that nobody has exploited yet.
Run the lookup directly at Google’s Safe Browsing site-status tool, and read how the scan actually works in Google’s Safe Browsing transparency FAQ. For the fuller process this single check feeds into, see the fuller checklist this feeds into.
Blacklist and DNSBL checks
A blacklist check is a DNS lookup, cross-referenced against third-party lists such as Spamhaus, Barracuda or SORBS. Each list sets its own listing criteria. A clean result here means the domain or IP has not been reported yet, not that the underlying code is clean. It also misses a site that was compromised recently and hasn’t been reported, and it can produce a false positive on shared hosting, where one bad neighbor gets an entire IP block listed.
The padlock and certificate
A valid certificate confirms two things only: the connection between browser and server is encrypted, and whoever requested the certificate had administrative access to the server at the moment it was issued. It does not confirm the software behind that connection is patched, that server-side validation is sound, or that the site is free of malware.
Free certificate issuance changed what the padlock actually signals. A phishing site can get the same valid HTTPS certificate a legitimate business gets, and vendor reporting on phishing incidents has noted that most reported phishing sites now carry a valid certificate too.
Treat the padlock as confirmation of encryption, never as confirmation of safety.
Malware and vulnerability scanning
This is the layer the first three checks cannot touch, because it requires looking at the site’s own files rather than at how the outside world sees the domain. A malware scan inspects the files and database for injected code, unexpected admin accounts and altered core files. A vulnerability check compares the installed versions of core, themes and plugins against public disclosure databases such as WPScan’s.
Both require server-side access or a direct look at the codebase. A URL-only checker run from outside the site cannot do either.
- Safe Browsing
- Blacklist
- Certificate
Requires file-system access
Requires file-system access
- Malware scan
- Vulnerability check
External reputation and file-level access are two different zones. Safe Browsing, blacklist status and the certificate all judge the site from outside. A malware scan and a vulnerability check are the only ones that look at what is actually sitting on the server.
What good looks like
A genuinely clean result means all four signals come back clear at once:
One green result out of four is a start, not a finish. It tells you one layer looks fine today. It says nothing about the other three.
What to do about it
-
01
Run the Google Safe Browsing site-status lookup directly against the domain.
-
02
Run a blacklist (DNSBL) checker against the domain to see if it appears on Spamhaus, Barracuda or a similar list.
-
03
Check the certificate’s validity in the browser, and look in the browser console for mixed-content warnings on pages that should be fully encrypted.
-
04
Run a malware and vulnerability scan, either through a security plugin with file-system access or through a fuller audit.
Each of these is a snapshot, not a standing guarantee, so the useful habit is running all four again after any change to the site, not just once after a scare.
Get the layer those four checks can’t see.
NoDrama’s free website audit checks the site’s actual files and versions, no pitch attached.
Common misconceptions
“HTTPS means the site is safe.”
It confirms encryption in transit and that someone controlled the server when the certificate was issued. That’s all it confirms.
“A clean Safe Browsing result means nothing is wrong.”
It reflects only what Google’s crawler has seen so far, and that can lag behind a fresh infection by hours or days.
“A security plugin covers all of this.”
A plugin scans what it has file-system access to. Reputation flags such as Safe Browsing and blacklist status are external judgments, and a local plugin cannot see or clear them.
What this does not solve
None of the four checks above replace an ongoing, operated security practice: updates tested before they go live, monitoring that runs continuously rather than once, and a documented process someone actually follows. A clean result across all four today answers only “as of today.” For how the security work is scoped, see how the security work is scoped, and for who actually watches this after today, see who actually watches this after today.
Conclusion
Checking whether a website is secure is four separate signals, not one: Google Safe Browsing status, blacklist status, certificate validity, and a file-level malware and vulnerability scan. Each one is narrow, each one misses what the other three catch, and the only honest answer to “is my site secure” comes from running all four rather than trusting whichever one came back clean first.