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 in the cloud by default, with no prompt: the audit level decides which pages, only the ones that need JavaScript at quick and every page at surface and full. The first such run prints a one-line note about what audits cost. The crawl progress shows the rendering spend so far (the 50-credit base appears in the final total, not this counter):

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 need a browser for it (it is not cheaper: every audited page costs the same 2 credits either way, it is just faster):

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

--http forces plain HTTP for that run. The opposite, --render, renders every page even when your config disables it.

Pick a strategy: off / auto / all

Rendering isn’t all-or-nothing. The render setting takes a scale:

The price is the same for all three: 2 credits per audited page plus the 50-credit base. auto is usually what you want: a static or server-rendered site runs at HTTP speed, while a JS app still gets a real rendered DOM where it matters. robots.txt, sitemaps, and assets are always plain HTTP. Even with all, only crawled HTML pages are ever rendered.

Run a single audit with a strategy:

squirrel audit https://example.com --render-mode auto

Make the choice permanent for a project

Pin the render strategy in squirrel.toml so it no longer follows the audit level. Cloud rendering still needs a signed-in, online run, and command-line flags override the setting:

[cloud]
render = "auto"   # off | auto | all

Setting render explicitly overrides the level’s default, so every signed-in audit of this project renders the same way. (The older rendering = "http" | "browser" still works: http = off, browser = all, but render is preferred.)

Watch your page count

Every audited page costs 2 credits on top of the audit’s 50-credit base, rendered or not, so page count is the part of an audit that scales. 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 about 475 pages; a larger page limit is lowered to fit it, with a notice. Raise the cap (or set it to 0) for bigger 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