Most sites are built for humans. Some are also optimised for Google. But over the past couple of months I’m hearing a lot of teams who want to “show up in AI” and haven’t checked what their site looks like to LLMs. It might be very different to what you see in the browser.
The Core Problem
Users see the fully rendered, interactive experience thanks to JavaScript.
Googlebot can render JavaScript, but rendering is a separate step with its own constraints, so it’s slower and less reliable than content served directly in the HTML.
Then there are the LLMs and many AI crawlers, which typically don’t execute JavaScript at all. They read only the raw HTML. If your key content is added in after load, they may never see it.
That gap between what a person sees and what a crawler sees is where visibility quietly breaks down, and it’s becoming a real technical SEO issue as more discovery happens through AI.
What To Do: Audit Raw vs Rendered
Start by auditing. Run a raw HTML vs rendered content check, the goal is simply to confirm your primary content, links and navigation are present in the initial HTML, not added later by JavaScript.
What “Good” Looks Like
- SSR, SSG or prerendering used for any page you need indexed or cited.
- Critical copy (H1, H2s, primary body, key CTAs) present in the server-delivered HTML.
- Main navigation and important internal links available in the raw HTML, not injected after load.
- No “content skeletons” that only fill in later for your core messaging.
The Three Main Rendering Approaches
There are three common ways to make sure your content is in the HTML from the start. Which one fits depends on your site.
Server-Side Rendering
The server builds the page before sending it to the browser, so the content is fully formed and ready to read the moment it arrives.
Best for: dynamic pages that change often but still need to be reliably indexed and cited.
Static Site Generation
Pages are pre-built as static HTML files at deployment, so they load fast and don’t rely on JavaScript for their core content.
Best for: content that doesn’t change constantly, blogs, landing pages, marketing sites.
Prerendering
Generates HTML snapshots of JavaScript-heavy pages specifically for crawlers that can’t execute JavaScript.
Best for: legacy client-side apps or specific routes that need indexability without a full rebuild.
A note on implementation: in practice, most sites use SSG or SSR for their core pages, and prerendering for legacy client-side apps or specific routes that need to be indexable or citable. It’s not always one or the other.
How to Check What Bots Actually See
You don’t need developer tools to get a first read on this. A few quick checks reveal whether your content is in the raw HTML or only appears after JavaScript runs.
View the page source. Right-click the page and choose “View Page Source” (or put view-source: before the URL). This is the raw HTML, before any JavaScript runs. Search it (Ctrl/Cmd + F) for a sentence from your main body copy or a key heading. If it’s there, good. If it’s missing, that content is being added by JavaScript and may be invisible to crawlers that don’t render.
Compare raw vs rendered. Google’s URL Inspection tool in Search Console shows you the rendered HTML and a screenshot of how Googlebot sees the page. Compare that against your View Source. Big differences are a flag.
Turn JavaScript off. Disable JavaScript in your browser and reload. What’s left is roughly what a non-rendering crawler sees. If your nav, main content or key links vanish, that’s exactly what’s at risk.
Check the pages that matter. Product pages, service pages and anything you want cited in AI results matter most. Test the pages that actually drive your business, not just the homepage.
If the raw and rendered versions look very different on the pages that matter, that’s your signal to look at SSR, SSG or prerendering.
What’s the risk of loading content in JavaScript?
If your key content only loads with JavaScript, you’re taking a risk on two fronts.
For Google: it can process JavaScript, but it takes extra time and isn’t guaranteed. Putting your most important text and links directly in the HTML means Google sees them faster and more reliably.
For AI tools and LLMs: most don’t run JavaScript at all. If your content isn’t in the initial HTML, you may simply be invisible to these models, and increasingly, that’s where people are discovering and choosing brands.
Quick Checklist
- Can I see the main content when I hit View Source?
- Are the key links there even with JavaScript turned off?
- Do the raw and rendered versions of the page look very different?
If the answer to that last one is yes, it’s worth looking at SSR, SSG or prerendering for the pages that matter most.
Frequently Asked Questions around rendering / site visibility
Do AI crawlers like ChatGPT and Perplexity render JavaScript?
Mostly no. Unlike Googlebot, which can render JavaScript as a separate step, most AI and LLM crawlers read only the raw HTML and don’t execute JavaScript at all. If your content is injected after load, it can be invisible to them, which directly affects whether your brand appears in AI-generated answers.
Does Google see JavaScript content?
Google can render JavaScript, but it’s a separate, later step with its own constraints, so it’s slower and less reliable than content served directly in the HTML. Putting your important text, links and navigation in the initial HTML means Google sees them faster and more dependably.
How do I know if my site has a rendering problem?
Compare your raw HTML (View Source) with the rendered page. If key content, headings, body copy, navigation or internal links, only appears in the rendered version, it’s at risk. Disabling JavaScript in your browser is a quick way to see roughly what a non rendering crawler sees.
What’s the difference between SSR, SSG and prerendering?
SSR builds each page on the server at request time, SSG pre-builds pages as static HTML at deployment, and prerendering generates HTML snapshots specifically for crawlers. All three put your core content into the HTML so it doesn’t depend on JavaScript to be seen.
Is this only a problem for big JavaScript frameworks?
No. It’s most common on JavaScript heavy sites, including those built with frameworks like React, Vue and Angular, and many modern AI and no-code site builders such as Lovable, which produce the same kind of client rendered code. Anything that loads core content, navigation or links via JavaScript after the initial page load can be affected, whether or not you know what it’s built on. It’s always worth checking.
Rendering is one of those issues that stays invisible until you go looking for it, and by then it may already be costing you visibility in both search and AI results.
If you want a focused audit that checks how your site looks to users, Google and AI crawlers, and a clear plan to fix any hidden content, that’s exactly the kind of work I do. Explore SEO audits or get in touch and we’ll work out what your site is really showing.
