Lighthouse & WCAG Audit: Core Web Vitals, SEO, Monitoring avatar

Lighthouse & WCAG Audit: Core Web Vitals, SEO, Monitoring

Pricing

from $16.00 / 1,000 page auditeds

Go to Apify Store
Lighthouse & WCAG Audit: Core Web Vitals, SEO, Monitoring

Lighthouse & WCAG Audit: Core Web Vitals, SEO, Monitoring

Bulk Lighthouse audits (the engine behind PageSpeed Insights): performance, Core Web Vitals, SEO and best-practice scores, plus accessibility failures mapped to WCAG and EN 301 549. Optional scheduled regression monitoring.

Pricing

from $16.00 / 1,000 page auditeds

Rating

0.0

(0)

Developer

Trophy Apps

Trophy Apps

Maintained by Community

Actor stats

0

Bookmarked

2

Total users

1

Monthly active users

21 hours ago

Last modified

Share

What does this audit Actor do?

It runs Google Lighthouse audits on a list of pages in one run (Lighthouse is the open-source engine behind PageSpeed Insights), and adds accessibility findings mapped to WCAG and EN 301 549. For each URL you get:

  • Lighthouse scores (0–100) for performance, accessibility, best practices and SEO, on mobile or desktop.
  • Core Web Vitals lab metrics: LCP, FCP, TBT, CLS and Speed Index.
  • Failing checks, ordered by impact, with estimated time savings for performance items.
  • Accessibility failures mapped to standards:
    • the WCAG 2.x success criteria (e.g. 1.4.3 contrast) and conformance level;
    • the matching EN 301 549 clauses, the standard referenced by the European Accessibility Act;
    • up to three offending HTML snippets per issue, plus a link to remediation guidance.
  • A run summary (key-value store record SUMMARY): average scores, the issues that recur across the most pages, and any regressions.

Typical uses: checking a whole site or a set of landing pages at once, tracking performance and accessibility over time, and catching regressions after a release.

Why run it on Apify?

  • Schedule it (e.g. weekly) with the monitoring mode below and get regressions only.
  • Call it through the Apify API, or from AI agents through Apify's MCP server.
  • Send results to webhooks and integrations, and export them as JSON, CSV or Excel.

How to use it

  1. Paste the URLs to audit. Duplicates are removed.
  2. Choose the device: mobile (default; throttled like Lighthouse's mobile profile) or desktop.
  3. Optionally set a Monitor name to compare each run with the previous one.
  4. Run the Actor and open the Output tab, or read the dataset and the SUMMARY record through the API.

Monitoring on a schedule

Set Monitor name and run the Actor on an Apify schedule. Each page's result then includes a changes block comparing it with the previous run of the same monitor:

  • score deltas per category;
  • new and resolved issues;
  • a regression flag when a score drops by at least the threshold (default 5 points; doubled for performance, because lab scores vary between runs), or when any new accessibility failure appears.

The SUMMARY record lists every regressed page, so a webhook can alert you only when something gets worse.

Input example

{ "urls": ["https://example.com", "https://example.com/pricing"], "device": "mobile", "monitorName": "my-site" }

How much does it cost?

You pay per successfully audited page (see the Pricing tab for current prices).

You're never charged for pages that:

  • return an HTTP error;
  • can't be loaded;
  • show a bot check instead of their content.

These are reported as error rows instead of being scored. A run stops when it reaches the maximum charge you set.

Limits — please read

  • Automated tools detect only part of accessibility problems. A score of 100 doesn't prove WCAG or EN 301 549 conformance, and this Actor isn't a legal compliance certificate.
  • Lab metrics come from a single load in a cloud container. They vary between runs and differ from real-user (field) data.
  • Some sites block cloud servers. Those pages come back as free error rows.
  • Each page is loaded once, like a normal visit. Only audit sites you're entitled to test.
  • Only public http(s) hosts are audited. Private, loopback and internal addresses are refused, and results that end on a non-public host after a redirect aren't reported. Query strings are kept in the output (they can change the page) but removed from logs.