Many sites hide their content behind JavaScript that runs in the browser. Google can usually handle this, but most AI crawlers cannot. They read only the raw HTML your server sends. If your words load after the page does, an AI engine sees an empty shell and cannot cite you.
We run into this a lot when a client wonders why ChatGPT or Perplexity never mentions their brand. The site looks fine to a human. But the actual text lives in JavaScript that the AI crawler never runs. The machine sees a blank frame where the answer should be.
This is one reason we care so much about how a site is rendered. Getting content into the raw HTML is not a nice-to-have anymore. It is the difference between being a source that both Google and AI answer engines can read, and being invisible to half the search world.
JavaScript rendering is when a page uses JavaScript to build or fetch its content after the initial HTML loads. Instead of the server sending a finished page, it sends a near-empty file plus scripts. The browser then runs those scripts to fill in the text, images, and links you see.
This approach powers many modern sites built with frameworks like React and Vue. It can make for smooth, app-like experiences. The trade-off is that the meaningful content is not in the first response from the server. It only appears once a device runs the JavaScript successfully.
For a human on a fast phone, this usually works fine. For a crawler, it depends entirely on whether that crawler runs JavaScript. And as we will see, the machines reading the web for search and AI do not all play by the same rules.
Google handles JavaScript in phases. According to Google Search Central documentation, Googlebot first crawls the raw HTML, then queues the page for rendering, where its Web Rendering Service runs the JavaScript using an evergreen version of headless Chromium. Only after that render can Google index the content the scripts produced.
The catch is that rendering is not instant. The page waits in a render queue, and that wait can stretch from hours to much longer. During that gap, Google only knows what was in the raw HTML. If your key content and links are missing there, indexing is delayed or incomplete.
So even for Google, which does run JavaScript, putting content in the initial HTML is safer and faster. It removes the render step from the critical path. The page can be understood and indexed on the first pass, instead of waiting in line for the rendering service to catch up.
No. The major AI crawlers do not run JavaScript. OpenAI's GPTBot, Anthropic's ClaudeBot, and PerplexityBot all read only the raw HTML your server returns. They do not wait for scripts, and they do not render the page. Whatever is not in that first response is invisible to them.
This is the single most important fact for anyone who wants to show up in AI answers. Google may eventually render your JavaScript content, but the AI crawlers never will. If your article text is injected by a script, these engines see a page with no article on it.
We see this cut both ways. Sites with content baked into the HTML get quoted by AI engines. Sites that rely on client-side rendering get skipped, even when their content is excellent. Our guide to getting cited by AI search engines covers the wider habits that help, but rendering is the foundation.
Client-side rendering means the browser builds the page using JavaScript after loading a mostly empty HTML file. It can hurt SEO because crawlers may see that empty file first. Google might render it later, but AI crawlers never do, so your content risks being missed by the tools that matter most.
The problem is not JavaScript itself. It is where the content lives. A single-page app that fetches its text after load looks great to a user and blank to a crawler that does not execute scripts. The richer your site, the more content you can accidentally hide this way.
There is a speed cost too. Client-side rendering asks the visitor's device to do the work of building the page, which slows the first paint and can hurt your Core Web Vitals. The result is a page that is slower for humans and harder to read for machines at the same time.
Server-side rendering and static prerendering both put finished content into the HTML before it reaches the browser. Server-side rendering builds the page on the server for each request. Static prerendering builds the pages ahead of time and serves them as ready-made HTML files. Both mean crawlers see real content immediately.
Static prerendering is often the strongest choice for content sites and blogs. The pages are generated at build time, so every crawler, human, and AI engine gets the full text in the first response. There is no render queue to wait in and no script that must run first.
Tools like Next.js and build systems such as Vite make this practical. You get the developer experience of a modern framework and the crawler-friendliness of plain HTML. The content that matters is right there in the source, ready to be read, indexed, and cited.
You check by viewing the raw HTML, not the rendered page. Right-click and choose "view page source", or fetch the URL with a tool that does not run JavaScript. If your main content and links appear in that raw source, crawlers can read them. If not, they cannot.
A quick test is to disable JavaScript in your browser and reload the page. If the content vanishes, that is roughly what an AI crawler experiences every time. It is a humbling test to run on a site you thought was fine, and it reveals the gap between what humans and machines see.
For a deeper check, Google Search Console has a URL Inspection tool that shows how Googlebot renders a page. Pair that with a plain source view, and you get the full picture. You will know exactly which content is safe in the HTML and which depends on a script that may never run.
We build so that content lives in the HTML from the first byte. Our own blog is statically prerendered, which means the full article text sits in the static source before any JavaScript runs. Every crawler, from Googlebot to the AI engines, can read and cite it right away.
This is a deliberate choice, not an accident. We would rather do the rendering work at build time than gamble on a crawler running our scripts. It keeps pages fast and keeps content visible. Clean, semantic markup is part of the same discipline, which we cover in our piece on why semantic HTML matters.
It also pairs with our focus on speed. Prerendered pages have less to block and less to compute, which is why we can keep our projects at an average PageSpeed score of 98. The same setup that makes a page fast also makes its content easy for machines to read. Reducing render-blocking resources is the natural next step once the content is in the HTML.
You should worry if your content only appears after JavaScript runs. Test the raw source. If your key text is missing, you are likely invisible to AI engines and slow to index in Google. If your content is already in the HTML, you are in good shape and can focus elsewhere.
The stakes have risen with AI search. A few years ago, a client-side app that Google eventually rendered was a manageable risk. Now, with so many people asking AI engines for answers, being unreadable to those crawlers means missing a fast-growing channel entirely.
Our honest view is that most content-driven sites should avoid pure client-side rendering. The convenience is not worth the visibility cost. Prerender or server-render the pages that carry your important content, and let JavaScript enhance the experience rather than hide the words.
Open your most important page, view the raw source, and confirm the real content is there. If it is missing, plan a move to server-side rendering or static prerendering for those pages. Start with the content that should rank and get cited, then work outward from there.
If this feels technical and you would rather have a team make your content readable to both Google and AI engines, we are happy to help. We rebuild sites so their words live in clean, fast HTML that every crawler can read. Reach out at phoenix.studio, and let's talk about what your crawlers actually see.
Tell us where you want to go. We'll tell you how we'd get you there.