The AI-generated Next.js site: why it looks familiar, and what renders where

Next.js is a framework, not a design. The familiar look comes from what gets layered on it by default.

• The same starter stack. Next.js with Tailwind and shadcn/ui is the most common answer a model gives, so the components, spacing and radius repeat from site to site.
• Starter leftovers. The starter font, a generic title and an empty description survive into production surprisingly often.
• One landing page for everything. A single route carries the whole pitch, written for an average visitor, instead of one page per question people actually ask.
• The median SaaS voice: “Ship faster”, “Built for modern teams”, “Get started for free”. Correct, unobjectionable, and on every other page.

Each of these is a few minutes in the codebase.

IntentGrid rewrites the words a visitor reads: headlines, body copy, feature descriptions and button labels, based on how that visitor arrived (traffic source, campaign, approximate city, device, language, local time). It adapts the copy you already render, and brand names, prices, dates and numbers stay as written.

It does not touch your repository, your components, your build or your caching, and it does not need a framework integration. It does not change design, and 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 explains the difference.

In the App Router, pages are server components by default and are rendered on the server or prerendered at build time. Components marked “use client” are still rendered to HTML on the server first and made interactive in the browser afterwards. So for most Next.js pages the copy is in the HTML response, and the demo can rewrite it.

The exceptions matter for crawlers as much as for the demo: text fetched in the browser after the page loads, components loaded with server rendering switched off, and content that only renders after a click. The demo strips scripts and sees the page as it first arrives, which is roughly what a crawler that does not run JavaScript sees too.

You can hand-roll a version of this. Read the utm_source search parameter in the page, map your two or three biggest sources to a headline each, and fall back to the default for everyone else, at the same URL. Crawlers arrive without the parameter and get the default.

Know the cost. Reading search parameters makes that page render per request instead of being served as a prebuilt file, which is fine for a landing page but worth doing on purpose. And every variant is copy you now maintain by hand. That is the point where a tool earns its place, and not before.

Same layout, same prices, same claims. Every version uses only what the original page already says: in this made-up case, a script-tag install, a config file, and fewer support tickets as the stated goal.

These are code changes, so you can make them with whichever AI tool built the site.

• Retheme shadcn/ui. Change the CSS variables for colour and radius so the components stop looking like everyone else's.
• Replace the starter font with next/font, and set a real title and description per route with the metadata API.
• Split the one long page. Give each real question its own route with its own title, so search and answer engines can land on the specific answer.
• Keep the copy in one content file, separate from the JSX, so changing words is a quick edit rather than a hunt.
• Check rendering with curl. Fetch your URL from the terminal and search the output for your headline. If it is missing, something is rendering only in the browser.

The design half, and why every AI tool lands on these defaults, is in why vibe coded websites look the same.