Skip to content
Chalk Labs / AI SEO
How-to guide

How to Make Your Site Readable by ChatGPT (Server-Side Rendering)

By Rahil Jain, founder of Chalk LabsUpdated How we research

The short answer

In the last public test we can cite, from December 2024, ChatGPT's crawlers did not run JavaScript, so text that appears only after scripts run can be invisible to them. Test your page with view-source or curl. If your key text is missing from the raw HTML, serve it from the server using static pages, server-side rendering or prerendering.

  • Vercel's December 2024 study found OpenAI, Anthropic and Perplexity crawlers did not render JavaScript. Google's Gemini and Apple's crawler did.
  • That study is almost two years old. Test your own pages instead of trusting any claim, including ours.
  • Test: if your main text is in view-source or in a curl download, a non-rendering bot can read it.
  • Fix with static generation or server rendering. Google calls dynamic rendering a workaround, not a long-term solution.

Does ChatGPT render JavaScript?

The last public test we can cite says no. In a study published on 17 December 2024, Vercel and MERJ reported that the crawlers from OpenAI (GPTBot, OAI-SearchBot, ChatGPT-User), Anthropic (ClaudeBot), Perplexity (PerplexityBot), Meta, ByteDance and Common Crawl did not render JavaScript 1. JavaScript rendering means running a page's scripts, as a browser does, so that text built by those scripts appears.

The same study found two AI-related crawlers that did render: Gemini, which uses Googlebot's infrastructure, and Apple's crawler 1. Apple's own support page confirms that Applebot may render content within a browser, but may not do it properly if scripts or styles are blocked 2.

Two cautions apply. First, the study is almost two years old, and crawlers change. Second, the study covered traffic on Vercel's network, not every site. Treat it as a strong reason to test, not as a permanent rule.

Do it step by step

0 of 7 done0%

  1. Choose five page types: home, a service or product page, a blog post, a pricing page and a category or listing page. Copy one distinctive sentence of body text from each, not a heading.

  2. Open each page, view its source, and search for your sentence. If you find it inside the HTML, mark pass. If you only find script tags and an empty container such as a div with id root, mark fail.

    Tip: View-source shows what the server sent. Do not use the Elements panel, which shows the page after scripts ran.

  3. Run the script in the templates section against each URL and phrase. It saves the HTML and tells you if the phrase is there. Record the byte size too.

  4. In developer tools, disable JavaScript and reload. Note what is missing: text, links, prices, images, structured data. Links should still exist as real anchor tags with href values.

  5. Use the options table. Make marketing pages static, make fresh pages server-rendered, and add prerendering for a legacy app you cannot rewrite yet. Write the choice next to each page type.

  6. Ask your developer to render the title, headings, main text, internal links, canonical tag and structured data on the server. Keep interactive widgets as scripts, but render a text fallback.

    Tip: Ask for a pull request that includes the before and after curl output.

  7. Re-run the tests after deployment, on production. Then check server logs for visits by OAI-SearchBot, PerplexityBot and other bots to confirm they fetch your pages and receive 200 responses.

Your ticks are saved in this browser only.

Copy-ready templates

Raw HTML test script (bash)

bash
#!/usr/bin/env bash
# Usage: ./rawcheck.sh https://example.com/page "a sentence from the page"
URL="$1"
PHRASE="$2"
curl -sL -A "Mozilla/5.0 (compatible; raw-html-test)" "$URL" -o page.html
echo "Downloaded $(wc -c < page.html) bytes"
if grep -qiF -- "$PHRASE" page.html; then
  echo "PASS: phrase found in raw HTML"
else
  echo "FAIL: phrase missing from raw HTML"
fi
echo "h1 tags: $(grep -o -i '<h1' page.html | wc -l)"
echo "links: $(grep -o -i '<a [^>]*href=' page.html | wc -l)"

curl does not run scripts, so this shows what a non-rendering bot downloads. Some firewalls block unusual agents; a block here is a separate problem.

Empty shell versus server-rendered HTML

html
<!-- FAIL: client-side shell. A bot that cannot run scripts sees no content. -->
<body>
  <div id="root"></div>
  <script src="/app.js"></script>
</body>

<!-- PASS: content is in the HTML the server sends. -->
<body>
  <main>
    <h1>Fixed-fee bookkeeping for cafes</h1>
    <p>We charge a fixed monthly fee and file on the 15th of each month.</p>
  </main>
  <script src="/app.js" defer></script>
