Last updated 7 September 2026
If you found SiteCheckBot in your server logs, this page is why. It belongs to Scan44, a service that checks a website for security problems and reports them to the person who asked for the check.
Somebody entered your address on our home page and asked for a check. We do not crawl the web and we do not keep a list of sites to visit. If your site was checked, a person asked for it.
Three things follow from that address rather than from a list, and it is fairer to say so than to claim we fetch nothing else. We look up the public certificate records for the domain, which name its own subdomains, and we load up to ten of those to see whether any points at a service nobody has claimed. Those are pages on the same domain that was entered. Separately, we ask DNS whether misspellings of that domain exist, which is how the report can list addresses registered to look like the customer's. That is a name lookup and nothing more.
The third is newer and goes further, so it is worth being exact about it. Apps built with tools like Lovable, Bolt or Claude usually talk to a database, and the address of that database and the public key for it are both compiled into the page for the browser to use. When we find them there, we ask that database whether a single row would come back, using nothing but the key the page already hands to every visitor. A row coming back means that table can be read by anyone holding that key, either because the rule that decides who may read it is off or because it says everyone may. We report which tables answered and leave which of those is deliberate to the owner, because from outside the two look identical. It is the most common serious mistake these tools produce and cannot be seen any other way. That request goes to the database the site's own code names, and only ever to one on the scanned domain or on the managed addresses these tools use, such as supabase.co. We do not fetch the row, so nothing that is in your tables reaches us at all, and we never write, change or delete anything.
We do not verify that the person owns the site. There is no way to do that before making the first request, and we would rather say so than pretend otherwise. What we do instead is limit the damage: every check is passive, and the results go only to whoever started it.
It makes the same kind of requests any visitor's browser makes, reads the replies, and looks up public DNS records. Usually under a hundred requests over about ten seconds, spread out rather than sent at once.
It does not:
It reads what your server already hands to anyone who asks. If a file is downloadable without a login, we can download it, which is the entire point of telling you about it.
Most of what you will see in your log is us asking for files that should not be public: around forty five specific addresses such as /.env, /.git/config and /wp-config.php.bak, a handful of common admin addresses such as /admin and /dashboard, and a few deliberately made-up addresses used to learn what your site does with one that does not exist. Almost all of them come back 404, which is the answer we are hoping for. We ask rather than guess because there is no other way to tell an owner that a file is downloadable. We do not try to open anything we find, and we do not try to log in.
If your home page answers with 429, we wait the time your Retry-After header asks for, up to six seconds, and try at most twice more. If it answers 429 or 503 while we are looking for leftover files, that part stops at once and does not come back for the rest of the check.
Being straight about the limits of that: perhaps thirty other requests, spread across the rest of the check, are already in flight or are sent afterwards and do not read that signal. So it is a sharp drop rather than a full stop, and if you want a full stop the two options below are the reliable ones. All of this is deliberate: a check that knocks a small server over is worse than no check at all. If you are still seeing more traffic than you want, write to us and we will look at it the same day.
Two ways, and both of them work:
SiteCheckBot/1.0. Block it in your firewall or at your CDN, for example with a Cloudflare rule matching that user agent. Our scanner is not a search crawler, so blocking it costs you nothing anywhere else.Not robots.txt, though. That file is a convention for crawlers that go looking for pages to index, and we are not one: we fetch the address a person entered and pages on that same domain. We also read a few public directories about it, which are named further up this page and in our privacy policy. We would rather tell you that than let you add a line and believe it had done something.
A site on that list stays off it. The refusal is in the scanner itself rather than in somebody remembering, so typing your address into the box returns a refusal instead of a report. We do not ask you to renew the request.
The results of a check, so the person who asked for it can come back to their report. An unpaid check is deleted after two days, a paid one after ninety. We do not build a database of scanned sites and we do not sell anything to anyone.
The full detail is in our privacy policy.