Website Audit Monitor: Lighthouse + Accessibility

Lighthouse scores, lab Core Web Vitals, the fixes that matter and a full axe-core accessibility scan for every URL you give it. Name a monitor and schedule it to get a change log of what got worse (or better) since the last run.

For each URL and device (mobile and/or desktop) you get:

• Lighthouse scores: Performance, SEO, Best practices, Accessibility (0-100, same engine as PageSpeed Insights and Chrome DevTools).
• Lab Core Web Vitals: LCP, CLS, TBT, FCP and Speed Index.
• Top fixes: failing audits and performance opportunities ranked by estimated time saved, with KiB savings and a "learn more" link.
• Accessibility violations from axe-core (WCAG 2.2 A/AA plus best practices): rule, impact, number of affected elements, WCAG success criteria, help link and example CSS selectors.
• Monitor mode: score drops and rises beyond your threshold, slower or faster lab metrics, newly failing audits, new or resolved accessibility violations, pages that stopped loading, and redirects that changed.
• An HTML report you can open or send to a client, plus a JSON summary.

Only audit sites you own or have permission to test. The Actor loads each URL once per selected device, like a single visitor would, and never follows links or crawls.

Who it is for

• Agencies and freelancers: put each client's key pages in a named monitor, schedule it weekly, and send the report link. You see the regression before the client does.
• SEO and performance teams: track Lighthouse scores and lab Core Web Vitals for templates (home, category, product, article) after every release.
• Developers: a cheap post-deploy check on staging or production pages, wired to Slack, email or a webhook with Apify integrations.
• Accessibility leads: a recurring axe-core scan with element-level evidence, so new WCAG violations are caught when they ship.

What you get

Output	Where	What is in it
Audit results	Default dataset (one row per URL × device)	performanceScore, accessibilityScore, bestPracticesScore, seoScore, lcpMs, cls, tbtMs, fcpMs, speedIndexMs, topIssues, opportunities, failedAudits, axeViolations, axeByImpact, changes, changeSummary, finalUrl, warnings, benchmarkIndex, versions and timing
Dataset views	Output tab	Scores and Core Web Vitals, Monitor changes, Accessibility (axe-core) tables
HTML report	Key-value store REPORT.html	Summary table with colored scores, change log, per-URL opportunities, failing audits and axe violations. Light and dark mode, readable on phones
Run summary	Key-value store SUMMARY.json	Counts, settings, change log and compact results, handy for integrations
Full Lighthouse reports (optional)	Key-value store LIGHTHOUSE-<device>-<hash>.html	Lighthouse's own HTML report per audit, linked from the row (saveLighthouseReports)

Failed and skipped URLs are rows too (status: "failed" or "skipped", with an errorCode), so you always see what happened to every input. They are never charged.

How to use it

1. Paste your page URLs into URLs to audit, one per line.
2. Pick Devices (mobile is the default, like PageSpeed Insights) and, if you want, fewer Lighthouse categories.
3. Click Start. One URL on one device takes roughly 10-30 seconds depending on the page.
4. Open the Output tab for the tables and the HTML report, or export the dataset as JSON, CSV or Excel.

Monitor mode (scheduled change tracking)

1. Enter a Monitor name, for example client-acme.
2. Run once: every URL is saved as the baseline in a named key-value store website-audit-monitor-client-acme in your account.
3. Create a schedule (daily or weekly) with the same input. Every run compares each URL and device with its previous result and fills changes, changeSummary, regressionCount and improvementCount.
4. Connect the dataset to Slack, email, Google Sheets, Make or Zapier, or filter on regressionCount > 0.

What counts as a change (defaults, all adjustable):

Change	Rule
Performance score	moves by 10+ points (performanceChangeThreshold); lab performance scores vary a few points between identical runs
Accessibility, SEO, Best practices score	moves by 5+ points (scoreChangeThreshold); these scores are stable, so a change usually means the page changed
Lab metric (LCP, FCP, Speed Index, TBT, CLS)	changes by 25%+ (metricChangeThresholdPct) and at least LCP/SI 500 ms, FCP 300 ms, TBT 200 ms, CLS 0.05
Newly failing / fixed Lighthouse audit	any SEO, accessibility or best-practices audit; performance audits only when worth 200+ ms of estimated savings (smaller performance insights flip between runs)
New / resolved accessibility violation	an axe-core rule that starts or stops failing
Audit failed / recovered	the page could not be audited (HTTP error, DNS, timeout...) after it worked before, or works again
Final URL changed	the page now redirects somewhere else

If an audit fails, the last good result is kept, so the next successful run is compared with it.

Input example

