August 6, 2026

Technical SEO

Vue.js SEO: New Technical Ways

Master Vue.js SEO with practical guidance on SSR, SSG, Nuxt, crawlable links, structured data, Core Web Vitals, and raw vs. rendered HTML audits

Vue.js SEO

Vue.js can produce fast, accessible, search-friendly websites, but Vue does not make a site SEO-safe by itself. The outcome depends on what your server returns, how the application fetches content, how routes behave before JavaScript starts, and whether the rendered DOM still agrees with the original HTML. I have seen attractive Vue applications lose organic visibility because their most important content existed only after a browser executed several bundles and completed an API request. I have also seen teams migrate to server-side rendering and assume the job was finished, while hydration errors silently removed links, replaced metadata, or turned missing products into indexable soft 404s.

This guide explains how I approach Vue.js SEO in production. The central principle is simple: every public URL should deliver a complete, stable, and semantically correct representation of its primary content as early as possible. JavaScript should enhance that representation, not be the only mechanism capable of creating it.

Why Vue.js SEO Is Different

A conventional server-rendered page arrives as meaningful HTML. A crawler can immediately read its title, canonical URL, headings, body copy, links, image references, and structured data. A client-rendered Vue single-page application may initially return little more than a root element and script references:

<div id="app"></div>
<script type="module" src="/assets/app.8f3a2.js"></script>

The browser must download, parse, compile, and execute JavaScript before it can build the useful DOM. It may then need to call one or more APIs. If a bundle fails, a request times out, a consent layer blocks execution, or a bot does not render JavaScript, the primary content never appears.

Google can render JavaScript, but crawling and rendering are separate stages. Googlebot first requests the URL, reads the response, discovers links in the initial HTML, and may later send the page to its Web Rendering Service. The rendered DOM can then be used for indexing and additional link discovery. That capability is not a reason to make Google perform unnecessary work. Rendering can be delayed, resources can fail, and many non-Google crawlers do not execute JavaScript reliably. Server-side rendering or prerendering reduces those dependencies for search engines and users.

For that reason, I do not ask only, “Can Google render this page?” I ask four harder questions:

What is present in the raw HTTP response?
What changes after Vue renders and hydrates?
Does every important URL return the correct status, metadata, content, and links without relying on client-side state?
Can the page remain useful when a script or API request fails?

Choose the Right Rendering Architecture

The highest-impact Vue SEO decision is the rendering mode. Do not choose it globally by habit. Choose it according to the search value, update frequency, and personalization requirements of each route type.

Client-side rendering

Client-side rendering, or CSR, sends an application shell and constructs the page in the browser. It is appropriate for authenticated dashboards, internal tools, account settings, editors, and other views that should not rank. It is usually the weakest default for product pages, category pages, location pages, documentation, editorial content, and landing pages.

A CSR page is not automatically invisible to Google. The problem is reliability and efficiency. Its content depends on successful rendering, link discovery can happen later, metadata may initially be generic, and error routes often return HTTP 200. If organic search matters, do not make CSR your default merely because it is easy to deploy to static hosting.

Server-side rendering

With server-side rendering, Vue components are executed on the server and converted into HTML for each request. The browser receives the content, then Vue hydrates the markup to add interactivity. SSR is a good fit for frequently changing inventory, personalized but indexable entry pages, marketplaces, and content that must be current at request time.

SSR improves content availability, but it is not a ranking switch. Slow APIs can increase time to first byte, uncached rendering can overload infrastructure, and inconsistent server/client output can cause hydration problems. Treat SSR as an architecture that makes good technical SEO easier, not as a substitute for technical SEO.

Static site generation and prerendering

Static generation creates HTML files at build time. It is often my preferred approach for documentation, marketing pages, evergreen articles, and catalogs with manageable update frequency. The response is fast, cacheable, and already contains the content. The tradeoff is build complexity: every important dynamic route must be discovered, generated, and regenerated when its source data changes.

