Browser Rendering

Some sites build their content with JavaScript - single-page apps, client-rendered frameworks, content loaded after the initial response. A plain HTTP fetch sees the empty shell, so content rules report missing headings, thin word counts, and absent meta tags that are actually there.

Browser rendering solves this: pages are loaded in a real headless browser in the cloud, and the audit runs against the fully rendered HTML.

It’s automatic when you’re logged in

squirrel auth login          # once
squirrel audit https://example.com

Once you’re logged in, audits render every page in the cloud by default. The first time this would spend credits, the CLI asks once and remembers your answer - so you opt in knowingly and never get prompted again. The crawl progress shows the running credit spend:

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

Logged-out runs (and --offline) always use plain HTTP and cost nothing.

Turn it off for one run

If a site is server-rendered and you don’t want to spend render credits:

squirrel audit https://example.com --http

--http forces plain HTTP for that run. The opposite, --render, forces rendering even when your config disables it. The two are mutually exclusive.

Make the choice permanent for a project

Pin the behavior in squirrel.toml so it never depends on login state or the prompt:

[cloud]
rendering = "browser"   # always render; use "http" to always skip

Setting rendering explicitly overrides the auto default - no prompt, every audit of this project behaves the same.

Watch your page count

At 2 credits per page, rendering is the most spend-sensitive cloud feature. Two settings to keep in mind:

• --max-pages / [crawler] max_pages - fewer pages, fewer credits.
• [cloud] max_credits_per_audit (default 1000) - the hard cap. It covers rendering for about 500 pages; raise it or cap your pages for larger rendered crawls.

[cloud]
rendering = "browser"
max_credits_per_audit = 400

Do I need it?

Run a normal audit first. If pages you know are full of content come back with implausibly low word counts or missing headings, the site is client-rendered - switch to browser rendering. Server-rendered sites (most CMSs, SSR frameworks, static sites) gain nothing from it.

If rendering fails

You never lose an audit to rendering problems:

• A single page that fails to render falls back to plain HTTP; the rest keep rendering.
• If you run out of credits or the service is down, the whole crawl falls back to plain HTTP with a one-line warning, and the report notes the fallback.

Related

• Cloud rendering explained - service behavior, costs, fallback details
• Credits & Pricing - balance, pricing, spend controls
• Crawler settings - page limits and crawl behavior