Sprachen

Nuxt und SEO

Nuxt liefert standardmäßig serverseitiges Rendering, aber das ist eine Einstellung pro Route, keine Garantie – vollständiges HTML für Crawler nur auf Routen, die es beibehalten. Rendering-Modi, useSeoMeta(), das @nuxtjs/seo-Toolkit, Hydration- und Nitro-Besonderheiten, Core Web Vitals und die Fehler, die Sie stillschweigend kosten.

Erstveröffentlicht: 26. Juni 2026 · Zuletzt aktualisiert: 21. Aug. 2026 · Fortgeschritten
Sprachen
AIVerfasst vonAI v2
1 Evidenzsignal auf dieser Seite

Nuxt rendert Seiten standardmäßig serverseitig, sodass eine Route, die diese Standardeinstellung beibehält, Crawlern ein vollständiges HTML-Dokument liefert, anstatt der leeren Hülle, die eine einfache Vue-SPA ausliefert – aber es ist eine Einstellung pro Route: routeRules oder ein globales ssr:false kann jede Route auf CSR umstellen, also überprüfen Sie die tatsächliche Route, anstatt vom Framework-Namen auszugehen. Die grundlegende Entscheidung ist der Rendering-Modus pro Route – SSR (Standard), SSG über nuxt generate oder hybride Routenregeln – denn Meta-Tags, Schema und Sitemaps kommen alle danach. Verwenden Sie useSeoMeta() für Meta, behandeln Sie Harlan Wiltons @nuxtjs/seo-Bundle als optionales Drittanbieter-Toolkit (nicht Nuxt-Kern) für robots/sitemap/OG/schema/canonical, greifen Sie niemals zu dynamischem Rendering (Google hat es eingestellt), überprüfen Sie Hydration/Payload und Nitro-Deployment-Preset/Cache-Verhalten unabhängig vom Server-HTML, und denken Sie daran, dass die Rendering-Verträge für KI-Crawler je nach Anbieter variieren – SSR/SSG platziert Inhalte in rohem HTML und maximiert die Abdeckung.

TL;DR – Nuxts Standard ist Server-Side Rendering, sodass eine Route, die diesen Standard beibehält, ein vollständiges DOM erhält, statt der leeren Hülle, die eine reine Vue-SPA ausliefert – aber das ist ein Ergebnis pro Route: ssr: false oder eine routeRules-Überschreibung kann jede Route in CSR oder Hybrid umwandeln. Testen Sie also die tatsächliche Route, nicht den Projektnamen. Die Rendering-Strategie ist die grundlegende Entscheidung – SSR (Standard), SSG (nuxt generate) oder hybrides routeRules –, weil Meta, Schema und Sitemaps alle danach kommen. Verwenden Sie useSeoMeta() für Meta-Tags (useHead() für den Rest des Head-Bereichs, Server-only-Varianten, wenn Sie keine Reaktivität benötigen), und behandeln Sie Harlan Wiltons @nuxtjs/seo-Bundle als optionales Drittanbieter-Toolkit für Robots/Sitemap/OG/Schema/Canonical – nicht als Teil von Nuxt Core und nicht als Beweis für eine korrekte Ausgabe vor deren Prüfung. Verwenden Sie niemals Dynamic Rendering (Google hat es verworfen). Das Rendering von KI-Crawlern variiert je nach Anbieter – SSR/SSG maximiert die Abdeckung von rohem HTML. Über das anfängliche HTML hinaus verifizieren Sie Hydration/Payload, Nitro-Deployment-Presets und Caching sowie direkte HTTP-Status unabhängig – Server-HTML allein beweist keines davon. Die üblichen JS-SEO-Regeln gelten weiterhin: echte <a href>-Links, JS/CSS nicht blockieren, gerendertes vs. rohes HTML überwachen.

Nuxt ist Vues Antwort auf das SPA-Problem

