Browser rendering

A plain HTTP fetch is fast and accurate for server-rendered sites - but sites that build their content with JavaScript (SPAs, client-side frameworks) can look nearly empty to it, which skews every content rule.

Cloud browser rendering fixes that: each page is loaded in a real headless browser in the cloud, and the fully rendered DOM is returned to your local crawler. Everything downstream - parsing, rules, reports - works exactly as it does with plain HTTP, just on the post-JavaScript HTML.

When it runs

Rendering follows your login state and the audit level by default:

• Logged in - audits render in the cloud browser automatically, with no prompt. The level decides which pages: quick renders only the pages that need JavaScript (auto), surface and full render every page (all). The first such run prints a one-line note about what audits cost.
• Logged out or --offline - plain HTTP, no credits.
• Logged in with --http, or rendering turned off in [cloud] - plain HTTP, but the audit is still billed: 50 credits plus 2 per audited page.

Override the default any time:

Flags win over config, and config wins over the auto default. Non-interactive runs (CI, agents, pipes) follow the same rules: they never prompt, and signed in they render by default.

Cost

Rendering costs nothing extra. A signed-in audit costs 50 credits plus 2 per audited page, and a rendered page is one audited page: the same 2 credits as a page fetched over plain HTTP, a page served from the render cache, or a page that fell back to plain HTTP after its render failed. A 100-page audit costs 250 credits in total, rendered or not, so mind your per-audit cap: the default cap of 1000 covers about 475 pages. The crawl progress line shows what the rendered pages have been charged so far (the 50-credit base and the plain-HTTP pages are settled when the audit completes, and appear in the final total):

Crawling (cloud-rendered) 34/100 · ~68 credits

Fallback behavior

Rendering is best-effort and degrades gracefully:

• Single page fails or times out - that page falls back to plain HTTP; the crawl continues rendering the rest.
• Out of credits, auth error, or service outage - the crawler switches permanently to plain HTTP for the remainder of the crawl, prints a one-line warning, and notes the fallback in the report metadata.

A render failure never fails the audit.

When to use it

A quick tell: run squirrel audit normally, and if word counts or headings look implausibly low on pages that render fine in your browser, the site needs rendering.