Prebuild-Workflow mit Hugo für dynamische Headless CMS Inhalte

Wenn du mit Hugo als Static Site Generator (SSG) arbeitest, stehst du häufig vor dem Problem: manche Inhalte sind dynamisch, etwa aus einem Headless CMS wie Strapi. Du willst aber trotzdem von den Performance-Vorteilen statischer Seiten profitieren.

Eine elegante Lösung: Man verwendet eine zweite, kleine Hugo-Instanz als Prebuild-Schritt, um aus den dynamischen Daten automatisiert Markdown- oder Content-Dateien zu erzeugen — die Hauptseite verarbeitet diese wie „normale“ Hugo-Inhalte. So kannst du das Beste aus statischem und dynamischem Modell kombinieren.

Warum überhaupt ein Prebuild mit zweiter Hugo-Instanz?

Performance & SEO
Statisch generierte Seiten sind schnell, zuverlässig und gut für SEO (z. B. schnelle Ladezeiten, kleinere Serverlast). Durch den Prebuild vermeidest du (oder minimierst du) Laufzeit-Abfragen an CMS oder APIs bei Page-Requests.
Konsistenter Umgang mit Inhalten
Dein Haupt-Hugo kennt nur „Markdown & Frontmatter“. Du musst deine Hugo-Templates nicht mit komplizierten API-Logiken durchsetzen — der Prebuild übersetzt die API-Daten in das Format, das Hugo erwartet.
Trennung von Verantwortung
Der Prebuild-Prozess kann unabhängig laufen (z. B. in CI/CD, Cronjob oder Build-Pipeline). Dein Frontend bleibt schlank und fokussiert.
Flexibilität für dynamisches Content-Modell
Inhalte können im CMS gepflegt werden. Bei Änderung triggerst du den Prebuild (z. B. via Webhook). So bleibt dein Seiteninhalt aktuell, ohne dass du bei jedem Besuch eine API-Abfrage durchführen musst.

Architekturübersicht & Ablauf


CMS (z. B. Strapi)
   ↓ (API / Webhook)
Prebuild-Hugo-Instanz  → erzeugt Markdown-Dateien
   ↓
Haupt-Hugo-Instanz  → rendert statische Seiten
   ↓
Deployment (z. B. CDN, Netlify, Vercel)

Schritt-für-Schritt

1. Prebuild-Hugo Projekt einrichten

Erstelle ein separates Hugo-Projekt für den Prebuild
Nur die Logik zur Markdown-Generierung wird benötigt
Go Template im Layout: /layouts/index.html

2. JSON vom CMS abrufen

Beispiel: JSON aus Strapi als Datei `data/posts.json` speichern.

3. Hugo-Template zur Markdown-Erzeugung


{{ with resources.GetRemote "" }}
  {{ $items := unmarshal .Content }}
  {{ range $items }}
    {{ $string := "+++\n" }}
    {{ $string = printf "%s title = \"%s\"\n" $string .title }} 
    {{ $string = printf "%s url = \"/%s\"\n" $string .slug }} 
    {{ $string = printf "%s type = \"%s\"\n" $string .type }}
    {{ $string = printf "%s date = \"%s\"\n" $string .date }}
    {{ $string = printf "%s%s" $string "+++\n" }}
    {{ $string = printf "%s %s\n" $string .content.rendered }}
    {{ $filename := printf "posts/%s.md" (urlize .id) }} 
    {{ $resource := resources.FromString $filename $string }} 
    {{ $file := $resource.RelPermalink }} 
  {{ end }}
{{ end }}

Erklärung:

`resources.GetRemote` liest die Daten aus dem CMS aus
Schleife `range` erzeugt für jeden Post Markdown mit Frontmatter
Hugo schreibt diese Inhalte beim Build in das `public/`-Verzeichnis

4. Haupt-Hugo-Projekt nutzen

Die generierten Markdown-Dateien werden ins Content-Verzeichnis der Haupt-Hugo-Instanz kopiert:


prebuild/public/posts/*.md → main-site/content/posts/

Danach normal `hugo --gc --minify` ausführen.

SEO & Performance Tipps

Canonical-URLs und Slugs korrekt setzen
Meta-Titel, Description und OG-Tags im Frontmatter pflegen
Bilder lokal speichern und mit Hugo Image Pipes optimieren
Sitemap und robots.txt aktualisieren
Fehlerbehandlung, falls JSON nicht verfügbar ist

Fazit

Mit Hugo + Go als Prebuild-Instanz lassen sich dynamische Inhalte automatisch in Markdown umwandeln. So profitierst du von maximaler Performance, SEO-Freundlichkeit und einem einfachen, Go-basierten Workflow.

Wanna team up?