--- title: "On reports +67% Google traffic after prerendering its JavaScript site" url: https://seomadman.com/studies/on-prerender-javascript-rendering-traffic-case-study section: studies published: 2026-09-23T00:00:00.000Z modified: 2026-09-25T00:00:00.000Z author: Adam Hafez topics: ["Technical SEO"] --- # On reports +67% Google traffic after prerendering its JavaScript site ## The short answer On, a sportswear retailer, says bots could not read its JavaScript pages before a 2023 front-end update. It chose Prerender.io over building server-side rendering and reports a 67% rise in Google traffic and 98% in Bing after nearly three years. The figures are percentages published by the vendor, with no baselines. ## Key takeaways - On reports a 67% increase in Google traffic and a 98% increase in Bing traffic after nearly three years on Prerender.io. - On evaluated server-side rendering first and rejected it because it would have tied up developers for several months. - On says traffic fell to under 10% of normal in one low-traffic market when Prerender.io was switched off for a month. - The case study is written by the vendor and gives percentage changes only, with no baseline traffic figures. - Prerendering serves rendered HTML to bots, so it is a different fix from SSR, SSG or hydration in the browser. On is a sportswear brand with an ecommerce business in more than 60 countries. In a case study published on the Prerender.io site, the company describes how it handled a JavaScript-heavy front end that search bots could not read reliably. It reports a 67% increase in Google traffic and a 98% increase in Bing traffic. This is a vendor-authored account of a customer, not an independent test. It sits with the other [technical SEO](/topics/technical-seo) studies here. ## What problem did On have with JavaScript rendering? Ahead of a major front-end update in 2023, On says its JavaScript-heavy pages were not rendering reliably for crawlers. The listed symptoms were indexing issues across global markets, broken social link previews, continuous ad disapprovals on Google Shopping and display platforms, and low organic traffic. The case study names one root cause: bots could not read the JavaScript content. The ad side mattered as much as organic search. According to the case study, Googlebot could not render critical page elements, so campaigns on Google Shopping and DV360 were rejected, throttled or paused. Marilena Pixner, Senior Organic Growth and SEO Specialist at On, is quoted saying the team "needed to protect the entire digital marketing ecosystem," not only traffic. ## Why did On pick prerendering over SSR? On evaluated server-side rendering as a long-term fix. According to the case study, a full SSR build would have taken developers off the roadmap for several months and added maintenance and infrastructure. On chose Prerender.io instead, a one-time integration that serves rendered HTML to bots. That is prerendering, not SSR: the site itself stays client-rendered for users. The case study credits this with avoiding 90% of engineering costs, a figure it does not break down. ## What results did On report? The case study reports a 67% increase in Google traffic, a 98% increase in Bing traffic and faster recognition of new and updated content, over nearly three years of use. It says visibility stabilised within days of the integration, that Google Ads disapprovals stopped, and that social previews worked, naming Pinterest images and WhatsApp links. It also claims image traffic improved and estimates millions of dollars in protected annual ad revenue, without figures behind either. To test the effect, On switched Prerender.io off for one month in a low-traffic market, and traffic fell to under 10% of normal before recovering once it was turned back on. ## What does Google say about this approach? Serving pre-rendered HTML to bots and the live JavaScript app to users is what Google calls dynamic rendering. Its [documentation](https://developers.google.com/search/docs/crawling-indexing/javascript/dynamic-rendering) describes dynamic rendering as a workaround and not a long-term solution, and recommends server-side rendering, static rendering or hydration instead. It is not treated as cloaking as long as the content bots receive is similar to what users see; serving completely different content is. So the On case is a trade-off, not a verdict against SSR. Prerendering bought speed and saved engineering time, but it leaves two versions of every page to keep in sync, and it depends on a third-party service staying up, which is exactly what the shutdown test illustrates in reverse. ## How should this case study be read? The traffic figures are percentage changes with no baseline, comparison period or traffic volume, so they are recorded here as changes from a zero baseline and the study is marked unverified. The author is also the vendor. The controlled shutdown test is the strongest evidence in the write-up, but it covers one small market. The transferable point is narrow: if bots cannot see your JavaScript content, rendered HTML for crawlers can restore visibility without an SSR rebuild. To check whether you have the same problem, compare the raw HTML your server returns with the rendered page in Search Console's URL Inspection tool. If product names, prices or links only appear after rendering, Google only sees them once the page is rendered, a delay covered in our look at [how long JavaScript content waits](/research/javascript-rendering-googlebot-delay). ## Sources 1. [How On Increased Traffic by 67% and Saves Millions With Prerender.io](https://prerender.io/resources/case-studies/on-prerender/) - Prerender.io (primary) 2. [Dynamic rendering as a workaround](https://developers.google.com/search/docs/crawling-indexing/javascript/dynamic-rendering) - Google Search Central (primary)