Why every Cursor landing page reads the same

Cursor gives you far more control than a prompt-to-app builder, and the output still converges, for reasons that sit upstream of the editor.

• The model is the designer. Cursor sends your request to a model you pick from a short list, and the same few models are writing most new landing pages on the web. They share the same defaults.
• The default stack is the popular stack. Asked for a landing page, models reach for what they have seen most: Next.js or React, Tailwind, shadcn/ui, lucide icons. Good tools, identical output.
• The agent fills in the blanks. Ask for “a landing page for my API” and it decides the sections, their order and every word, picking the most common answer for each.
• Placeholder copy survives. The first draft's “Build faster. Ship smarter.” was meant to be replaced, and on a lot of shipped sites it never was.

The code is often good. The page is still interchangeable, because the decisions that make a page specific were never made by anyone.

IntentGrid rewrites the words for each visitor: headlines, body copy, feature descriptions and button labels, based on how that visitor arrived (traffic source, campaign, approximate city, device, language, local time). It starts from the copy you already have, and brand names, prices, dates and numbers are on a do-not-touch list.

It does not touch your repository. There is nothing to install for the demo, no change to your components, CSS, layout or build, and nothing for Cursor to merge. It will not fix a generic layout and it will not bring you traffic.

The working part today is a demo that renders a rewritten copy of any public URL in a sandbox on intentgrid.ai. On-domain adaptation is early access, set up per site by hand. How it works has the details.

What the demo sees depends on what you asked Cursor to build. A Next.js site prerenders or server-renders its pages by default, so the HTML already contains your copy and the demo has something to rewrite. A React single-page app built with Vite sends an empty root element and a script instead; the text only appears once JavaScript runs, and because the demo strips scripts, the preview can come back nearly blank.

You can check yours in ten seconds: open View Source (not Inspect) and search for your headline. If it is missing, the demo has little to work with, and so does any crawler that does not run JavaScript, which includes many AI crawlers. For a marketing page that is worth fixing regardless, and static generation of the landing route is usually a small change.

Same layout, same prices, same claims. Every version uses only what the original page already says: in this made-up case, YAML configuration and a status page that updates automatically.

Because the code is yours, you can fix most of this in the editor, and several of these take minutes.

• Put constraints in a rules file. Project rules live in .cursor/rules and can be applied to every request, so write the design and copy rules once: one accent colour, no gradient hero, no three-card row, a list of banned phrases.
• Move the copy into one file. Keep every headline, subheading and button label in a single content module instead of scattered through JSX. You will rewrite words far more often when they all sit in one place.
• Ban the median phrases: “streamline”, “seamless”, “unlock”, “empower”, “supercharge”, “next-level”. Then ask Cursor to find every sentence on the page that could appear on a competitor's site.
• Write the headline yourself, using the words a user wrote in an issue, a support email or a forum reply rather than the words the model offered.
• Hand-roll one variant per channel. If most traffic comes from two places, read the utm_source parameter and swap the headline for each. Keep the default for everyone else, including crawlers, and keep one URL.
• Server-render the landing page. If View Source shows no copy, make the marketing routes static. It helps crawlers and the IntentGrid demo alike.

The design half is covered in more depth in why vibe coded websites look the same.