auditgate A machine-readable website audit API for AI agents and their operators. Score any URL for speed, SEO, SSL, security headers, crawl hygiene, image hygiene, social-preview tags, internal link health and (deep tier) agent readiness — the accessibility tree an AI agent operates — with a ranked fixes[] list an agent can act on directly. Endpoints: POST /v1/audit run an audit GET /v1/audits/:id retrieve a previously stored result GET /llms.txt machine-readable service description GET /openapi.json OpenAPI 3.1 document (the audit operation carries x-payment-info with the live prices) Request body: { "url": "https://example.com", "tier": "fast" } tier is "fast" (default, static checks only), "deep" (adds mobile PageSpeed Insights performance data and the agent-readiness check), or "free": the fast checks with no payment, 3 per 24 hours per client address and 300 in total, never from a browser page — once spent, the same request gets the fast 402 with a "free" note in the body saying why and when to retry. Category weights (fixed and published, not configurable per-site): speed: 0.15 seo: 0.20 ssl: 0.10 images: 0.15 social: 0.05 security-headers: 0.10 crawl-hygiene: 0.10 link-sanity: 0.05 ai-readiness: 0.10 Every result is scored on this one scale. Whatever a run could not measure (performance and agent readiness on the fast tier, images on a page with none) drops out of "overall", and the remaining weights are renormalized to sum to 1. "coverage" is the share of the scale the result measured (fast: 0.75; full deep: 1.0); "weights" and categories[].weight are the renormalized weights it actually used, exact, so the sum of score x weight x 10 over the measured categories is "overall". Read "coverage" before comparing two scores: a fast audit says nothing about performance or agent readiness, so a slow site can score higher on fast than on deep. The deep tier is the missing 25%, not a different number. In every category, presence checks earn at most 7 of 10; the last 3 need quality evidence (a script-constraining CSP, dated sitemaps, sized images, a resolving og:image, Core Web Vitals). On the deep tier, ai-readiness is Chrome's agent-accessibility check, graded: only 10 equals its pass. "engine" identifies the scoring ladders and the envelope shape; compare two results only when it matches. Payment (x402, protocol v2) POST /v1/audit is paid per call in USDC on Base mainnet. fast tier 0.05 USDC deep tier 0.50 USDC Payments settle to 0x648D083deB3E805AfA676aea1e835d65F25AB6A6 on Base mainnet. Calling without payment returns 402 with the machine-readable requirements in a base64 PAYMENT-REQUIRED header (and the same data in the JSON body, plus a "free" note). No crawl runs behind a 402, so an unpaid call costs nothing on either side; only tier "free" runs work unpaid, within its quota. An x402-capable client handles the retry automatically — for example @x402/fetch wrapped around fetch with an EVM signer. By hand: sign an EIP-3009 authorization for the amount in accepts[0] and retry the same request with the base64 payment payload in a PAYMENT-SIGNATURE header. A paid call returns 200 with a settlement receipt in the PAYMENT-RESPONSE header. Payment is verified before any work starts and settled only once we reached the target and ran the crawl the payment was for. A site we never reached (unreachable, blocked, redirect loop) is never charged. A deep audit is never charged when it comes back with no performance data, whatever the reason (notice: "performance_unavailable"). A page we reached but could not read returns 422; the crawl you paid for ran, so a fast audit is charged for it — a deep one, by the rule above, is not. Paid callers are limited to 300 audits per hour per wallet. curl -i -X POST https:///v1/audit \ -H 'Content-Type: application/json' \ -d '{"url":"https://example.com","tier":"fast"}' -> HTTP/1.1 402 Payment Required PAYMENT-REQUIRED: