How we audit a website

• Only show numbers we measured. If we didn't crawl every page on the site, we don't print “7 pages are missing meta descriptions.” We say what we observed on the homepage and recommend a fuller crawl with a tool that actually does one.
• Lab data and field data are different things. Lighthouse runs an automated test from one machine. CrUX (Chrome User Experience Report) is what real Chrome users actually experienced over the last 28 days. We label both clearly and never mix them.
• Verifiable, not just trustworthy. Every audit links you to Google's own PageSpeed Insights tool with the same URL pre-filled, plus a download of the raw PSI response we received. You don't have to take our word for any of it.

Every finding, score, and source claim in ScanoraAI maps to one of seven canonical evidence labels. The label answers a single question: how was this number produced?

We adopted this vocabulary in v8.1 (May 2026) after an audit review flagged that phrases like “verified”, “estimated”, “AI-generated”, and “never estimated” had drifted in meaning across the product. The labels are now shared across the report UI, the methodology page, and the engine's typed contracts.

Implementation: src/lib/evidence-labels.ts (shared module) and src/components/EvidenceLabel.tsx (UI chip). See /self-audit for the labels applied to a real audit run.

Every audit goes through these stages, in order. Each stage has a kill-switch — if a stage fails clearly (DNS doesn't resolve, the URL serves a parking page, etc.), we stop and tell you instead of producing a bogus score.

1. Pre-scan gate. 11 named checks: DNS resolution, TCP reachability, TLS validity, redirect loops, parked-domain detection, soft 404s, placeholder/under-construction pages (including unconfigured WordPress / Ghost / Drupal / Joomla installs), and empty shells. Failures emit audit.gate.reject with the named reason.
2. HTTP probe. A single GET request to the homepage with a real user-agent. We extract: response time, content length, charset, response headers, the parsed DOM (heading hierarchy, image/link/form counts, schema.org JSON-LD, Open Graph tags, viewport meta, canonical, hreflang, robots), and security headers.
3. PageSpeed Insights (Lighthouse + CrUX). 5 independent runs per strategy (desktop + mobile), fired in parallel from our server against Google’s public PSI REST endpoint. We take the median performance score across runs and flag high variance (>15 points) explicitly. Desktop scores drive the main category scoring formula; the mobile performance score is surfaced separately as mobilePerfScore and used for the mobileScore metric. CrUX field data is extracted separately when Google has enough Chrome traffic for your site.
4. Signal evaluation. Each signal is a pure function over the probe + Lighthouse data. Penalties are deterministic — same inputs always produce the same penalty.
5. Recommendation ranking. Issues are ranked by a transparent formula (see the Scoring section below). No language model is involved in the ranking.
6. Persistent storage. The full report and raw PSI response are saved to a database with a 90-day retention. Every report has a SHA-256 fingerprint of (URL, timestamp, scores, signal IDs) — if anyone edits the data, the fingerprint changes.

Performance scores come from Google's PageSpeed Insights API v5, which runs the same Lighthouse engine you can run yourself at pagespeed.web.dev. We do not use a custom Lighthouse fork or modified scoring.

Lighthouse is non-deterministic — even Google's own tool returns scores that vary by ±5 points between runs on the same URL. That's why we run it 5 times and use the median, and why our scores will sometimes differ slightly from a single re-run on pagespeed.web.dev.

The Chrome User Experience Report (CrUX) is real-user data Google publishes for sites with enough Chrome traffic. When CrUX data exists for a URL we show it explicitly and label it “p75 real users” — that's the 75th-percentile experience over the last 28 days, the standard Web Vitals threshold.

CrUX requires a minimum traffic threshold. Roughly 1 in 4 sites we audit don't meet it. When CrUX data is unavailable we show a clear “Not enough real-world traffic” panel — we never invent placeholder field values.

We also flag lab/field divergence: if Lighthouse's lab measurement is more than 20 points off the CrUX field measurement, that's a signal worth knowing about (typically the homepage was tested on a fast pipe but real users hit slower mobile networks).

These come from the HTTP probe — we evaluate the homepage HTML directly:

• SEO basics: title length and uniqueness, meta description presence and length, canonical, hreflang, Open Graph, schema.org JSON-LD, robots directives.
• Accessibility (homepage scope): language attribute, viewport meta, image alt count vs missing-alt count (real numbers — we count what's in the DOM we received).
• Security headers: HSTS, CSP, X-Frame-Options, Referrer-Policy, Permissions-Policy. Graded the same way securityheaders.com does.
• Performance hints: resource counts and sizes from Lighthouse, missing width/height on images, render-blocking resources, unused CSS/JS opportunities.

Every check the engine runs, its source, the maximum penalty it can apply, and its confidence level. Verified = measured directly by Lighthouse or a third-party provider. Estimated = derived from structural HTML analysis.

Penalties are additive within a category and capped at the category floor (8 points minimum). The exact penalty applied to any signal depends on severity multipliers — see the Scoring section below. This table reflects engine v10.0. Rule IDs are stable across versions; penalties may be tuned.

Engine 6.0.0 added four probe-derived signals that fire only when the probe field is explicitly populated. An undefined field means “unknown” — it never fires a false negative. All four carry confidence: 'verified' and appear in structural-only mode.

These signals were added because they are directly observable from a single HTTP response — no Lighthouse run required — and they represent real, fixable problems that affect a large fraction of audited sites.

Engine 7.0 adds seven independent third-party sources that run in parallel alongside the Lighthouse probe. Each source is free, has no API key requirement (except Safe Browsing which reuses your existing PSI key), and produces results you can independently verify by pasting your domain into the provider's own UI.

Engine v8.0 added eight more in-process and lightweight sources that run on every audit:

Engine v10.0 adds eight in-process probes (JS-shell detection, rendered-meta extraction, TLS certificate-chain inspection, CDN detection, cookie security audit, broken link sampling, exposed file detection, mixed content detection) that produce findings the sources above cannot. Each is its own evidence source: it has distinct inputs, distinct outputs, and surfaces failures the other 15 sources miss (10 third-party + 5 in-house parsers, listed above).

Both desktop and mobile Lighthouse strategies run on every audit (5 runs each, in parallel). The desktop run drives the main category scores (SEO, Performance, UX, Design) and the overall score. The mobile performance score is surfaced separately as mobilePerfScore in the report and shown in the audit results UI.

Overall = mean(SEO, Design, UX, Performance)   ← all from desktop Lighthouse

Mobile Performance score = separate field (mobilePerfScore)
                         ← from mobile Lighthouse 5-run median

Rationale: desktop scores are more stable (lower variance) and are what most site owners compare against their own PageSpeed Insights runs. The mobile score is surfaced prominently because Google's ranking algorithm uses mobile Core Web Vitals — a large gap between your desktop and mobile scores is a high-priority finding.

For each Critical and Medium finding, the engine generates a 2–4 sentence explanation that:

• References your actual numbers. The prompt receives the Lighthouse JSON for that specific finding — LCP element, image size, blocking time. The model is forbidden from inventing metrics.
• Names the specific element. “Your hero image banner.jpg is 3.8 MB and is your LCP element” — not “large images slow your page.”
• Gives the stack-specific fix. The tech detector identifies your CMS/framework first. The explanation then gives the exact fix for your stack: WordPress plugin, Shopify theme setting, Next.js component, etc.
• Labeled as AI-generated. Every explanation carries an aiGenerated: true flag and cites the model used. It is an enhancement to the verified finding — it never replaces the score deduction or the upstream source citation.

The multi-page audit runs the full single-page pipeline on up to 10 pages of a site and aggregates the results. It does not replace a full-site crawler — it is a bounded, honest sample.

• Page discovery. We first audit the homepage, then extract up to 9 additional URLs from the homepage's internal links (most-linked = most important). If the homepage has fewer than 3 internal links (SPA shell, hero-only landing page), we fall back to sitemap.xml.
• Sequential, not parallel. Pages are audited one at a time with a 3-second politeness delay between requests. Parallel audits would exhaust the PSI key pool (4 keys × 5 runs × 10 pages = 200 simultaneous calls).
• Failure tolerance. If a page fails (timeout, blocked, error), we record the failure and continue. We never silently drop a page or pretend it succeeded.
• Aggregation. We report the arithmetic mean of per-page scores, the worst page (priority fix target), the best page (template to replicate), and signals that appear on 3+ pages (template/CMS issues — fix once, fix everywhere).

Each signal carries a penalty (0–25 points) and lands in a category: SEO, Performance, UX/Accessibility, or Design. Each category starts at 100. The probe and Lighthouse layers populate real findings on top, deducting points per active signal. The final per-category score blends Lighthouse (when available) with the structural signals at the rates below, then clamps to [8, 96]:

Performance       = 70% Lighthouse perf      + 30% structural
SEO               = 70% Lighthouse SEO       + 30% structural
UX/Accessibility  = 70% Lighthouse a11y      + 30% structural
Design            = 50% Lighthouse practices + 50% structural

Overall           = mean(perf, SEO, UX, design)   ← desktop Lighthouse
Mobile perf score = separate field (mobilePerfScore) ← mobile Lighthouse

Quick-win bonus   = +2 priority for fixes ≤ 5 min

When Lighthouse fails or is unavailable for the audit, the affected categories carry an “unverified” flag in the report payload (dataSources.<cat>.verified = false) and the UI shows a clearly-labelled notice in place of fabricated numbers. We do not synthesise category scores from a URL hash — that was removed in engine 6.0.0.

Recommendations are ranked by:

priority = penalty × severityMultiplier × confidenceBoost ÷ effortMultiplier

The multiplier values are fixed constants — not tuned per-run or per-model:

severityMultiplier
  critical  → 2.0
  high      → 1.5
  medium    → 1.0
  low       → 0.6
  info      → 0.3

confidenceBoost
  verified  (Lighthouse / axe-core measured)  → 1.2
  estimated (structural inference)            → 1.0
  inferred  (heuristic / single-source)       → 0.8

effortMultiplier
  trivial   (< 5 min,  e.g. add alt text)    → 0.5   ← quick-win boost
  low       (< 30 min, e.g. add meta tag)    → 0.8
  medium    (< 2 h,   e.g. compress images)  → 1.0
  high      (< 1 day, e.g. lazy-load JS)     → 1.4
  complex   (> 1 day, e.g. CLS layout fix)   → 2.0

All four factors are deterministic — same inputs always produce the same priority order. We do not use an LLM to rank issues; the AI chat is purely an explanatory layer over the deterministic findings.

Worked example — “Missing alt text on 14 images”:

Signal:   missing-alt-text
Penalty:  12 points
Severity: high      → severityMultiplier = 1.5
Source:   axe-core  → confidenceBoost    = 1.2  (verified)
Effort:   trivial   → effortMultiplier   = 0.5  (< 5 min)

priority = 12 × 1.5 × 1.2 ÷ 0.5
         = 12 × 1.5 = 18
         = 18 × 1.2 = 21.6
         = 21.6 ÷ 0.5 = 43.2  ← ranked #1 in most audits

Compare: "Render-blocking JS" (penalty 18, high, verified, high effort)
priority = 18 × 1.5 × 1.2 ÷ 1.4 = 23.1  ← ranked lower despite higher penalty

The trivial effort divisor (0.5) intentionally surfaces quick wins above harder fixes of equal impact — because a fix you can ship in 5 minutes delivers value faster than one that takes a day.

PSI sometimes blips. We handle it without lying about the data:

• Multi-key pool with round-robin rotation across up to 4 PSI keys. Per-key cooldown after 429/403.
• Circuit breaker opens after 5 consecutive PSI failures, with a 30s cooldown and a single half-open probe before fully closing.
• Targeted retry on 429 / 5xx / ECONNRESET / ETIMEDOUT only. Three attempts with exponential backoff and full jitter. Never retries on AbortError or 4xx (other than 429).
• Honest fallback: when Lighthouse is unavailable for a URL, we show a clear panel explaining why and never fabricate Core Web Vitals numbers. Structural signals still apply.

ScanoraAI is a public URL scanner. That means we must prevent it from being used as a proxy for SSRF attacks, internal network probing, or denial-of-service amplification. Here is what we enforce:

• Private IP blocking. Before any outbound HTTP request, the target hostname is resolved and the resulting IP is checked against RFC 1918 / RFC 4193 private ranges (10.x, 172.16–31.x, 192.168.x, fc00::/7, ::1, 127.x, 169.254.x). Requests to private IPs are rejected with a 400 before any connection is made.
• DNS rebinding protection. The IP check is performed after DNS resolution, not on the hostname string, so a domain that resolves to a private IP is blocked even if the hostname looks public.
• Protocol allowlist. Only https:// and http:// URLs are accepted. File, FTP, data, and other schemes are rejected at input validation.
• Rate limiting. Single-page audits are limited to 5 per IP per 10 minutes. Site audits (multi-page crawl) are limited to 2 per IP per 10 minutes. Limits are enforced server-side before any external requests are made.
• Timeout caps. Each outbound source has a hard timeout (PSI: 120 s, SSL Labs: 150 s, all others: 30 s). The overall audit has a 12-minute watchdog that terminates any hanging job and returns partial results.
• Redirect following. HTTP redirects are followed up to a maximum of 5 hops. Each hop is re-validated against the private IP blocklist so a redirect chain cannot escape to an internal address.
• No JavaScript execution. Our probe fetches raw HTTP responses — it does not execute JavaScript, render a DOM, or run any user-supplied code. This eliminates the XSS-via-audit-target attack surface.
• Responsible disclosure. If you find a security issue, email admin@scanoraai.com with subject line “Security disclosure”. We aim to respond within 48 hours.

Three independent ways:

1. Re-run on Google directly. Every audit page has a button that opens pagespeed.web.dev with your URL pre-filled. Compare the scores. They will be highly similar (accounting for normal run-to-run variance).
2. Download the raw PSI response. Each audit links to the verbatim JSON Google returned to us, unmodified. You can run curl against the same endpoint with your own API key and diff the responses.
3. Check the audit fingerprint. Every report displays a 16-character SHA-256 prefix at the top. If any data in the report changes after the audit was generated, the fingerprint won't match. We compute it from (url, scannedAt, category scores, signal IDs).
4. Read our self-audit. We run the engine on scanoraai.com itself and publish the full output — scores, source timestamps, findings, and AI explanations — at /self-audit. We don't hide our own issues. The homepage currently scores 72 on mobile performance due to a large JS bundle — that's a known issue we are actively fixing.

Saying we are accurate is not the same as proving it. We are committing in public to publishing measurable accuracy data — false-positive and false-negative rates against a fixed corpus of test sites — on a quarterly cadence.

What that means in practice:

• A fixed benchmark corpus. We are assembling a public set of test sites with known, deliberately-injected issues — broken canonicals, missing alt text, mixed-content warnings, slow LCP, low-contrast text, malformed JSON-LD — plus a control set of clean sites. Every release we run the engine against the corpus and record which signals fired correctly, which were missed, and which fired in error.
• Published metrics. For each major signal, we will publish precision (no false positives), recall (no false negatives), and the corpus version it was tested against. Numbers will appear on this page and on /transparency.
• Quarterly cadence. The first benchmark report is targeted for Q3 2026. After that, every quarter, alongside the engine changelog. We will publish regressions as well as improvements — if a new release worsens recall on a signal, that will be visible.
• External corroboration. Where a signal is measured by an external tool (Lighthouse, axe-core, SSL Labs, W3C Validator), we already link out to the provider so anyone can cross-check us. Benchmarks add the missing piece: statistically validated agreement, not just spot checks.

This section is intentionally a roadmap commitment, not a finished number. The audit engine currently passes a 644-test internal suite covering signal detection, scoring math, and provider failure handling. The benchmark corpus is the next layer up — testing the engine as a black box against ground-truth issues. We'd rather under-promise here than publish cherry-picked numbers.

• The single-page audit covers the homepage only. Inner-page issues are inferred from homepage signals where appropriate. The multi-page audit extends this to up to 10 pages — see the Multi-page audit section above.
• We don't test logged-in or paywalled pages.
• CrUX data has a ~28-day publication lag and a minimum traffic threshold; for low-traffic sites it's unavailable.
• Lighthouse runs from Google's test infrastructure. Sites that block Googlebot or restrict by IP will fail PSI but may still be audited via structural signals only.
• We do not (and cannot) audit JavaScript-rendered content the way a real Chromium-based crawler would. PSI does, which is one reason we lean on it for performance.
• SSL Labs latency: SSL Labs' API performs a full TLS handshake analysis and can take 60–120 seconds for a domain it hasn't recently cached. It runs in parallel with other sources, but on a fresh domain it is typically the last source to complete and is the most common reason an audit approaches the 5-minute ceiling. Cached results (domains scanned within ~24 hours) return in under 5 seconds.

Every material change to scoring, signals, data sources, or honesty disclosures is recorded here. We don't silently retune weights — if a check changes how it deducts points, or a new data source goes live, it shows up in this list. Versions follow the audit engine (separate from the marketing-site version).

Earlier internal iterations (pre-v6) are not listed because they predate the public commitment to a stable signal contract. v6.0 is the first version whose signal IDs and penalty caps match what runs in production today.