Vue liefert von sich aus eine Single-Page-Anwendung: eine HTML-Hülle plus JavaScript, mit dem das DOM im Browser aufgebaut wird. Nuxt ist das Meta-Framework auf Vue (läuft auf der Nitro-Server-Engine in Nuxt 3, mit Nuxt 4 ab 2025), und sein gesamter Existenzgrund – aus SEO-Sicht – ist, dass es standardmäßig auf dem Server rendert. Jede Seite kommt als vollständig geformtes HTML-Dokument an, was genau das ist, was Googlebot lesen möchte, ohne zuerst JavaScript ausführen zu müssen. Reines Vue-SEO ist ein eigenes Thema mit eigenen Fehlermodi; hier gehe ich davon aus, dass Sie Nuxt genau deshalb gewählt haben, um nicht gegen das SPA-Problem kämpfen zu müssen.

Das ist derselbe Punkt, den ich allgemein zu JavaScript mache: “any kind of SSR, static rendering, and prerendering setup is going to be fine for search engines. Gatsby, Next, Nuxt, etc., are all great.” (Übersetzung) „Jede Form von SSR, statischem Rendering und Prerendering eignet sich für Suchmaschinen. Gatsby, Next, Nuxt und ähnliche Frameworks sind dafür bestens geeignet.“ Nuxts Standardeinstellungen sind in die richtige Richtung ausgerichtet. Die meisten Nuxt-SEO-Probleme entstehen, wenn Leute diese Standardeinstellungen deaktivieren oder Fehler darauf aufbauen.

Die Rendering-Strategie ist die Grundlage – pro Route entschieden, nicht pro Projekt

Vor Meta-Tags, vor Schema, vor Sitemaps ist die Frage, die alles entscheidet: Wie wird das HTML für diese spezifische Route erzeugt? Nuxt dokumentiert universelles (Server-)Rendering als app-weiten Standard, aber dieser Standard ist keine Garantie auf Routenebene: Ein globales ssr: false schaltet die gesamte App auf Client-Rendering um, und routeRules kann jedem URL-Muster einen anderen Modus zuweisen. „Das ist eine Nuxt-App“ sagt Ihnen nichts darüber, wie eine bestimmte Seite rendert – Sie müssen die Route prüfen. Nuxt bietet Ihnen fünf Strategien:

ModusSo stellen Sie ihn einSEO-AuswirkungAm besten geeignet für
Universal / SSRStandard (ssr: true)Ausgezeichnet – vollständiges HTML bei jeder AnfrageDynamische, personalisierte Inhalte
Statisch / SSGnuxt generateAusgezeichnet – HTML zur Bereitstellungszeit erstelltBlogs, Dokumentation, Marketing
HybridrouteRules pro RouteAusgezeichnet – Mischung pro RouteGroße Seiten mit gemischten Inhalten
SPA / CSRssr: falseSchlecht für indexierte InhalteDashboards, Admin-Panels
Edge-seitigBereitstellungszielAusgezeichnet – niedrige TTFBGlobale Leistung

Die offiziellen Nuxt-Dokumente sind unmissverständlich, warum Client-Side-Rendering die falsche Wahl für Inhalte ist: “Indexing and updating the content delivered via client-side rendering takes more time” (Übersetzung) „Das Indizieren und Aktualisieren von Inhalten, die über clientseitiges Rendering ausgeliefert werden, dauert länger“, wohingegen bei Server- beziehungsweise Universal-Rendering “web crawlers can directly index the page’s content.” (Übersetzung) „Web-Crawler den Inhalt der Seite direkt indizieren können.“ Evidence for this claim Nuxt documents that universal rendering delivers HTML content immediately and allows crawlers to index it directly. Scope: Nuxt rendering; no indexing guarantee. Confidence: high · Verified: Nuxt: Rendering modes (Nuxt rendering docs.) CSR (ssr: false) ist für Back-Office, Dashboards und Spiele gedacht – nicht für etwas, das Sie indexiert haben möchten.

