Skip to main content
Security Auditor — runs the Google Lighthouse Best Practices category against the monitored page and reports its score: below 90 is a warning and below 50 is a failure, both thresholds set per monitored URL. Every audit Lighthouse lists under the score is a check of its own, with Lighthouse’s own description and the offending elements.

Same score as PageSpeed

The score is the one Lighthouse computes, so it matches Chrome DevTools and PageSpeed Insights.

Fast

No performance trace is recorded, so the run finishes seconds after the page loads.
This auditor starts a headless Chromium, lets Lighthouse load the page with the desktop preset (or the mobile profile, by preference) and run only its Best Practices audits, and reads the category score from the report. It tells you whether the page follows the web platform’s safety and hygiene rules: the Best Practices score. The check names the lowest-scoring audits of the category, so the report says what to fix first. Lighthouse’s Best Practices audits cover HTTPS, front-end libraries with known vulnerabilities, browser console errors, deprecated APIs, third-party cookies, image aspect ratios and resolution, source maps and the document’s doctype and charset. The Lighthouse Best Practices auditor is one of four auditors that share one Lighthouse image; the others are Lighthouse Performance, Lighthouse Accessibility, Lighthouse Best Practices and Lighthouse SEO. Enable the ones a URL needs: each runs its own Lighthouse pass.

​
How it works

  1. Thresholds — reads formFactor, warningBelowScore and failBelowScore. When failBelowScore is not lower than warningBelowScore the audit fails with a single check (401) and Lighthouse does not run.
  2. Lighthouse run — runs the Lighthouse CLI (version pinned in the image, reported in the 100 check) with the best-practices category only, the desktop preset or the mobile form factor, and the 37AuditsBot user agent. The run has a time budget derived from the audit’s remaining time; a page that does not finish loading inside it is an ERROR (500).
  3. Blocked or unloadable page — an HTTP 403, 429 or Cloudflare challenge on the document is the platform’s blocked response (590). Any other Lighthouse runtime error (NO_FCP, PAGE_HUNG, DNS_FAILURE, ERRORED_DOCUMENT_REQUEST, …) is an ERROR (500) that names the error.
  4. Score — the Best Practices score (0–100) is compared with the thresholds: below failBelowScore is FAIL (400), from failBelowScore up to but excluding warningBelowScore is WARNING (300). A category Lighthouse could not score is an ERROR (501). At or above warningBelowScore the audit succeeds (200).
  5. Audits — every audit Lighthouse lists under the Best Practices score becomes a check: a scored audit below Lighthouse’s pass mark (0.9) is a FAIL whose code is 400 plus the audit’s fixed number in this auditor’s catalog (16 audits, 410–431); an audit Lighthouse reports without a score or leaves to a manual check is an INFORMATION with 100 plus that number. An audit a newer Lighthouse adds gets 490 or 190 until the catalog is updated. Hidden Lighthouse audits and audits that do not apply to the page are not reported. These checks keep their own status but never change the result: the score alone decides it.
  6. Report pin — every result carries an INFORMATION check (100) with the Lighthouse and Chrome versions, the device profile, the run duration and Lighthouse’s benchmark index, because scores are only comparable between runs of the same Lighthouse version.
The Lighthouse navigation is not signed with Web Bot Auth: Lighthouse opens its own browser target and its only header hook adds headers to every request of the page, which breaks cross-origin fetches. Allowlist the 37AuditsBot user agent if the site challenges unsigned bots. With Basic auth the Authorization header is sent on every request the page makes, third-party origins included, so prefer allowlisting over credentials for a staging site that loads third-party scripts.

​
Preferences

An invalid value (missing, fractional, outside 0–100) makes the auditor fall back to that preference’s default and log a warning. A fail threshold equal to or above the warning threshold is not an invalid value: it makes the audit fail (401) until the thresholds are fixed.

​
What it audits

Every row maps to one checkRule* method and one CheckCode. The score check carries in data: category, score, formFactor, both thresholds, failingAudits (up to ten audits of the category below Lighthouse’s pass mark, lowest score first, each with id, title, score, displayValue), lighthouseVersion, chromeVersion, benchmarkIndex, elapsedSeconds and runWarnings. Each audit check (1NN, 4NN) adds auditId, auditTitle, auditScore (0–100 or null), scoreDisplayMode, displayValue, weight, group, numericValue, numericUnit, learnMore (Lighthouse’s documentation link), inCatalog, itemCount and items (up to ten rows of Lighthouse’s details table: DOM nodes reduced to selector, snippet, label and explanation; source locations to url:line:column).

​
Output documentation

​
Risks and considerations

​
A score is not a certification

Lighthouse automates the Best Practices checks a machine can run on one page load (HTTPS, front-end libraries with known vulnerabilities, browser console errors, deprecated APIs, third-party cookies, image aspect ratios and resolution, source maps and the document’s doctype and charset). A perfect score means no automated check failed, not that the page is flawless; manual review still finds problems automation cannot.

​
Desktop and mobile differ

The two device profiles render the page at different sizes, so the audits that depend on layout can give different results. Pick the profile that matches the audience and keep it, because the scores of the two profiles are not strictly comparable.

​
The run is unsigned

The Lighthouse navigation carries the 37AuditsBot user agent but no Web Bot Auth signature. A site that only admits signed bots answers with a challenge, which this audit reports as blocked (590).

​
The score alone decides the result

Lighthouse weighs its audits into the score, so a page can score 90 with one audit failing. The result follows the score, as Lighthouse’s gauge does: that page is a SUCCESS. The failing audit is still listed as a FAIL check, because the item is what the owner has to fix, but it never changes the status of the result. The check order follows Lighthouse’s report: heavier audits first, then the lowest scores.

​
Codes are fixed per audit

Each audit keeps its number across Lighthouse upgrades, so a deep link to a code stays valid. An audit a newer Lighthouse adds is reported with 490 (failing) or 190 (informative or manual) and inCatalog: false in its data until the catalog in this auditor is extended; an audit Lighthouse removes keeps its number unused.