Should you really abandon client-side JavaScript for indexing product links?

What actually happens when a site loads its product links in JavaScript?

When an e-commerce site uses client-side JavaScript to display its product listings, Google doesn’t see these links immediately. The crawler first fetches the raw HTML — often an empty shell — and then places the page in a rendering queue.

It is only after this rendering step, which executes the JavaScript in a Chromium browser, that Googlebot discovers the actual links to product pages. This process introduces a discovery delay that can impact how quickly new products are indexed.

How long is this rendering delay according to Google?

Martin Splitt suggests that 90% of pages are rendered in a few minutes. This phrasing is deliberately vague: “a few minutes” can mean anywhere from 2 to 15 minutes, or even longer in some cases.

For an e-commerce site with thousands of items and a high turnover rate (new arrivals, limited stock, flash sales), even a delay of 5 to 10 minutes can pose a competitive disadvantage against sites that expose their links directly in the initial HTML.

What conditions make this delay negligible?

Google implies two conditions: the site must be fast and function properly in testing tools (Search Console, Mobile-Friendly Test, PageSpeed Insights). Practically, this means JavaScript must not crash, critical resources must load quickly, and the final rendering must be stable.

If your JavaScript relies on slow API requests, large libraries, or variable network conditions, rendering may fail or be significantly delayed. In that case, the “negligible” delay becomes problematic.

• JavaScript links are only discovered after rendering, not during the initial crawl of the raw HTML.
• Google states that 90% of pages are rendered in a few minutes, but the definition remains imprecise.
• Switching to SSR is not mandatory if the site is fast and functions well in Google’s tools.
• Sites with a dynamically changing catalog (high product turnover) are more sensitive to the discovery delay.
• JavaScript errors, slow dependencies, or blocked resources can exacerbate the delay or completely prevent link discovery.

Is this statement consistent with real-world observations?

Yes and no. Tests do show that Google eventually renders most JavaScript pages, but the actual timing varies considerably depending on crawl budget, code quality, and the priority assigned to the site. [To be verified] The figure of 90% being rendered in “a few minutes” is not backed by any precise public data.

On high-traffic e-commerce sites with a high crawl budget, the delay may indeed be short. But for smaller sites or less prioritized sections, there are often delays of several hours, or even days before rendering. Splitt's generalization obscures a heterogeneous reality.

When does the rendering delay become really problematic?

The delay becomes an issue in several concrete scenarios. If you're launching limited edition products or flash sales, a 10-minute delay may mean that Google indexes your URLs while the products are already out of stock.

Similarly, for sites facing strong SEO competition on transactional queries, being indexed 15 minutes after a competitor who exposes their links in SSR can cost you critical positions during simultaneous launches. Google’s “negligible” isn’t negligible for everyone.

Should you systematically migrate to SSR?

No, and this is where Splitt's statement makes sense. SSR introduces its own complexity: cache management, server response time, risk of duplicate content if poorly implemented. If your CSR site is performing well, your products remain online for several days, and tests show correct rendering, the ROI of an SSR migration may be low.

On the other hand, if you observe recurring indexing problems, inexplicable position fluctuations, or if your SSR competitors consistently outpace you on new arrivals, then yes, SSR becomes a strategic priority. The decision should be made site by site, rather than based on a general rule.

How can you check that your JavaScript site is rendered correctly by Google?

Use the URL Inspection Tool in Search Console to compare the raw HTML and the rendered HTML. If critical product links only appear in the rendered version, you are impacted by this delay. Also check the coverage reports: URLs listed as “Discovered – currently not indexed” may signal a rendering issue.

Test your pages in PageSpeed Insights and the Mobile-Friendly Test. If these tools display your product links correctly, that’s a good sign. But be cautious: these tools do not always reflect the actual timing of the live crawler. An isolated test may succeed while rendering in real conditions takes longer.

What optimizations should you implement if you stay with client-side JavaScript?

Minimize the weight of JavaScript bundles: code-splitting, lazy loading of non-critical components, aggressive tree-shaking. The lighter and faster your JS is, the higher priority the rendering will get in Google’s queue.

Implement a progressive rendering: first display a skeleton with the main links in static HTML, then enrich it with JavaScript. This allows Google to discover at least some links during the initial crawl, without waiting for the full rendering. Monitor JavaScript errors in Search Console: a blocking error may completely prevent link discovery.

In what cases does switching to SSR become essential?

If your product catalog changes multiple times a day (drop sneakers, event ticketing, fresh products), the rendering delay becomes a real obstacle. Likewise, if your direct competitors are on SSR and you observe a systematic indexing delay, that’s a warning signal.

SSR is also necessary if your site regularly generates rendering errors in Search Console, or if your JavaScript relies on unstable network conditions (third-party APIs, slow CDNs). In these cases, the risk of non-discovery outweighs the technical complexity of migrating.

• Compare the raw and rendered HTML in the URL Inspection Tool to identify links discovered late.
• Reduce your JavaScript bundles and implement strategic code-splitting to speed up rendering.
• Monitor JavaScript errors in Search Console: a blocking error cancels link discovery.
• Test your pages in PageSpeed Insights and ensure links are displayed correctly in the rendered version.
• Consider a hybrid progressive rendering: HTML skeleton + JavaScript enrichment, to combine quick discovery and dynamic UX.
• If your catalog changes several times a day or your SSR competitors outpace you, prioritize an SSR migration.