<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Case Studies on RenderCache.com</title>
    <link>https://rendercache.com/tags/case-studies/</link>
    <description>Recent content in Case Studies on RenderCache.com</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Sun, 18 Oct 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://rendercache.com/tags/case-studies/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>AI Crawlers Like GPTBot and ClaudeBot See an Empty Shell on JavaScript Sites</title>
      <link>https://rendercache.com/ai-crawlers-like-gptbot-and-claudebot-see-an-empty-shell-on-javascript-sites/</link>
      <pubDate>Sun, 18 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://rendercache.com/ai-crawlers-like-gptbot-and-claudebot-see-an-empty-shell-on-javascript-sites/</guid>
      <description>&lt;p&gt;Take a developer docs site built with a JavaScript framework. Every page is a route in one app, and the content loads from Markdown files after the app starts. Search works. The pages look right. Then someone on the team asks an AI assistant about their own API and gets an answer that&amp;rsquo;s a year out of date, or a shrug.&lt;/p&gt;&#xA;&lt;p&gt;One likely reason is in the server logs. GPTBot, ClaudeBot, PerplexityBot and the other AI crawlers have been fetching those pages for months. What they received was the app shell: a title, a script tag and an empty container. Most of these crawlers read the HTML they&amp;rsquo;re given and don&amp;rsquo;t run the JavaScript, so a page whose text only exists after rendering looks blank to them. Their capabilities differ and they change, but on a client-rendered site the safe assumption is that the words aren&amp;rsquo;t reaching them.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Fixing Blank Link Previews From Slackbot and LinkedInBot on JavaScript Apps</title>
      <link>https://rendercache.com/fixing-blank-link-previews-from-slackbot-and-linkedinbot-on-javascript-apps/</link>
      <pubDate>Sun, 18 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://rendercache.com/fixing-blank-link-previews-from-slackbot-and-linkedinbot-on-javascript-apps/</guid>
      <description>&lt;p&gt;Someone pastes a link to your new feature page into Slack. Instead of a card with the headline and a screenshot, the preview shows your app&amp;rsquo;s generic title and the default logo. Or nothing at all. The same thing happens on LinkedIn, on X, in a Discord channel. The page itself is fine. The preview is wrong because of where the tags live.&lt;/p&gt;&#xA;&lt;p&gt;Most JavaScript apps set their Open Graph and Twitter card tags at runtime. Libraries like React Helmet and Vue Meta write &lt;code&gt;og:title&lt;/code&gt;, &lt;code&gt;og:image&lt;/code&gt; and &lt;code&gt;og:description&lt;/code&gt; into the head after the app boots. The bots that build link previews don&amp;rsquo;t boot the app. Slackbot, LinkedInBot, Twitterbot, facebookexternalhit and Discordbot fetch the HTML, read the head, and leave. What they read is the static &lt;code&gt;index.html&lt;/code&gt; that every route shares.&lt;/p&gt;</description>
    </item>
    <item>
      <title>How a React or Vue Shop Gets Full Product Pages to Googlebot with RenderCache</title>
      <link>https://rendercache.com/how-a-react-or-vue-shop-gets-full-product-pages-to-googlebot-with-rendercache/</link>
      <pubDate>Sun, 18 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://rendercache.com/how-a-react-or-vue-shop-gets-full-product-pages-to-googlebot-with-rendercache/</guid>
      <description>&lt;p&gt;Picture a small furniture shop built as a single-page app. The storefront is React, the catalogue comes from a JSON API, and every product URL returns the same 2 KB of HTML: a title tag, a script bundle and an empty &lt;code&gt;&amp;lt;div id=&amp;quot;root&amp;quot;&amp;gt;&lt;/code&gt;. In a browser it looks fine. The name, the price, the photos and the stock level all arrive a moment later from the API.&lt;/p&gt;&#xA;&lt;p&gt;Googlebot does run JavaScript. It just doesn&amp;rsquo;t do it straight away. The first fetch gets the raw HTML, and the page goes into a render queue that can take a while to come back round. Until it does, Google has a product page with no product on it. Bing, DuckDuckBot and Applebot each handle JavaScript their own way, and the shop owner can&amp;rsquo;t control any of them. When the catalogue changes weekly, a slow or partial render costs real listings.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Moving From a Hosted Prerender Service to Self-Hosted RenderCache</title>
      <link>https://rendercache.com/moving-from-a-hosted-prerender-service-to-self-hosted-rendercache/</link>
      <pubDate>Sun, 18 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://rendercache.com/moving-from-a-hosted-prerender-service-to-self-hosted-rendercache/</guid>
      <description>&lt;p&gt;Plenty of JavaScript sites already solved the crawler problem years ago by signing up for a hosted prerender service. A middleware snippet in nginx or the app server spots crawler user agents and forwards those requests to the service with an API token. The service renders the page on its own machines, caches it, and sends it back. It works. Then the site grows.&lt;/p&gt;&#xA;&lt;p&gt;The bill usually grows with it, because hosted plans are priced on renders or cached pages. A site with tens of thousands of product or listing pages pays for every one of them, refreshed on the plan&amp;rsquo;s schedule. There&amp;rsquo;s a second cost that doesn&amp;rsquo;t show on the invoice. Every crawler request now depends on someone else&amp;rsquo;s uptime. And the record of what crawlers actually received lives in their dashboard, not in your logs.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