</body>

Interactive features can still load by script. The readable text must not depend on it.

Release checklist

markdown
- [ ] Main text, headings and prices appear in view-source
- [ ] Internal links are real <a href> tags
- [ ] Title, meta description and canonical are in server HTML
- [ ] Structured data is in server HTML and matches visible text
- [ ] No key answer hidden behind tabs or click-to-expand only
- [ ] robots.txt does not block script or style files
- [ ] curl test passes on all five page types
- [ ] Server logs show 200 responses to AI bots after launch

Paste it into the pull request template.

What is at risk if your site is client-side rendered?

A client-side rendered site sends a nearly empty HTML shell and builds the page in the browser. web.dev defines client-side rendering as rendering an app in a browser using JavaScript to modify the DOM, and server-side rendering as rendering on the server to send HTML rather than JavaScript 3. A bot that does not run scripts sees only the shell.

That can mean an empty page for the bot: no headings, no prices, no answers. Vercel also reported that ChatGPT and Claude crawlers fetch JavaScript files but do not execute them, and that ChatGPT and Claude cannot read client-side rendered content 1.

Microsoft adds a related warning. Its AI search guidance says AI systems may not render hidden content such as tabs or expandable menus, so key details can be skipped 4. Put the important text in the page itself, not behind a click.

Is Google different from other AI crawlers?

Yes. Google renders JavaScript, but with a delay. Its documentation says pages with a 200 status code go to a rendering queue, where a page may wait a few seconds or longer 5. The same page says server-side or pre-rendering is still a great idea, because not all bots can run JavaScript 5.

Google also reads only so much of each file. It crawls the first 2MB of a supported file type, measured uncompressed, and stops the fetch at that point 6. Large inline scripts at the top of a page can push your real text beyond the cut-off, which is another reason to keep HTML lean.

So a client-side site may do fine in Google and still be thin or invisible elsewhere. That gap is why a single check in Google is not enough.

How do you test what a bot without JavaScript sees?

Run three tests, each taking under five minutes. First, open the page, use view-source, and search for a sentence from the main text. View-source shows the HTML as the server sent it, before any scripts ran.

Second, download the page with curl, which does not run scripts, and search the file for the same sentence. The script below does this. Third, in your browser's developer tools, turn JavaScript off and reload. If the page goes blank, a non-rendering bot sees the same.

Test five page types: home, a service or product page, a blog post, a pricing page and a category page. Frameworks often render some routes on the server and others in the browser.

Which fix should you choose?

Choose static generation for pages that rarely change, server-side rendering for pages that must be fresh on each request, and prerendering as a stopgap for a legacy single-page app. All three put real text into the HTML the bot downloads.

web.dev defines prerendering as running a client-side application at build time to capture its initial state as static HTML, and notes that static rendering happens at build time 3. It also says server rendering can raise time to first byte because pages are built per request, while static rendering gives a consistently fast one 3. Vercel's own advice to site owners who want to be crawled is to prioritise server-side rendering for critical content 1.

Rendering options compared
OptionBest forWatch out for
Static generation (SSG)Marketing pages, blogs, docsRebuild needed when content changes
Server-side rendering (SSR)Pages that change per request or per userSlower first byte if the server is slow
Incremental or on-demand regenerationLarge catalogues that change a littleFramework-specific; test cache behaviour
Prerendering at buildAn existing single-page app you cannot rewriteDynamic parts still need scripts
Dynamic rendering (bot-only HTML)Short-term fix when nothing else is possibleGoogle calls it a workaround, not a long-term solution 7

What mistakes do teams make?

The most common mistake is testing in a browser and calling it done. A browser runs scripts, so everything looks fine. Always test the raw HTML.

Other mistakes are loading the main answer only after a click or scroll, putting the title, canonical tag or structured data in client-side code only, and blocking script or style files in robots.txt. Apple warns that blocked resources can stop Applebot rendering content properly 2.

A further mistake is relying on dynamic rendering for good. Google says dynamic rendering was a workaround, not a long-term solution, and recommends server-side rendering, static rendering or hydration instead 7. Use it as a bridge, with a date set to remove it.

Does server rendering slow the site down?

