Some sites ship almost no HTML and build the page in the browser — single-page apps, and some site builders. The crawler detects that pattern and renders those pages in a real browser engine before reading them, so a JS-rendered site audits like any other. Detection is per page: plain pages are read fast, and only the pages that need rendering pay the rendering cost.
There's nothing to switch on — rendering engages by itself. Read on if a JS-heavy site still audits thin: the usual causes are on the site's side, and they're fixable.
Why a rendered site can still read as thin
Rendered pages appear in the report like any others. Two site-side patterns produce thin results even when rendering succeeds:
- Content behind interaction. The renderer loads the page — it doesn't click tabs, scroll infinitely, or submit forms. Content that only exists after a click doesn't exist for any crawler, including Google's.
- Rendering that requires consent. A site that renders nothing until a cookie banner is accepted shows crawlers the banner. To fix it, render your content regardless of consent state — that also helps your Google indexing.
Limits and usage
- Rendering is slower than plain fetching, so JS-heavy sites consume more of the crawl window per page. Pair a big JS site with a sensible audit scope →.
- Page discovery needs URLs to exist somewhere readable. An XML sitemap matters more for a JS site than for any other kind, because homepage links may themselves be JS-rendered. The mapper can also fall back to ranking data to find your indexed pages.
- Your auth cookie → is carried into rendering, so logged-in JS areas work.
If something isn't working
The audit sees a loading spinner as the page
Why this happens: the app renders slowly, or errors without certain headers.
To fix: check that the page loads in a plain incognito visit. If it takes several seconds to appear, that latency is also your users' problem.
One section comes back empty
Why this happens: that section is client-routed with no server response — a hard 404 masked by the router.
To fix: server-render or prerender those routes. Google needs it too.
Meta tags read as missing on pages that have them
Why this happens: the tags are injected after load by JavaScript.
To fix: move your title and description into the server response. Tags that only exist post-render are unreliable for every crawler.
Does rendering cost extra credits?
No. Rendering is a fallback inside the normal crawl — one credit per audit run, no matter how many pages needed the browser engine. The cost is time: rendered pages consume more of each leg's window.
If rendering fails on a page, is it graded as empty?
No. A page whose render failed is marked content-unknown, not content-missing, and it's excluded from thin-content and duplicate-content judgments rather than scored against you.