How to Optimize a Vibe-Coded Website for SEO and AI Search (2026 Guide)

Most vibe-coded websites ship with the same four problems, and all four are invisible in the browser. The text loads only after JavaScript runs, so some crawlers see a blank page. The titles still say the builder's default. The robots file, or the CDN in front of it, quietly turns away the bots that feed ChatGPT and Perplexity. And nothing on the page tells a machine who the company is.

None of this shows up when you click around your own site, which is why founders find out months later, when the site has no search traffic and no AI assistant ever mentions the brand.

This guide walks through the eight fixes in the order we apply them at fivetwentyone when a founder brings us a site built with Lovable, Bolt, v0, Replit, Cursor, or any other AI builder. It does not matter which framework the tool chose. The checks are the same, and most of them take an afternoon.

Step 1. Check what a crawler actually sees

The single biggest SEO problem on vibe-coded sites is that the page is empty until JavaScript runs. AI builders default to client-side rendering because it is the easiest thing to generate, and the result looks perfect to a human with a modern browser.

Googlebot can execute JavaScript, though it queues pages for a second rendering pass and does not always complete it. The crawlers behind AI answers are stricter. OpenAI's search bot and Perplexity's bot fetch the raw HTML and move on. If your copy arrives through a fetch call after the page loads, they index a shell.

The test takes thirty seconds. Open your homepage in Chrome, open DevTools, press Cmd+Shift+P (Ctrl+Shift+P on Windows), type "Disable JavaScript", and reload. Everything that matters for ranking should still be on screen, meaning the headline, the body copy, the navigation, and the links to other pages. Repeat on a product page and a blog post. If the page goes blank, the fix is server-side rendering or static generation, and every mainstream framework supports it. In Next.js it means moving content out of client components and useEffect. In Nuxt, SvelteKit, Astro, and Remix the equivalent setting is usually already on, and the builder turned it off. If you are on a hosted builder with no rendering option, that is a signal to pick a stack that can be found before you invest in content.

Step 2. Let the right bots in

A site can be perfectly rendered and still invisible because the front door is locked. Two things lock it, and vibe-coded sites often have both.

The first is robots.txt. Open yoursite.com/robots.txt in a browser. If it returns a 404, the file was never generated. If it says Disallow: / under User-agent: *, the builder copied a template meant for staging and nothing on the site can be indexed. The file should allow public pages, block private routes such as /api/, /dashboard/, and /admin/, and point to your sitemap. Google's robots.txt guide covers the syntax.

The second is the CDN. Cloudflare offers a one-click option to block all AI bots, and similar toggles exist in Vercel's firewall and most WAF products. Builders and hosting defaults sometimes switch these on. If you want ChatGPT, Perplexity, Claude, and Gemini to cite you, the search crawlers from each of them need to get through, specifically OAI-SearchBot, PerplexityBot, ClaudeBot, and Google-Extended. Blocking the training crawlers while allowing the search crawlers is a reasonable middle ground, and OpenAI and Anthropic document the difference between the two on their crawler pages.

A quick way to confirm access is to fetch a page with curl and the bot's user agent string. A 200 with full HTML means the bot is welcome. A 403, a challenge page, or a near-empty body means something upstream is in the way. Keep the rest of the firewall on while you do this, since the same settings that gate bots also cover the basics in our guide to securing a vibe-coded website.

Step 3. Give every page one address and a sitemap entry

Search engines index addresses, and vibe-coded sites tend to publish the same page under several of them. The www and non-www versions both resolve. Some links carry a trailing slash and some do not. UTM parameters create fresh copies every time a campaign runs. Each duplicate splits whatever authority the page earns.

The fix has three parts. Pick one canonical host, usually https plus either www or bare, and redirect the others to it permanently. Add a self-referencing canonical tag to every page so that a URL with parameters points back to the clean version. Then publish a sitemap at /sitemap.xml that lists every public page with an accurate last-modified date and leaves out anything gated behind login or marked noindex. Google explains the canonical rules and the sitemap format, and every framework can generate the sitemap from your routes rather than by hand.

Submit the sitemap in Google Search Console once it exists. The Pages report there will show you, within a few days, which addresses Google chose to index and which it quietly dropped as duplicates.

Step 4. Replace the placeholder titles and descriptions

Open your site in a tab and read the tab label. If it says "Create Next App", "Vite + React", "My App", or the name of the builder, that is the title Google shows in results. It is also the title an AI assistant sees when it decides whether your page answers a question.

Every public page needs its own title tag and meta description. Titles run 50 to 60 characters and lead with what the page is about. Descriptions run 140 to 160 characters and say what a visitor gets. Dynamic pages such as blog posts and product pages should generate both from their content rather than inheriting a site-wide default, because a hundred pages with the same title look like one page to a crawler.

Add Open Graph and Twitter card tags while you are there, including an image. Links shared in WhatsApp, Slack, LinkedIn, and inside AI chat interfaces render a preview from these tags, and a link with no preview gets fewer clicks. The Open Graph protocol page lists the handful of fields that matter.

Then check the opposite problem. Preview and staging deployments usually ship a noindex header so that test versions stay out of Google, and that header can follow the site into production. View the page source and the response headers for the live domain and confirm there is no noindex in either the meta robots tag or the X-Robots-Tag header.

Step 5. Fix the HTML skeleton

