JavaScript rendering

Also called JS rendering, client-side rendering, CSR

Whether a crawler runs your JavaScript before reading the page. The answer divides crawlers into two groups, and the split matters more every year.

Googlebot renders, on a queue and with resource limits. Applebot renders. Most AI crawlers do not document rendering at all, and GPTBot is the one people assume wrongly about most often. For anything undocumented, assume the crawler sees the HTML your server returned and nothing after it.

The test is a comparison. Fetch the raw HTML, fetch the rendered DOM, and diff them. Whatever appears only in the second copy exists for browsers and for two crawlers.

curl -s https://example.com/page | wc -c
# then the same URL through a headless browser, and compare

The mistake

Concluding that rendering works because Google indexed the page.

Rendering is not free and it is not immediate. It happens on a second pass, after the initial fetch, and it competes with everything else in the queue. A page can be indexed from its raw HTML first and rendered later, which means a snippet built from an empty shell can persist for a while. It also means a slow client-side request after load can time out, producing a rendered DOM missing the content that a browser on a fast connection always shows you.

The deeper problem is that Google is the exception now. A client-rendered site can rank fine and still be invisible to every AI crawler fetching it, which is a quiet and growing gap between what your analytics measures and what your content reaches.

If the content matters, put it in the server response. Prerendering and server rendering both do this, and both also improve time to first byte for the part of the page that matters. Do not serve a different page to crawlers to solve it, which is cloaking. Watch for the single-page application variant of soft 404 while you are there, since an unknown route returning the app shell with a 200 is the same class of bug.