Hybrides Rendering ist der entscheidende Vorteil für große Websites. Routenregeln in nuxt.config.ts ermöglichen es Ihnen, den Rendering- und Cache-Modus pro URL-Muster festzulegen:

routeRules: {
  '/blog/**':     { prerender: true },        // SSG for the blog
  '/product/**':  { swr: 3600 },              // ISR-style: regenerate hourly
  '/admin/**':    { ssr: false },             // SPA for the admin area
  '/checkout/**': { ssr: true },              // always-fresh SSR
}

swr (stale-while-revalidate) und isr (incremental static regeneration) generieren eine Seite statisch und aktualisieren sie dann im Hintergrund – ideal für E-Commerce mit vielen Seiten oder Nachrichten, bei denen ein vollständiger Neuaufbau bei jeder Änderung nicht praktikabel ist. Nuxt Islands (<NuxtIsland>) rendern Komponenten, ohne clientseitiges JavaScript auszuliefern, was die Hydrierungskosten senkt und INP verbessert – die Core Web Vital, die bei Nuxt-Apps am häufigsten problematisch ist.

So überprüfen Sie, was Sie tatsächlich ausgeliefert haben: View Source zeigt das rohe HTML, das der Server gesendet hat; wenn Ihr Inhalt dort ist, rendern Sie serverseitig. Das Elements-Panel von DevTools zeigt das gerenderte DOM. Und das URL Inspection-Tool von GSC zeigt, was Google tatsächlich abgerufen und gerendert hat – die Quelle der Wahrheit. Vertrauen Sie nicht auf “sieht in meinem Browser gut aus”.

Wie Googlebot eine Nuxt-App verarbeitet

Google verarbeitet jede JavaScript-App in drei Phasen – Crawlen, Rendern, Indexieren – und die Herausforderung ist das Timing: Das Rendern erfolgt in einer Warteschlange, nicht sofort. Wie ich es in meinem JavaScript-SEO-Leitfaden formuliert habe, ist der Renderer geduldig – “there is no fixed timeout for the renderer… It’s really patient, and you should not be concerned.” (Übersetzung) „Es gibt kein festes Zeitlimit für den Renderer … Er ist wirklich geduldig, und Sie sollten sich keine Sorgen machen.“ Aber geduldig ist nicht dasselbe wie schnell für frische Inhalte. Wenn Sie eine clientgerenderte Seite ausliefern, existiert Ihr Inhalt für Google erst, wenn diese Render-Welle läuft; SSR und SSG schließen diese Lücke, weil das HTML beim ersten Abruf vollständig ist.

Zwei weitere Dinge sind im großen Maßstab wichtig. Das Rendern von JavaScript ist teuer – aus meinem Vortrag JavaScript SEO (Ungagged) von 2019 steigen die Crawl-Kosten um etwa das 20-Fache, sobald Google rendern muss (richtungsweisend, aber die Größenordnung gilt weiterhin). Und Google verwendet die restriktivste Direktive über rohes und gerendertes HTML hinweg – so gewinnt ein per JavaScript injiziertes noindex gegenüber einem index im rohen HTML und umgekehrt. Ein über JavaScript injiziertes Canonical wird nur respektiert, wenn im rohen HTML noch kein Canonical vorhanden ist. Halten Sie Ihre Robots- und Canonical-Signale im serverseitig gerenderten HTML, was Nuxt für Sie erledigt, wenn SSR aktiviert ist.

Die Realität der KI-Crawler

Das ist die Besonderheit von 2026. KI-Crawler – GPTBot, ClaudeBot, PerplexityBot und der Rest – führen im Allgemeinen kein JavaScript aus. Sie indexieren das rohe HTML und sonst nichts. Eine clientgerenderte Nuxt-Seite ist für KI-Antwort-Engines also praktisch unsichtbar. SSR oder SSG ist hier nicht nur besser für Google; es ist die Eintrittskarte für Answer-Engine-Optimierung. Wenn Sie möchten, dass Ihre Inhalte von ChatGPT, Perplexity oder Claude zitiert werden, müssen sie beim ersten Abruf im HTML enthalten sein.

