Nuxt Content Preview Modus: Entwürfe sicher verwalten und testen

1. Warum Draft Content ohne Preview Modus riskant ist

Ohne einen funktionierenden Preview Modus bleibt Redakteuren häufig nur ein unbefriedigender Kompromiss: Entwürfe entweder direkt live schalten und hoffen, dass niemand die unfertige Seite vor der finalen Prüfung entdeckt, oder den kompletten Entwicklungsserver lokal starten, was für nicht technische Teammitglieder oft keine praktikable Option ist. Beide Wege erhöhen das Risiko, dass halbfertige Inhalte versehentlich live gehen oder von Suchmaschinen indexiert werden, bevor sie überhaupt fertig sind.

Ein sauberer Preview Modus für Nuxt Content löst dieses Problem, indem er einen geschützten Zugang zu Entwürfen schafft, der unabhängig vom normalen Veröffentlichungsstatus funktioniert. Über einen speziellen Link mit Token kann ein Redakteur, ein Reviewer oder ein Kunde den Entwurf exakt so sehen, wie er später live aussehen wird, während reguläre Besucher und Suchmaschinen Crawler weiterhin nur veröffentlichte Inhalte zu Gesicht bekommen.

Ein praktisches Beispiel verdeutlicht den Nutzen: Ein Marketing Team schreibt einen Blogartikel für eine Produktankündigung, die erst in zwei Wochen stattfinden soll. Ohne Preview Modus müsste der Artikel entweder verfrüht live gehen oder komplett unsichtbar bleiben, bis er fertig ist. Mit Preview Modus lässt sich der Artikel per Link mit Kollegen und Stakeholdern teilen, exakt im finalen Layout, ohne dass er für die Öffentlichkeit sichtbar wird.

2. Das draft Feld im Frontmatter und Standard Filterung

Die Grundlage für jeden Preview Modus in Nuxt Content ist ein draft Feld im Frontmatter, das über eine Content Collection Schema Definition typisiert und standardmäßig auf false gesetzt wird. Jede Abfrage über den Query Builder filtert im Normalbetrieb automatisch alle Einträge mit draft: true heraus, sodass unveröffentlichte Inhalte in regulären Übersichtsseiten und über direkte URLs unsichtbar bleiben.

Diese Standard Filterung ist die erste und wichtigste Sicherheitsebene für jeden Preview Modus: Ohne ein zuverlässiges draft Feld gibt es keine verlässliche Unterscheidung zwischen veröffentlichten und unveröffentlichten Inhalten, und jede weitere Preview Logik baut auf dieser Grundunterscheidung auf. Wichtig ist, das Feld mit einem klaren Standardwert zu versehen, damit neue Dateien ohne explizite Angabe automatisch als Entwurf oder als veröffentlicht behandelt werden, je nachdem, welches Verhalten für das Projekt sinnvoller ist.

// content.config.ts — draft field as the foundation for preview mode
import { defineContentConfig, defineCollection, z } from '@nuxt/content'

export default defineContentConfig({
  collections: {
    blog: defineCollection({
      type: 'page',
      source: 'blog/**/*.md',
      schema: z.object({
        title: z.string(),
        date: z.date(),
        // New files default to draft until explicitly published
        draft: z.boolean().default(true)
      })
    })
  }
})

3. Preview Modus aktivieren: Query Parameter und State

Der übliche Weg, den Preview Modus für einen einzelnen Besuch zu aktivieren, führt über einen Query Parameter in der URL, etwa ?preview=true, kombiniert mit einem geteilten Preview Token. Ein globaler useState Wert speichert, ob der aktuelle Besuch im Preview Modus läuft, und diese Information wird dann in jeder Content Abfrage berücksichtigt, um auch Entwürfe mit einzuschließen.

Wichtig ist, dass diese Aktivierung ausschließlich clientseitig oder über eine explizite Server Prüfung erfolgt und niemals allein durch das Vorhandensein des Query Parameters ohne Token Prüfung. Ein Preview Modus, der jedem Besucher mit einem einfachen URL Parameter Zugriff auf alle Entwürfe gäbe, wäre keine echte Absicherung, sondern nur eine kosmetische Hürde, die jeder durch einfaches Ausprobieren der URL umgehen könnte.

