JavaScript and search: what gets indexed, and what gets deferred
Your site is a JavaScript app and you want to know whether search engines really see the content.
Short answer
Google does execute JavaScript and does index content that only appears after rendering, but it happens on a second pass, on its own schedule, and not always. Most other crawlers, including several AI answer engines, link tools and social preview fetchers, do not execute JavaScript at all. So client-rendered content is not invisible to Google, it is deferred and conditional, and it is genuinely invisible to much of everything else.
The two-pass model
The first pass reads your HTML. If the content is there, it can be indexed immediately. If it is not, the URL joins a render queue and comes back when capacity allows, which may be hours or considerably longer. Everything downstream of indexing, including how fast a new page starts ranking, inherits that delay.
Who never runs your JavaScript
Plenty of things fetch your pages besides Googlebot. Social previews, link databases, feed readers, archive crawlers and several AI retrieval systems read raw HTML and stop. For them, a client-rendered page is a blank page with a script tag, and no amount of Google rendering fixes that.
The signals of a shell
An empty mount element with nothing inside it. A large framework data payload that is content waiting to be rendered rather than content. A stack of script tags against almost no words. Any one of these can be innocent; together they mean the HTML is scaffolding and the page arrives later.
What to do about it, in order
Server-render or prerender the pages that need to rank. Static prerendering at build time is the cheapest version and it is enough for content pages: the HTML contains the words, the headings, the links and the structured data, and the app takes over afterwards for interactivity.
Links are the part people forget
A crawler discovers pages by following links in the HTML. If your navigation is rendered client-side, the first pass sees no links, so discovery of the rest of your site waits on rendering too. This is how a JavaScript site ends up with a handful of indexed pages and no explanation.
Structured data has the same problem
JSON-LD injected after render may be read later or not at all. If your markup is the reason you expect a richer result, put it in the HTML that the server returns, not in a script that adds it afterwards.
How to check rather than assume
Fetch the page and read the raw HTML, not the inspector. The inspector shows you the page after your browser executed everything, which is exactly the state a first-pass crawler does not have. View source, or use a tool that reports the served bytes.
Questions
- Is server-side rendering required to rank?
- No. Client-rendered pages do get indexed. What you lose is speed of indexing, reliability, and every crawler that does not render. For a site with authority and patience that trade can be fine; for a new site trying to get found, it is a self-inflicted delay.
- Does prerendering count as cloaking?
- Not if you serve the same content to everyone. Cloaking is showing different content to crawlers than to users. Static prerendering serves identical HTML to both and simply does the rendering earlier.
- How do I know if rendering is delaying my indexing?
- Compare when a page was published against when it first appears in Search Console with impressions. Then compare that lag against a page whose content is in the raw HTML. If the client-rendered pages are consistently slower to appear, rendering is your bottleneck.
Measured, not asserted
This site prerenders every guide page for exactly this reason, and so does ihatepdf.cv, which reached 100,542 users on search alone. Fetching one of its tool pages as a crawler returns the full page in the HTML: hundreds of words, the headings, dozens of internal links and the structured data, all present before a single script runs.
Free tool for this: Crawler View. No account, nothing uploaded.
Where this goes deeper
Every number on this page comes from one complete dataset: one product taken from zero to 100K+ users on search alone, with nothing spent on advertising. The full argument is Chapter 10 and Chapter 11 of the book. Five chapters are free to read.