Über das anfängliche HTML hinaus: Payload, Hydrierung und Statuscodes

Serverseitiges HTML mit Ihrem Inhalt zu erhalten ist notwendig, aber nicht ausreichend – mehrere Dinge können nach dieser ersten Antwort dennoch schiefgehen, und “ich habe View Source überprüft” deckt sie nicht ab:

  • Datenübergabe und Hydrierung. Universelles Rendering sendet das HTML und einen serialisierten Datenzustand, mit dem der Browser die Seite hydriert. Dabei bindet er Ereignisbehandler ein und setzt den Zustand des Servers fort, ohne die Daten erneut abzurufen. Dass das Server-HTML richtig aussieht, beweist nicht, dass die Hydration erfolgreich war, dass die Client-Navigation denselben Inhalt reproduziert oder dass der Payload nicht veraltet ist. Wenn eine Seite beim ersten Laden gut funktioniert, aber nach einer clientseitigen Routenänderung bricht, ist das ein Hydrations-/Payload-Problem, kein Rendering-Modus-Problem.
  • <ClientOnly> und ausschließlich im Browser verfügbare Inhalte. Etwas in <ClientOnly> zu wrappen – üblich für Widgets, die von Browser-APIs abhängen – bedeutet, dass es in der Serverantwort fehlt, selbst auf einer ansonsten universellen Route. Wenn Ihre Hauptinhalte, ein wichtiger Link oder Ihre Meta-Tags in einer Grenze für rein clientseitige Inhalte geraten, übersehen Crawler und KI-Bots, die nur das rohe HTML lesen, diese Inhalte, unabhängig von Ihrer Rendering-Modus-Einstellung. Überprüfen Sie die tatsächliche Antwort, nicht nur die Rendering-Modus-Konfiguration.
  • Statuscodes und Weiterleitungen sind nicht selbstbestätigend. Eine Nuxt-Fehlerseite, die im Browser gerendert wird, oder eine navigateTo()/Composable-gesteuerte Weiterleitung beweist für sich genommen nicht, welchen HTTP-Status die direkte Serverantwort gesendet hat. Googles Leitfaden ist eindeutig, dass aussagekräftige Statuscodes für das Crawling und die Indexierung wichtig sind – bestätigen Sie den tatsächlichen Header mit curl -I, nicht das, was die clientgerenderte Fehlerseite anzeigt.

Nichts davon ist ein Argument gegen universelles Rendering – es ist die Erinnerung daran, dass „das HTML ist servergerendert“ der erste Check ist, nicht der letzte.

Nitro, Deployment-Presets und Cache-Grenzen

Nuxts Serverausgabe wird von Nitro erstellt, und Nitro kompiliert unterschiedlich, je nachdem, welches Deployment-Preset Sie anvisieren (Node-Server, Cloudflare, Vercel, Netlify, statisch und andere). Das ist für SEO wichtig, weil Presets und Adapter sich in verfügbaren Laufzeit-APIs, Cache-Verhalten, Streaming-Unterstützung, regionalem Deployment und Dateisystemzugriff unterscheiden können – eine Routenregel oder ein Server-Handler, der unter einem Preset funktioniert, ist nicht garantiert unter einem anderen identisch. Zwei Konsequenzen, die es wert sind, explizit getestet zu werden, statt sie anzunehmen:

  • Cache-Schlüssel und Invalidierung sind routenspezifisch, nicht automatisch. swr- und isr-Routenregeln cachen und regenerieren die Ausgabe, aber ein falscher Cache-Schlüssel, fehlende Invalidierung oder ein Cache-Header, der von Ihrer Deployment-Plattform gesetzt wird, können veraltetes, personalisiertes oder inkonsistentes HTML an Crawler ausliefern. Überprüfen Sie das tatsächliche Antwortalter und alle Cache-Control/Age-Header auf einer Live-URL, nicht nur die routeRules-Konfiguration.
  • Produktionsparität ist nicht durch Staging-Verhalten garantiert. Eine Route, die in der lokalen Entwicklung oder in einer Preview-Deployment korrekt rendert, bestätigt nicht, dass das Produktions-Preset dieselbe Ausgabe erzeugt – Serverrouten, Weiterleitungen und Fehlerbehandlung leben in Nitros Server-Schicht, und diese Schicht ist der Teil, der sich am wahrscheinlichsten je nach Ziel unterscheidet. Testen Sie die Produktions-URL direkt nach jeder Deployment-Änderung, so wie Sie den Rendering-Modus verifizieren würden.

