Website Health Check: Lighthouse, SEO, Tech Stack

Check any website in one run: SEO findings ranked by impact with a plain-English fix for each, the technologies it runs on with the evidence for every detection, redirects and status codes, and (in full mode) Lighthouse lab scores taken as the median of several runs, with the cost of every third-party script. Read-only: it never logs in, never edits anything and needs no access to the site.

Built for agencies and developers who audit many client sites, for store owners who want a second opinion on a speed or SEO app, and for AI agents that need structured, explainable findings. You pay per page checked and per Lighthouse run; pages that cannot be checked are free.

What you get for every page

• SEO findings with fixes. 48 checks on the page source and headers (plus 9 on the lab results and 5 site-wide): indexing blockers (noindex, robots.txt, canonical problems, redirect chains), titles and descriptions, headings, image alt text, mobile viewport, Open Graph, structured data (JSON-LD), hreflang, mixed content and more. Each finding has a severity, the evidence we saw, a fix written for the site owner and an "ask your developer" version, and an impact score; findings are ranked by impact.
• Tech stack with evidence. About 300 technologies from our own fingerprint set: Shopify, Wix, WordPress, WooCommerce, Webflow and other CMSs and builders, frameworks, analytics and tag managers, CDNs and hosting, payments, chat widgets, consent tools, review apps and more. Each detection lists its confidence (0 to 100), version where visible, and what matched.
• Status and redirects. The final URL, HTTP status, every redirect hop and the server response time.
• Third-party code, per vendor. Which vendors' scripts the page loads. In full mode also the bytes and main-thread time each vendor costs in the lab run, and scripts that failed to load.
• Likely leftovers. Scripts that fail to load (typical for apps that were uninstalled but left code in the theme), tags for services that were shut down (Universal Analytics, Google Optimize, AddThis), scripts from compromised sources (polyfill.io) and scripts included twice.
• Scripts your own security policy blocks. A script that the site's Content-Security-Policy does not allow never runs: it is reported as blocked by your Content-Security-Policy (with the rule that blocks it), never as a leftover. A common cause is a CDN feature that adds a script at its edge, such as Cloudflare Web Analytics with automatic setup.
• Lighthouse lab data (full mode). Performance, accessibility, best practices and SEO scores, Largest Contentful Paint, Total Blocking Time, Cumulative Layout Shift and more, for mobile, desktop or both, as the median of 1 to 5 runs with the lowest and highest value.
• Budgets. Set limits such as performance 70 or LCP 2500 ms and get pass or fail per page.
• Change detection. Give runs a watch ID and each run reports what changed since the last one.

A site summary for each site (robots.txt and sitemap facts, which AI crawlers are blocked, average scores, the most common findings, the full tech stack and third-party vendors) goes into the run's OUTPUT record, and the whole run as Markdown into the REPORT record.

Lab data, measured honestly

Every Lighthouse number this Actor returns is lab data: Lighthouse loads the page in headless Chrome on our server, emulating a mid-range phone on a slow 4G connection (or a desktop). It is not data from your real visitors, which can be faster or slower. Lab scores also move from run to run, so:

• choose 3 or 5 runs per device and you get the median plus the lowest and highest value;
• each lab result carries data_type: "lab", the number of runs, the Lighthouse and Chrome versions, and the row carries a lab_note that says what lab data means;
• when you compare runs with a watch ID, a change only counts when it is larger than the normal run-to-run variation (at least 5 performance points, or the spread you measured, whichever is larger), and smaller moves are reported as "within normal lab variation". A lab finding such as "LCP needs work" only counts as new or resolved when its metric moved beyond that variation, and lab results are only compared when both runs completed a lab test for that device.

Which script slows the site down

In full mode the third_parties list on each row shows, per vendor, how many scripts it loads, how many bytes it transferred and how many milliseconds of main-thread time its code took in the lab run, sorted with the most expensive first. Vendors are named with the open third-party-web dataset that Lighthouse itself uses, plus our own fingerprints. This is the quickest way to answer "which app makes my store slow?" without disabling apps one by one.

