Skip to content
Page Lookout

What we check and what you get

The scanner is a set of independent modules. Each runs as its own task per URL and returns findings in the same normalized shape. Below is every module together with the checks it performs.

Scanner modules

Security baseline

This module checks the basics that should be in place on any production site, from the certificate through the security headers to how cookies are set.

What this module checks

  • HTTPS use and redirects from HTTP to HTTPS
  • TLS handshake, certificate expiry date, untrusted certificates, weak keys and legacy protocol versions
  • Strict-Transport-Security (HSTS) header
  • Content-Security-Policy header, and weak settings in it such as unsafe-inline, unsafe-eval and wildcard script sources
  • X-Content-Type-Options header
  • Clickjacking protection (framing controls)
  • Referrer-Policy header
  • Permissions-Policy header
  • Server software version disclosure
  • Cookie attributes (Secure, HttpOnly, SameSite)
  • Mixed content (HTTP resources on an HTTPS page)

Performance (Lighthouse / Core Web Vitals)

This module runs a Lighthouse measurement against a fixed list of Performance pages for each site and returns Core Web Vitals together with the elements that weigh on the result most. By default the list is the home page and the pages closest to it, up to 20 per site, chosen at the first scan and kept the same after that, so results can be compared from scan to scan. You can edit the list.

What this module checks

  • A fixed list of Performance pages per site: the home page and the pages closest to it by default, up to 20
  • Your own list: add pages the scan has found, remove pages, and at least one page stays
  • Core Web Vitals (LCP, CLS, INP)
  • Time to first byte and first contentful paint
  • Weight and number of resources loaded on the page
  • Render-blocking resources
  • Unoptimized images and images without dimensions
  • Repeatable measurement across scans for trend tracking, because the pages stay the same

Accessibility (axe-core, WCAG)

This module runs the axe-core rule set against the rendered page and returns findings referenced to the WCAG guidelines. Automation does not replace testing with people, it catches what a machine can check.

What this module checks

  • Text contrast against its background
  • Alternative text for images
  • Form field labels
  • Heading structure and page landmarks
  • ARIA attributes and their validity
  • Keyboard operability and visible focus
  • Document language attribute

Technical SEO

This module checks the technical layer of SEO: what follows directly from the server response and the page markup, without judging content or tracking search rankings.

What this module checks

  • HTTP status codes and redirect chains
  • Page title (presence, length, duplicates)
  • Meta description
  • Canonical URL
  • Robots directives (meta robots and the X-Robots-Tag header)
  • H1 to H6 heading structure
  • robots.txt and the sitemap.xml file, including noindex pages listed in the sitemap
  • Broken links and links that redirect
  • Broken and oversized images, and alt text that is empty, too short or too long
  • Basic page markup: language, character set and viewport

Cookie & consent observation

This module visits the page, records the state before and after interacting with the consent banner, and runs the collected data through a rule engine. It can also read what the page declares about the visitor's choice: the IAB consent string and Google Consent Mode. The output describes the observed behaviour, with no legal assessment attached.

What this module checks

  • Consent management platform (CMP) detection
  • Cookies set before any consent interaction
  • Cookies set after accepting and after rejecting
  • Requests to third-party domains and when they happen
  • Attributes and lifetimes of the cookies that were set
  • The IAB consent string (TCF) and Google Consent Mode, as the page declares them; the raw string is never stored
  • A step the scan could not complete, such as a banner it could not press, is reported as not performed and never as nothing found
  • Reject all and Accept all pressed on OneTrust, Cookiebot, Usercentrics, Didomi, CookieYes, InMobi Choice and TrustArc, with the choice confirmed as stored. Many other platforms are recognized from a public rule set, and what depends on them is marked as needing verification
  • Your own banner selectors, set in the site scan policy, for a banner the scan does not know
  • An inventory of the third-party domains contacted, the cookies set and the storage keys used, by name and never by value, as a screen and as a CSV download
  • A list of approved third parties that you keep, with a finding for each third party seen that is not on it
  • A vendor and category for known cookies and trackers, with the source of each classification shown and uncertain ones marked as needing verification
  • A rule engine describing the observed behaviour patterns

Visual changes

This module takes screenshots of the pages you pick and compares each with the last version you accepted, so you can see what moved after a release. It shows the difference. Whether a change is wanted is for you to decide, page by page. Included in Enterprise.

