The server side rendering AI search question sounds technical, but the business issue is straightforward: when an AI crawler requests one of your pages, does it receive the useful content immediately, or does it first receive an almost-empty shell that depends on JavaScript to build the page?
That difference is called rendering.
A website can look completely normal to a human visitor while delivering very different HTML to an automated crawler.
Google can execute JavaScript using Chromium, but Google itself still recommends server-side or prerendered content where appropriate and notes that not all bots can run JavaScript.
OpenAI documents OAI-SearchBot as the crawler used to surface websites in ChatGPT Search, but its crawler documentation does not promise that every page receives the same JavaScript rendering process Google provides.
So the safe principle is:
The more important your content is, the less you should depend on an unknown crawler executing JavaScript perfectly before it can read it.
Table of contents
- What does rendering actually mean?
- What is server-side rendering?
- What is client-side rendering?
- What is prerendering?
- SSR vs CSR for AI search
- Why client-side rendering can create crawler problems
- Is React bad for AI search?
- What about WordPress and Elementor?
- How to tell which rendering method your site uses
- Which rendering option should you choose?
- Questions to ask your developer
- Does fixing rendering require a rebuild?
- Frequently asked questions
What does rendering actually mean?
Rendering is simply how the content that becomes a webpage is produced.
A user visits a URL.
Something has to create the HTML that contains the headings, paragraphs, links, products, pricing or service information they eventually see.
The key question is:
Where does that happen?
On the server?
In the visitor’s browser?
Or before the visitor even requests the page?
That gives us three useful models:
- server-side rendering
- client-side rendering
- prerendering or static rendering
In practice, many modern websites use a mixture.
What is server-side rendering?
Server-side rendering, usually shortened to SSR, means the server generates the HTML before sending the response to the browser.
So when someone requests:
example.com/pricing/
the server may return HTML that already contains:
- the page title
- pricing information
- product descriptions
- links
- FAQs
- other meaningful content
JavaScript can still run afterwards to add interactivity.
But the core content already exists.
web.dev defines server-side rendering as rendering an application on the server so HTML is sent to the client rather than requiring JavaScript to construct the page in the browser.
Read web.dev’s guide to rendering on the web
Why this is useful for crawlers
A crawler requests the URL and receives meaningful content immediately.
It does not need to successfully:
- download a large JavaScript application
- execute that application
- call another API
- wait for the API response
- insert the result into the page
before it knows what the page says.
That reduces dependency on rendering capability.
What is client-side rendering?
Client-side rendering, or CSR, moves much of that work into the browser.
The server may initially return something closer to:
<div id=”app”></div>
<script src=”/app.js”></script>
Then JavaScript runs.
The application fetches data.
The browser creates the DOM.
Only then does the visitor see the useful page.
This architecture is common in single-page applications and JavaScript frameworks.
web.dev explains that client-side rendered sites may initially deliver relatively little HTML and then populate the page through JavaScript. It also notes that heavy client-side rendering can create additional performance work and delay discovery of page resources.
That does not mean CSR is automatically bad.
It means crawler access becomes more dependent on what happens after the first response.
What is prerendering?
Prerendering, or static rendering, generates the HTML before the request happens.
Instead of generating the page each time a visitor arrives, the system builds a ready-to-serve HTML file in advance.
For content that does not need to change every second, this can be a strong option.
Examples might include:
- product feature pages
- documentation
- service pages
- marketing landing pages
- blog articles
- comparison pages
web.dev notes that static rendering can provide fast initial content delivery because the HTML is generated ahead of time and can often be served efficiently through a CDN.
There is one terminology trap here.
Static prerendering is not the same as dynamic rendering.
Google now describes dynamic rendering, where crawlers are deliberately served a rendered version while users receive another version, as a workaround rather than a recommended long-term solution. Google recommends server-side rendering, static rendering or hydration instead.
Google’s guidance on dynamic rendering
SSR vs CSR for AI search
| Approach | What the first response contains | Crawler dependency | Typical trade-off |
|---|---|---|---|
| Server-side rendering | Meaningful HTML | Lower | More server/rendering complexity |
| Client-side rendering | May contain only an app shell | Higher | Strong app flexibility, heavier JS dependency |
| Prerendering / static rendering | Complete prebuilt HTML | Lower | Content may need rebuilding when it changes |
None of these is universally “best”.
The right choice depends on what the page does.
A logged-in analytics dashboard may legitimately depend heavily on client-side rendering.
A public SaaS feature page whose job is to attract new customers has a different requirement.
That page benefits from be
Why client-side rendering can create crawler problems
Google is unusually capable here.
Google Search processes JavaScript pages through three broad stages:
crawling → rendering → indexing
Google can execute JavaScript using Chromium and analyse the resulting rendered HTML.
But even Google documents limitations.
Some content may fail to appear in rendered HTML, resources can fail and JavaScript implementations can create indexing problems. Google therefore recommends testing rendered output using Search Console’s URL Inspection Tool or the Rich Results Test.
Google also explicitly says:
server-side or prerendering remains useful because not all bots can run JavaScript.
That sentence is particularly important for GEO.
You should not assume:
Google can render this, therefore every AI crawler can render it.
OpenAI confirms that OAI-SearchBot is used for automatic ChatGPT Search discovery and must be allowed if a business wants its pages eligible for those search answers. Its crawler documentation explains access and user-agent behaviour, but does not document a Google-equivalent JavaScript rendering pipeline.
OpenAI’s official crawler documentation
The cautious conclusion is therefore:
Important public information is safer when meaningful HTML is already present in the response.
Is React bad for AI search?
No.
React itself is not the problem.
The rendering architecture is.
A React site can be:
- client rendered
- server rendered
- statically generated
- streamed
- hybrid rendered
Modern frameworks can produce excellent server-rendered or statically generated pages.
The problem appears when the implementation means the initial response contains very little meaningful content and everything commercially important depends on JavaScript running afterwards.
So instead of asking:
Is React bad for SEO or GEO?
Ask:
What HTML does this URL return before the application’s JavaScript executes?
That is a much better diagnostic question.
What about Vue?
Same principle.
Vue can be used for client-side applications, but it can also be server rendered or used through frameworks that support server-side and static output.
The framework name tells you less than the actual output.
Ask what the server returns.
What about WordPress and Elementor?
WordPress is not automatically a client-side rendered platform.
Most traditional WordPress pages deliver substantial HTML from the server.
Elementor is also not automatically an AI crawlability problem.
A normal Elementor heading or text block will often be included directly in the page HTML.
Problems are more likely to appear when specific components rely on JavaScript to retrieve or create important content.
Examples include:
- third-party sliders
- interactive comparison widgets
- dynamically loaded tabs
- AJAX content
- counters that begin at 0
- API-powered grids
- custom React components embedded inside WordPress
So do not rebuild a WordPress or Elementor site just because somebody says:
JavaScript is bad for AI.
Test the actual output first.
How to tell which rendering method your site uses
You do not need to understand the entire codebase.
Start with one commercially important page.
Test 1: View Source
Open the page.
Copy an important sentence.
Then open:
view-source:https://yourdomain.co.uk/page/
Search for the sentence.
If it is there, it was included in the initial HTML response.
If it is absent but visible on the finished page, JavaScript may be inserting it.
Test 2: Disable JavaScript
Temporarily disable JavaScript and reload.
Ask:
- Is the H1 still there?
- Can you see the service description?
- Are prices present?
- Are FAQs available?
- Are internal links present?
- Is the page still understandable?
This does not simulate every crawler.
It tells you how dependent the page is on JavaScript.
Test 3: Ask your developer for the raw response
For a more technical check, ask for the server response using curl.
For example:
curl -L https://example.com/product/
Then compare that HTML with the rendered DOM.
That difference tells you a lot.
For a full practical walkthrough, see:
Why your website may be invisible to AI search because of JavaScript
Which rendering option should you choose?
Do not choose based on GEO alone.
Choose based on the type of page.
Public marketing pages
For pages designed to attract buyers, SSR or static rendering is usually easier to make robust for both users and crawlers.
Think:
- homepage
- service pages
- feature pages
- landing pages
- documentation
- pricing pages
- case studies
Highly interactive applications
CSR may make much more sense for areas such as:
- dashboards
- internal tools
- account interfaces
- complex configurators
- authenticated applications
Those pages may not even need public search visibility.
Mixed products
A hybrid approach is often perfectly reasonable.
Your public SaaS website could be server rendered or static.
Your logged-in application could remain heavily client rendered.
You do not need one rendering strategy for every URL on the domain.
What does each option cost?
Not just money.
There are four kinds of cost worth discussing.
Development complexity
SSR introduces server-side rendering infrastructure and often hydration concerns.
Infrastructure
Dynamic server rendering can require more compute than serving prebuilt files.
Publishing workflow
Static rendering may require builds when content changes.
Technical debt
Retrofitting SSR into an established client-rendered application can be more involved than choosing the architecture at the beginning.
web.dev notes that SSR itself has trade-offs, including potentially higher TTFB and added complexity, while static rendering can avoid some server-generation overhead.
The right answer is therefore not:
SSR at any cost.
It is:
Make the public content that drives discovery reliably available, using the least complicated architecture that achieves that.
Questions to ask your developer
You do not need to ask:
Are we using hydration with streamed React server components and partial revalidation?
Ask questions tied to the business outcome.
1. Is our important page copy present in the initial HTML response?
If yes, good.
If not, ask why.
2. Which parts of the site require JavaScript before their content exists?
Get a specific list.
3. Are our public service, product and pricing pages server rendered or statically generated?
These usually deserve more scrutiny than logged-in app screens.
4. If JavaScript fails, what important information disappears?
Focus on meaning.
Not animations.
5. Can important content be moved into server-rendered HTML without rebuilding the whole application?
Often the answer is yes.
6. Are we using dynamic rendering specifically for bots?
If so, ask whether it is still necessary.
Google now calls dynamic rendering a workaround and recommends SSR, static rendering or hydration for long-term solutions.
7. How are we testing rendered output?
For Google, use tools such as URL Inspection and the Rich Results Test.
For wider crawler testing, compare raw HTML, rendered HTML and server/CDN logs.
Does fixing rendering require a rebuild?
Usually not.
That depends on how deeply the rendering architecture is embedded in the site.
Sometimes the problem is one component.
For example:
- a pricing table loaded through JavaScript
- a FAQ widget that fetches answers after interaction
- a dynamic service grid
- an API-fed location module
Changing that component may solve the visibility issue.
Other sites may be full single-page applications where every public URL depends on client rendering.
Those can require more substantial architectural work.
But even there, the first question should be:
Which pages actually need search and AI visibility?
You may only need to change the rendering strategy for the public commercial layer.
That is much more practical than rebuilding the entire product.
For broader traditional technical SEO support, see Lobo Digital’s SEO services.
For the AI-search layer, see Generative Engine Optimisation.
Frequently Asked Questions About Rendering and AI Search
Common questions about server-side rendering, client-side rendering, WordPress, Elementor, prerendering and how JavaScript can affect AI search visibility.
Is WordPress affected by server-side vs client-side rendering?
Yes, but most conventional WordPress content is server rendered.
Issues are more likely to arise when plugins, widgets or custom components load important information through JavaScript after the initial HTML response.
Does Elementor cause AI search problems?
Not automatically.
Many Elementor elements output their content directly into server-generated HTML. Individual third-party widgets or dynamic components may behave differently, so test the actual page rather than judging the platform name.
Is prerendering a good fix for client-side rendering?
It can be.
Static prerendering can generate complete HTML ahead of time, which works particularly well for stable marketing and content pages.
Do not confuse this with dynamic rendering, where crawlers and users receive different rendering paths. Google now considers dynamic rendering a workaround rather than a preferred long-term solution.
Does Google need server-side rendering?
Not necessarily.
Google can execute JavaScript using its Web Rendering Service.
However, Google still recommends SSR or prerendering as useful approaches because they improve reliability and not every bot can execute JavaScript.
Can ChatGPT render JavaScript websites?
OpenAI documents how OAI-SearchBot accesses websites for ChatGPT Search, but its public crawler documentation does not publish a Google-equivalent JavaScript rendering specification.
For that reason, do not assume that content requiring client-side rendering will be processed identically across every AI search platform.
How much does it cost to switch from CSR to SSR?
There is no useful universal figure.
The cost depends on:
- framework
- hosting setup
- application complexity
- number of routes
- data sources
- caching
- authentication
- whether only public pages need changing
A handful of marketing pages may be relatively straightforward.
Retrofitting SSR into a large single-page application can be a significant development project.
Get your developer to scope the affected public pages first before discussing a full rebuild.
The important question is what the crawler receives
Rendering terminology gets complicated quickly.
The business decision does not have to.
When someone requests an important public page, ask:
Does meaningful content arrive in the HTML?
If yes, you are less dependent on the crawler running your JavaScript correctly.
If no, find out what has to happen before the page becomes useful.
That does not automatically mean you need SSR everywhere.
It means you should be deliberate about where client-side rendering is doing useful product work and where it is creating unnecessary dependency for public content.
For SaaS and technology businesses, that separation is particularly useful:
Let the application behave like an application.
Let the public website behave like a website that needs to be found.
If you are unsure what AI crawlers currently receive from your site, Lobo Digital’s audit can check technical access alongside wider AI-search visibility.