Meta-Tags: useSeoMeta() und useHead()

Nuxts Head-Verwaltung läuft auf Unhead und bietet zwei Composables für unterschiedliche Aufgaben.

useSeoMeta() ist das, was Sie für SEO- und Social-Meta-Tags verwenden sollten. Es ist eine flache, typsichere API mit typisierten Parametern. Evidence for this claim useSeoMeta is a typed Nuxt API for SEO and social meta tags. Scope: Current Nuxt composable. Confidence: high · Verified: Nuxt: useSeoMeta Es hilft, den klassischen Open-Graph-Bug zu vermeiden, bei dem name verwendet wird, wo property benötigt wird:

useSeoMeta({
  title: 'My Page Title',
  ogTitle: 'My Page Title',
  description: 'Concise page-specific description with the key information first',
  ogDescription: 'Concise social description tailored to this page',
  ogImage: 'https://mysite.com/og-image.png', // must be an absolute URL
  twitterCard: 'summary_large_image',
})

useHead() ist das Allzweck-Head-Tool für alles andere – Skripte, Link-Tags, Body-Attribute und Titelvorlagen:

useHead({
  titleTemplate: '%s · My Site Name',
  htmlAttrs: { lang: 'en' },
})

Das zuverlässige Schichtungsmuster ist: statische Standardwerte (Zeichensatz, Viewport, Favicon) in nuxt.config.ts → seitenweite Titelvorlage und globale OG-Standardwerte in app.vue → seitenspezifische Überschreibungen über useSeoMeta() in der Seitenkomponente. Ein häufiger Fehler ist, useSeoMeta() in einem Layout statt in der Seite zu platzieren, wodurch spezifische Seiten-Tags mit generischen überschrieben werden. Und da Suchmaschinen den initialen Ladevorgang lesen, muss SEO-Meta generell nicht reaktiv sein – useServerHead() überspringt die clientseitige Neuausführung.

Welche API und was sie tatsächlich beweist:

APIUmfangReaktiv?Was sie über die Ausgabe beweist
useSeoMeta()Nur flache, typisierte SEO-/Social-MetaJa (Standard)Setzt typisierte Eigenschaften korrekt – nicht, dass die Route eindeutig, kanonisch oder indexierbar ist; diese Logik liegt weiterhin bei Ihnen
useHead()Alles in <head> – Skripte, Links, Attribute, TitelvorlageJa (Standard)Allgemeine Head-Kontrolle; gleiche Einschränkung – API-Nutzung ist kein Beweis für eine korrekte Serverantwort
useServerHead() / nur Server-AufrufeWie obenNein – nur Server, überspringt Client-NeuausführungBestätigt, dass das Tag einmal im Server-HTML ausgeliefert wird; bestätigt nicht, dass die Client-Navigation es erneut setzt, wenn Sie sich dort darauf verlassen

Der Aufruf einer dieser Composables sagt Ihnen, dass die API ausgeführt wurde – es sagt Ihnen nicht von selbst, was eine direkte Serverantwort oder eine clientseitige Routenänderung tatsächlich ausgibt. Bestätigen Sie dies mit View Source oder curl, nicht nur mit „Ich habe useSeoMeta() aufgerufen.“

