How we scan: passive, safe, transparent
This page describes exactly what each scanner does on the wire, how findings become a grade, and what we deliberately do not do. If a check is not described here, we do not run it.
The one rule
Every Scan.now check is something a normal visitor's browser, mail server or DNS resolver would do anyway. We fetch, read and compare. We never send crafted input, never try credentials, never submit forms, never exploit a finding to prove it. A passive result cannot demonstrate that a site is exploitable; it can show that the conditions for exploitation exist and tell you how to remove them. The passive versus active scanning guide explains the boundary in depth.
Website scanner, step by step
- Target validation. The address is normalised, resolved, and refused if it points at a private, loopback, link-local or reserved range. This is re-checked on every redirect hop.
- One page fetch. A single GET with a browser-like User-Agent identifying itself as ScanNowBot with a link to this page. Up to six redirects are followed. The body is capped at 3 MB.
- TLS probes. One verified handshake to read the certificate and negotiated protocol, one handshake per TLS version (1.0 to 1.3) to see which are accepted, and one per weak cipher family (RC4, 3DES, NULL, export, anonymous, static RSA).
- Header and cookie analysis. Values are parsed, not just detected: A CSP with
'unsafe-inline'scripts or an HSTS max-age under six months counts as weak. - Content analysis. Mixed content, insecure form actions, third-party scripts without Subresource Integrity, generator tags, sensitive-looking HTML comments and redirect parameters. Script URLs and, when needed, the first 400 KB of up to 25 scripts are matched against the Retire.js repository.
- Exposure probes. Twenty fixed paths such as
/.git/HEAD,/.envand/phpinfo.php, plusrobots.txt,security.txtand, if WordPress is detected,readme.html,xmlrpc.phpand the users REST endpoint. A random path is requested first so soft-404 pages are not mistaken for hits; every hit is verified by content, not status code. - DNS. SPF, DMARC, MX, CAA and DS records, forty common DKIM selectors, and the AD flag from a validating resolver.
- CORS and TRACE. One request with a foreign Origin header and one TRACE request.
Total: Roughly thirty HTTP requests, ten TLS handshakes and fifty DNS queries, spread over a few seconds. That is less load than one visitor browsing three pages.
Scoring
Each failing check subtracts a fixed penalty from 100: Critical 25, high 12, medium 6, low 2. Informational notes subtract nothing. Grades: A+ at 95 or above, A at 88, B at 78, C at 65, D at 50, F below. Severities follow the CVSS qualitative scale and are set per check in the reference; a few are adjusted by evidence, for example a certificate expiring in three days is high while one expiring in twenty-five is medium.
WordPress scanner
When a site is identified as WordPress, a further pass runs on top of the checks above, which reads the REST route index that WordPress publishes at /wp-json/ and ?rest_route=/, and matches the route names against a database of signatures for more than five thousand plugins; a plugin is identified when any of its known routes appear, and the report shows what share of them matched. Plugin and theme slugs are also taken from wp-content paths in the page markup. Versions come from each plugin's readme.txt, each theme's style.css and, for core, the generator tag or a core asset URL. The dedicated WordPress scanner additionally requests readme.txt for a short list of the most popular plugin slugs, after first requesting a random slug so that a host which answers 200 for everything is not misread as running every plugin in existence.
Every version found is compared against a processed copy of the Wordfence Intelligence vulnerability feed, which covers plugins, themes and core with an affected version range, CVE, CVSS score and whether exploitation needs a login. Records that claim every version with no fixed release are reported separately from version-specific findings, because there is nothing to upgrade to and treating them as a version problem would be misleading. A plugin whose version cannot be read is reported as unknown, never assumed safe.
SEO and site health crawl
The SEO audit is a crawl rather than a single fetch, because most SEO problems only exist across a site: A duplicate title needs two pages to be duplicated, an orphan page is defined by the absence of links to it, a redirect chain spans several URLs. It starts at the address you give, reads robots.txt and honours it, expands one level of any sitemap index to collect page URLs, then crawls breadth-first from both the entry point and the sitemap to the page budget the visitor chose (30, 100 or 250) and three levels deep, four requests at a time with a pause between waves. On any site larger than the budget this is a sample, and the report states the percentage of discovered URLs it covered rather than implying a full inventory. Only same-site HTML is followed; assets, downloads and external hosts are not fetched. Nothing is submitted, and no JavaScript is executed, so what is reported is what a crawler sees before it renders anything.
Each page is recorded with its status, full redirect chain, response time, transferred size, encoding and cache headers, then parsed for title, meta description, canonical, meta robots, viewport, language, heading outline, Open Graph and Twitter tags, JSON-LD, hreflang annotations, images with and without alt text, and every link with its anchor text. The site-wide checks are computed from that table: Duplicate titles and descriptions, duplicate body text by hash, crawl depth, broken internal links, and sitemap entries cross-checked against what the crawl actually found. Orphan pages are judged only against sitemap URLs, because a crawl that follows links can reach nothing but linked pages and would otherwise be testing something it cannot fail; with no sitemap that check is skipped rather than passed. Where the markup is at fault, the finding carries the source line number, so "no canonical link" comes with the line to add it at.
Two differences are worth stating plainly. We do not run a headless browser, so we cannot measure rendering, layout shift or anything that only exists after hydration. A lab tool that drives a real browser measures those, and this does not replace one. And the SEO grade uses a different curve from the security grades: Each additional failure of the same severity costs less than the one before, because twenty-seven over-long meta descriptions are one template problem rather than twenty-seven separate faults.
Deep scans
Both the website scanner and the SEO scanner can crawl rather than fetch a single page. The crawler is the same in both cases: Breadth-first from the URL you give, internal links only, robots.txt honoured, four requests at a time with a pause between waves, stopping at the page budget you chose.
What differs is what runs on each page. The SEO scan parses the markup for the crawl-wide checks. The deep security scan re-runs the header, cookie, mixed-content, subresource-integrity, inline-script, form and library checks against every page, then merges the results so a single finding reports which pages failed and why. Scripts are fetched once per unique URL across the whole crawl rather than once per page.
Host-level checks are not repeated: TLS, DNS, HSTS and the exposed-path probes run once, because their answer cannot differ between pages. Page-level checks are the ones that genuinely vary, and on real sites they do: A policy applied at the edge to one language prefix and not another, a legacy template still loading an old library, a form left on HTTP after everything around it moved.
Every deep result opens with its own coverage: How many pages were checked, how many internal URLs were discovered, and what percentage that represents. A crawl of a large site is a sample, and a sample presented as an inventory would be a lie about what was tested.
Browser check
Runs in your browser. Fingerprint signals are hashed with SHA-256 before being sent; the server counts hashes and returns how many browsers in our sample share each value, converted to bits of identifying information (bits = -log2 of the share of browsers that match). WebRTC addresses are gathered with a public STUN server and compared with the address your connection presented. Policy-enforcement tests load small pages served with specific headers from /probe/ and observe whether your browser obeyed them. Browser version is compared with the vendors' own release feeds.
File scanner
The file is read into memory and never written to disk or executed. We compute hashes, detect the true type from magic bytes, and then parse the container: OOXML relationships and macro parts, PDF object keywords including inside deflated streams, archive listings and compression ratios, LNK headers, and script text for download-and-execute and obfuscation patterns. Where a signature engine is available to the server, the bytes are streamed to it as well, so a sample that is already classified is recognised immediately. Only the SHA-256 hash and the verdict are stored. Where a finding rests on somebody else’s vulnerability database rather than on our own measurement, the data sources page says whose it is.
What we do not do
- No SQL injection, XSS, path traversal or command injection payloads.
- No password guessing, credential stuffing or login attempts.
- No port scanning beyond the web port in the URL.
- No crawling: One page, plus the fixed probe list.
- No scanning of private, internal or local addresses.
- No storage of uploaded files, and no public index of reports.
Limits you should know
A passive scan sees the unauthenticated surface only. It cannot judge application logic, authorisation, or anything behind a login. An active scanner finds things we cannot, at the cost of needing permission and a maintenance window; that write-up sets out what each approach catches and misses. Fingerprint uniqueness is estimated against our own sample, which is smaller than the web. File verdicts are indicators, not proof: A clean result means none of our indicators fired. Read the guide to reading a scan report before acting on a grade.