SEO Optimization for AI Agents: A Practical Vue and Nuxt Guide

Search has quietly split in two. Alongside the ranked list of blue links, a growing share of queries now get answered directly — by Google's AI Overviews, by ChatGPT search, by Perplexity, by Claude fetching a page mid-conversation. For a website, that means there are now two audiences to write and build for: people scanning search results, and language models trying to extract, summarize, and cite your content in real time.

This guide combines Google's and Bing's own AI-search documentation, OpenAI's crawler docs, and academic research on Generative Engine Optimization (GEO) into one practical framework — with Vue and Nuxt specifics for the technical parts. Where the evidence is solid, it says so plainly. Where it's still experimental, it says that too.

TL;DR

• GEO/AEO is not a separate discipline from SEO. Google's AI features run on the same crawling, indexing, and ranking systems as regular Search — there's no secret AI-only ranking factor to chase.
• AI crawlers are not one thing. OpenAI, Google, Anthropic, and Perplexity each run separate bots for search inclusion vs. model training, and you can control them independently in robots.txt.
• Rendering mode is the single biggest technical risk. Most AI crawlers don't execute JavaScript. Client-side-rendered pages are frequently invisible to them.
• Content that gets cited is specific, not vague. Research shows adding statistics, direct quotations, and citations to source material measurably increases how often generative engines quote a page — keyword stuffing does not.
• llms.txt is experimental and unproven. Google explicitly says it doesn't help. Treat it as a nice-to-have, not a strategy.
• You can't fully measure AI referrals yet. Search Console, Bing Webmaster Tools, and analytics referral segments each show a partial picture.

GEO/AEO Compared With Traditional SEO

"Generative Engine Optimization" (GEO) and "Answer Engine Optimization" (AEO) are the informal names for optimizing content to be selected and cited by AI systems, as opposed to ranked in a list of links. The terms come from outside the search engines themselves — most notably a widely-cited 2024 research paper that framed GEO as a black-box optimization problem: given that generative engines synthesize an answer from several sources and attach inline citations, which changes to a page increase the odds it gets pulled into that answer?

That paper is a useful frame, but it's worth being precise about what's actually established versus experimental:

Established (Google's own position): AI Overviews and AI Mode are built on Google's core Search ranking and quality systems. There is no separate technical requirement or special markup needed to appear in them — a page needs to be indexed, crawlable, and eligible for regular search results. Google's guidance goes further and explicitly debunks several popular "AI SEO" tactics: creating an llms.txt file, "chunking" content into AI-friendly fragments, and rewriting content specifically to sound more AI-friendly are all called out as not helping.

Experimental (from the GEO research and industry practice): because generative engines still have to select which sources to quote from a candidate set, content-level choices can shift how often a given page is the one selected. The GEO paper's own testing found that adding quotations from experts (+41% on their visibility metric), adding statistics (+40%), and citing credible sources (+30%) produced the largest gains, while traditional keyword stuffing produced almost none. That's a meaningful signal, but it's a single study of specific generative systems at a specific point in time — treat the direction as useful and the exact percentages as illustrative, not guaranteed.

The practical takeaway: don't treat GEO as a replacement for SEO fundamentals, and don't chase AI-specific hacks that have no evidence behind them. Do treat "write clearly, back claims with evidence, and structure content so a machine can parse it" as good practice for both humans and AI systems at once.

AI Crawlers and robots.txt

Every major AI provider runs more than one crawler, and they are controlled separately. Conflating them is the most common mistake — disallowing "AI bots" wholesale can remove a site from ChatGPT search results while doing nothing to stop model training, or vice versa.

A few practical rules:

• If you want citations from ChatGPT, Claude, or Perplexity, make sure their search/indexing bots aren't blocked — check your robots.txt doesn't have a blanket Disallow: / for these user agents.
• If you want to opt out of your content being used for model training specifically, disallow the training-focused bots (GPTBot, Google-Extended, ClaudeBot) while still allowing the search-focused ones.
• Bots that fetch pages because a user asked an AI assistant to (ChatGPT-User, Claude-User, Perplexity-User) behave more like a human clicking a link than a background crawler — some of these may not fully respect robots.txt the way a scheduled crawl does, since they're acting on direct user intent.
• Review this periodically. Crawler names and behavior have changed multiple times as these products evolve; don't treat a robots.txt block list as a "set once" artifact.

Semantic HTML and Crawlable Server-Rendered Content

None of the AI crawlers above execute JavaScript the way a browser does. They request a URL and parse whatever HTML comes back. If that HTML is a near-empty shell — a single <div id="app"> waiting for a client-side framework to hydrate it — there is nothing for the crawler to read, summarize, or cite.

This makes two things matter more for AI visibility than they might for a human audience reading in a modern browser:

1. The initial HTTP response must contain the real content, not a loading state. This is a rendering-mode decision, covered below.
2. Semantic HTML carries meaning that a language model uses to parse structure — <h1>–<h3> hierarchy, <article>, <nav>, <table>, <dl> for definitions, proper <button>/<a> usage. A wall of unstyled <div>s with visual formatting applied purely via CSS gives a crawler no structural signal about what's a heading, what's a list, and what's the primary content versus a sidebar.

Neither of these is AI-specific advice, exactly — they're accessibility and traditional SEO best practices that happen to matter even more once a non-rendering bot is the reader.

CSR vs. SSR, SSG, and Hybrid Rendering in Vue and Nuxt

This is the single most consequential technical decision for AI (and traditional) crawlability, so it's worth being explicit about the trade-offs:

• CSR (client-side rendering) — a plain Vite SPA. The server sends an empty shell; the browser runs JavaScript to render content. Googlebot queues these for a delayed, resource-limited second rendering pass with no guaranteed timeline, and most AI crawlers don't render JavaScript at all. Fine for authenticated dashboards and internal tools; a liability for any public, indexable page.
• SSR (server-side rendering) — a Vue/Nuxt server renders full HTML per request. Every crawler gets complete content immediately. Best for pages with personalized or frequently-changing content, at the cost of server compute per request.
• SSG (static site generation) — routes are pre-rendered to static HTML at build/deploy time (nuxt generate). Ideal for marketing pages, documentation, and blog posts that don't need per-request data. This site is built this way: nuxt generate prerenders every route to static HTML served from a CDN, so every crawler — Googlebot, GPTBot, ClaudeBot, or a human — receives identical, complete HTML with no JavaScript execution required.
• ISR / hybrid rendering — Nuxt's routeRules let you mix strategies per route: static generation for marketing pages, swr (stale-while-revalidate) for content that updates periodically, and full SSR reserved for genuinely dynamic or personalized routes.

// nuxt.config.ts — mixing rendering strategies per route
export default defineNuxtConfig({
  routeRules: {
    '/blog/**': { prerender: true },       // static at build time
    '/case-studies/**': { prerender: true },
    '/dashboard/**': { ssr: false },       // CSR is fine — not indexable
    '/pricing': { swr: 3600 },             // ISR — revalidate hourly
  },
})

Whatever mode you choose for a public page, verify it the same way a crawler would: view source (not the rendered DOM in DevTools), or curl the URL directly and confirm the response body already contains your headline and body copy — not just a <div id="__nuxt">.

Metadata, JSON-LD, Sitemaps, Canonical URLs, and IndexNow

These are established SEO fundamentals that also directly feed AI systems, since AI Overviews and AI Mode are built on the same indexing pipeline as regular Search.

• useSeoMeta() on every page — title, meta description, Open Graph, and Twitter card tags. AI summarizers frequently lean on the meta description when a page lacks a clear opening paragraph, so don't leave it generic.
• JSON-LD structured data, placed on the page it describes, using the most specific applicable schema.org type, and matching the visible content exactly. Google's structured-data policy is explicit that markup must reflect what's actually on the page — don't mark up content that isn't visible, and don't over-claim a schema type your page doesn't fully support. This site emits Organization and OfferCatalog JSON-LD on the homepage and BlogPosting JSON-LD (title, description, image, datePublished, author, publisher) on every post automatically via the page template.
• Canonical URLs on every indexable page, especially where the same content is reachable through more than one path.
• A sitemap that's accurate and excludes pages you don't want indexed (@nuxtjs/seo generates one automatically from your routes here, with explicit excludes for private/noindex pages).
• IndexNow — a protocol, currently supported by Bing (and Yandex), that lets a site push a notification the moment a page is created, updated, or removed, instead of waiting for the next scheduled crawl. Bing's webmaster team now frames faster discovery via IndexNow as directly relevant to how quickly new or updated content can surface in Copilot and Bing's AI-generated answers — useful for anything time-sensitive, though it's a Bing/Yandex-specific mechanism, not a universal one Google or OpenAI consume.

Writing Clear, Factual, Citation-Friendly Content

Generative engines don't rank your page — they extract a fact, a number, or a sentence from it and attribute it. That changes what "good content" looks like at the paragraph level, on top of everything traditional SEO already asks for:

• Answer the question directly, early. A generative engine assembling a response favors a page where the relevant fact is stated plainly near the top of a section, not buried three paragraphs into scene-setting.
• Back claims with specifics. The GEO research consistently found that adding concrete statistics and direct quotations from credible sources increased how often a passage got selected for citation — vague, generic prose performs worse than a page with the same information stated precisely.
• Cite your own sources. Linking out to primary data or authoritative references — the same signal that's long mattered for E-E-A-T in traditional SEO — also correlated with higher citation rates for generative engines in the same research.
• Use structure a machine can parse without ambiguity: headings that describe their section accurately, tables for comparisons, ordered lists for sequential steps.
• Don't rewrite for AI at the expense of readability. Google explicitly flags "rewriting content to be more AI-friendly" as a debunked tactic — content optimized to be quotable by a machine should still read naturally to a person; if it doesn't, you've over-optimized.
• Skip keyword stuffing entirely. It was already a weak SEO tactic; the GEO research found it produced close to zero benefit for generative engine visibility either.

Authority, Original Research, Statistics, and Freshness

Both Google and the GEO research converge on the same underlying signal, even though they describe it differently: content that demonstrates real expertise and original insight — not a repackaged summary of what's already ranking — performs better in both traditional rankings and AI citation rates. Google's guidance is direct about this: create "distinctive, non-commodity content" with a genuine point of view, and avoid publishing near-duplicate pages targeting minor query variations, which its scaled-content-abuse policies treat as spam regardless of AI involvement.

Practical ways to build that signal:

• Publish original data, benchmarks, or findings from your own work where you have them, instead of only synthesizing third-party sources.
• Attribute content to a named author with real, verifiable expertise (bio, credentials, other published work) rather than a generic "Team" byline — this also strengthens BlogPosting/Person structured data.
• Keep genuinely time-sensitive content (pricing, version numbers, statistics, tool comparisons) up to date — both Google's AI features and Bing's AI Performance guidance call out freshness as a factor in whether content continues to surface in AI-generated answers.

Measuring AI Referrals and Citations

This is the least mature part of the stack today — there is no single dashboard that shows "here's every time an AI system cited your page," and providers report data in intentionally different ways.

• Google Search Console has a dedicated Generative AI performance report, separate from the standard Performance report, covering impressions and clicks that originated from AI Overviews and AI Mode.
• Bing Webmaster Tools recently introduced an AI Performance report (public preview) that tracks total citations, unique pages cited per day, the queries that triggered a citation ("grounding queries"), and page-level citation activity across Copilot and Bing's AI-generated summaries.
• Referral traffic in your analytics tool. Segment referral sources for known AI-assistant domains (e.g. chatgpt.com, perplexity.ai, claude.ai) to see actual click-through sessions, as distinct from citation-without-click impressions reported by the two tools above.

Treat all three as partial and directional rather than a complete picture — none of them currently expose the same granularity that traditional search analytics do, and that's expected to keep evolving.

llms.txt: An Experimental Approach

llms.txt is a community-proposed convention — a plain-text or Markdown file at the site root summarizing a site's content for consumption by LLM-based tools. It is not a proven or officially adopted standard: Google's own AI optimization guidance explicitly lists "creating llms.txt or other AI-specific files" among the tactics it says don't affect AI search visibility, and no major AI provider has published documentation confirming they read or prioritize it.

That said, it's cheap to produce, and some sites — including this one — publish one anyway as a lightweight, structured summary for whichever tools might choose to read it, generated automatically from existing content collections rather than maintained by hand. The honest framing: it's a low-cost bet with no confirmed payoff, not a substitute for crawlable HTML, clean structured data, and genuinely well-written content. Don't let it displace time spent on the things with actual evidence behind them.

Practical Vue/Nuxt Implementation Checklist

• Public, indexable pages render as full HTML on the first response — SSR, SSG (nuxt generate), or ISR via routeRules, never CSR-only.
• Verify with view-source or curl <url> that content is present without executing JavaScript.
• useSeoMeta() set on every page — title, description, Open Graph, canonical.
• JSON-LD structured data matches visible content exactly, uses the most specific applicable schema.org type, and isn't blocked by robots.txt or noindex.
• Sitemap auto-generated and accurate; private/noindex routes explicitly excluded.
• robots.txt reviewed crawler-by-crawler: search-focused bots (OAI-SearchBot, Googlebot, Claude-SearchBot, PerplexityBot) vs. training-focused bots (GPTBot, Google-Extended, ClaudeBot) controlled independently based on actual intent, not a blanket allow/deny.
• Semantic HTML: correct heading hierarchy, <article>/<nav>/<table> used for their actual purpose.
• Content leads with a direct answer, backs claims with specific data or citations, and avoids AI-specific rewriting that hurts human readability.
• Named author with real expertise on long-form content, not a generic byline.
• Time-sensitive content (versions, pricing, comparisons) has an owner and a review cadence.
• Search Console's Generative AI performance report and Bing's AI Performance report checked periodically alongside standard analytics.
• llms.txt treated as optional polish, not a strategy — implemented only after everything above is solid.

Where to Go From Here

Most of this checklist is work Vue and Nuxt teams already know how to do — it's rendering strategy, structured data, and content quality, not a new discipline. The gap is usually prioritization: knowing which of these actually move the needle for AI visibility versus which are folklore.

If your team wants a structured pass through this — rendering audit, robots.txt and crawler review, structured data, and a content framework your writers can reuse — that's exactly what our AI-Ready Frontend Setup engagement covers for Vue and Nuxt codebases.