The AI-built React + Vite site: a nice page that crawlers barely see

Vite is a build tool and React is a UI library; neither has a look. The look arrives with the defaults.

• The usual pairing: React, Vite, Tailwind, a component kit such as shadcn/ui and an icon set, chosen because models have seen them together most often.
• Everything in one bundle. The landing page and the app share a component tree, so the marketing copy is written and reviewed as part of the app, which in practice means barely at all.
• Copy written for no one, because the brief was about features.

These are easy to change. The rendering problem below decides whether anyone reads the copy at all.

IntentGrid rewrites the visible copy for each visitor: headlines, body copy, feature descriptions and button labels, based on how they arrived. It adapts the copy you already have, and brand names, prices, dates and numbers stay as written. It needs that copy to exist in the HTML it receives.

It does not touch your code, your bundle or your hosting, it does not run JavaScript for you, and it does not change design. On a page whose HTML is an empty root element, there is nothing for it to rewrite.

Today the working part is a demo that renders a rewritten copy of a public URL in a sandbox on intentgrid.ai; adaptation on your own domain is early access, set up per site by hand. How it works has the full mechanism.

A default Vite React app serves index.html for every route: the head you wrote, an empty root element and a module script. The demo fetches that file and strips the script, so it receives the shell and the preview comes back nearly blank. Any crawler that does not run JavaScript, including many AI crawlers, gets the same shell. Google renders JavaScript, so it can usually still index the page, with some delay.

Client-side routing adds a second trap. A deep link such as /pricing only works if your host sends every path to index.html; if it does not, the page loads fine when you click through to it and returns a 404 when someone opens the link directly. Open a deep link in a private window to check.

Prerender the marketing routes. A prerendering step at build time renders the landing and pricing pages to static HTML, while the app stays a single-page app. This is usually the smallest change.

Move the landing page to a static site. Put the marketing pages in a static-first framework such as Astro, or in plain HTML, and keep the React app on its own path or subdomain.

Adopt server rendering. A React framework with server rendering solves it for every page, at the cost of a migration. Worth it for a content-heavy site, rarely for a single landing page.

Same layout, same prices, same claims. Every version uses only what the original page already says: in this made-up case, RAW support, no install, and editing on a phone. On a client-rendered build, none of these headlines would reach the demo until the copy is in the HTML.

In order:

• Write a real title and meta description in index.html. For a client-rendered app it is often the only text crawlers and link previews ever see.
• Get the landing page into the HTML, using one of the three routes above.
• Make sure deep links work when opened directly, so shared links to /pricing or /docs do not 404.
• Rewrite the hero yourself. Then ask your AI tool to list every other headline and button label, and rewrite the ones that could belong to any product.
• Change the component kit's theme, the font and one stock section, so the page stops reading as the starter.

Why every generated site lands on the same defaults is covered in why vibe coded websites look the same.