{
  "urls": [
    "https://www.example.com/",
    "https://www.example.com/pricing",
    "https://www.example.com/blog/launch"
  ],
  "formFactors": ["mobile", "desktop"],
  "categories": ["performance", "seo", "best-practices", "accessibility"],
  "monitorName": "example-weekly",
  "axeStandard": "wcag22aa",
  "axeBestPractices": true
}

Field	Default	Notes
urls	required	http(s) page URLs; https:// is added when missing; duplicates and #fragments removed; up to 500 per run
formFactors	["mobile"]	mobile (Lighthouse mobile emulation: moto g power, simulated slow 4G, 4x CPU slowdown) and/or desktop (Lighthouse desktop preset). Each device is a separate audit
categories	all four	performance, seo, best-practices, accessibility
monitorName	none	Turns on change tracking. Letters, digits and hyphens
performanceChangeThreshold	10	Points
scoreChangeThreshold	5	Points, for accessibility, SEO and best practices
metricChangeThresholdPct	25	Percent, plus the absolute floors above
axeScan	true	Runs axe-core on the page Lighthouse already loaded (no second page load)
axeStandard	wcag22aa	wcag22aa, wcag21aa, wcag2aa or wcag2a
axeBestPractices	true	Adds axe best-practice rules, flagged bestPractice: true
maxIssuesPerUrl	10	Failing audits and opportunities listed per row
maxAxeExamples	3	Example selectors per axe rule
saveHtmlReport	true	REPORT.html
saveLighthouseReports	false	Full Lighthouse HTML report per audit
maxConcurrency	1	Up to 4 parallel audits. Parallel audits compete for CPU and lower performance scores; each needs about 2 GB of memory
perUrlTimeoutSecs	90	Per attempt
maxRetries	1	For temporary failures only (timeouts, connection errors, HTTP 5xx/429, browser crashes)

Output example (one row, shortened)

Real result from a test run on 2026-10-23 against W3C's deliberately inaccessible demo page:

{
  "url": "https://www.w3.org/WAI/demos/bad/before/home.html",
  "formFactor": "mobile",
  "status": "ok",
  "performanceScore": 98,
  "accessibilityScore": 50,
  "bestPracticesScore": 88,
  "seoScore": 75,
  "lcpMs": 1384,
  "cls": 0,
  "tbtMs": 152,
  "fcpMs": 787,
  "speedIndexMs": 823,
  "axeViolationCount": 8,
  "axeViolationNodes": 69,
  "axeByImpact": { "critical": 2, "serious": 4, "moderate": 2, "minor": 0 },
  "topIssues": [
    "Improve image delivery (est. 300 ms saved)",
    "Image elements do not have [alt] attributes",
    "Select elements do not have associated label elements."
  ],
  "opportunities": [
    { "id": "image-delivery-insight", "title": "Improve image delivery", "estSavingsMs": 300, "estSavingsKiB": 54.6, "metricSavings": { "LCP": 300 } }
  ],
  "axeViolations": [
    {
      "rule": "image-alt", "impact": "critical", "count": 33,
      "help": "Images must have alternative text", "wcag": ["1.1.1"], "level": "WCAG 2.0 A",
      "helpUrl": "https://dequeuniversity.com/rules/axe/4.14/image-alt?application=axeAPI",
      "selectors": ["img[src$=\"border_left_top.gif\"]", "img[src$=\"border_top.gif\"]", "img[src$=\"border_right_top.gif\"]"]
    }
  ]
}

In monitor mode the row also has (illustrative values):

{
  "monitorStatus": "compared",
  "previousAuditAt": "2026-10-22T06:00:12.000Z",
  "regressionCount": 2,
  "improvementCount": 0,
  "changeSummary": "2 regressions: Accessibility score 91 → 78 (-13); New accessibility violation: image-alt (critical, 3 elements): Images must have alternative text",
  "changes": [
    { "type": "score-drop", "severity": "regression", "category": "accessibility", "previous": 91, "current": 78, "delta": -13 },
    { "type": "new-axe-violation", "severity": "regression", "rule": "image-alt", "impact": "critical", "count": 3 }
  ]
}

Lab data, not field data: what the numbers mean

Lighthouse measures one page load in a controlled lab setup. Mobile audits use Lighthouse's default simulated throttling (slow 4G network and a 4x slower CPU), the same method PageSpeed Insights uses for its lab section.

