---
title: "JavaScript SEO for AI-Built Websites: Why Google and ChatGPT Ignore Your Site"
slug: "javascript-seo-ai-built-websites"
url: "https://fimo.ai/blog/javascript-seo-ai-built-websites"
category: "Marketing"
date: 2026-09-18T19:43:16.160Z
description: "Javascript SEO is sort of an oxymoron. Google dislikes it, and ChatGPT can't read it. The good news? Fimo fixes the situation instantly. "
---

# JavaScript SEO for AI-Built Websites: Why Google and ChatGPT Ignore Your Site

_Javascript SEO is sort of an oxymoron. Google dislikes it, and ChatGPT can't read it. The good news? Fimo fixes the situation instantly. _

## Key Takeaways

- Most Javascript seo problems on AI-built sites trace back to one decision nobody made on purpose, whether a page is rendered on the server or assembled in the browser.
- Google runs your JavaScript after a rendering queue, and the crawlers behind ChatGPT, Claude and Perplexity don't run it at all, so a client-rendered page shows up late in Google and never in AI answers.
- Hosted builders have reacted. Lovable moved new apps to server-side rendering on 13 May 2026, Base44 serves crawlers a rendered copy of each page, but [Bolt.new](http://Bolt.new) still defaults to a Vite and React app.
- Claude Code, Codex and Cursor have no default at all. They build what the prompt implies, so if you never mentioned rendering, you got whatever was quickest to build.  
  

AI coding agents are now building most websites (sorry, Squarespace and [Webflow](https://fimo.ai/compare/webflow)!). That means we’re all prompting Claude Code or Cursor to get our websites just the way we want them.

But there’s a hidden issue lurking beneath the code. It looks pretty, but it’s often some form of Javascript, which Google, Claude, and ChatGPT can’t crawl and read. Which kind of makes Javascript SEO an oxymoron. 

## Used AI to build your website? Sorry…it’s probably Javascript.

Every tool below produces a JavaScript site. React, Vite, Next.js and TanStack Start are all JavaScript, and to a non-developer the names look unrelated, so the third column translates each one. The column that decides your fate is the last one, what a crawler gets before any JavaScript runs, because for most AI crawlers that first response is the last thing they'll ever see.

| Tool | What it builds by default (vendor's words) | In plain English | What a crawler gets first |
| --- | --- | --- | --- |
| Lovable, new apps (since 13 May 2026) | TanStack Start with server-side rendering | A JavaScript site that builds each page on the server and sends finished HTML | The full page |
| Lovable, older apps | React + Vite single-page app | A JavaScript app that builds the page inside the visitor's browser | A rendered copy for verified crawlers (Google, Bing, ChatGPT, Perplexity, Claude, Gemini), an empty shell for everyone else |
| Base44 | React app built with Vite, client-side rendered | The same, assembled in the browser | A rendered copy for search and AI crawlers, refreshed when you publish |
| [Bolt.new](http://Bolt.new) | React, Vite, Tailwind CSS and Node.js unless you ask for another stack | The same, assembled in the browser, with no crawler copy | An empty shell and script tags |
| Claude Code, Codex, Cursor | No default, whatever the prompt implies | Almost always a JavaScript site; server or browser depends on the framework the agent picked | Depends entirely on that framework |

The bottom line is, unless you specifically asked for a non-JavaScript website that’s SEO and GEO optimized, you likely have a JavaScript website on your hands. 

## Javascript SEO decrypted: Why Google can (sort of) read Javascript and why ChatGPT can't read it at all

Google processes JavaScript in [three phases](https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics), crawling, rendering and indexing. Googlebot fetches the raw HTML, queues every page that returned a 200 for rendering, and once resources allow a headless Chromium runs the scripts and Google indexes the result. Google's doc says a page "may stay on this queue for a few seconds, but it can take longer than that", and when Vercel and the agency MERJ [matched 37,000 crawl and render events on ](https://vercel.com/blog/how-google-handles-javascript-throughout-the-indexing-process)[nextjs.org](http://nextjs.org) in 2024, the median gap was 10 seconds, the 75th percentile was 26 seconds, the 90th was around three hours and the 99th around 18 hours. So Google gets there, usually fast and sometimes the next day.

AI crawlers don't get there at all. The same Vercel and MERJ team [analysed AI crawler traffic across the Vercel network](https://vercel.com/blog/the-rise-of-the-ai-crawler) in December 2024 and found that none of the major ones execute JavaScript, OpenAI's, Anthropic's and Perplexity's included. GPTBot downloaded JavaScript files in 11.50% of its requests and ClaudeBot in 23.84%, and neither ran a line of it. The exceptions were Gemini, which rides on Googlebot's rendering, and Applebot, which crawls with a browser. A [server-log study from May 2026](https://roiandshine.com/blog-ai/geo-seo/ai-bots-server-logs/), 43,345 requests on one domain over 26 days, a small but clean sample, found the ChatGPT and Perplexity fetchers requested 0% of JavaScript, CSS and image files while Googlebot pulled 60% of them and Applebot 79%. And Google's JavaScript SEO page, updated March 2026, still says server-side or pre-rendering is a great idea because "not all bots can run JavaScript".

## The 60-second test for Javascript SEO issues

Open your homepage, right-click, choose View Page Source, and search for a full sentence from your main content, something from the hero or the first paragraph. 

If the sentence is there, crawlers can read it, and if the source is a <div id="root"></div> and a stack of script tags, your content only exists after JavaScript runs and the right-hand column of the table is describing your site. Check your title tag, meta description, canonical and JSON-LD the same way, because they're just as invisible if a script injected them.

## Claude Code and Codex don't have a default, so tread carefully

Claude Code, Codex and Cursor aren't website builders. They're agents that write code, and they write whatever the prompt implies. Ask for a marketing site with a blog and you'll usually get Next.js, because the model associates blogs with search. Ask for "a website for my consultancy" with nothing else and you'll often get Vite and React, because it's the smallest thing that looks finished in the preview, and you'd hope the agent would pause to ask how the pages should render, but for some reason they rarely do. 

Some AI coding agents are making moves to help their users. For most of its life Lovable generated React and Vite single-page apps as static files, and its own engineering blog now describes a client-rendered app on first request as "a near-empty HTML shell" that is "effectively invisible" to crawlers. In May 2026 it [moved every new project to TanStack Start with server rendering](https://lovable.dev/blog/building-apps-using-tanstack-start) and started pre-rendering older apps for verified crawlers, and it reports a 2.9% lift in organic search traffic and a 98.5% lift in traffic from AI tools across the apps using that pre-rendering. 

## How to fix javascript SEO on an AI-built site: Server-side rendering, pre-rendering, or one line in the prompt

Which of the three fixes you need depends on where you landed in the table.

1. **Render on the server. I**f the site is on Next.js, Astro, SvelteKit, TanStack Start or React Router in framework mode, this is mostly already true, and the work is checking that content, metadata and JSON-LD come from the server rather than a component that fetches after load. If it's a Vite single-page app, the fix is moving it to one of those frameworks, which for a dozen-page marketing site is in practice a day or two with the same agent that built it, since the components carry over.
2. **Pre-render for crawlers. **What Lovable does for its older apps and Base44 does for all of them. A service detects a verified crawler and serves a rendered snapshot while humans get the app, and it's the right answer when you can't touch the codebase. The cost is two versions of every page, a snapshot that goes stale between publishes, and a shell for anything that isn't a verified crawler.
3. **Fix the prompt.** If you're building with a coding agent and haven't shipped yet, this is one sentence. Name the framework and say every public page has to return its content, title and description in the initial HTML, and the problem never exists.

Teams put this off because the site looks finished, Google does index it eventually so Search Console reads as a delay rather than a defect, and rebuilding something you paid for last month feels like admitting the first build was wrong. What waiting costs is every page you publish in the meantime being unreadable to the answer engines your buyers ask first.

## How Fimo fixes the entire Javascript SEO dilemma

We built Fimo to turn AI code into autonomous websites. One thing we fixes on the way there, was helping people avoid the Javascript SEO dilemma. 

Here’s how it works.

You hand Fimo the site your coding agent built. If it's one of the browser-built JavaScript apps in the table above, Fimo rebuilds it on Astro or [Next.js](http://next.js) (two frameworks that support server-side rendering, meaning that Google reads it on the first visit and so does ChatGPT).

That's the rendering problem gone without anyone rewriting the site by hand. Then, Fimo’s autonomous agents stop the issue from ever returning, by converting any new code your AI coding agent produces. Plus, Fimo’s autonomous agents handle things like SEO, content updates, internal linking, translations, and more, while you sleep. 

So by introducing Fimo, you barely have to lift a finger to solve the Javascript SEO issue. 

You can [find out more about Fimo’s SEO agents here](https://fimo.ai/features/seo-geo), and then I recommend going through our [website GEO checklist](https://fimo.ai/blog/website-geo) which covers what to do once crawlers can finally read your website.

## Make the JavaScript rendering decision before you write another page

Building pretty websites is no longer hard. Making the right call (and the right prompt) to ensure the prettiness gets crawled is what will make a real difference. 

To avoid any issues either way, [just bring Fimo into the mix, for free](https://fimo.ai/for-marketers). Javascript SEO problems, solved!

## FAQ

### Does Google index JavaScript websites?

Yes, once it has rendered them. In the [nextjs.org](http://nextjs.org) data a quarter of pages rendered within four seconds of the crawl and half within ten, so on a small site the lag is usually minutes and the problem is the long tail.

### Is SSR necessary for javascript seo?

Not strictly for Google, which can render, but it's the only approach that gives every crawler, verified or not, the same full HTML on the first request, and it's what Google's own guidance recommends alongside pre-rendering.

### Why is JavaScript bad for SEO?

On its own it isn't. JavaScript that adds interaction to a page whose content, title and links already sit in the HTML causes no indexing problems, and the trouble starts only when the script has to run before those things exist.

### Which JavaScript framework is best for SEO?

Any framework that renders on the server by default, and Next.js, Astro, SvelteKit, TanStack Start and React Router in framework mode all do. A plain Vite and React app doesn't, unless the platform hosting it adds pre-rendering.

### What should I put in a Claude Code prompt to avoid this?

Name a server-rendering framework, state that every public page must return its content, title, meta description and canonical in the initial HTML, and ask the agent to prove it by fetching a built page without a browser and showing you the source.

  

