Vue ist ein beliebtes JavaScript-Framework für Oberflächen, von einzelnen Bausteinen auf einer klassischen Website bis zu kompletten Anwendungen. Für Google zählt dabei vor allem, was eine Anwendung im ersten HTML ausliefert und was erst im Browser entsteht. Diese Seite zeigt, an welchen Stellen eine Vue-Anwendung für die Suche angepasst werden muss: Rendering, Routing, Links, Titel und Fehlerseiten. Die allgemeinen Grundlagen stehen im Ratgeber JavaScript SEO Grundlagen; für Angular gibt es einen eigenen Ratgeber unter Angular SEO.
Wird Vue nur für einzelne Bausteine einer sonst klassisch erzeugten Website genutzt, etwa für einen Rechner oder ein Formular, stellen sich die meisten dieser Fragen kaum. Der Inhalt kommt dann als fertiges HTML aus dem CMS, und Vue ergänzt nur die Interaktion. Die folgenden Abschnitte betreffen Anwendungen, bei denen Vue die ganze Seite im Browser aufbaut.
Wie Google eine Vue-Anwendung sieht
Google verarbeitet JavaScript-Webanwendungen in drei Hauptphasen: Crawling, Rendering und Indexierung [1]. Seiten mit dem Statuscode 200 stellt der Googlebot in eine Warteschlange zum Rendern [1]. Erst nach dem Rendern sieht Google, was Vue im Browser aufgebaut hat. Google nennt serverseitiges Rendering oder Pre-Rendering deshalb weiterhin eine sehr gute Option, weil die Website dadurch schneller wird und nicht alle Bots JavaScript ausführen können [1].
Die Vue-Dokumentation beschreibt dasselbe Problem aus Sicht des Frameworks. Reine clientseitige Single-Page-Anwendungen seien problematisch, wenn eine Anwendung auf SEO und eine schnelle Anzeige der Inhalte angewiesen ist, weil der Browser eine weitgehend leere HTML-Seite erhält und warten muss, bis JavaScript geladen ist [2]. Im Leitfaden zum serverseitigen Rendering heißt es zudem, Google und Bing könnten synchrone JavaScript-Anwendungen gut indexieren. Startet die Anwendung aber mit einem Ladekreisel und holt die Inhalte erst danach per Ajax, warte der Crawler nicht, bis sie fertig ist [3].
SSR, SSG und Hydration in Vue
Vue kann dieselben Komponenten auf dem Server zu HTML rendern, an den Browser schicken und dort zu einer interaktiven Anwendung "hydrieren" [3]. Beim Hydrieren erzeugt Vue dieselbe Anwendung wie auf dem Server, ordnet jede Komponente den passenden DOM-Knoten zu und hängt die Ereignisse an [3]. Für Suchmaschinen heißt das: Der Crawler sieht die fertig gerenderte Seite direkt [3]. Den Begriff erklärt das Glossar unter Server-Side Rendering.
Die Alternative ist statische Erzeugung beim Build, kurz SSG. Sie eignet sich laut Vue-Dokumentation nur für Seiten mit statischen Daten, die beim Build feststehen [3]. Für einen häufigen Fall gibt die Dokumentation einen klaren Rat: Wer SSR nur prüft, um die SEO einiger Marketingseiten wie Startseite, Über uns oder Kontakt zu verbessern, braucht wahrscheinlich SSG statt SSR [3].
| Ansatz | passt für | Aufwand |
|---|---|---|
| reine SPA im Browser | Anwendungen hinter einem Login, Werkzeuge ohne Suchbedarf | gering |
| SSG, Vorab-Erzeugung | Marketingseiten, Ratgeber, Dokumentation | mittel |
| SSR | Seiten mit häufig wechselnden Daten, Shops, Portale | höher, Node.js-Server nötig |
Die Tabelle ist eine Einordnung von SEO NW. Die Vue-Dokumentation nennt als Nachteile von SSR unter anderem Einschränkungen bei browserspezifischem Code, einen aufwendigeren Build und mehr Last auf dem Server, weil ein Node.js-Server laufen muss [3]. Einen allgemeinen Vergleich der Rendering-Arten finden Sie im Ratgeber CSR oder SSR wählen.
Noch eine Frage offen?
In der gratis Sprechstunde beantworten wir Fragen zu SEO live, jeden ersten Samstag im Monat um 18 Uhr. Oder Sie rufen einfach an.
Nuxt als Rahmen für SSR
Ein eigenes SSR-Setup ist aufwendig. Die Vue-Dokumentation empfiehlt deshalb ausdrücklich, für SSR ein Vue-Framework zu verwenden, weil diese oft eingebaute SSR-Unterstützung haben [3]. Ein verbreitetes Beispiel ist Nuxt. Nuxt verwendet standardmäßig universelles Rendering: Der Vue-Code läuft auf dem Server und liefert eine fertig gerenderte HTML-Seite an den Browser [4].
Mit den routeRules lässt sich das Rendering je Route festlegen, etwa die Startseite beim Build vorab erzeugen und einen Verwaltungsbereich nur im Browser rendern [4]. Wer Nuxt mit ssr: false betreibt, bekommt reines Rendering im Browser. Die Nuxt-Dokumentation weist darauf hin, dass Indexierung und Aktualisierung dann länger dauern als bei serverseitig gerendertem HTML [4].
Adressen ohne Raute: der Router
Der Vue Router kennt zwei Modi. Der Hash-Modus setzt eine Raute vor den eigentlichen Pfad; die Dokumentation sagt dazu, er habe einen schlechten Einfluss auf SEO [5]. Der HTML5-Modus mit createWebHistory erzeugt saubere Adressen und ist der empfohlene Modus [5]. Google rät ebenfalls, beim clientseitigen Routing die History API zu verwenden und keine Fragmente zum Laden von Inhalten einzusetzen [1].
Der HTML5-Modus braucht eine Anpassung am Server: Eine Auffangregel liefert für alle unbekannten Pfade die index.html aus [5]. Daraus entsteht ein Nebeneffekt, den die Router-Dokumentation selbst nennt: Der Server meldet keine 404-Fehler mehr, weil jeder unbekannte Pfad die Anwendung lädt. Sie empfiehlt eine Auffangroute in der Vue-Anwendung, die eine 404-Seite zeigt [5].
Fehlerseiten ohne Soft 404
Eine 404-Seite, die mit Status 200 ausgeliefert wird, nennt Google einen Soft 404. Für Single-Page-Anwendungen beschreibt Google zwei Auswege: eine JavaScript-Weiterleitung auf eine Adresse, die tatsächlich mit 404 antwortet, oder ein per JavaScript eingefügtes noindex-Meta-Tag auf Fehlerseiten [1]. Mit SSR oder Nuxt lässt sich der richtige Statuscode direkt vom Server senden, was nach unserer Einschätzung die sauberste Lösung ist.
Umgekehrt gilt Vorsicht: Steht noindex bereits im ursprünglichen HTML, kann Google Rendering und JavaScript überspringen. Ein noindex, das JavaScript später wieder entfernen soll, funktioniert deshalb nicht [1].
Echte Links mit RouterLink
Google findet Links nur, wenn sie als a-Element mit href-Attribut vorliegen [1]. In Vue ist RouterLink die übliche Komponente für Navigation. Laut Router-Dokumentation legt die Eigenschaft custom fest, ob RouterLink seinen Inhalt nicht in ein a-Element einpacken soll [6]. Ohne diese Eigenschaft entsteht also ein normales a-Element. Problematisch sind Kacheln oder Schaltflächen, die per @click mit router.push navigieren und kein a-Element enthalten. Für den Crawler sind das keine Links. Mehr dazu im Ratgeber JavaScript-Links und Navigation.
Titel und Beschreibung je Route
Jede Route braucht einen eigenen Title und eine eigene Meta-Description. Google bestätigt, dass sich beide mit JavaScript setzen oder ändern lassen [1]. In einer reinen Vue-Anwendung geschieht das oft in einem Router-Hook nach jeder Navigation. Sicherer ist es, wenn die Angaben schon im gerenderten HTML stehen. In Nuxt dienen dafür die Composables useHead und useSeoMeta; useSeoMeta erlaubt, die SEO-Meta-Tags als Objekt mit voller Typsicherheit zu definieren [7]. Über app.head in der nuxt.config lassen sich statische Vorgaben für die ganze Anwendung setzen. Ein titleTemplate legt ein einheitliches Titelformat fest, zum Beispiel mit dem Namen der Website; die Nuxt-Dokumentation empfiehlt, es als Funktion in app.vue zu setzen [7]. Wie ein guter Title aussieht, beschreibt der Ratgeber Title Tag schreiben.
Prüfen, was Google sieht
Das URL-Prüftool der Search Console zeigt im Live-Test den zurückgegebenen HTML-Code, die HTTP-Header, die Ausgabe der JavaScript-Konsole und die geladenen Ressourcen, dazu einen Screenshot der gerenderten Seite [8]. Prüfen Sie damit für jeden Seitentyp, ob Inhalt, Title, Description, Canonical und Links im gerenderten HTML stehen. Vergleichen Sie zusätzlich den Quelltext, den der Server ohne JavaScript liefert. Nach unserer Erfahrung zeigen sich die meisten Probleme bei Vue-Anwendungen genau in diesem Vergleich.
Sie betreiben eine Vue-Anwendung und sind unsicher, welcher Rendering-Weg zu Ihren Seiten passt? Stellen Sie die Frage in der gratis Sprechstunde, dort besprechen wir Ihren Aufbau.
- Organisation Grundlagen von JavaScript-SEO. Google Search Central. Stand 04.03.2026. abgerufen am 31.10.2026
- Organisation Ways of Using Vue. Vue.js. Stand laufend. abgerufen am 31.10.2026
- Organisation Server-Side Rendering (SSR). Vue.js. Stand laufend. abgerufen am 31.10.2026
- Organisation Rendering Modes. Nuxt. Stand Version 4.x. abgerufen am 31.10.2026
- Organisation Different History modes. Vue Router. Stand laufend. abgerufen am 31.10.2026
- Organisation Interface RouterLinkProps. Vue Router. Stand laufend. abgerufen am 31.10.2026
- Organisation SEO and Meta. Nuxt. Stand Version 4.x. abgerufen am 31.10.2026
- Organisation URL-Prüftool. Search Console-Hilfe. Stand laufend. abgerufen am 31.10.2026
Häufige Fragen
Kann Google eine Vue-Anwendung ohne SSR indexieren?
Grundsätzlich ja, Google rendert JavaScript. Die Vue-Dokumentation warnt aber, dass der Crawler nicht wartet, wenn die Anwendung erst einen Ladekreisel zeigt und Inhalte nachlädt. Google nennt serverseitiges Rendering oder Pre-Rendering eine sehr gute Option.
Brauche ich für Vue SEO unbedingt Nuxt?
Nein. Für wenige Marketingseiten reicht laut Vue-Dokumentation oft statische Erzeugung. Für SSR empfiehlt Vue aber ein Framework wie Nuxt, weil ein eigenes Setup aufwendig ist.
Warum ist der Hash-Modus im Vue Router schlecht für SEO?
Er setzt eine Raute vor den Pfad. Die Router-Dokumentation nennt ausdrücklich einen schlechten Einfluss auf SEO, und Google rät, keine Fragmente zum Laden von Inhalten zu verwenden. Der History-Modus mit createWebHistory ist die empfohlene Wahl.
Wie setze ich in Vue den Title für jede Seite?
In einer reinen Vue-Anwendung meist in einem Router-Hook, in Nuxt mit useHead oder useSeoMeta. Am besten steht der Title schon im serverseitig gerenderten HTML.
Warum meldet meine Vue-Anwendung keine 404-Fehler?
Im History-Modus liefert der Server für alle unbekannten Pfade die index.html aus. Eine Auffangroute in der Anwendung zeigt dann die Fehlerseite, braucht aber zusätzlich noindex oder eine Weiterleitung auf eine echte 404-Adresse.
Noch eine Frage offen?
In der gratis Sprechstunde beantworten wir Fragen zu SEO live, jeden ersten Samstag im Monat um 18 Uhr. Oder Sie rufen einfach an.
Zuletzt geprüft am 03.11.2026, nächste Prüfung spätestens im November 2027. Haben Sie einen Fehler entdeckt? Schreiben Sie uns.
