All posts

Vibe Coding 馃6 min read

Why AI-Built Websites Don't Rank on Google (And How to Fix It)

You published your AI-built store weeks ago, and Google still can't find it. The problem is usually one empty div. Here's the two-minute test that diagnoses it, why most AI builders generate sites Google struggles to read, and what actually fixes it.

By Juan Molina

Blog title card reading AI Sites That Do Not Rank, The Empty Div Problem, beside an illustration of a finished web page next to its raw HTML source and an empty search results panel

Imagine this: you just made your first AI website. Maybe with Manus, Lovable, or any of the other thousands. It looked incredible in the preview. You published it, told your friends, maybe even ran a few ads.

It's been months, and your website doesn't even show up when you type its own domain into Google. You ask yourself what you did wrong. You spend more on tokens rewriting pages, changing colors, adding sections, because you assume the problem is you.

Turns out, you fell into a trap most AI builders never tell you about. And once you see it, you can never unsee it.

聽

Check Your Site Right Now. It Takes Two Minutes.

Open your website, right-click anywhere, and choose View Page Source. Now look for your actual content. Your product names. Your headings. Your prices.

If they're there in the HTML, good news: your problem is elsewhere, and we'll get to that. But if what you see looks like this, keep reading, because you just found your answer:

<body>
  <div id="root"></div>
  <script src="/assets/index-8f3a2c.js"></script>
</body>

That's it. That's your entire website as far as the document is concerned. An empty box and a script.

What you're looking at is a client-side rendered React app, and it's the default output of most vibe coding sessions. Everything you built only appears after a browser downloads and runs that JavaScript bundle. Your browser does it instantly, which is why everything looks fine to you. Google is not your browser.

聽

CSR vs SSR: The Difference Nobody Showed You

Client-side rendering (CSR) ships that empty shell plus a JavaScript bundle, and makes every visitor's browser assemble the page. Server-side rendering (SSR)聽builds the page on the server and ships you finished HTML, content already inside.

Here's why that one difference decides whether you rank. Google can run JavaScript, but read聽their own documentation: rendering happens in a separate, queued phase after crawling. Your CSR pages wait in a line behind the rest of the internet's JavaScript. You have a new domain with zero authority, which means you're at the back of that line. Your pages get read late, shallowly, or in practice never. An SSR page skips the line entirely, because there's nothing left to render.

And the empty div is just the first domino. Look what falls after it:

Your metadata.聽A CSR single-page app usually ships one HTML file, meaning one title tag for your entire store. Your product pages can't tell Google what they are. Search for a product you sell and, at best, your homepage shows up with the wrong title.

Your share previews.聽Paste one of your product links into iMessage or Slack right now. See a naked URL with no image and no title? That's because social crawlers don't run JavaScript at all. Your link looks like spam to everyone you send it to.

Your heading structure.聽Google reads your page through its headings: one h1 saying what the page is, h2s for sections. A lot of vibe-coded output styles text to聽look聽like headings while the code underneath is a soup of divs. It looks structured to you. It reads as noise to a crawler. Looking right and being right are different things, and only one of them shows in the demo.

Your speed.聽Nothing paints until that bundle executes. That shows up in your聽Core Web Vitals, which Google uses as a ranking signal, and which your visitors feel as a white screen on their phone.

Your discovery.聽Many tools never generate a sitemap, so Google isn't even told your pages exist.

聽

The AI Isn't The Problem. The Missing Reviewer Is.

Here's the part that should actually give you hope: plenty of AI-built websites rank just fine. Most of the client sites we ship are AI-assisted, and they rank. The difference was never the AI.

The difference is whether anyone in the loop can read what came out. A developer prompting a builder spots the empty div in five seconds. You can't catch what you've never seen, and the demo looks identical either way. The tools aren't lying to you. They're just incapable of telling you what they did wrong.

So this isn't "you shouldn't have used AI." It's "nobody handed you the checklist." Now you have it.

聽

Your Two-Minute Audit

  1. View Page Source聽on a product page. Is your content in the HTML?
  2. Paste a product URL into Slack or iMessage.聽Does a real preview appear, with image and title?
  3. Search Google for聽site:yourdomain.com. How many of your pages actually show?
  4. Run a page through聽PageSpeed Insights. Is Largest Contentful Paint under 2.5 seconds?

Fail the first check and the rest follow from it. Pass all four and your problem isn't architecture, it's content and authority, which is a slower but very winnable fight.

聽

So How Do You Fix It?

Here's the hard truth: there's no toggle that converts a CSR site to SSR. The rendering model聽is聽the architecture. Your realistic options are rebuilding the frontend in a server-rendering framework like聽Next.js, or regenerating the site with a tool that outputs one.

The Problem... most if not all (with the exclusion of Vercel's V0 and a few others) strictly write websites with the React Library, which is in itself a CSR solution. You can try tell Lovable right now to go ahead and make a Next.js website and it will deny your request (as of September 9th 2026). Even in their own website, React Devs recommend that you use a Fullstack, SSR capable framework, and to not use React on its own, (https://react.dev/) "React is a library. It lets you put components together, but it doesn鈥檛 prescribe how to do routing and data fetching. To build an entire app with React, we recommend a full-stack React framework like Next.js聽or聽React Router."聽The reason most businesses refuse to code websites in Nextjs is because of the costs of tokens.

If you're not sure what you're looking at, or you'd rather have someone who does this daily read your site, our ecommerce SEO service聽starts with exactly this audit. And because the same team does聽storefront development, the audit doesn't end at a PDF listing problems nobody on your side can fix. We find it, we can fix it.

聽

We Felt Your Pain. So We Built The Fix Into The Tool.

We build ecommerce sites, and landing pages for a living, and we kept meeting the same person: proud of the website they described into existence, confused about why nobody could find it, and staring at a rebuild they never budgeted for.

That's why聽Forge, our AI web builder, writes into a real Next.js project instead of a client-side React sandbox. Server-side rendering by default, so your pages arrive at Google already readable.聽Per-page SEO fields聽that live on the product itself. A聽sitemap generated from your actual catalog, so every new product is a new indexed URL without you maintaining a list. And a codebase you can actually open and read, because output you can inspect is the entire difference between the sites that rank and the sites that don't.

Vibe coding was never your problem. Vibe coding into an architecture Google can't read was. Check your source, run the audit, and next time, describe your store into something that renders.

You can learn more about CSR vs SSR on our partner's website: https://www.codecraftstudios.net/blog/client-side-rendering-vs-server-side-rendering-everything-you-need-to-know, https://www.codecraftstudios.net/blog/nextjs-vs-react-key-differences-best-use-cases聽聽

Related Blogs

More from the blog, picked at random. Everything published is on the index.

1 of 15

Build on It Yourself

Sign up, take your keys, and scaffold a storefront against a real backend.

Why Vibe-Coded Websites Don't Rank on Google (+ The Fix) 路 DashForDevs