Mobile-Friendly Checker — Multi-Signal Audit, Not Just the Viewport Tag

A real mobile-friendliness audit checks more than one meta tag. This actor reads every static signal: the viewport meta (fully parsed into props), responsive evidence (@media queries inline AND in linked stylesheets, responsive <link media>, srcset/<picture>), fixed pixel widths ≥1000px, sub-12px font sizes, legacy tech (Flash/applets), touch icons, and user-scalable=no accessibility traps — then combines them into a weighted 0-100 score and a verdict with named issues. Up to 50 URLs per run, online, by API, or as an agent tool via Apify MCP.

Since Google retired its public Mobile-Friendly Test tool, batch-checking this by API got harder — this is the fetchable replacement for the static-signal portion.

What you get

• mobileFriendly — the verdict (requires viewport + device-width + responsive evidence + no Flash + score ≥60)
• score — weighted 0-100 across all signals
• details — every signal separately: hasDeviceWidth, viewportContent + viewportProps (fully parsed key/values), hasFixedWidth, hasTinyFont, hasFlash, hasTouchIcon
• issues — each problem in plain English ("Fixed pixel widths ≥1000px detected (e.g. 1120px)...")
• Fail-soft: an unreachable URL or HTTP error never fails the run — {ok: false, error}, never charged.

Input

{ "urls": ["https://yoursite.com/", "https://yoursite.com/pricing"], "maxUrls": 50 }

Or a single URL via url.

Output (real run)

{
  "url": "https://www.wikipedia.org/",
  "ok": true,
  "mobileFriendly": false,
  "score": 68,
  "hasViewport": true,
  "hasResponsiveHints": true,
  "details": {
    "hasDeviceWidth": false,
    "viewportContent": "initial-scale=1,user-scalable=yes",
    "viewportProps": { "initial-scale": "1", "user-scalable": "yes" },
    "hasFixedWidth": true,
    "hasTinyFont": false,
    "hasFlash": false,
    "hasTouchIcon": true
  },
  "issues": ["Viewport meta has no width=device-width.", "Fixed pixel widths ≥1000px detected..."]
}

That record is real and instructive: wikipedia.org's portal page ships a viewport meta without width=device-width — a one-signal checker that only asks "is there a viewport tag?" calls it friendly; the multi-signal audit catches why it isn't fully.

Pricing

$0.002 per page checked — all signals including linked-CSS inspection. No start fee. Unreachable pages are never charged (this was a measured billing defect in the previous build — fixed).

Measured against store incumbents (2026-08-07): dev00/bing-mobile-Friendliness-checker charges $0.002 per audit (Bing-API-dependent), artifact-machine/mobile-ux-auditor $2 per item.

Honest limits

• Static-signal analysis: no headless browser, so no actual rendering, tap-target geometry measurement, or JS-injected style detection. The signals checked are the ones that decide most real-world verdicts; a rendering-based audit (Lighthouse) is the complement, not the substitute, at ~100x the compute.
• Linked-CSS media-query checking fetches up to a few stylesheets, only when nothing responsive was found inline — best-effort by design.
• score weights are ours (documented by the issue list); treat trends and failures as the signal, not single-point decimals.

FAQ

Is this a replacement for Google's Mobile-Friendly Test? For the static-signal portion, yes — and it batches by API, which Google's tool never did publicly. For full rendering audits, run Lighthouse on the pages this flags.

What does viewportProps give me? The viewport content string fully parsed (width, initial-scale, user-scalable, viewport-fit...) so your pipeline can assert exact values instead of regexing the string.

Why flag user-scalable=no? It blocks pinch-zoom — an accessibility failure (WCAG 1.4.4) that also costs score in real audits.

Can I gate deploys on it? Yes — run your key pages and fail CI when mobileFriendly is false or score drops below your threshold.

Why did some rows come back ok: false? DNS/timeout failures or HTTP errors — nothing was analyzed. Recorded, never charged.

Use from code or AI agents

curl -s "https://api.apify.com/v2/acts/EliAI~webpage-mobile-friendly-checker/run-sync-get-dataset-items?token=$APIFY_TOKEN" \
  -X POST -H 'Content-Type: application/json' \
  -d '{"urls": ["https://yoursite.com/", "https://yoursite.com/landing"]}'

Agents: connect Apify MCP and call the EliAI/webpage-mobile-friendly-checker tool.

• Capability: multi-signal static mobile-friendliness audit of one or many URLs with weighted score + parsed viewport props
• Required input: url (string) or urls (array)
• Returns: one record per URL; mobileFriendly + score + issues summarize it
• Bounded: 50 URLs per run; failures isolate per URL
• Side effects: none (page GET + up to a few stylesheet GETs)