It can, if the server is slow. web.dev puts a good time to first byte at 0.8 seconds or less and a poor one above 1.8 seconds, and calls those a rough guide 8. It also says a server-rendered site may have a higher TTFB yet better paint times 8.

Caching removes most of the penalty. Cache rendered HTML at your content delivery network, which is a network of servers that stores copies close to visitors, and rebuild when content changes. For speed topics beyond rendering, read how to speed up your site for AI crawlers.

When can you skip all this?

Skip it for pages you do not want found, such as logged-in dashboards, and for sites already built as plain HTML or on a platform that sends finished HTML. Run the test once to confirm, because you cannot tell from the outside.

If bots cannot reach your site for other reasons, fix that first. See how to check if AI bots can crawl your website and use the AI crawler checker. Then read what AI crawlers each want.

Frequently asked questions

Does ChatGPT render JavaScript?

In Vercel's December 2024 study, OpenAI's crawlers did not render JavaScript 1. No newer public test is available to us, so verify with the curl test. If your text is in the raw HTML, the question stops mattering for your site.

How do I check if my site is client-side rendered?

View the page source and search for a sentence from your body text. If the source holds only script tags and an empty container, the page is client-side rendered. A curl download gives the same answer in a script.

Is server-side rendering the only fix?

No. Static generation, server rendering and build-time prerendering all work. Google recommends server-side rendering, static rendering or hydration, and calls dynamic rendering a workaround 7. Pick the lightest option that puts real text in the HTML.

Will server-side rendering get me cited by ChatGPT?

It removes one barrier but does not earn a citation, and we do not guarantee one. Your content must also be relevant, allowed by robots.txt, and trusted. Think of rendering as the entry ticket, not the prize.

Does this matter if I only care about Google?

Less, since Google renders JavaScript, but it can queue pages for a time 5. Google also still calls server-side or pre-rendering a great idea because not all bots can run JavaScript 5.

About the author

Rahil Jain

Rahil Jain is an AI SEO (answer engine and generative engine optimisation) consultant and co-founder of Chalk Labs.

LinkedIn · Method and credentials

Sources

  1. The rise of the AI crawler · Vercel (with MERJ)Opened October 20, 2026. Supports: Published 17 Dec 2024: crawlers from OpenAI, Anthropic, Perplexity, Meta, ByteDance and Common Crawl did not render JavaScript; Gemini and AppleBot did; ChatGPT and Claude fetch but do not execute JS files; advice to prioritise server-side rendering for critical content.
  2. About Applebot · AppleOpened October 20, 2026. Supports: Applebot may render content within a browser; if scripts, styles or other resources are blocked in robots.txt it may not render properly.
  3. Rendering on the Web · web.dev (Google)Opened October 20, 2026. Supports: Definitions of client-side rendering, server-side rendering and prerendering; static rendering happens at build time; trade-offs on time to first byte.
  4. Optimizing Your Content for Inclusion in AI Search Answers · Microsoft Advertising (Bing)Opened October 20, 2026. Supports: AI systems may not render hidden content such as tabs or expandable menus, so key details can be skipped.
  5. Understand JavaScript SEO basics · Google Search CentralOpened October 20, 2026. Supports: 200-status pages are queued for rendering, possibly for longer than a few seconds; server-side or pre-rendering is still a great idea because not all bots can run JavaScript.
  6. Googlebot · Google Search CentralOpened October 20, 2026. Supports: Googlebot crawls the first 2MB of a supported file type, measured on uncompressed data, and stops the fetch at the cutoff.
  7. Dynamic rendering as a workaround · Google Search CentralOpened October 20, 2026. Supports: Dynamic rendering was a workaround and not a long-term solution; Google recommends server-side rendering, static rendering or hydration.
  8. Time to First Byte (TTFB) · web.dev (Google)Opened October 20, 2026. Supports: Good TTFB is 0.8 seconds or less, poor is over 1.8 seconds, as a rough guide; server-rendered sites may have higher TTFB but better paint times.
How this page was made. Built on Rahil Jain's AI SEO method and drafted with AI research assistance. Every statistic links to the page we read it on (opened October 20, 2026 or nearby). Published October 20, 2026; last updated October 20, 2026. Chalk Labs sells AI SEO services, so we have a commercial interest in this topic. Spotted an error? Tell us and we will fix it.