Before and after: did the change help?

Run the Actor with a watch ID (for example shop-speed-app) and 3 runs per device, make your change (install or remove a speed app, change the theme), then run it again with the same watch ID. Every row then has changes and a one-line change_summary: score and lab metric changes (flagged when they are beyond normal lab variation), new and resolved findings, and technologies added or removed. Schedule the same input weekly to monitor a site.

How to use it

1. Add your pages or sites, one per line: example.com, https://example.com/shop.
2. Pick Quick (no browser, cheap, fast) or Full (adds Lighthouse).
3. Optionally raise Pages per site to also check pages from the sitemap, set budgets, or add a watch ID. Results are in the dataset (one row per page), OUTPUT and REPORT.

Quick audit of many sites (SEO findings, tech stack, redirects):

{
    "urls": ["example.com", "example.org", "https://example.net/shop"],
    "mode": "quick"
}

Weekly mobile and desktop monitoring of a store's top pages, with budgets:

{
    "urls": ["https://shop.example.com/"],
    "mode": "full",
    "maxPagesPerSite": 10,
    "lighthouseDevices": ["mobile", "desktop"],
    "lighthouseRuns": 3,
    "lighthouseMaxPagesPerSite": 3,
    "budgets": { "performance": 60, "lcp_ms": 3000, "cls": 0.1, "seo_score": 85 },
    "watchId": "shop-weekly"
}

Use it from n8n, Make, Zapier or an AI agent

• n8n: add Apify's verified n8n node (@apify/n8n-nodes-apify; on n8n Cloud the instance owner first enables verified community nodes). Use the operation "Run an Actor and Get Dataset" and select this Actor By URL (enter exactly https://console.apify.com/actors/J21xhi9Z1lGIA4kMD/input) or by ID (J21xhi9Z1lGIA4kMD); the From list picker may not show it while the Actor is hidden from Store search. The Actor's Store page URL does not work in the By URL field. Then paste the same JSON input. For weekly monitoring, put a Schedule Trigger in front, set a watchId and budgets, and send the rows whose budget_status is fail to email or Slack.
• Make: Apify's app: the "Run an Actor" module, then "Get Dataset Items" (the "Watch Actor Runs" trigger fires when a run finishes).
• Zapier: Apify's app: the "Run Actor" action, then "Fetch dataset items" (the "Finished Actor run" trigger fires when a run finishes).
• AI agents (MCP clients): add this Actor as a tool through Apify's MCP server: https://mcp.apify.com?tools=quarrywise/website-health-check-lighthouse-seo The MCP server needs an Apify sign-in or API token.
• API: POST https://api.apify.com/v2/acts/quarrywise~website-health-check-lighthouse-seo/run-sync-get-dataset-items with your Apify token in the Authorization: Bearer header and the input JSON as the body. Full mode (Lighthouse) over several pages can take longer than the 300 seconds this call waits (HTTP 408 after that); start those runs asynchronously and read the dataset when they finish.

Input

Field	What it does	Default
urls	Pages or sites, one per line (up to 200); https:// is added when missing	required
mode	quick (HTML and headers) or full (adds Lighthouse lab runs)	quick
maxPagesPerSite	1 checks only your addresses; higher also checks sitemap pages up to this many per site (up to 500)	1
lighthouseDevices	Full mode: mobile, desktop or both	["mobile"]
lighthouseRuns	Full mode: runs per device and page, 1 to 5 (median and range)	1
lighthouseMaxPagesPerSite	Full mode: pages per site that get Lighthouse (1 to 30); the rest get the quick checks. At most 30 Lighthouse page loads per site per run (pages x devices x runs)	5
budgets	Pass or fail limits, see below	none
watchId	Compare each run with the previous run of the same watch ID	none
includeMarkdown	Add a Markdown report to each row	false

Budgets: minimum scores (0 to 100) performance, accessibility, best_practices, lighthouse_seo, seo_score; maximums lcp_ms, cls, tbt_ms, fcp_ms, total_bytes, third_party_bytes, max_serious_issues (critical plus high findings). Lab budgets compare the median per device and only apply in full mode.