A common failure is prerendering only the routes linked from the homepage. Orphaned pages, newly published entries, paginated archives, and parameterized routes may never become HTML files. Build the route list from the canonical data source, not only by crawling the current site.

Hybrid rendering with Nuxt

For most public Vue projects, I recommend evaluating Nuxt before building a custom SSR layer. Nuxt supports universal rendering, prerendering, server-side caching, stale-while-revalidate strategies, and route-specific rules. A typical site can prerender stable pages, cache product pages, render live pages on the server, and leave the private dashboard client-only.

// nuxt.config.ts
export default defineNuxtConfig({
  routeRules: {
    '/': { prerender: true },
    '/guides/**': { prerender: true },
    '/products/**': { swr: 3600 },
    '/account/**': { ssr: false },
  },
})

This is a more useful model than debating SSR versus SSG for the entire application. Classify route templates, document the reason for each rendering choice, and test the output of every class.

Put Search-Critical Content in the Initial HTML

The raw response should contain the page’s unique title, meta description, canonical, robots directives, primary heading, main copy, essential product or article data, important internal links, and relevant structured data. The rendered DOM may add interface state, reviews, calculators, maps, or recommendations, but it should not have to invent the page’s identity.

In a Nuxt page, fetch indexable data with SSR-aware composables. useFetch and useAsyncData can fetch on the server and transfer the result in the Nuxt payload so hydration does not repeat the same request.

<script setup lang="ts">
const route = useRoute()

const { data: product, error } = await useAsyncData(
  `product-${route.params.slug}`,
  () => $fetch(`/api/products/${route.params.slug}`)
)

if (error.value || !product.value) {
  throw createError({
    statusCode: 404,
    statusMessage: 'Product not found',
  })
}
</script>

Avoid placing the only content request inside onMounted(). That hook runs in the browser, so the server response cannot contain the result. Also avoid calling $fetch directly in setup when the same data is needed during SSR; without the proper Nuxt data layer, it can be fetched once on the server and again during hydration.

For large pages, distinguish primary content from secondary enhancements. The product name, price, availability, description, main image, and core links belong in the initial HTML. A personalized recommendation carousel can load later. “Below the fold” is not the same as “unimportant to indexing.” If text is necessary to understand the page, render it even if its visual component is lazy-loaded.

Generate Unique Metadata on the Server

Every indexable route needs a unique and accurate <title>, meta description, canonical, and social metadata. In Nuxt, useSeoMeta is the recommended typed interface for common meta tags, while useHead can manage canonical links and other head elements.

<script setup lang="ts">
const route = useRoute()
const siteUrl = 'https://example.com'
const canonical = `${siteUrl}${route.path}`

useSeoMeta({
  title: () => `${product.value.name} | Example Store`,
  description: () => product.value.metaDescription,
  ogTitle: () => product.value.name,
  ogDescription: () => product.value.metaDescription,
  ogUrl: canonical,
  robots: 'index, follow',
})

useHead({
  link: [{ rel: 'canonical', href: canonical }],
})
</script>

Do not ship one default title for every route and hope JavaScript updates it later. Do not place two canonicals in the source and rendered DOM. Do not let a tracking query string become the canonical simply because it appears in window.location.href. Construct canonicals from normalized route data: preferred protocol, host, casing, path, and trailing-slash policy. Exclude fragments and non-canonical parameters.

For international sites, render reciprocal hreflang references for valid localized URLs and include an appropriate self-reference. Each language version should canonicalize to itself unless it is genuinely a duplicate. Do not generate locale links to routes that return errors or redirect elsewhere.

Make Vue Routes Crawlable and Return Honest Status Codes

Use clean path-based URLs. Vue Router recommends createWebHistory() for normal URLs. Hash-based routes such as /#/products/blue-widget are poor SEO architecture because the fragment is not sent to the server and does not represent a conventional server-addressable document.

