<b>Why only 30% of a 9,000-page site ever got rendered</b>

<b>Why only 30% of a 9,000-page site ever got rendered</b>

A classifieds site published 9,000 listing pages a week. Crawled fine — Search Console showed Googlebot fetching them all. But only ~30% ever made it past 'Discovered' into the index.

Crawl wasn't the bottleneck. Rendering was. We measured time-to-interactive on a mid-tier connection: 14 seconds, dominated by a 2.8MB JavaScript bundle that had to parse, execute, and hydrate before any content appeared.

Google crawls cheaply but renders expensively, and it rations the render queue. For a massive site shipping a heavy bundle per page, the render budget simply ran out. Pages sat in the queue for weeks, then got dropped.

The insight that reframed everything: their indexing problem was a performance problem wearing a costume. Render cost per page was the hidden tax.

Fix: server-rendered the listing content into static HTML, deferred the interactive bundle to hydrate after. Render cost per page dropped 80%.

Result: index coverage climbed from 31% to 88% over six weeks, and total indexed pages went from 2,800 to 7,900 — organic sessions +63%.