From Being Seen by Search Engines to Being Read by Agents: An SEO/AEO Playbook for Vibe-Coded Projects

Every vibe coder knows the open secret: the week you build the product is pure joy; the week after launch is pure anxiety. You spent seven days turning an idea into a working site, deployed it on Vercel, bought the domain — and then nothing happened. Google Search Console shows a flatline. Your launch post got three likes, one of them from your own alt account.

It's not that your product is bad. The traffic landscape changed in 2026: the search box is ceding traffic to the answer box. Fewer and fewer users click the tenth blue link; more and more just ask an AI "any good podcast editing tools?" and download whatever names show up in the answer. Whether your project appears in that answer depends on something completely different from writing code: whether machines can read your website.

SEO used to solve "being seen by search engines." Now there's a second layer: "being read by agents." Search engines crawl your HTML; agents read your docs, your pricing page, your API reference — then decide whether to recommend you in their answers. This guide splits the two layers: the first is the classic SEO foundation, don't skip it; the second is the AI discovery layer (some call it AEO, some GEO — the name doesn't matter), all new plays from the last couple of years; and finally the strategy calls — which work you can hand to AI, and which you have to make yourself.

The conclusion up front, to save you time: SEO is the first growth job of the vibe-coding era that is genuinely "vibe-able" — sitemaps, meta tags, structured data are all formulaic grunt work that AI does faster than you and without typos. But "what content to make, which questions to answer, whether to rewrite your pricing page for AI" — those judgments AI can't make for you. Outsource the grunt work, keep the judgment. That's the division of labor for this entire guide.

The Foundation: Four Pieces, Skip None

Hearing "the AI era" makes a lot of people want to skip classic SEO. That's a mistake. AI answers' citations lean heavily on the traditional search index — model training and retrieval both eat the same web pages. Without the foundation, the AI layer is a castle in the air. Four pieces, each with a clear acceptance test.

Piece 1: sitemap.xml + robots.txt — a map and a street address for crawlers

This is the cheapest step and the one vibe projects skip most. Next.js users just drop two files in the app directory:

// app/sitemap.ts
import { MetadataRoute } from 'next'

export default function sitemap(): MetadataRoute.Sitemap {
  const base = 'https://yourproject.com'
  return [
    { url: base, lastModified: new Date(), changeFrequency: 'weekly', priority: 1 },
    { url: `${base}/pricing`, lastModified: new Date(), priority: 0.8 },
    { url: `${base}/docs`, lastModified: new Date(), priority: 0.9 },
    // list every public page, don't be lazy
  ]
}

In robots.txt, beyond Allow / Disallow, add one line: Sitemap: https://yourproject.com/sitemap.xml. Acceptance test: after deploying, /sitemap.xml loads in a browser, and you've submitted it once in Google Search Console. Don't underestimate this — half of vibe projects' pages aren't even in the index, which makes all keyword research theater.

Piece 2: meta + OG tags — your social business card

When users share your link on Twitter, Discord, or chat apps, the card preview decides the click. Every page needs its own title and description, with hard length caps: title under 60 characters, description around 150. For the OG image (1200×630), skip the solid-color-background-with-big-text template — a real product screenshot converts far better.

<meta property="og:title" content="ClipShelf — save web snippets in one click" />
<meta property="og:description" content="Save anything you read in one click. AI auto-tags, organizes, and full-text searches it. Free for 30 days." />
<meta property="og:image" content="https://yourproject.com/og.png" />
<meta name="twitter:card" content="summary_large_image" />

Acceptance test: paste the link into the Twitter Card Validator and a phone messaging app, and check the card renders cleanly — no garbled text, no default gray box.

Piece 3: JSON-LD structured data — let machines "understand," not just "see"

HTML is for humans; JSON-LD is the résumé for machines. For tool-style vibe projects, the SoftwareApplication type fits best:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "SoftwareApplication",
  "name": "ClipShelf",
  "applicationCategory": "ProductivityApplication",
  "operatingSystem": "Web",
  "offers": { "@type": "Offer", "price": "0", "priceCurrency": "USD" }
}
</script>

