AI-generated Astro sites: fast, static, and often saying the same thing
Astro renders pages to static HTML by default, with server rendering available when you opt into it, and ships JavaScript only for the interactive islands you mark. That makes an AI-generated Astro site one of the friendliest stacks for crawlers and for the IntentGrid demo: the copy is in the HTML. What it does not fix is sameness. Generated Astro sites converge on the same starter themes, Tailwind defaults and median copy as any other, and that part is editorial.
Last updated 2 October 2026.
Why AI-generated Astro sites still converge
Astro solves rendering and performance. It has no opinion about what your page says.
- Starter themes. Generated and template-based Astro sites tend to start from a small set of popular themes, and their layouts show through.
- Tailwind defaults: the same spacing, type scale and shadows, unless someone changes them.
- Blog-shaped landing pages. Astro is popular for content sites, so generated marketing pages often borrow the shape of a blog home: hero, latest posts, newsletter box.
- Copy written for nobody: “Insights to help you grow”, “Join thousands of readers”.
Because Astro pages are mostly .astro files and Markdown, these are some of the easiest fixes on any stack.
What IntentGrid does and does not do on an Astro site
IntentGrid rewrites the words for each visitor: headlines, body copy, feature descriptions and button labels, based on how they arrived (traffic source, campaign, approximate city, device, language, local time). It adapts the copy already on the page, and brand names, prices, dates and numbers stay as written.
It does not touch your repository, your content collections, your components or your build output, and it does not change design. It is not a traffic source.
The working part today is a demo that renders a rewritten copy of any 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 details.
Static by default: what the demo can read
An Astro page is rendered to HTML at build time unless you opt it into server rendering, and either way the copy is in the HTML response. Components from other frameworks used inside Astro, such as React or Svelte, are rendered to HTML too, unless they are told to render only in the browser. So the demo usually gets your real copy.
The one trap is a component with the client:only directive. It renders nothing into the HTML, so any copy inside it is invisible to the demo and to crawlers that do not run JavaScript. If your hero or pricing lives in a client-only island, move the text out of it and keep only the interactive part inside.
An illustrative before and after
- Default, the same for everyone
- Insights to help you grow your indie game
- Arrived from a game-dev forum thread, on a laptop, late at night
- Weekly teardowns of how small indie games found their first players
- Tapped a link in a podcast's show notes, on a phone
- Start with a free issue: one indie game teardown, every week
Same layout, same prices, same claims. Every version uses only what the original page already says: in this made-up case, weekly teardowns and a free sample issue.
Fixes in an Astro codebase
Mostly edits to .astro and Markdown files:
- Move hero and section copy into a content collection or one data file, so the words are edited in one place instead of hunted through components.
- Pass a real title and description from each page into your layout's head, instead of inheriting one site-wide default.
- Retheme Tailwind: your own colours, type scale and a typeface the starter does not use.
- Remove the theme's stock sections you do not need. A blog-shaped landing page for a product that is not a blog reads as a template.
- Keep copy out of client-only islands. Text belongs in the static HTML; only behaviour needs JavaScript.
The design side, and why AI tools converge on the same defaults, is in why vibe coded websites look the same.
Astro questions
Does the IntentGrid demo work on Astro sites?
Usually very well, because Astro renders pages to HTML by default and the copy is in the response. The exception is text inside a component that only renders in the browser, which the demo, like a crawler that does not run JavaScript, cannot see.
Does per-visitor copy undo the point of a static Astro site?
It does not have to. Crawlers and visitors without context get the static default page. On-domain adaptation is designed to adapt the HTML a browser receives and to serve crawlers the canonical page at one URL; it is early access and not a self-serve product yet.
Do I need an Astro integration for IntentGrid?
Not for the demo, which works on any public URL. On-domain adaptation is designed to need no framework integration and no rebuild, and how it is installed will be published when it ships.