• It is not field data. The "real user" Core Web Vitals in PageSpeed Insights and Google Search Console come from the Chrome UX Report (CrUX): 28 days of visits from real Chrome users. This Actor does not read CrUX. Lab and field numbers often differ, and Google ranking signals use field data.
• INP cannot be measured in a lab page load. Total Blocking Time (TBT) is the lab metric that best tracks responsiveness.
• Scores vary between runs. Network conditions, server response times, ads and third-party scripts change from load to load. Performance usually moves by a few points between identical runs; accessibility, SEO and best-practices scores are stable. The monitor thresholds are set with this in mind.
• Scores can differ from PageSpeed Insights because the audit runs on different hardware in a different location. Each row includes benchmarkIndex (Lighthouse's CPU benchmark of the machine) so you can compare like with like. For the most stable performance scores keep Parallel audits at 1.

Accessibility: what axe-core does and does not tell you

axe-core is the open-source rules engine behind many accessibility tools (and behind Lighthouse's own accessibility score). It reports issues it can detect with certainty, such as missing alt text, missing form labels, low contrast, missing document language and invalid ARIA.

• Automated rules cover only part of WCAG. A page with zero violations is not automatically accessible or "compliant": keyboard use, meaningful alt text, focus order and screen reader behavior still need a human review.
• The scan runs on the page as loaded, at the selected device's screen size. Content behind clicks, logins, cookie banners or menus that are closed is not tested.
• Cross-origin iframes (maps, video players, chat widgets) are tested only when the browser allows it.

Pricing

Pay per event: you pay only for audits that produce a result.

Event	Price
URL audited (one URL on one device: Lighthouse + axe-core + monitor comparison + report)	$0.015
Actor start	Apify's standard synthetic start event

Free: failed or unreachable URLs, invalid inputs, URLs skipped because of your spending limit, the HTML report, the summary and the change log.

Examples: 10 pages on mobile = $0.15. 10 pages on mobile and desktop = $0.30. A weekly monitor of 25 pages on mobile = about $1.60 a month.

The Actor respects the maximum cost per run you set: it never starts an audit your limit cannot pay for, stops cleanly, and lists the remaining URLs as skipped (CHARGE_LIMIT_REACHED).

Error codes

errorCode	Meaning	Retried?
INVALID_URL	Not a valid public http(s) URL (also local/private addresses)	no
DNS_FAILURE	Domain could not be resolved	no
CONNECTION_FAILED	Connection refused, reset or timed out	once
HTTP_ERROR	Server answered 4xx/5xx (httpStatus has the code)	5xx and 429 once
TLS_ERROR	Invalid HTTPS certificate or browser interstitial	no
NOT_HTML	The URL is a PDF, image, JSON or other non-HTML file	no
NO_CONTENT	The page never painted anything	once
PAGE_TIMEOUT	No result within the per-URL timeout	once
BROWSER_ERROR	The browser crashed or ran out of memory	once
AUDIT_ERROR	Lighthouse failed for another reason (see errorMessage)	once
CHARGE_LIMIT_REACHED, RUN_TIME_LIMIT, ABORTED	Not audited (status skipped)	-

A run where every URL fails ends with a failed status (nothing is charged), so schedules and alerts notice when a site is down.

Limits

• Public pages only. No logins, cookies, form filling or clicking. Local and private network addresses are refused.
• One page load per URL and device. Lighthouse's back/forward-cache test is skipped because it needs a second navigation. Lighthouse also fetches /robots.txt for the SEO category.
• Memory: 4 GB is the default and recommended for one audit at a time; 2 GB is the minimum. Each extra parallel audit needs about 2 GB more (the Actor lowers parallelism automatically when memory is too small).
• Up to 500 URLs per run. Split bigger lists into several runs or schedules.
• The axe-core scan reports violations only (not "needs review" items); axeIncompleteCount tells you how many rules need a manual check.

FAQ

Is this the same as PageSpeed Insights? It runs the same open-source Lighthouse engine with the same default mobile settings, but on Apify's machines and without Google's API, quotas or API key. PageSpeed Insights also shows CrUX field data, which this Actor does not.

Why did my performance score change when I didn't deploy anything? Lab measurements vary (server response time, third-party scripts, ads). That is why the monitor uses a 10-point performance threshold and minimum metric changes. Raise the thresholds for very busy pages.

Why does robots.txt is not valid sometimes appear and disappear? Lighthouse fetches /robots.txt on every audit. If the server rate-limits or returns an error page for that request, the SEO audit fails for that run. The monitor reports it, and reports the recovery next time.

Can I audit pages behind a login or on localhost? No. The Actor audits public URLs from Apify's cloud.

Will this get me "ADA compliant"? No tool can certify that. Use the axe-core results to find and fix detectable issues, and pair them with a manual review.

Is it polite to the sites I audit? Each URL is loaded once per device, audits run one at a time by default, and nothing is crawled. Only audit sites you own or have permission to test.

How do I get alerts? Schedule the Actor with a monitor name and add an integration (Slack, email, webhook) on the dataset or run. Filter on regressionCount > 0 or monitorStatus = "failed".

Where is the monitor history stored? In a named key-value store in your own Apify account (website-audit-monitor-<name>), one small record per URL and device. Delete the store to reset the baseline.

Changelog

See CHANGELOG.md.