HEAD requests, one click, no stored dates of birth. What our scanner does when it visits your site, what it never does, and why “Not checked” is a real answer.
A scanner for adult sites has an obvious problem: the thing it checks is whether explicit content is reachable, and the last thing anyone wants is a tool that collects that content. So we built No451 around one rule from the start: we look at how your site behaves, never at what your media shows.
This post lists, plainly, what the scanner does and doesn’t do. It is the same list we work from internally.
When you start a scan, you pick the country your visitors come from. The scanner then connects through a vantage point in that country, for example a German home connection, and loads your site the way a first-time visitor would: a fresh browser, no cookies, no account.
It records what appears first: no check, a disclaimer, a click-through button, a date-of-birth form, a card form, a widget from an age-verification provider, a login wall or a geo-block. That is the gate type. Then it looks at what loaded before the gate and whether files open around it.
Whenever the scanner wants to know whether a media file is reachable, it sends a HEAD request. HEAD is part of HTTP itself: it asks the server for the same headers a normal request would get, without the body. The server answers “yes, here is an image of this type and size” or “no, you need to log in”, and no image is ever transferred.
We never send a normal GET for a media file, never request a partial range of one, and never read embedded metadata such as EXIF or C2PA. Per check, we send at most ten of these header requests to a sample of files.
There is one exception to “we never fill in forms”. If your age gate is a date-of-birth form or a button, the scanner enters one fixed, synthetic date of birth for an adult once and submits it, to see whether the content opens with no further check. That is the whole interaction. We don’t store a real person’s date of birth because there isn’t one: it is the same test value on every scan.
Besides the first page, the scanner reads the places that list your files to machines: robots.txt, sitemaps, feeds and, on WordPress, the public media API. It checks the link-preview image that social networks show. For verified owners only, it also tries a few things a determined visitor might: calling itself Googlebot, opening inner pages directly, or checking whether the gate’s cookie can be faked. Those checks add about seven page requests and up to about twenty header requests per scan. Owner verification is a DNS TXT record or a meta tag, so we only probe sites whose owners asked for it.
If something is unclear, missing data, a bot check, a location we couldn’t prove, a robots rule that asks us not to read a file, the result is “Not checked”, never a guess. We would rather show a gap than invent a pass or a fail. A report with three “Not checked” rows is more useful than one that quietly assumed the best.
Each finding says what we saw, with evidence you can open yourself: the URL, the list it came from, the response we got. It says what the rule in your visitors’ country says about it, with a link to the official source, and it gives you a fix you can apply. Our wording is careful on purpose: we describe what we saw and what the sources say, not what the law requires of you.
Scan results are stored so you can open your report again and compare rechecks. They contain URLs, response headers and our verdicts, not media. If you scan without an account, the result link expires after a set number of days.
The first scan is free. Pick a country, paste your address and see what a first-time visitor from there meets. If you want the owner-only checks, verify your site in the dashboard first.
Not legal advice. This page summarises and links to primary sources; it does not tell you what the law requires of your specific site. Related: Why we answer with fixes, not 451s · Regulations by country
One free scan shows your age check, report routes and labels, with evidence and fixes.