// composables/usePreviewMode.ts
export function usePreviewMode() {
  const isPreview = useState('preview-mode', () => false)

  function enablePreview() {
    isPreview.value = true
  }

  return { isPreview, enablePreview }
}

// plugins/preview.client.ts — check token on page load
export default defineNuxtPlugin(() => {
  const route = useRoute()
  const { enablePreview } = usePreviewMode()

  // Token validation happens server side, this only reads the result
  if (route.query.preview === 'true' && route.query.token) {
    enablePreview()
  }
})

4. Server Middleware für Preview Tokens

Die tatsächliche Sicherheitsprüfung für den Preview Modus gehört immer auf den Server, niemals ausschließlich in den Client. Eine Nitro Server Middleware prüft bei jeder Anfrage mit Preview Query Parametern, ob das mitgesendete Token gültig ist, meist durch Vergleich mit einem in Umgebungsvariablen hinterlegten Geheimwert. Nur bei gültigem Token wird ein serverseitiges Cookie oder ein Session Flag gesetzt, das nachfolgende Requests als Preview Sitzung markiert.

Dieser Ansatz stellt sicher, dass der eigentliche Zugriffsschutz für den Preview Modus nicht durch reine Client Logik umgangen werden kann, die jeder in den Browser Entwicklertools einsehen und manipulieren könnte. Das Token selbst sollte ausreichend lang und zufällig sein, idealerweise mit einer Ablaufzeit versehen, damit ein einmal geteilter Preview Link nicht dauerhaft gültig bleibt.

// server/middleware/preview.ts
export default defineEventHandler((event) => {
  const query = getQuery(event)

  if (query.preview === 'true') {
    const token = query.token as string
    const validToken = useRuntimeConfig().previewToken

    if (token !== validToken) {
      throw createError({ statusCode: 403, statusMessage: 'Invalid preview token' })
    }

    // Set a short lived cookie so subsequent requests stay in preview mode
    setCookie(event, 'preview-session', 'active', {
      maxAge: 60 * 60 * 2, // 2 hours
      httpOnly: true
    })
  }
})

5. Entwürfe im Frontend sichtbar machen

Sobald der Preview Modus serverseitig bestätigt ist, muss die Content Abfrage im Frontend das draft Feld anders behandeln als im Normalbetrieb. Statt Entwürfe grundsätzlich herauszufiltern, erlaubt eine bedingte Query Bedingung, basierend auf dem Preview Status, auch Einträge mit draft: true mit einzuschließen. Diese Unterscheidung sollte zentral in einem Composable gekapselt werden, damit nicht an jeder Stelle im Code manuell zwischen den beiden Modi verzweigt werden muss.

Zusätzlich empfiehlt sich ein visueller Hinweis auf der Seite selbst, etwa ein auffälliges Banner, das anzeigt, dass die aktuell angezeigte Version ein ungeprüfter Entwurf ist. Dieser Hinweis verhindert Missverständnisse bei Reviewern, die sonst nicht sofort erkennen, ob sie die bereits veröffentlichte oder die als Entwurf markierte Version eines Artikels betrachten.

// composables/useBlogPost.ts
export function useBlogPost(slug: string) {
  const { isPreview } = usePreviewMode()

  return useAsyncData(`post-${slug}`, () => {
    const query = queryCollection('blog').path(`/blog/${slug}`)

    // Only bypass the draft filter when preview mode is confirmed active
    if (!isPreview.value) {
      query.where('draft', '=', false)
    }

    return query.first()
  })
}

6. Nuxt Studio als alternative Vorschau Lösung

Neben einem selbst gebauten Preview Modus bietet Nuxt Studio, die visuelle Editor Oberfläche für Nuxt Content, eine alternative Lösung mit integrierter Live Vorschau direkt beim Bearbeiten eines Artikels. Redakteure sehen Änderungen in Echtzeit im finalen Layout, ohne eine separate Preview Infrastruktur selbst aufbauen zu müssen, was besonders für Teams ohne eigene Entwicklungsressourcen attraktiv ist.

Der Kompromiss bei Nuxt Studio liegt in der Abhängigkeit von einem zusätzlichen Dienst und einem anderen redaktionellen Workflow als das direkte Bearbeiten von Markdown Dateien im Git Repository. Für Teams, die bereits vollständig auf Git basierte Workflows mit Pull Requests setzen, bleibt ein selbst gebauter Preview Modus über Token oft die passendere Wahl, weil er sich nahtlos in bestehende Review Prozesse einfügt, statt einen parallelen Workflow zu etablieren.

