How WebVitalist scores your site

The overall score

A report has up to seven category scores, each 0–100. The overall score is their weighted mean. Copy carries the most weight because it is the part no other tool measures; Security Pass runs on every paid product; the functional category only exists on products that run the Full Test.

Renormalisation when a category is missing

Categories that did not run are left out and the remaining weights are scaled back up to 100 %. A category is missing when the product does not include it (Functional on an Audit or Deep Audit) or when a measurement could not be taken (Lighthouse quota exhausted, in which case Performance and Accessibility are both skipped and marked as such on the progress page). Formula: overall = Σ(score × weight) / Σ(weight), over the categories that produced a number, rounded to the nearest integer.

Each category score is clamped to 0–100 and rounded before it enters the mean. A category that ran but produced no score (for example, Lighthouse returned no accessibility category) is treated as missing.

Technical SEO checks

19 deterministic checks run on the HTML of every audited page. Each ends in pass, warn, fail or info, and each has a weight. A pass earns the full weight, a warn earns 40 % of it, a fail earns nothing, and an informational result (a page with no images) earns the full weight so it cannot lower the score. The technical score is earned weight / total weight × 100, with a total weight of 33.5.

Severity is how the free scan and report rank a problem: a fail on a check weighing 3 or more is critical; other fails and any warn on a check weighing 2 or more are major; the rest are minor.

Multi-page products

On the Deep Audit, Full Test and Fix Pack the same checks run on every crawled page. The technical score is the plain average of the per-page scores; the report lists the checks for the page you entered in full, plus a per-page summary with the failing checks and every page scoring below 70. robots.txt and sitemap results are looked up once per site and shared by all pages.

Length thresholds (30–65 characters for titles, 70–165 for descriptions) are deliberately wider than the 30–60 and 120–160 we recommend in the fix text, so a check only warns when truncation or emptiness is likely rather than merely possible.

Security Pass

Paid reports add a Security Pass score (0–100) from 12 passive checks on the public URL. The scoring rule is the same as Technical SEO: earned weight / total weight × 100, with a total weight of 28.5. A pass earns the full weight, a warn earns 40 %, a fail earns nothing, and informational results (no cookies, leak probes skipped, HTTPS already in use so we did not see an HTTP landing page) earn the full weight.

We only HEAD/GET the audited URL and a short allowlist of common leak paths on the same origin, with 3 probes at a time and a 4 s timeout. This is not a penetration test: no port scanning, no authentication, no form submission, no SQL/XSS payloads, no fuzzing.

Performance and Core Web Vitals

Performance comes from a real Lighthouse run on a simulated mobile device through Google's PageSpeed Insights API, requesting the Performance, Accessibility, Best Practices and SEO categories. The Performance category score (0–100 as Lighthouse reports it) is used unchanged as your performance score. Lighthouse Best Practices and SEO are printed in the report but do not enter the overall.

New to these metrics? How to read a Lighthouse / Core Web Vitals report.

The run is made against the URL you entered. On multi-page products we also request Lighthouse for up to 2 more crawled pages on a best-effort basis, but only the main page's numbers feed the score.

Core Web Vitals thresholds

Where Google has enough real-user data (Chrome UX Report, last 28 days), the report shows field LCP, INP and CLS at the 75th percentile with Google's own classification. We do not re-classify these; the thresholds are Google's:

Anything between the two boundaries is "needs improvement". Sites with little traffic have no field data; the report says so and relies on the lab run.

Lab metric targets

The lab numbers Lighthouse measured are printed next to the target we hold them to. Targets are informational: the score itself is Lighthouse's, not ours.

We also list up to 8 Lighthouse opportunities that save at least 100 ms, sorted by estimated savings. If PageSpeed Insights is unavailable or its quota is exhausted, the Performance and Accessibility steps are skipped, the overall is renormalised, and the report says so.

Accessibility

The accessibility score is the Lighthouse Accessibility category from the same mobile run, unchanged. It is an automated audit (axe-core rules: contrast, names and labels, ARIA usage, document language, heading order and similar) and can only ever find a subset of real accessibility problems. The report lists up to 12 failing audits by title. Manual and informational Lighthouse audits are excluded.

Independently of Lighthouse, our own HTML analysis counts form fields without labels and buttons without an accessible name; these counts are handed to the AI review as evidence and to the Full Test as functional issues, but they do not change the accessibility score.

Copy & messaging and UX & conversion

These two categories are the model-generated part of the report. A language model acting as a CRO consultant receives: the structured signals we extracted from the page (title, meta, headings, CTA candidates, link and image counts, structured data types), the visible text (up to 14,000 characters), the failing technical checks with their fixes, the Lighthouse summary, and – on multi-page products – the title, H1 and word count of every crawled page. It also receives the goal, notes, platform and competitor URL you gave in the wizard.

What it must return

The answer has to match a strict schema (defined with Zod) or it is rejected and retried:

• Two scores, 0–100, one for copy and one for UX. The prompt calibrates them: 90–100 excellent, 70–89 good with clear gaps, 40–69 significant problems, below 40 fundamentally broken.
• 3–7 findings per category, each with a title, the evidence on the page that shows it, why it matters, a concrete recommendation, and an impact and effort rating.
• Ready-to-paste rewrites: title (30–60 characters), meta description (120–160), H1, hero sub-heading and primary CTA text.
• A 30-day action plan in three blocks (week 1, week 2, weeks 3–4) with 2–6 items each, combining its own findings with the technical and performance items it was given.
• An executive summary and the language the report is written in.

How it is validated

We ask the model for structured output at temperature 0.4 with up to two retries. If the provider cannot produce a schema-conforming object, we fall back to a plain-text request that must contain only JSON, extract it, and validate it against the same schema. Any response that still fails validation fails the audit, which triggers an automatic refund rather than a partial report. The prompt forbids inventing facts about the business, requires every finding to quote evidence, and tells the model not to repeat purely technical items that the deterministic checks already cover.

The report is written in the language of the page (detected from the lang attribute and the visible text), so rewrites can be used directly. In demo deployments the model is replaced by deterministic fixtures derived from the fetched page and the report is labelled accordingly.

How the crawl works

Multi-page products discover pages by breadth-first search from the URL you entered (plus any extra URLs you listed in the wizard). Only same-origin links that look like HTML pages are followed; robots.txt rules for User-agent: * are honoured with Google's longest-match semantics, and pages you disallow are skipped, not fetched. The crawler fetches 4 pages at a time with a 10 s timeout per page and stops after 90 s even if the page cap has not been reached. Responses are read up to 2 MB.

Site-wide issues

After the crawl we compare pages with each other. Each issue below costs 12 (high), 6 (medium) or 3 (low) points off a crawl health score that starts at 100 and cannot fall below 40. That crawl score is shown on the progress page and its issues appear in the report; it is not one of the weighted categories, because the same problems already lower the per-page technical scores.

What the Full Test actually does

Today the functional test is an HTTP-level inspection, not a real browser. We parse the HTML of the page you entered, collect every link, button with an onclick navigation, image and form, and then:

• request up to 150 internal links and record every 4xx/5xx or connection error;
• request up to 60 images and flag errors and HTTP images on HTTPS pages;
• request up to 40 external links and flag 4xx answers (5xx from third parties is ignored as noise);
• inspect every form for an action, a method, labelled fields, named required fields, a submit button and an HTTPS target – forms are never submitted;
• list dead anchors (href="#", javascript:void, malformed mailto/tel).

Each request has an 8 s timeout, runs 4 at a time, and the whole step stops after 120 s. The functional score starts at 100, loses 8 points per high, 4 per medium and 2 per low issue, and cannot fall below 20.

Because no browser is involved, the "JavaScript errors" and "failed requests" counters in a Full Test report currently reflect only the HTTP probes above: JavaScript is not executed, console errors are not captured, and buttons that navigate via framework code rather than a link or onclick are not exercised. A headless-browser version (Cloudflare Browser Rendering) is prepared in the pipeline and will replace this step when enabled; until then, read the Full Test as a thorough link, image and form audit.

Deterministic vs model-generated

Two audits of the same unchanged page should give the same deterministic numbers. The AI categories can differ between runs by a few points, which is why they are calibrated with explicit bands and asked to ground every finding in quoted evidence.

Score bands

Every score – overall, per category, per page and in the free scan – is coloured and labelled with the same three bands:

Scores in the "Needs work" band are the ones most worth acting on: they usually mean a handful of specific, fixable problems rather than a rebuild.

The free scan

The free scan fetches one page with an 8 s budget, runs the 19 technical checks above and detects the platform. Its score is the technical score exactly as described here – no Lighthouse, no crawl, no AI. The 3 most severe issues are shown in full (ranked by severity, then weight, then check order); the rest are listed by title only. A completed scan of the same URL is reused for 6 hours.

What we do not measure

• Rankings, keywords and backlinks. We do not query search engines or link databases. The report tells you why a page may struggle to rank, not where it ranks.
• Traffic and conversion rates. We have no access to your analytics; the UX score is an expert review of the conversion path, not a measurement of it.
• Logged-in, paywalled or geo-restricted content. We see what an anonymous visitor and Googlebot see.
• JavaScript execution. Our own checks read the server-rendered HTML. Lighthouse does render the page, so performance and accessibility reflect the rendered result, but the technical checks and the crawl do not see client-side-only content.
• Desktop. Lighthouse runs on a simulated mobile device only.
• Active security testing. Security Pass is a passive public-URL review (headers, cookie flags, TLS, a few leak paths). It is not a pentest, authenticated scan, or certificate deep-inspection.
• Every page of a large site. Crawls are capped per product (see above); site-wide template problems are caught because they repeat, but a broken page outside the crawl will not be.
• Manual accessibility. Automated audits find a fraction of WCAG issues; the report is not a conformance statement.

Something unclear or wrong on this page? Email hello@webvitalist.com. Last updated 2026-09-13.