AI builders produce pages that look structured and are not. Headings are styled divs. Navigation fires a router call on click instead of being a real link. Images are raw img tags with no dimensions. All of this hurts both ranking and page speed, and all of it is mechanical to repair.

Each page gets exactly one h1 that states the page's subject, followed by h2 and h3 tags in order, without skipping levels. Navigation, pagination, and in-content links use anchor tags with real href attributes, because a crawler follows links and does not click buttons. Images declare width and height so the layout does not jump as they load, carry alt text that describes the picture, and the first large image on the page is flagged as high priority so it paints early. Fonts load through the framework's font tool or are self-hosted, which removes a render-blocking request to a third party.

These four changes are most of what moves Core Web Vitals, the three speed and stability scores Google uses as a ranking input. Run the live site through PageSpeed Insights before and after. The before score on an untouched vibe-coded site is often in the 40s on mobile, and the layout-shift score is the usual culprit.

Missing pages need attention too. A custom not-found page is fine, as long as it returns a real HTTP 404. Builders often make it return 200, which Google treats as a soft 404 and which wastes crawl budget on pages that do not exist. Once the site is live, watch the server logs or analytics for 404s on addresses you never created. AI assistants invent plausible URLs when they cite a brand, and a permanent redirect from each invented address to the real page turns that hallucination into a visit.

Step 6. Add structured data and say plainly who you are

Structured data is a block of JSON in the page head that describes the page in a vocabulary machines already understand. Google uses it for rich results, and AI engines use it to work out what kind of entity they are reading about. Vibe-coded sites almost never have it, because nothing visible depends on it.

The minimum set is an Organization schema on the homepage with the legal name, logo, contact details, and a sameAs list of your social profiles, a WebSite schema, and then one schema per content type, meaning Article for blog posts, Product for products, and SoftwareApplication for a SaaS product. The JSON goes in a script tag with the type application/ld+json and must be present in the server-rendered HTML, not injected after load. Google's structured data guide lists the supported types, and the Rich Results Test plus the schema.org validator will show you errors before Google does.

Alongside the markup, the homepage and the About page should state in plain sentences who the company is, what it does, who it is for, and where it operates. Large language models build their picture of a brand from text, and a homepage that opens with a slogan and a hero image gives them nothing to work with. One paragraph that reads like an answer to "what is this company" does more for AI visibility than any amount of design. The brand name, domain, and contact details should then match exactly across the site, the schema, and every external profile, so that a model does not conclude it is looking at two different companies.

Step 7. Format pages so AI engines can quote them

Once crawlers can read the site, the question becomes whether anything on it is worth quoting. Answer engines pick passages that answer a question cleanly, and most vibe-coded marketing copy does not.

Four patterns raise the odds. Put a direct answer of 40 to 60 words immediately under any heading phrased as a question, so the model can lift it without reading the rest of the section. Use tables for comparisons, bullet lists for specifications, and clearly labelled pricing tiers, because retrieval systems prefer structured facts over paragraphs that hint at them. Show a visible published date and a last-updated date on guides and documentation, cite the source for every statistic, and put a real author name and bio on articles. Freshness and attribution both feed into what gets cited.

Optionally, publish an llms.txt file at the site root. It is a short Markdown document that summarises the product and lists your ten to twenty most important pages. The standard is young and support is uneven, but it costs an hour and gives AI coding agents and research tools a clean map of the site.

Step 8. Measure whether AI engines are sending anyone

You cannot tell whether any of this worked without separating AI referrals from the rest of your traffic. In GA4, or whichever analytics tool the builder wired in, create a channel or segment for referrals from chatgpt.com, perplexity.ai, claude.ai, gemini.google.com, and copilot.microsoft.com. These visits usually land in a generic referral bucket and get ignored.

Then, once a month, ask the four main assistants the five to ten questions a buyer would ask before choosing a product like yours, and note whether your brand appears and which page gets cited. This is a manual check and it takes twenty minutes. The pattern over three or four months tells you which pages the engines trust and which ones they never surface, which is where the next round of work should go.

A prompt you can paste into your AI builder

Every step above can be audited by the same tool that built the site. Paste the prompt below into Cursor, Claude Code, Lovable, Bolt, Replit, or whatever you used, and it will return a prioritised fix list against your actual code. We use a version of this on every site that comes through the studio.

Audit this codebase for SEO and AI search readiness. Check the root layout, the robots file, the sitemap, the framework config, and every public page. Flag any page that relies on client-side rendering or a post-load fetch for its primary text, any page missing a unique title, meta description, or canonical tag, any navigation that uses a click handler instead of a real link, any image without dimensions and alt text, any missing JSON-LD structured data, any custom 404 page that returns a 200 status, and any robots or CDN rule that blocks Googlebot, OAI-SearchBot, PerplexityBot, ClaudeBot, or Google-Extended. Output a prioritised fix list with exact code changes.

Run the no-JavaScript test from Step 1 after the builder says it is done, because builders report success on changes they did not fully make. Keep the output, because it doubles as the SEO section of the documentation you should be holding for the site anyway. If the output is longer than you expected, or the fixes keep breaking other things, that is usually a sign the underlying build needs a proper pass, and a short call with an engineer costs less than another month of being invisible. Book a 20-minute call and we will tell you which of the eight steps your site fails on.