With history mode, configure the server carefully. A generic SPA fallback may serve index.html with HTTP 200 for every unknown path. That keeps the client router working, but it can create unlimited soft 404s. In an SSR application, a missing product or article must return a real 404 response. A moved resource should return a server-side 301 or 308 to its most relevant replacement. A temporary move may use 302 or 307. Do not depend on window.location for SEO redirects when the server can return the correct response.

Test routes at the HTTP level, not only in browser navigation. Client-side navigation from a working page can hide server misconfiguration. Open a deep URL in a new private window, request it with curl, and verify the final status and redirect chain.

curl -I https://example.com/products/blue-widget
curl -L -s -o /dev/null -w '%{http_code} %{url_effective}\n' \
  https://example.com/old-product

Use Real Links, Not Click Handlers

Search engines discover pages through links. Google can reliably crawl an <a> element with an href that resolves to a real URL. A clickable <div>, a <span> with a custom attribute, or an anchor that only has an onclick handler is not an equivalent replacement.

Vue Router’s <RouterLink> normally renders an anchor with an href, which is appropriate. Still inspect the final markup, especially when a design-system component wraps or customizes links. Navigation must work with JavaScript disabled, middle-click, keyboard input, and direct requests.

<RouterLink :to="`/products/${product.slug}`">
  {{ product.name }}
</RouterLink>

Place descriptive anchor text inside the link. “Vue SSR deployment guide” gives search engines and users more context than “click here.” Ensure important categories and pages are connected through rendered internal links; an XML sitemap is useful, but it does not replace site architecture.

Prevent Hydration Mismatches

Hydration is where Vue attaches client behavior to server-rendered HTML. The client expects the server DOM to match what it would have produced. If the structures differ, Vue may warn, discard nodes, or rebuild part of the page. From an SEO perspective, that can change content, headings, links, and metadata after the initial response.

Common causes include invalid HTML nesting, random values, time-dependent output, browser-only APIs, different locale or timezone settings, and user state that is known only in the browser. Another frequent cause is fetching the same resource twice and receiving different values between SSR and hydration.

My rule is that the same input must create the same first render. Serialize required state from server to client. Use stable IDs. Apply the same formatting locale and timezone on both sides. Validate HTML. Isolate truly browser-only widgets with a client-only boundary, but do not put essential text inside that boundary. Watch the production console for hydration warnings; they are not harmless development noise.

In custom Vue SSR, create a new app, router, and state store for every request. Reusing a mutable singleton store on the server can leak one request’s state into another. Frameworks such as Nuxt and SSR-aware stores address this pattern, but custom integrations must handle it explicitly.

Add Structured Data Without Creating Two Truths

JSON-LD should describe visible page content accurately. Render it in the server response whenever practical. Google can process structured data added during rendering, but server output is easier to validate and less dependent on successful JavaScript execution.

Generate schema from the same object that renders the visible page. If the product UI says “out of stock” while JSON-LD says “in stock,” the implementation is unreliable. Include stable absolute URLs, use supported types and properties, and never mark up reviews, FAQs, prices, or ratings that users cannot see.

const productSchema = computed(() => ({
  '@context': 'https://schema.org',
  '@type': 'Product',
  name: product.value.name,
  image: [product.value.imageUrl],
  description: product.value.description,
  sku: product.value.sku,
  offers: {
    '@type': 'Offer',
    url: canonical,
    priceCurrency: 'USD',
    price: product.value.price,
    availability: product.value.inStock
      ? 'https://schema.org/InStock'
      : 'https://schema.org/OutOfStock',
  },
}))

useHead({
  script: [{
    type: 'application/ld+json',
    textContent: () => JSON.stringify(productSchema.value),
  }],
})

Validate the deployed URL with Google’s Rich Results Test and inspect the rendered HTML. Also check schema after client-side navigation; head-management errors can leave markup from the previous route or add duplicate entities.