What this module checks

  • Screenshots of the pages you choose
  • Groups of similar pages, called templates, with a few sample pages captured for each
  • The viewports you choose to capture
  • Comparison with the accepted version of each page
  • Regions of a page that you mark to be ignored
  • Accepting a change page by page, which becomes the new accepted version

Reports, alerts and schedules

Everything that gets scan results out of the platform and into your inbox, your reports or your own tooling.

What this module checks

  • A PDF report for each finished scan of a site
  • Alert rules, per site or for the whole organization: a number of findings, new or changed findings, a scan that did not finish, or Health turning to Needs attention. Each alert is e-mailed to the organization admins
  • Scans triggered on a schedule, daily or weekly, or started by hand
  • Signed webhooks to up to five HTTPS endpoints of your own whenever a scan finishes
  • API keys with separate permissions to start scans and read results, findings, reports and the consent inventory, with the documentation published openly
  • CSV downloads of the consent inventory and of the consent signals

What every scan gives you

  • Findings with a severity

    Every finding carries a severity, so it is clear where to start instead of facing a flat list of everything at once.

  • Technical evidence

    Structured evidence: the URL, the header name and value, cookie attributes, certificate data. No guessing what a finding was based on.

  • A recommendation

    Each finding comes with a recommendation of what to change. It is technical guidance, not a legal assessment or an audit opinion.

  • Comparison with the previous scan

    A stable fingerprint means the same issue is recognized in later scans. Each scan is compared with the one before: what is new, what is still there, what changed and what was fixed. If a check could not look, for example a page was missing or a step failed, it says so instead of calling the finding fixed.

  • Issues, not a flat list

    When one cause shows up on many pages, such as a header missing from a shared template, the findings are grouped into one issue with the pages behind it. One decision to make instead of two hundred rows.

  • A Health number

    Each site gets a Health number from 0 to 100, overall and for security, performance, SEO, accessibility and consent, to show where to look first. It describes what the latest scans found. It is not a grade or a certificate, and the Docs explain exactly how it is worked out.

  • Raw artifacts

    Raw tool output is preserved as an artifact, so you can go back to the source of a finding and verify it yourself.

  • Scan history and reports

    Every scan stays in the site history together with the policy it ran under. Every finished scan of a site can be printed as a PDF report, and alert rules tell you by e-mail when something needs a look.

Organizations, sites, policies

The data model is multi-tenant from the ground up: the organization is the access boundary, and everything else sits inside it.

Organization (tenant)
An organization holds sites, users and scan results. One organization never sees another organization's data.
Roles: admin and member
Admins manage sites, policies and team membership, and invite colleagues by e-mail. Members work with the scan results.
Access groups
Optional. Switch them on to give a member access to selected sites only, for example one client's sites. Admins always see every site.
Site tags
Label sites with coloured tags, such as a client or a kind of site, and filter the Sites list by them. Tags only help you find and group sites. They change nothing about scanning or who sees what.
A scan policy per site
For each site you choose the set of modules, the maximum number of URLs per scan, the crawl depth, the request rate and the schedule.
URL discovery
A scan starts from the seed URLs you provide, reads sitemap.xml and crawls the site up to the depth and URL limit you set.
Tasks and workers
One task is created per URL per module and handled by an independent worker. One module failing does not stop the others.
History, alerts and API access
Scans are stored in the site history and finding fingerprints make consecutive runs comparable. Alert rules, webhooks and the API let you pull the same results into your own tooling.

What Page Lookout is not

What the platform deliberately does not do matters as much as what it does.

  • It is not uptime monitoring

    We do not ping your site every minute to see whether it responds, and we do not raise outage alarms. We analyse technical quality when a scan runs, on demand or on your schedule.

  • It is not legal advice

    We do not rule on the legal status of a site and we do not issue certificates. We describe what we observed technically and recommend changes. Interpretation is for you and your legal advisers.

  • It is not a penetration test

    We do not try to bypass protections, exploit vulnerabilities or sign in to your systems. The scanner looks at your site the way an ordinary HTTP client does, within a bounded request budget.

  • It does not replace a human audit

    Automation catches what can be checked automatically. Some questions, accessibility especially, need human judgement and testing with real users.

Want to see how this looks on your own sites?

Request an invitation