How your site is rendered affects whether automated systems can access your content — and whether that content can be considered for search results or AI-generated answers. Here is what that means in plain English, and why I chose a setup designed to make my content easy to read.
Content an AI system cannot access is far less likely to be used or cited.
That sounds obvious. Yet a website can look complete in your browser while delivering very little usable content in its initial HTML. The words, headings and links may only appear after JavaScript has run. For a person, that can be seamless. For an automated crawler, the experience may be different.
When I rebuilt my portfolio with AI, one of the first meaningful decisions had nothing to do with design, colours or copy. It was about something largely invisible: how each page would be assembled before a human or machine tried to read it.
As someone who works with SEO and AI search visibility, I saw this as a content strategy decision. If the content cannot be accessed reliably, its quality, structure and relevance have little opportunity to matter. Here is why content and marketing teams should care.
TL;DR: Search engines and AI services use automated crawlers to access web content, but their capabilities and processes vary. Some can render JavaScript; others may render it only in certain circumstances, with delays or with limited resources. If important content appears only after JavaScript runs, it can be harder for automated systems to retrieve consistently. Server-side or static rendering places the main content in the HTML delivered with the page, reducing that dependency. Rendering is therefore not just an implementation detail: it is a content and discoverability decision worth making early.
Can AI Read Your Website?
Server-side / Static Rendering
- Browser
- Server builds page
- Complete HTML
- Crawler sees content
Client-side Rendering
- Browser
- HTML shell
- JavaScript runs
- Content appears
- AI crawler may miss it
What does “rendering” mean, and why does it matter for SEO?
Rendering is the process of turning a website’s code into the page you see. The relevant distinction here is where and when the main content is assembled.
Client-side rendering: the browser receives a basic page and uses JavaScript to add some or all of the content afterwards.
Server-side or static rendering: the server or build process creates the page’s HTML before it is sent. The main content arrives ready to read.
To a person, the result can look identical. The difference becomes important when the visitor is an automated system with different rendering capabilities or limits. Rendering therefore determines not what you publish, but how reliably it can be accessed.
Can AI read a JavaScript website?
Sometimes. A website built with JavaScript is not automatically invisible to AI systems or search engines. The important question is whether the main content is present in the HTML they receive, or whether they must execute JavaScript to reveal it.
Automated crawlers do not all process pages in the same way. Some render JavaScript, while others may not do so consistently or immediately. If that step fails, is delayed or is unavailable, the system may receive only a sparse page shell.
The human visitor sees a complete article. The crawler may not see the same version.
This does not mean every client-rendered site will disappear from search or AI answers. It means discoverability depends on an extra layer of processing that content teams should understand rather than take for granted.
Why does rendering matter even more for AI search and GEO?
AI search adds another reason to make content straightforward to retrieve. For a page to be considered as a source, the relevant system first needs access to it — whether through live retrieval, a search index, an earlier crawl or another data source.
Rendering does not guarantee that a page will be selected or cited. Authority, relevance, clarity, freshness and many other factors still matter. But inaccessible content cannot compete on any of them.
For generative engine optimisation (GEO), serving meaningful HTML from the outset removes one avoidable obstacle.
Traditional SEO does not offer a guaranteed “second chance”, and AI systems do not all follow one process. A system can only use content it can access. Making that access easy gives search engines and AI-driven services a clearer page to work with.
This isn’t hypothetical: what I see at work
I regularly encounter websites that are polished for human visitors but reveal very little content in the HTML initially returned by the server. Their main copy depends on JavaScript being successfully processed. Google can render JavaScript, for example, but crawling, rendering and indexing are separate stages, and rendering can take longer than processing HTML that already contains the content. Google’s JavaScript SEO documentation explains this process in more detail.
That does not make the site universally unreadable to bots. It does mean the site is relying on each crawler to complete more work before it can reach the content. At scale, that dependency can become a discoverability and operational problem rather than a minor technical detail.
On one large production site I worked with, the main page copy was absent from the initial HTML and appeared only after client-side JavaScript had run. Once the limitations of that setup became a serious concern, there was no quick switch to flip. The organisation eventually had to introduce an external prerendering layer so that crawlers could receive a complete HTML version of the pages.
That expensive retrofit added infrastructure, vendor costs and another system to maintain — all to make existing content easier for automated visitors to access. Treating rendering as a content requirement earlier could have avoided much of that complexity.
This is why the decision should not be left until after the site has been designed and built. On a small site, choosing a suitable rendering approach at the start can be relatively simple. On a large production platform, correcting it later may be anything but.
Why I chose a server-rendered site for AI visibility
I chose Astro because it generates static HTML by default. In other words, the main content is built in advance and delivered as finished HTML. A crawler does not need to execute JavaScript to find the page’s headings, body copy and links. This default mode is known as static site generation, rather than server-side rendering on request. Astro documents static output as its default rendering mode.
That does not guarantee rankings or AI citations, and it is not a substitute for useful content. What it does is remove an unnecessary dependency between publishing the content and making it readable to automated systems. For this type of content-led site, static generation gives me the discoverability benefit I wanted without requiring pages to be rendered on demand.
When ChatGPT suggested a technology stack, I assessed it as someone whose job is to make content findable. I wanted the core information to be present when the page arrived, whether the visitor was a person or an automated system.
The implementation was technical; the reason for choosing it was strategic. Rendering shaped who could access the content, making it a content and discoverability decision as much as a development one.
How can I check whether AI can read my page?
You can carry out a useful first review without writing code:
- View the raw HTML. Open the page, right-click and choose “View page source”. Search for a distinctive sentence or heading from the main content. If it is present, the server has included it in the initial HTML. If it is absent and the source mainly contains scripts and empty containers, the page probably relies on client-side rendering for that content.
- Inspect the page in Google Search Console. Use URL Inspection to review how Google fetched the page and, where available, test the live URL and examine the rendered result. Google’s JavaScript troubleshooting guidance explains what the test can reveal.
- Ask how the site is rendered. If the site uses a JavaScript framework such as React or Vue, find out whether server-side rendering, static generation or prerendering is enabled for important public pages.
- Check more than one page type. A homepage, article, product page and category page may use different templates and rendering methods.
“View page source” is only a first check, not a complete rendering test. It does not show how every search engine or AI service processes the page, or confirm that the page has been crawled, indexed or considered for an answer. Use it to spot obvious dependencies, then combine it with platform-specific inspection tools, server logs or a technical crawl where appropriate.
If important copy is missing from the initial HTML, investigate before assuming automated systems will retrieve it reliably.
Client-side vs server-side rendering: which is better for SEO?
For content-led pages where search and AI discoverability matter, server-side rendering or static generation is generally the lower-risk option. Both can deliver meaningful HTML immediately, without requiring a crawler to run JavaScript before it reaches the main content.
Client-side rendering is not inherently bad for SEO. It may be entirely appropriate for interactive applications, logged-in tools and experiences that change in real time. Problems arise when publicly discoverable content depends on client-side JavaScript without a reliable rendered alternative.
Make sure the initial response contains the content you want search engines and AI systems to understand. Choose the rendering method around the purpose of the page, rather than treating one approach as universally best.
The bigger point: technical choices are content choices
We tend to treat technical implementation and content strategy as separate disciplines. Developers handle rendering; marketers handle the words. In practice, the way a page is built affects whether its content can be retrieved, understood and considered for discovery.
AI now makes it easier than ever to build a convincing website without understanding every technical choice underneath it.
Ironically, that makes the fundamentals more valuable, not less.
You do not need to become a software engineer. But if discoverability matters, you do need to ask what HTML the site delivers, what depends on JavaScript and whether the main content is accessible before scripts run. Those questions influence the reach of every article, landing page and resource you publish.
AI can help build the website. It cannot decide what “findable” needs to mean for your content strategy. That remains a human judgement.