Das @nuxtjs/seo-Modul-Ökosystem (Harlan Wilton) – optional, nicht Kern

Nuxt-Kern liefert keine Sitemap, kein robots.txt, keine OG-Bildgenerierung oder Schema.org out of the box – diese liegen außerhalb von Nuxts eigenen Primitiven (useHead, useSeoMeta, Routenregeln, Rendering-Modi). Die Community füllt diese Lücke mit Harlan Wiltons @nuxtjs/seo – einem separat installierten Drittanbieter-Überbegriffspaket (nuxtseo.com, derzeit v5.x, aktiv gepflegt, zielt auf Nuxt 3,16+ und Nuxt 4), das sechs Module bündelt. Die Installation gibt Ihnen Sitemap, Robots, OG-Bild und Schema-Generierung – es garantiert nicht von selbst, dass die Ausgabe für Ihre Routen korrekt ist; verifizieren Sie, was es produziert, auf dieselbe Weise, wie Sie alles andere verifizieren würden:

ModulWas es tut
@nuxtjs/robotsrobots.txt + Meta-Robots + X-Robots-Tag-Header
@nuxtjs/sitemapAutomatische XML-Sitemaps aus Seiten + dynamischen Routen
nuxt-og-imageDynamische OG-Bilder (eine Vue-Vorlage → ein Bild)
nuxt-schema-orgSchema.org-JSON-LD-Strukturierte Daten
nuxt-seo-utilsKanonische URLs, Breadcrumbs, Standardwerte
nuxt-link-checkerBuild-Zeit-Erkennung defekter Links

Installieren Sie das gesamte Bündel mit npx nuxt module add seo, oder holen Sie sich einzelne Module (npx nuxt module add sitemap robots). Einige Verhaltensweisen, die Sie kennen sollten:

  • @nuxtjs/sitemap generiert automatisch aus Ihrem pages/-Verzeichnis plus dynamischen Routen, teilt automatisch in ein Sitemap-Index über 50 000 URLs auf, unterstützt i18n mehrsprachige Sitemaps und hat integrierte IndexNow-Unterstützung. Eine Sache, die Sie richtig machen sollten: Google ignoriert changefreq und priority; nur ein genaues lastmod zählt, und nur, wenn sich Inhalte tatsächlich ändern.
  • @nuxtjs/robots generiert robots.txt, das Robots-Meta-Tag und den X-Robots-Tag-Header – und standardmäßig verbietet es allen Crawlern den Zugriff auf Nicht-Produktionsumgebungen, was genau die Staging-Indexierungs-Falle ist, die Headless-Builds beißt. Es gibt Ihnen auch Regeln pro Bot, sodass Sie GPTBot gezielt blockieren können, während Sie alle anderen in Ruhe lassen (seien Sie bewusst – blockieren Sie einen KI-Crawler und er wird Sie nicht zitieren).
  • nuxt-seo-utils behandelt kanonische URLs und entfernt nützlicherweise Tracking- Parameter (utm_*, fbclid, gclid) automatisch aus Kanonischen.

nuxt/image und Core Web Vitals

@nuxt/image ist das Bildmodul: automatisches responsives srcset, moderne Formate (WebP/AVIF), integrierte Optimierung über CDN-Anbieter und Lazy Loading. Zwei Regeln tragen den größten Teil des SEO-Werts:

  • Laden Sie das LCP-Bild niemals verzögert. Ihr Hero-Bild sollte sofort geladen werden; verzögertes Laden verzögert Ihr Largest Contentful Paint.
  • Setzen Sie immer width und height, damit der Browser Platz reserviert und Sie keinen Cumulative Layout Shift erleiden.
<NuxtImg
  src="/hero.jpg"
  width="1200"
  height="630"
  alt="Descriptive alt text"
  :loading="isHeroImage ? 'eager' : 'lazy'"
  format="webp"
/>