One warning: don't write aggregateRating unless you have real user reviews — fabricated ratings get your rich-result eligibility revoked when Google catches them. Have pricing? Write offers. Have Q&A? Add FAQPage. Acceptance test: zero errors in Google's Rich Results Test.

Piece 4: Core Web Vitals — where vibe projects crash most

AI-generated code has a chronic disease: npm packages installed without mercy, three or four heavy image libraries on the first screen, LCP (Largest Contentful Paint) shooting to 5 seconds. Google's "good" thresholds are LCP ≤ 2.5s, INP ≤ 200ms, CLS ≤ 0.1 — miss them and you take a quiet ranking penalty. Worse, real users won't wait 5 seconds either.

Three fixes with immediate payoff: serve the hero image with next/image priority plus a modern format (AVIF / WebP); load all third-party scripts (analytics, support widgets) with strategy="lazyOnload"; self-host fonts with next/font instead of fetching them remotely. Acceptance test: all three mobile scores green in PageSpeed Insights.

With the four pieces done, your project is "visible to search engines." Now comes the genuinely new battlefield.

The AI Discovery Layer: Getting Read by Agents

Classic SEO optimizes the "crawler → index → rank" chain; AI discovery optimizes "agent reads docs → generates answer → cites you." Different consumers: the first serves crawlers, the second serves agents arriving with a user's question. Their reading habits differ too — crawlers chew HTML; agents prefer clean Markdown and structured facts.

llms.txt: a tour map for AI

In September 2024, Answer.AI co-founder Jeremy Howard proposed llms.txt: a Markdown file at the website root — an H1 with the project name, a short summary, then H2 sections listing key pages with one-line descriptions. The spec is short and lives at llmstxt.org. There's a companion, llms-full.txt: all important docs concatenated into one big Markdown file for feeding large-context models in one shot.

The mechanism is clear; expectations need calibrating: llms.txt is infrastructure, not magic. Google Search says it doesn't use the file; the real readers are coding agents like Cursor and Claude Code when they research "is there an existing API / tool for this" on a user's behalf. In other words, it doesn't optimize "where you rank on Google" — it optimizes "whether an agent can quickly understand you while shortlisting tools." For vibe projects that's exactly the high-value scenario: your users are people who live in AI tools.

A usable llms.txt takes under 30 minutes. The template looks like this:

# ClipShelf

> One-click web snippet collector: select to save, AI auto-tags, organizes, and full-text searches. Free tier available, Pro at $5/month.