Control Indexing, Canonicalization, and Duplicate URLs

Robots directives must be intentional and testable. Put stable directives in the initial response. A client-side change from noindex to index is especially risky because a crawler can encounter the restrictive directive before rendering. Do not block JavaScript or API resources required to render public content in robots.txt.

Faceted navigation deserves special attention. Vue makes it easy to generate combinations of filters, sorting, pagination, and UI state. Decide which combinations have independent search value. Give indexable facets stable URLs, unique content, self-referencing canonicals, internal links, and sitemap inclusion. Keep non-search states out of the index through URL design, controlled crawling, canonicals where appropriate, and consistent internal linking. Canonical is a consolidation signal, not a substitute for preventing an infinite crawl space.

Build XML sitemaps from canonical, indexable records. Include only URLs that return 200 and are intended for indexing. Use accurate lastmod values based on meaningful content changes, not the time the sitemap job ran. Split large sitemaps by content type when that improves monitoring, and submit the sitemap index in Search Console.

Optimize Core Web Vitals and JavaScript Cost

Rendering architecture affects both crawl reliability and user performance. Current Core Web Vitals measure loading with Largest Contentful Paint, responsiveness with Interaction to Next Paint, and visual stability with Cumulative Layout Shift. Good field thresholds are an LCP of 2.5 seconds or less, an INP of 200 milliseconds or less, and a CLS of 0.1 or less at the 75th percentile.

SSR can improve the time content appears, but hydration can still ship too much JavaScript and block interaction. Measure the client bundle per route. Split code at route and component boundaries. Remove unused dependencies, avoid importing browser-heavy libraries globally, and delay nonessential analytics and widgets. A server-rendered 500 KB page followed by several megabytes of JavaScript is not a fast page.

Make the LCP resource discoverable in HTML. Do not wait for a mounted component to insert the hero image. Use responsive images, explicit width and height, efficient formats, and an appropriate fetchpriority="high" for the actual above-the-fold LCP image. Do not lazy-load that image. Lazy-load below-the-fold media and reserve dimensions to prevent layout shifts.

To improve INP, reduce long main-thread tasks, expensive watchers, unnecessary reactivity, and large DOM updates. Virtualize truly large interactive lists, but provide crawlable paginated or category URLs for search discovery. For CLS, reserve space for images, ads, embeds, banners, and async components. Test real-user field data because lab tests cannot reproduce every device, network, and interaction.

Audit Raw HTML Against the Rendered DOM

This comparison is the most productive diagnostic in JavaScript SEO, and it is why I built WatchThis. The raw HTML shows what the server delivered before JavaScript. The rendered DOM shows what exists after a browser runs the application. Neither view is sufficient on its own.

Run the comparison on representative URLs from every template: homepage, category, product, article, pagination, filtered page, localized page, 404, redirect target, and a recently published URL. Check at least the following:

HTTP status and redirect chain;
title, description, robots, canonical, and hreflang;
H1 and heading hierarchy;
primary text and data;
internal link count, destinations, and anchor text;
image URLs and alt text;
JSON-LD presence and validity;
JavaScript, hydration, and network errors;
content that appears, disappears, or changes after rendering.

Not every difference is a defect. A menu opening after a click is normal. A title changing from “Loading…” to the product name is not. A personalized cart count is normal. The entire article body appearing only after an API call is a serious dependency. Classify differences according to whether they affect discovery, understanding, canonicalization, index control, or page quality.

You can inspect source with curl or View Source, inspect the live DOM in browser developer tools, and test Google’s rendered view with URL Inspection or Rich Results Test. WatchThis automates the direct comparison: it fetches raw HTML, renders the page in a browser environment, and reports changes to metadata, headings, content, structured data, errors, redirects, and internal links.

curl -s https://example.com/products/blue-widget > raw.html

Do not perform this audit only before launch. JavaScript SEO regressions often arrive through harmless-looking changes: a new head manager, an API migration, a consent platform, a component library update, route caching, or a deployment configuration change.