Die Ziele für 2026 (p75): LCP ≤ 2,5 s, INP ≤ 200ms, CLS ≤ 0,1. Bei Nuxt-Apps ist INP der Wert, der tendenziell leidet, weil Hydration Eingabeverzögerungen verursacht – genau dafür sind Nuxt Islands und <NuxtIsland> gedacht.

Nuxt Content + SEO

Wenn Sie @nuxt/content (das Markdown/MDX-Inhaltsmodul) verwenden, ist die Integration mit @nuxtjs/seo unkompliziert, hat aber eine Reihenfolge-Falle: Laden Sie @nuxtjs/seo vor @nuxt/content in Ihrem Module-Array. Sie können dann SEO im Content-Frontmatter (title, description, robots, ogImage, schemaOrg) festlegen und es in Ihre [slug].vue-Vorlage mit useSeoMeta() nach dem Abrufen des Inhalts einbinden. Dies ist die Nuxt-native Version des Headless-CMS-Musters, und dieselbe Disziplin „das neu aufbauen, was das Plugin getan hat“ gilt.

Häufige Nuxt-SEO-Fehler

  1. CSR (ssr: false) für Inhalte verwenden, die indexiert werden sollen. Das ist der teuerste Fehler und macht Ihre Inhalte für KI-Crawler unsichtbar.
  2. Relative Adressen für OG-Bilder. ogImage muss eine absolute URL sein, sonst brechen Social-Previews.
  3. useSeoMeta() in einem Layout statt auf der Seite – generische Tags überschreiben seitenbezogene.
  4. Gerendertes HTML nicht überprüfen – View Source ≠ DevTools ≠ was Google gerendert hat. Verwenden Sie URL Inspection.
  5. JS/CSS in robots.txt blockieren – Google rendert nicht aus blockierten Dateien.
  6. Das Staging-noindex/disallow nach dem Launch belassen (oder umgekehrt vergessen, dass @nuxtjs/robots Nicht-Prod standardmäßig blockiert, und sich wundern, warum Prod funktioniert, aber eine benutzerdefinierte Umgebung nicht).
  7. Das LCP-Bild verzögert laden – senkt Ihr LCP.
  8. Fehlende width/height bei Bildern – CLS.
  9. changefreq/priority in Sitemaps – Google ignoriert sie; nur lastmod zählt.
  10. Zu Dynamic Rendering greifen. Google hat es veraltet – “dynamic rendering is a workaround and not a long-term solution” (Übersetzung) „Dynamic Rendering ist ein Workaround und keine langfristige Lösung“ – und es bedient nur die Engines, für die Sie es konfigurieren, und lässt Bing und jeden KI-Crawler aus. Mit Nuxt brauchen Sie es nie: SSR und SSG liefern Crawlern bereits vollständiges HTML.

llms.txt und AEO

llms.txt ist eine Klartextdatei – der Cousin von robots.txt – die KI-Tools dabei hilft, Ihre Inhalte zu navigieren. Das nuxt-llms-Modul generiert automatisch /llms.txt und /llms-full.txt aus Nuxt Content. Seit Ende 2025 sind seine Hauptnutzer MCP-Server und KI-Codierungstools (Cursor, Claude Code) eher als ChatGPT oder Perplexity direkt, und es ist am nützlichsten für Dokumentationsseiten und technische Blogs – weniger für E-Commerce oder Nachrichten. Es lohnt sich, wenn Sie eine Docs-/Dev-Site haben; sonst keine Priorität.

Wo dies einzuordnen ist

Nuxt-SEO ist wirklich eine konkrete Anwendung von JavaScript-SEO durch Nuxts eigene Konventionen – und es überschneidet sich stark mit dem Thema SEO für ein Headless-CMS, wenn Ihr Nuxt-Frontend von einem Headless-Backend zieht. Die Prinzipien ändern sich nicht; Nuxt bietet nur gute Standardwerte und ein starkes Modul-Ökosystem, um sie umzusetzen.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.