---
title: "Rendering Modes for SEO in Vue"
description: "Compare Vue server rendering, static generation, and client rendering. Check initial HTML, state transfer, hosting, and actual interaction costs."
canonical_url: "https://nuxtseo.com/learn-seo/vue/routes-and-rendering/rendering"
last_updated: "2026-10-08"
---

> Index of every page on this site: [llms.txt](https://nuxtseo.com/llms.txt)

::key-takeaways
- Rendering mode determines which content the server generates and which depends on client JavaScript
- Vue ships the building blocks for SSR (`createSSRApp`, `renderToString`), but Vue's own docs recommend a framework for production SSR rather than hand-rolling it
- Google can render client JavaScript. SSR or generation can expose public content in initial HTML and reduce that dependency
- Vapor Mode appears in Vue 3.6 prereleases. Do not infer an SSR, hydration, or interaction result from a compiler mode alone
::

Rendering mode determines where page content is produced. A client-rendered app may serve an app shell, while SSR or generation can put route content in the response. Static tags or content can still exist in a client app's initial document. Vue supplies rendering APIs; hosting, caching, routing, and data integration depend on your tooling.

## Rendering Modes at a Glance

| Mode            | First response                                                  | Best for                                                    |
| --------------- | --------------------------------------------------------------- | ----------------------------------------------------------- |
| SSR             | Server-rendered HTML, possibly cached                           | Request-specific or frequently changing output              |
| SSG / prerender | HTML generated at build time                                    | Public content whose rebuild schedule meets freshness needs |
| ISR             | Framework or provider-managed generated and cached HTML         | Public output with an explicit revalidation policy          |
| CSR (SPA)       | App shell or static content, client app renders remaining views | Views that can depend on browser JavaScript                 |

## Server-Side Rendering (SSR)

After installing Vue, this Node TypeScript example renders a component to an HTML string. It does not serve a page or make the button interactive:

```ts
import { createSSRApp } from 'vue'
import { renderToString } from 'vue/server-renderer'

const app = createSSRApp({
  data: () => ({ count: 1 }),
  template: `<button @click="count++">{{ count }}</button>`
})

const html = await renderToString(app)
console.log(html)
```

A production app also needs server and client entries, routing, data loading, head serialization, and consistent initial state. This string-rendering example supplies none of those integrations. [Vue's own SSR guide says as much](https://vuejs.org/guide/scaling-up/ssr.html): a complete implementation is complex enough that Vue "highly recommends using Vue frameworks if you need SSR since they often have built-in SSR support." Nuxt is one option; see [Rendering Modes in Nuxt](https://nuxtseo.com/learn-seo/nuxt/routes-and-rendering/rendering) for the per-route version of this guide.

## Static Site Generation (SSG)

Static generation renders known routes at build time and produces HTML files. Serve those files through a static host with matching routing. For Vue content sites, that generally means reaching for a static-site tool built on Vue (VitePress for docs, Nuxt with `prerender: true` for general apps) rather than assembling a build-time renderer by hand.

Good for docs, marketing pages, and anything that changes at deploy time rather than per request. Route count, data access, and component work determine build cost. Measure your route set and rebuild requirements rather than applying a fixed page-count limit.

## Incremental Static Regeneration (ISR)

ISR generates and caches page output under framework or hosting rules. Revalidation timing and stale responses depend on that implementation; cache misses can still require rendering. Plain Vue and [Vite](https://vite.dev) do not supply a complete ISR service.

Nuxt separates server-side stale-while-revalidate rules from provider-specific ISR behavior. Its current ISR route-rule support is scoped to compatible [Netlify](https://netlify.com) and [Vercel](https://vercel.com) deployments. Inspect the [current rendering documentation](https://nuxt.com/docs/4.x/guide/concepts/rendering) and verify the host's cache behavior.

## Client-Side Rendering (CSR)

The default for a Vue app created with `create-vue` or a plain Vite SPA template: the host serves an app shell and Vue renders client views. Static content and metadata can also be present in that shell.

Google [crawls, renders, and indexes eligible pages](https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics). Content created by JavaScript depends on successful rendering and available resources. SSR does not bypass that queue or guarantee indexing.

Publish important public content in the response when clients need to read it without executing the app. AI products use different crawler, search, and retrieval systems; do not assume one universal JavaScript capability.

Client rendering can suit private dashboards and tools. Enforce access control for private data. [Noindex](https://nuxtseo.com/learn-seo/vue/controlling-crawlers/meta-tags) controls Search inclusion, not authentication, and a public client-rendered page is not automatically required to use it.

[Reported internal observations](https://www.seroundtable.com/google-crawling-indexing-serving-data-42225.html) show rendering itself taking seconds, with hours in its queue. Slow cases reached days or weeks. Initial HTML can expose content without client rendering, but SSR does not bypass every Google rendering process. See [Google Search timelines](https://nuxtseo.com/learn-seo/google-search-timelines) for the stages and their limits.

## Vapor Mode and Hydration Cost

Client-rendered apps mount; SSR apps can hydrate existing markup. Both can perform main-thread work, but hydration is not the sole cause of slow interactions. Measure long tasks and field INP on representative pages.

As checked on October 5, 2026, Vue's stable [npm](https://npmjs.com) tag is 3.5.43 and 3.6.0-rc.10 is a prerelease. Its [Vapor runtime README](https://github.com/vuejs/core/blob/v3.6.0-rc.10/packages/runtime-vapor/README.md) says the runtime runs only in the browser and requires an SFC build. This guide's server-rendering example uses the stable Vue renderer. Do not treat a Virtual DOM change as proof of SSR compatibility or a hydration performance improvement.

## Verifying What Google Sees

Inspect the HTTP response, browser output, and Google's reported fetch separately:

1. **View Page Source** (not "Inspect Element"). If content is missing from raw HTML, inspect rendering, data loading, and errors; compare the rendered output
2. **URL Inspection in Search Console.** Compare indexed crawl information with a live rendered fetch. A live test does not guarantee indexing
3. **Fetch under a Googlebot user-agent string.** This does not emulate Google rendering or verify the requester:

```bash
curl -A "Mozilla/5.0 (compatible; Googlebot/2.1)" https://yoursite.com
```

4. **Disable JavaScript** and reload to inspect that browser condition. Client-only content may disappear; static shell content can remain. This does not emulate a specific AI provider

## Checklist

::checklist{#vue-rendering}
- Rendering choice meets public content, freshness, hosting, and measured interaction needs
- Initial and rendered HTML contain the expected content for the clients you target
- Private data has access control; indexing directives follow the intended Search policy
- If you need SSR/SSG/ISR without building it yourself, you've evaluated Nuxt
::

## Sitemap

See the full [sitemap](https://nuxtseo.com/sitemap.md) for all pages.