Build SEO Tests Into Deployment

Manual audits find patterns; automated tests keep them from returning. Add a small set of SEO acceptance tests to continuous integration and production monitoring. For each critical template, assert that the response returns the expected status and contains a nonempty title, one intended H1, a valid canonical, primary content, crawlable internal links, and required schema. Then render the page in a headless browser and compare key fields.

Set thresholds carefully. A changed link count can be expected, but a 70% drop deserves investigation. A title that differs after rendering should fail unless the change is explicitly approved. Detect pages whose server HTML falls below a minimum text or product-data threshold. Monitor the percentage of indexable sitemap URLs returning non-200 responses.

Keep tests close to template ownership. Developers should be able to see which component removed the canonical or moved content behind onMounted(). SEO should be a release property, not a cleanup project performed after traffic declines.

Vue.js SEO Checklist

Classify every route template as SSR, SSG/prerendered, cached hybrid, or intentionally client-only.
Return primary content and SEO metadata in the initial HTML for every indexable page.
Use SSR-aware data fetching and serialize server data for hydration.
Return real 404, 410, 301, 308, 302, or 307 responses when those conditions exist.
Use path-based URLs and verify direct requests to nested routes.
Render internal navigation as anchors with valid href values.
Create unique titles, descriptions, canonicals, and social tags from normalized route data.
Keep server and client output deterministic to avoid hydration mismatch.
Generate structured data from the same data shown to users.
Control facets, parameters, pagination, locales, and duplicate URL variants.
Build sitemaps from canonical indexable records and use meaningful lastmod.
Do not block resources needed for rendering.
Reduce JavaScript cost and monitor LCP, INP, and CLS with field data.
Compare raw HTML with the rendered DOM across all important templates.
Automate critical SEO assertions before and after deployment.

Frequently Asked Questions About Vue SEO

Is Vue.js bad for SEO?

No. Vue is capable of excellent SEO. Problems arise when a public site relies entirely on client-side rendering, returns incorrect statuses, hides links behind JavaScript events, or produces unstable server and client output. Nuxt, custom Vue SSR, and prerendering can all deliver search-friendly HTML when implemented correctly.

Can Google index a client-rendered Vue SPA?

Google can render many JavaScript applications, but that does not make pure CSR the best choice for search-critical pages. Rendering adds dependencies and may delay content processing and link discovery. Other crawlers may not execute JavaScript. If content matters to organic acquisition, serve it in HTML whenever practical.

Should I use SSR or SSG for Vue SEO?

Use SSG or prerendering for stable pages that can be generated in advance. Use SSR or cached hybrid rendering for frequently changing pages that need current server output. Use CSR for private or non-indexable application areas. Many sites should use all three at the route level.

Is dynamic rendering still recommended?

No. Serving a pre-rendered version only to bots is considered a workaround, not the preferred long-term architecture. It increases operational complexity and creates parity risks. Use SSR, static rendering, or hydration for users and crawlers when possible.

How do I know what search engines can see?

Check the HTTP response, rendered DOM, status codes, blocked resources, and Google’s rendered output. Do not judge by what appears in your normal browser session because it may contain cached data, cookies, or local state that a crawler does not have. A raw-versus-rendered comparison exposes the gap directly.

Final Recommendation

The strongest Vue.js SEO setup is not the one with the most complicated rendering stack. It is the one that produces a complete and consistent document for every indexable URL, returns honest HTTP signals, keeps navigation crawlable, and remains observable after deployment.

Start with the raw HTML. If the page’s purpose is not clear there, decide whether the missing elements should be server-rendered or prerendered. Then inspect the rendered DOM for changes, errors, duplicates, and hydration problems. Repeat the test across templates and automate the rules that matter most. You can use WatchThis to compare raw HTML with the rendered DOM and catch JavaScript SEO issues before they affect indexing.