Output fields

One dataset row per page. Missing values are null.

Field	Meaning
url, final_url, site	The page as requested, where it ended up, and its site
status_code, redirect_count, redirect_chain	HTTP status and every redirect hop
response_time_ms, html_bytes	Server response time (from our server, one request) and HTML size
title, meta_description, h1, canonical, lang, word_count	Page facts
seo_score	Quarrywise SEO check score 0 to 100 from the page-source checks
issue_counts, issues	Findings per severity, and every finding: id, category, severity, title, evidence, fix, developer_fix, impact, source
technologies	name, category, confidence, version, evidence
third_parties	Per vendor: hosts, scripts, transfer_bytes and main_thread_ms (lab), failed_requests, blocked_by_csp (scripts the page's own Content-Security-Policy blocks), likely_leftover and the reason
performance_mobile, lcp_mobile_ms, tbt_mobile_ms, cls_mobile (and _desktop)	Lab medians for quick sorting
lab_mobile, lab_desktop, lab_note	Full lab results: every score and metric as median, min and max, opportunities, failed audits, versions
budget_status, budget_failures	pass or fail, and which budgets failed
change_summary, changes	With a watch ID: what changed since the previous run
report_markdown	The page as Markdown, when enabled
mode, checked_at	How and when the page was checked
error, error_detail	Set only on free error rows (for example robots-disallowed, challenge, http-404, network-error)

Example row (full mode, mobile, one run; from a local run of the prefill input on our own site on 2026-10-26, shortened):

{
    "url": "https://quarrywise.com/",
    "final_url": "https://quarrywise.com/",
    "status_code": 200,
    "redirect_count": 0,
    "response_time_ms": 68,
    "title": "Quarrywise: company data from public sources",
    "seo_score": 97,
    "issue_counts": { "critical": 0, "high": 0, "medium": 0, "low": 1, "info": 0 },
    "issues": [
        {
            "id": "open-graph-missing",
            "category": "social",
            "severity": "low",
            "title": "No social sharing preview (Open Graph)",
            "evidence": "no og:title and no og:image meta tags",
            "fix": "When someone shares the page on social media or in chat, it shows without a proper title and image. Add a sharing title and image.",
            "developer_fix": "Ask your developer to add og:title, og:description and og:image meta tags.",
            "impact": 25,
            "source": "html"
        }
    ],
    "technologies": [
        { "name": "Cloudflare", "category": "CDN", "confidence": 100, "version": null, "evidence": ["header server: cloudflare", "header cf-ray", "header cf-cache-status"] }
    ],
    "third_parties": [],
    "performance_mobile": 100,
    "lcp_mobile_ms": 872,
    "tbt_mobile_ms": 0,
    "cls_mobile": 0,
    "lab_mobile": {
        "data_type": "lab",
        "device": "mobile",
        "runs": 1,
        "lighthouse_version": "13.5.0",
        "performance": { "median": 100, "min": 100, "max": 100 },
        "lcp_ms": { "median": 872, "min": 872, "max": 872 }
    },
    "lab_note": "Lab data: scores and metrics come from Lighthouse runs in a simulated device and network on our server, not from your real visitors. Lab results vary between runs; the range shows the spread.",
    "budget_status": null,
    "mode": "full",
    "checked_at": "2026-10-26T00:55:56.401Z",
    "error": null
}

Pricing

Pay per event. You pay only for pages that were checked and Lighthouse runs that completed.

Event	What it is	Price
Page checked	One page row with SEO findings, technologies, redirects and third parties	$0.008
Lighthouse run	One completed Lighthouse lab run (one device, one run)	$0.02

Free: pages that could not be checked (robots.txt refusal, a challenge page, an HTTP error, a network error), failed Lighthouse runs, the site summaries and the Markdown report.

Examples: 1,000 pages in quick mode cost $8. One page with 3 mobile and 3 desktop runs costs $0.128. The prefill (3 pages of our own site, one mobile run) costs about $0.044. The run stops cleanly at the maximum charge you set and says so in OUTPUT (status limit-reached); it never starts a Lighthouse run that the remaining budget cannot pay for.

Good to know

• Read-only and polite. Requests identify themselves as QuarrywiseBot/1.0 (+https://quarrywise.com/bot), are throttled per site (about one request a second for the quick checks) and honour robots.txt, Crawl-delay and text-and-data-mining opt-outs (TDMRep). Only the pages you list (or that the site's sitemap lists, when you raise pages per site), plus the site's own robots.txt and the sitemap files on its own host, are requested. In a Lighthouse run the browser loads the page with all its images, scripts and styles, like a visitor's browser, with QuarrywiseBot added to its user agent. Lighthouse page loads of one site are at least 5 seconds apart (longer when robots.txt sets a Crawl-delay), and a site gets at most 30 of them per run.
• No bot-wall workarounds. When a site answers with a challenge page (Cloudflare, CAPTCHA), 401 or 403, the Actor stops for that site and returns a free error row. Some Shopify and Wix storefronts may do this; there is nothing to configure. A normal page that only contains a CAPTCHA in a form (for example a contact form with reCAPTCHA or Turnstile) is checked as usual.
• Privacy (best effort). The Actor never fills in forms and does not collect contact details. Email addresses and phone numbers in common formats are removed from titles, descriptions, headings, evidence and the Markdown report before saving, and addresses that carry personal data are not checked. Page titles and headings are otherwise returned as published, so on a small business site they can contain the owner's name. Watch state stores hashed page keys, scores and finding ids, not URLs.
• Safe browser. The lab browser reaches the internet only through a local guard that refuses private, loopback and cloud metadata addresses, so a page under test cannot make it reach internal systems.

Limitations

• Lab data is not field data: no Chrome UX Report or real-user metrics.
• Quick mode reads the HTML as served. Text and tags added by JavaScript after load are only seen in full mode (Lighthouse and the run-time script list).
• Technology detection is evidence-based but not exhaustive; a technology without public traces in the page, headers or requests is not found. Confidence below 100 means partial evidence.
• "Likely leftover" is a hint, not proof: a script can also fail because its vendor had an outage during the run. Scripts blocked by the page's own Content-Security-Policy are never counted as leftovers.
• Pages are checked as they are served to our server (Apify's cloud). Some CDNs vary a page by visitor location: for example Cloudflare Web Analytics in "exclude EU visitors" mode adds its script only for visitors outside the EU, so a check from Europe can differ.
• Server response time is measured from our server in one request, not from your visitors.
• Up to 200 addresses and 500 pages per site per run; one Lighthouse run at a time, so large full audits take a while (roughly 10 to 30 seconds per Lighthouse run, plus the spacing between page loads of one site).
• Pages are read up to 2 MB of HTML; larger pages are checked on their first 2 MB and flagged.
• Full mode needs 2 GB of memory (the default in full mode; quick mode defaults to 1 GB); with less than 1.5 GB the Actor runs the quick checks only and says so.
• No keyword, ranking or backlink data, and no automatic fixes.

FAQ

How is this different from PageSpeed Insights? It runs Lighthouse itself (no Google API key), several times if you want, adds an SEO audit with fixes and a tech stack, shows which third-party vendor costs what, works on lists of sites and compares runs over time.

Why does my score differ from PageSpeed Insights? Both are lab tests, on different machines and networks. Compare like with like: the same tool, the same device, several runs.

Can it fix the problems? No. It only reads. Every finding comes with a fix you or your developer can apply.

Does it work for Shopify and Wix stores? Yes, as long as the storefront answers normal requests. Both platforms and many of their apps are detected.

Can AI agents use it? Yes: findings are structured JSON with stable ids, and the REPORT record and report_markdown give the same content as Markdown.

Provider

Provided by Quarrywise, a trade name of Picazzo Research & Development, Zinkstraat 24, Box C4687, 4823 AD Breda, the Netherlands. KvK 42060545, VAT NL005464235B85. Contact: hello@quarrywise.com or the Issues tab.