7. Token Ablauf und Zugriffsschutz absichern

Ein häufig übersehener Aspekt bei der Absicherung des Preview Modus ist der Umgang mit abgelaufenen oder kompromittierten Tokens. Ein statisches, niemals wechselndes Token in einer Umgebungsvariable funktioniert zwar technisch, bedeutet aber, dass ein einmal geleaktes Token dauerhaft gültig bleibt, bis es manuell ausgetauscht wird. Für höhere Sicherheitsanforderungen empfiehlt sich stattdessen ein zeitlich begrenztes, signiertes Token, das nach Ablauf automatisch ungültig wird.

Zusätzlich sollte jede Preview Route explizit mit noindex Meta Tags versehen werden, damit selbst bei versehentlicher Verlinkung keine Suchmaschine die Entwurfsversion indexiert. Diese doppelte Absicherung, Token Prüfung plus noindex, stellt sicher, dass der Preview Modus auch bei kleineren Konfigurationsfehlern nicht zu ungewollter öffentlicher Sichtbarkeit von Entwürfen führt.

// nuxt.config.ts — ensure preview routes are never indexed
export default defineNuxtConfig({
  routeRules: {
    '/blog/**': {
      headers: {
        'X-Robots-Tag': 'noindex'
      },
      // Only applied conditionally when preview query param is present,
      // handled via server middleware for finer control per request
    }
  }
})

8. Typische Fallstricke im Praxiseinsatz

Der häufigste Fehler bei der Umsetzung eines Preview Modus ist, die Token Prüfung ausschließlich clientseitig zu implementieren. Ein Preview Status, der nur in einer Vue Reactive Variable gespeichert wird, ohne serverseitige Bestätigung, kann von jedem technisch versierten Besucher über die Browser Konsole manuell gesetzt werden, wodurch der gesamte Schutzmechanismus wirkungslos wird. Die Prüfung muss immer serverseitig erfolgen, der Client darf lediglich das Ergebnis dieser Prüfung anzeigen.

Ein zweiter Fallstrick ist das Vergessen von noindex Headern für Preview Routen, wodurch ein versehentlich geteilter oder von einem Bot gefundener Preview Link tatsächlich im Suchmaschinenindex landen kann. Ein dritter Fehler betrifft Static Site Generation Builds: Da Preview Modus serverseitige Logik zur Laufzeit benötigt, funktioniert er nicht in einem rein statischen Build ohne Node.js Laufzeit, weshalb Projekte mit Preview Anforderungen zumindest für die Preview Route eine Server Komponente benötigen, selbst wenn der Rest der Seite statisch generiert wird.

9. Preview Strategien im Vergleich

Es gibt mehrere praktikable Wege, einen Preview Modus für Nuxt Content umzusetzen, die sich in Aufwand, Sicherheit und Abhängigkeiten unterscheiden.

Für die meisten Projekte mit Git basiertem Workflow und mehreren Reviewern ist ein eigener Token basierter Preview Modus die praktikabelste Lösung, weil er ohne zusätzlichen externen Dienst auskommt und sich vollständig an die eigenen Sicherheitsanforderungen anpassen lässt. Nuxt Studio lohnt sich vor allem, wenn Redakteure ohne technisches Wissen regelmäßig Inhalte pflegen und eine visuelle Oberfläche einem Git basierten Workflow vorziehen.

10. Zusammenfassung

Ein durchdachter Preview Modus für Nuxt Content löst das Problem, dass Entwürfe entweder verfrüht live gehen oder für Reviewer komplett unzugänglich bleiben. Das draft Feld im Frontmatter bildet die Grundlage, während eine serverseitige Token Prüfung über Nitro Middleware sicherstellt, dass nur berechtigte Personen mit gültigem Link Zugriff auf unveröffentlichte Inhalte bekommen.

noindex Header für Preview Routen und eine zeitlich begrenzte Token Gültigkeit runden die Absicherung ab. Für Teams mit Git basiertem Workflow ist ein selbst gebauter Preview Modus meist die passendere Lösung als eine externe Editor Oberfläche, weil er sich nahtlos in bestehende Pull Request Reviews einfügt und ohne zusätzliche Dienstabhängigkeit auskommt.

11. FAQ: Nuxt Content Preview Modus