# Website Health Check: Lighthouse, SEO, Tech Stack (`quarrywise/website-health-check-lighthouse-seo`) Actor

Audit any website: SEO findings ranked by impact with plain-English fixes, tech stack detection with evidence, redirects and status, and optional Lighthouse lab scores (median of several runs) with the cost of each third-party script. Compare runs to catch regressions.

- **URL**: https://apify.com/quarrywise/website-health-check-lighthouse-seo.md
- **Developed by:** [Quarrywise](https://apify.com/quarrywise) (community)
- **Categories:** SEO tools, Developer tools, E-commerce
- **Stats:** 2 total users, 1 monthly users, 100.0% runs succeeded, 0 bookmarks
- **User rating**: No ratings yet

## Pricing

from $8.00 / 1,000 page checkeds

This Actor is paid per event. You are not charged for the Apify platform usage, but only a fixed price for specific events.

Learn more: https://docs.apify.com/actors/running/actors-in-store.md#pay-per-event

## What's an Apify Actor?

An Actor is a serverless cloud program that runs on the Apify platform. It has two run modes.
In Batch mode, an Actor accepts a well-defined JSON input, performs an action which can take anything from a few seconds to a few hours,
and optionally produces a well-defined JSON output, datasets with results, or files in key-value store.
In Standby mode, an Actor provides a web server which can be used as a website, API, or an MCP server.

Apify vocabulary and the platform model are defined once, in the agent quickstart at https://apify.com/agents.md.

## How to integrate an Actor?

If asked about integration, you help developers integrate Actors into their projects.
You adapt to their stack and deliver integrations that are safe, well-documented, and production-ready.

Do not guess an integration path. Every one of them is in the agent quickstart at https://apify.com/agents.md: the Apify MCP server, Agent Skills with the Apify CLI, the JavaScript and Python clients, the REST API, and the account-free path for an agent with no human to sign in. It also carries the rule on stating cost before the first paid run.

For examples already wired to this Actor's own input schema, see the [API](#api) section below.

Each client library has reference documentation the quickstart does not restate: [JavaScript/TypeScript](https://docs.apify.com/api/client/js/docs.md) (`npm install apify-client`) and [Python](https://docs.apify.com/api/client/python/docs.md) (`pip install apify-client`).

# README

## 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):

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

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

```json
{
    "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):

```json
{
    "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.

# Changelog

This Actor's version history is a separate document: https://apify.com/quarrywise/website-health-check-lighthouse-seo/changelog.md

# Actor input Schema

## `urls` (type: `array`):

One address per line: a page (https://example.com/shop) or a site (example.com). https:// is added when missing. Up to 200 addresses per run; pages on the same site are checked one after another at a polite pace.

## `mode` (type: `string`):

Quick reads the HTML and headers only (no browser): SEO findings, technologies, redirects and status. Full also runs Lighthouse in headless Chrome on the first pages of each site (see the Lighthouse settings) and adds lab scores, Core Web Vitals lab metrics and the cost of each third-party script. Full mode needs 2 GB of memory.

## `maxPagesPerSite` (type: `integer`):

1 checks only the addresses you list. A higher number also checks pages from the site's sitemap (found through robots.txt or /sitemap.xml) until this many pages per site are checked.

## `lighthouseDevices` (type: `array`):

Full mode: run Lighthouse as a mid-range phone on a slow 4G connection (mobile; Google indexes the mobile version of pages, but these are lab results, not the real-visitor data Google uses), as a desktop, or both. Each device is a separate lab run.

## `lighthouseRuns` (type: `integer`):

Full mode: lab scores vary from run to run. With 3 or 5 runs you get the median plus the lowest and highest value, which is what you need to compare before and after a change. 1 is cheapest.

## `lighthouseMaxPagesPerSite` (type: `integer`):

Full mode: Lighthouse runs on this many pages per site (the addresses you list first, then sitemap pages). The other pages get the quick checks only. At most 30 Lighthouse page loads per site per run (pages x devices x runs), spaced at least 5 seconds apart.

## `budgets` (type: `object`):

Optional limits; each page row gets budget_status pass or fail with the failures listed. 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 lab median per device. Example: {"performance": 70, "lcp_ms": 2500, "cls": 0.1, "seo_score": 80}

## `watchId` (type: `string`):

Optional name for this set of pages (letters, digits, '.', '\_' or '-'), for example shop-weekly. Each run with the same watch ID is compared with the previous one: score and lab metric changes (flagged when beyond normal lab variation), new and resolved findings, technologies added or removed. Use it for scheduled monitoring and for before and after checks of a speed app or theme change.

## `includeMarkdown` (type: `boolean`):

Adds report_markdown to each page row: the findings, fixes and lab table as Markdown, handy for AI agents and tickets. The full report for the run is always in the REPORT record.

## Actor input object example

```json
{
  "urls": [
    "https://quarrywise.com/"
  ],
  "mode": "full",
  "maxPagesPerSite": 3,
  "lighthouseDevices": [
    "mobile"
  ],
  "lighthouseRuns": 1,
  "lighthouseMaxPagesPerSite": 1,
  "includeMarkdown": false
}
```

# Actor output Schema

## `results` (type: `string`):

One row per checked page: status and redirects, SEO check score, findings ranked by impact with fixes, technologies, third-party code and, in full mode, Lighthouse lab results. Rows with error set are free error rows.

## `summary` (type: `string`):

Run status, counts, charged events and warnings, plus one summary per site (robots.txt, sitemap, average scores, lab medians, most common findings, technologies, third parties, changes). The OUTPUT record.

## `report` (type: `string`):

The whole run as Markdown: site overviews, then each page with its findings, fixes and lab table (the REPORT record).

# API

You can run this Actor programmatically using our API. Below are code examples in JavaScript, Python, and CLI, as well as the OpenAPI specification and MCP server setup.

## JavaScript example

```javascript
import { ApifyClient } from 'apify-client';

// Initialize the ApifyClient with your Apify API token
// Replace the '<YOUR_API_TOKEN>' with your token
const client = new ApifyClient({
    token: '<YOUR_API_TOKEN>',
});

// Prepare Actor input
const input = {
    "urls": [
        "https://quarrywise.com/"
    ],
    "mode": "full",
    "maxPagesPerSite": 3,
    "lighthouseDevices": [
        "mobile"
    ],
    "lighthouseRuns": 1,
    "lighthouseMaxPagesPerSite": 1
};

// Run the Actor and wait for it to finish
const run = await client.actor("quarrywise/website-health-check-lighthouse-seo").call(input);

// Fetch and print Actor results from the run's dataset (if any)
console.log('Results from dataset');
console.log(`💾 Check your data here: https://console.apify.com/storage/datasets/${run.defaultDatasetId}`);
const { items } = await client.dataset(run.defaultDatasetId).listItems();
items.forEach((item) => {
    console.dir(item);
});

// 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/js/docs

```

## Python example

```python
from apify_client import ApifyClient

# Initialize the ApifyClient with your Apify API token
# Replace '<YOUR_API_TOKEN>' with your token.
client = ApifyClient("<YOUR_API_TOKEN>")

# Prepare the Actor input
run_input = {
    "urls": ["https://quarrywise.com/"],
    "mode": "full",
    "maxPagesPerSite": 3,
    "lighthouseDevices": ["mobile"],
    "lighthouseRuns": 1,
    "lighthouseMaxPagesPerSite": 1,
}

# Run the Actor and wait for it to finish
run = client.actor("quarrywise/website-health-check-lighthouse-seo").call(run_input=run_input)

# Fetch and print Actor results from the run's dataset (if there are any)
print(f"💾 Check your data here: https://console.apify.com/storage/datasets/{run.default_dataset_id}")
for item in client.dataset(run.default_dataset_id).iterate_items():
    print(item)

# 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/python/docs/quick-start

```

## CLI example

```bash
echo '{
  "urls": [
    "https://quarrywise.com/"
  ],
  "mode": "full",
  "maxPagesPerSite": 3,
  "lighthouseDevices": [
    "mobile"
  ],
  "lighthouseRuns": 1,
  "lighthouseMaxPagesPerSite": 1
}' |
apify call quarrywise/website-health-check-lighthouse-seo --silent --output-dataset

```

## MCP server setup

```json
{
    "mcpServers": {
        "apify": {
            "type": "http",
            "url": "https://mcp.apify.com/?tools=fetch-actor-details,quarrywise/website-health-check-lighthouse-seo"
        }
    }
}
```

The hosted server signs you in with OAuth on first connect, so no API token belongs in this config. Clients without OAuth support can send an `Authorization: Bearer <APIFY_API_TOKEN>` header instead, using a token from API & Integrations in Apify Console (https://console.apify.com/settings/integrations).

## OpenAPI specification

Download the OpenAPI definition: https://api.apify.com/v2/actors/J21xhi9Z1lGIA4kMD/builds/47ANTTi6CyPvJGwfT/openapi.json