## Core pages
- [Home](https://yourproject.com): product tour and live demo
- [Pricing](https://yourproject.com/pricing): Free vs Pro feature comparison
- [API docs](https://yourproject.com/docs/api): REST API guide with auth and rate limits

## Developers
- [Quickstart](https://yourproject.com/docs/quickstart): integrate the clipping API in 5 minutes
- [Changelog](https://yourproject.com/changelog): weekly release notes

## Optional
- [Blog](https://yourproject.com/blog): product thinking and usage tips

The details that matter: describe each link by "what question this page answers," not "welcome to our pricing page." Keep it under 5,000 tokens. Update it whenever you ship doc changes — or generate it with a build script. A stale static file is worse than none: an agent recommending a deprecated endpoint from your old docs costs you reputation.

A Markdown version of every page: zero out the agent's reading cost

llms.txt is the index; Markdown pages are the text. The recipe is simple: serve a clean Markdown version of every important page — the convention is appending .md to the URL (e.g. /docs/api.md), or just link it from llms.txt. An agent fetching .md doesn't parse your hydrated React HTML or guess which div is the nav bar — fewer tokens spent, better understood.

In Next.js it's a dozen lines: a route handler that renders the same content source as Markdown text with Content-Type: text/markdown. Your docs should be Markdown anyway, so this step is nearly free.

FAQ schema: hand-delivering the "official answer" to AI

Think about it: when a user asks an AI "what's the difference between ClipShelf Free and Pro," where does the answer come from? Most likely from the most clearly structured passage on your site. FAQPage structured data hands over that "official answer" personally:

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [{
    "@type": "Question",
    "name": "What are the limits of the ClipShelf free tier?",
    "acceptedAnswer": {
      "@type": "Answer",
      "text": "Free tier stores 500 snippets with 20 AI tags per day; Pro at $5/month is unlimited and adds a shared team library."
    }
  }]
}

The judgment call in writing: skip the PR speak, write the questions users actually ask AI — pricing, limits, how you differ from competitors, whether data exports, language support. Two or three sentences per answer, with concrete numbers. An AI won't cite a vague answer; it will cite specific numbers.

Make your pricing and API docs agent-readable

This is the most underrated lever for vibe projects. Picture the agent's workflow: a user says "find me a cheap web-clipping API for my workflow," and the agent reads several products' pricing pages and API docs to compare. If your pricing page is a glossy image and your API docs sit behind a login wall, you're already out of that round — not because the product lost, but because the docs lost.

Three hard rules: first, write prices, quotas, and limits in a real HTML table — no images, no JS modals; second, make API docs publicly crawlable, with auth method, rate limits, and pricing endpoints spelled out, plus a downloadable OpenAPI spec; third, put a sub-200-word "integration in one sentence" at the top of the docs — that's the part the agent actually reads when comparing.

The essence: in the agent economy, your docs are your sales team. Sales used to happen in human conversations; now they happen in agent reads. Vague docs are a salesperson who can't explain the product.

The Citation Game: Getting Into AI Answers

Even with perfect on-site optimization, one question remains: why should an AI mention you instead of a competitor when recommending podcast editing tools? Model recommendations come from training data and retrieved pages, and both favor products "mentioned in many places." So the entire off-site game is one sentence: get your product's name into content other people write.

Directory listings: your "AI résumé drop"

The logic is straightforward: when an AI answers "vibe-coding projects worth watching in 2026," it reads directories, awesome lists, and review articles. Directories built for vibe-coded projects, like VibeFix (vibefix.work), exist for exactly this — submit your project with a one-line pitch, your stack, and your link. Same for Product Hunt and BetaList: every submission is another citation opportunity.

Don't phone in the submission: describe concrete features and numbers ("exports to 12 formats" beats "powerful export features" tenfold), list your stack honestly, and use a real running screenshot. These directory pages carry high authority, so AI retrieval reads them first — and you get classic-search backlink weight as a side effect. One submission feeds both chains.

Brand mentions: from "begging for coverage" to "supplying quotable material"

Traditional PR begs media to cover you; the AI-era mention game inverts it: you supply quotable material to people who write. Nobody cites "we're committed to efficiency," but plenty cite "we cut support response time from 4 hours to 11 minutes."

Concretely: write one or two deep build-in-public logs — why you chose this stack, what broke, how the numbers moved — on your blog and in dev communities; proactively give authors of comparison posts and awesome lists accurate product info and screenshots so they don't get it wrong; if you have a free API, let indie developers use it — they'll mention you when they write tutorials. Remember what AI likes to cite: concrete numbers, explicit comparisons, clear positioning. Hit all three and it cites you with confidence.

Three Classic Ways Vibe Projects Crash

Three pitfalls specific to vibe projects, distilled from watching real ones step in them. Knowing them in advance saves you weeks.

Crash 1: your SPA's first paint is blank — and that's all the crawler sees. Vibe tools default to client-rendered single-page apps, so the first thing a crawler grabs is an empty div plus a pile of JS. Google can execute JavaScript now, but "can" doesn't mean "will wait" — the render queue adds delay, and slow pages get indexed late. The fix isn't hard: pre-render your marketing pages (home, pricing, docs landing) with SSG — in Next.js that's just static export. If you insist on an SPA, put a pre-render service in front for crawlers. Acceptance test: curl your homepage and confirm the core copy is visible without executing any JS.

Crash 2: your most important information is an image. A beautifully designed pricing long-image, a feature comparison table exported from Figma as PNG — delightful for humans, invisible to machines. The "real HTML table for pricing" rule from earlier exists for exactly this. Note the asymmetry: OG images should be images (that's a card for humans), but key information in the page body must be text. One-line rule: anything you want cited must be machine-readable text.

Crash 3: blasting identical copy to twenty directories. Some founders write one description and paste it into 20 directories to save time. Low-quality duplicate backlinks hurt classic SEO, and they add nothing for AI citation either — an AI wants "independent mentions from multiple parties," and 20 verbatim copies count as roughly one. The right move: write 2–3 different sentences per directory, each highlighting a different angle — the vibe-coding angle on VibeFix, the problem solved on Product Hunt, the beta perk on BetaList. One source draft, three tellings, ten minutes of work.

Strategy Calls: What to Give AI, What to Decide Yourself

Everything above was "how." This is "what" — and AI can't help you here, because it doesn't have your context.

Call 1: chase citations first, or clicks first? Classic SEO's KPIs are clicks and rankings; the AI era adds one more: being cited in AI answers. For a freshly launched vibe project, I'd go citations-first — you'll never outrank giants for "online clipboard," but you can absolutely be the cited name in long-tail content like "AI clipboard tools compared." Citations buy "the AI vouched for you" trust; clicks buy traffic; early projects are shorter on trust.

Call 2: content priority is docs > blog > social noise. Many indie developers spend their days posting, hoping one viral tweet brings traffic. Virality is a lottery ticket; docs are assets: one clearly written API doc, one honest pricing comparison gets read by agents hundreds of times more than a tweet. Blogs are worth it, but only the kind others cite — build logs, technical decisions, real data — never self-congratulatory release notes.

Call 3: don't build a site only machines can enjoy. This is the easiest trap. llms.txt, Markdown versions, FAQ schema are "while you're at it" enhancements — your site is for humans first. If a visitor can't tell what you do in 3 seconds, a hundred AI citations won't help, because humans still pay the bills. The crude-but-effective test: show your homepage to a non-technical friend and ask "what is this, how much?" If they can't answer, fix the homepage before talking AEO.

The 30-Day Ship List

The above condensed into one month of execution, reviewed every weekend:

Week 1 (foundation): ship sitemap.xml + robots.txt and submit in Search Console; audit every page's title / description / OG tags; add JSON-LD (SoftwareApplication + FAQPage) and pass the Rich Results Test; get all three mobile PageSpeed Insights scores green.

Week 2 (AI-readable layer): write /llms.txt and keep it under 5,000 tokens; add .md versions of core pages (home, pricing, docs); convert the pricing page to a real HTML table; make API docs public with a downloadable OpenAPI spec.

Week 3 (citations): submit to 3–5 directories (VibeFix, Product Hunt, …); publish one build log with real numbers; assemble a one-page press kit (one-liner, key numbers, screenshots) and send it to authors who write comparisons.

Week 4 (review): check index coverage and impressions in Search Console; ask several mainstream AIs for tool recommendations in your category — do you show up, and which sentence gets cited? If not, go back and rewrite the page behind that sentence. The single north-star metric of the whole AEO loop: are you in the AI's answer.

Back to the opening question: where does traffic come from? In 2026 the answer walks on two legs — the search engine index is the foundation, agent citations are the growth. SEO used to optimize "being seen"; now it must also optimize "being read." The good news: the cost of being read has never been lower for a vibe coder — llms.txt in half an hour, Markdown versions in a dozen lines of code, FAQ schema in an afternoon. All formulaic grunt work AI can write for you.

But remember the division of labor: grunt work can be vibed, judgment can't. What content to make, which questions to answer, whether you dare to state your pricing plainly — the calls that decide what AI says when it cites you are yours to make. How well you document sets your product's ceiling in the agent economy: an agent can only recommend what it has read, and the ceiling of what it reads is the ceiling of what you're willing to spell out. That simple — and that hard.