Auditing pages the scanner cannot reach

The crawler identifies itself as `VeriFixScanBot/1.0` and never solves a CAPTCHA, a browser challenge, a firewall rule or a rate limit. A page that answers with one is recorded with the kind of protection met and reported as restricted, never analysed.

Login walls are treated the same way: an authentication requirement is a protection, not an obstacle to work around.

When that happens, the report says which URLs could not be read and why, and offers to analyse the exact URL from the browser instead.

That is the honest outcome for a staging site behind a password, an account area, a checkout that requires sign-in, or a site whose firewall refuses automated clients.

The page's URL, title and rendered HTML, its visible text, declared language and viewport, and its meta description, robots directive and canonical URL.

Its H1 to H3 headings, images with their alternative text, internal and external links, forms with their action, method and field count, buttons and navigation entries.

Open Graph and Twitter card properties, and the raw JSON-LD blocks, which the server parses defensively and never executes.

Timings measured in your browser — time to first byte, DOMContentLoaded, load and transfer size — and, with recent versions of the extension, Core Web Vitals, the resources loaded, contrast samples, third-party hosts and cookie metadata.

Cookie values, storage contents, request bodies and response headers are structurally absent from what is accepted. The whole payload is capped and treated as untrusted input.

The snapshot becomes a scan like any other: the same deterministic checks, the same issue and report format, the same entitlement rules.

Nothing is re-crawled from the server, so the analysis describes exactly what your browser rendered.

Content findings apply as they would on a crawled page: a missing title or H1, images without alternative text, unlabelled form fields, a form posting to an HTTP address, structured data present or absent.

Measured performance comes from your machine and network, which makes it a single laboratory reading rather than what visitors experience in aggregate.

Collectors that did not run in your browser leave their checks not verifiable, rather than passing.

The page is the page as your account sees it. Personalised content, feature flags and role-specific menus are part of the capture and may not match what another user sees.

Header-based checks — security headers, HSTS, cookie flags set by headers — cannot come from this capture, because headers are not part of it. Those checks need a server-side scan of a reachable URL, or a look at the response in your browser's developer tools.

One page is not a site. Findings that depend on comparing pages — duplicate titles, internal link structure — need a crawl.

Timings from one visit on one connection are not field data; treat them as a direction, not a verdict.

The capture includes the rendered HTML and visible text, so anything the page displays — your name, an order history, a customer's details — travels with it.

Capture pages while signed in with a test account where one exists, especially on admin screens that show other people's data.

Values that are secret by nature — cookie contents, stored tokens, request bodies — are never part of the payload, by design of the schema.

The same care applies to staging environments that hold real data copied from production.

The browser observation carries its own challenge field: whether the page shown was a Cloudflare challenge, Turnstile, reCAPTCHA, hCaptcha, another CAPTCHA, a login wall or a bot-protection page.

A capture of a challenge page is therefore recognised as a challenge, not audited as if it were the content behind it.

It also records whether the capture came from a mobile user agent and which collectors actually ran, so the report knows which of its checks the capture can support.

Solve the challenge yourself, as any visitor would, and capture the page you then reach.