Sprachen

Storyblok und SEO

Storyblok ist ein visuelles Headless-CMS – es speichert Inhalte, rendert aber nie Ihre Seiten, daher liegt SEO im Frontend. Rendering, Meta-Felder, Preview-noindex, Sitemaps, Bilder.

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

Storyblok ist ein visuelles Headless-CMS: Es speichert blockbasierte Inhalte und liefert sie über REST/GraphQL aus, rendert aber nie Ihre Seiten – Ihr Frontend-Framework übernimmt das, daher sind SEO-Ergebnisse fast vollständig eine Frontend-Entscheidung. SSG und SSR sind sicher; CSR riskiert leeres HTML und verzögerte Indexierung. Die integrierte SEO-Felder-App und die KI-SEO-App fügen nur Felder hinzu; das Frontend muss Meta-Tags, Kanonische URLs, Sitemaps, robots.txt und JSON-LD selbst rendern. Die plattformspezifische Falle ist der Vorschaumodus – blockieren Sie Entwurfs-/Vorschau-Umgebungen mit serverseitig gerenderten noindex-Headern, niemals mit JavaScript. Nutzen Sie den /m/-Bilddienst für WebP und Core Web Vitals und verlassen Sie sich auf Storybloks strukturierte Inhalte für die KI-Suche.

TL;DR — Storyblok ist ein visuelles, API-first Headless-CMS: Es speichert blockbasierten Inhalt und liefert ihn über REST/GraphQL aus, rendert Ihre Seiten jedoch nie — das übernimmt das Frontend-Framework, daher ist SEO eine Frontend-Entscheidung. SSG und SSR liefern vollständig gerendertes HTML und sind sicher; CSR birgt das Risiko von leerem HTML und Verzögerungen durch die Render-Warteschlange. Die integrierte SEO Fields App (seo-metatags) und die AI SEO App (sb_ai_seo) liefern nur Feldwerte — das Frontend muss Meta-Tags, Canonicals, Sitemaps, robots.txt und JSON-LD selbst rendern. Die plattformspezifische Falle ist der Vorschaumodus: Blockieren Sie Draft-/Vorschau-Umgebungen mit serverseitig gerendertem X-Robots-Tag: noindex, niemals mit JavaScript, da Google die JS-Ausführung überspringen kann, wenn es ein noindex sieht. Nutzen Sie den /m/-Bilddienst für WebP + Core Web Vitals, generieren Sie die Sitemap über die Content Delivery API und setzen Sie auf das strukturierte Inhaltsmodell für die KI-Suche.

Evidence for this claim The article's described storyblok-seo capabilities must be evaluated against the platform's current documentation rather than assumed to be search-engine behavior. Scope: Platform-specific capability documentation. Confidence: high · Verified: Storyblok documentation Evidence for this claim Regardless of platform, Google needs crawlable URLs, accessible rendered content, descriptive metadata, and valid search directives. Scope: Google requirements independent of platform. Confidence: high · Verified: Google Search Central: SEO Starter Guide

Die grundlegende Trennung: Storyblok speichert, das Frontend rendert

Storyblok ist ein Backend. Es bietet ein aus wiederverwendbaren Blöcken aufgebautes Inhaltsmodell, einen visuellen Editor und eine Content Delivery API (REST und GraphQL). Was es nicht tut, ist das Erzeugen des HTML, das Suchmaschinen crawlen. Diese Aufgabe übernimmt ein separates Frontend — Next.js, Nuxt, Astro, SvelteKit — das Storyblok-Inhalte abruft und Seiten rendert.

Storyblok sagt dies deutlich: “Since Google doesn’t load content directly from Storyblok, your team is responsible for a fast and performant website.” (Übersetzung) „Da Google Inhalte nicht direkt von Storyblok lädt, ist Ihr Team für eine schnelle und leistungsfähige Website verantwortlich.“ Derselbe Punkt taucht in ihrer Anleitung zu strukturierten Inhalten auf — “AI doesn’t see your CMS directly. Search engines and generative models read what’s rendered on your website or app, not the JSON coming from Storyblok’s APIs.” (Übersetzung) „KI sieht Ihr CMS nicht direkt. Suchmaschinen und generative Modelle lesen, was auf Ihrer Website oder App gerendert wird, nicht das JSON, das von den Storyblok-APIs kommt.“ Verinnerlichen Sie das, und fast jede Storyblok-SEO-Frage beantwortet sich von selbst: Das CMS ist nahezu SEO-neutral, und die Rendering-Entscheidungen des Frontends bestimmen alles. Dies ist dieselbe Architektur-Realität, die ich in SEO for a Headless CMS behandle; Storyblok ist eine spezifische Variante davon mit visuellem Editor.

Rendering-Strategie: die wichtigste SEO-Entscheidung

Wie Ihr Frontend Storyblok-Inhalte rendert, ist der größte SEO-Hebel. Vier Modi, die alle Inhalte von derselben Storyblok-CDN/GraphQL-API abrufen:

SSG — Static Site Generation. HTML wird zur Bereitstellungszeit erstellt und als statische Dateien ausgeliefert. Best-Case-SEO: vollständiges HTML bei der ersten Anfrage, sehr schnell. Der Haken ist die Aktualität — neue oder bearbeitete Inhalte benötigen einen Neubuild. Verdrahten Sie daher Storybloks Publish-Webhook, um einen auszulösen. Am besten für überwiegend statische Inhalte. Astro und Gatsby sind SSG-first; Next.js und Nuxt unterstützen es pro Route.

SSR — Server-Side Rendering. HTML wird pro Anfrage auf einem Server oder in einer Edge-Funktion gerendert. Immer aktuelle, vollständig gerenderte HTML-Dateien. Am besten für häufig wechselnde Inhalte; der Kompromiss sind Infrastrukturkosten und ein etwas höherer TTFB.

ISR — Incremental Static Regeneration. Standardmäßig statisch, wird nach Zeitplan oder bei Bedarf neu generiert. Der empfohlene Mittelweg für große Storyblok-Sites mit gemischten Inhaltstypen — beachten Sie jedoch die Falle „veraltet bei der ersten Anfrage nach der Neugenerierung“, die ich im Headless-CMS-Artikel detailliert beschreibe.

CSR — Client-Side Rendering (SPA). Der Server sendet eine fast leere Hülle und der Browser erstellt das DOM. Googlebot muss die Seite für eine spätere Render-Welle in die Warteschlange stellen (die “may stay on this queue for a few seconds, but it can take longer than that” (Übersetzung) „kann einige Sekunden in dieser Warteschlange bleiben, aber es kann auch länger dauern“). Das Rendering durch KI-Crawler variiert je nach Anbieter, daher sehen reine HTML-Fetcher nur die Hülle. Liefern Sie Inhaltsseiten niemals nur per CSR aus. Googles eigene Aussage: “If the content isn’t visible in the rendered HTML, Google won’t be able to index it.” (Übersetzung) „Wenn der Inhalt nicht im gerenderten HTML sichtbar ist, kann Google ihn nicht indexieren.“

Die Entscheidungsregel: überwiegend statische Inhalte → SSG; immer aktuelle/volatile Inhalte → SSR; große gemischte Sites → ISR; CSR nur für angemeldete, nicht indexierte Oberflächen.

Integrierte Storyblok-SEO-Funktionen (und ihre Grenzen)

Storyblok bietet drei Möglichkeiten, SEO-Feldwerte zu verwalten. Alle drei erfassen nur Werte – das Frontend muss sie weiterhin rendern.

SEO-Felder-App (seo-metatags). Ein natives Plugin-Feld, das Editoren Eingaben für Titel, Beschreibung, OG-Titel, OG-Beschreibung und OG-Bild bietet, plus eine Google-SERP-Vorschau im Editor. Erfordert einen Growth-Plan und muss pro Inhaltstyp hinzugefügt werden – leicht zu vergessen bei einem neuen Inhaltstyp.

KI-SEO-App (sb_ai_seo). Generiert Meta-Titel, Beschreibung, Keywords und Autor mit einem LLM in 22 unterstützten Sprachen. Erfordert Premium. Sie können bulk-generieren über alle Stories mit einer Management-API + Node.js-Skript.

Manuelle Feldmodellierung. Keine Plananforderung: Fügen Sie Ihre eigenen seo_title, seo_description, og_title, og_image, noindex (boolesch) und canonical_url Felder zu Ihrem Content-Modell hinzu. Am flexibelsten und das, was ich bei komplexen Websites verwenden würde.

Das Nonplusultra: Keine Storyblok-App rendert automatisch ein einziges Tag. Eine globale Kopf-/ Layout-Komponente in Ihrem Framework muss die SEO-Feldwerte aus der API-Antwort lesen und serverseitig ausgeben, mit sinnvollen Fallback-Ketten (seo_title || story.name).

Kanonische Tags

Storyblok hat keine Kenntnis Ihrer Frontend-URL-Struktur, daher können Canonicals nicht vom CMS kommen. Berechnen Sie diese im Frontend – typischerweise aus dem full_slug der Story plus Ihrer Domain – und rendern Sie diese serverseitig. Immer absolute URLs, nie relative, auf jeder Seitenvorlage. (Für die Mechanik siehe Canonicalisierung.)

Vorschaumodus und Entwurfsinhalte: das prägende Storyblok-Risiko

Das ist die plattformspezifische Falle, die Sie richtig hinbekommen müssen. Der Visual Editor lädt Ihre Seiten in einem iframe mit Vorschau-URLs, die _storyblok- und _storyblok_tk-Parameter enthalten, und die Vorschauumgebung verwendet Entwurfsinhalte mit einem Vorschau- Zugriffstoken. Die Produktion muss veröffentlichte Inhalte mit dem öffentlichen Zugriffstoken verwenden. Das saubere Muster sind zwei separate Storyblok-Spaces/Projekte (Vorschau und Produktion), damit das falsche Token keine Entwurfsinhalte in den Live-Index leaken kann.

Der kritische Teil ist, wie Sie Vorschau/Staging aus dem Index heraushalten. Google warnt: “When Google encounters the noindex tag, it may skip rendering and JavaScript execution, which means using JavaScript to change or remove the robots meta tag from noindex may not work as expected.” (Übersetzung) „Wenn Google auf das noindex-Tag stößt, kann es das Rendering und die JavaScript-Ausführung überspringen, was bedeutet, dass die Verwendung von JavaScript zum Ändern oder Entfernen des Robots-meta-Tags von noindex möglicherweise nicht wie erwartet funktioniert.“ Mit anderen Worten: Ein noindex, das clientseitig per JS injiziert wird, ist unzuverlässig – Google führt das JS möglicherweise nie aus. Schützen Sie also Nicht-Produktionsumgebungen mit einem serverseitig gerenderten Antwort-Header – X-Robots-Tag: noindex auf CDN-/Hosting-Ebene – und fügen Sie Disallow: / in der robots.txt dieser Umgebung hinzu. Beobachten Sie die Search Console auf unerwartete Vorschau-Domains; das ist Ihre frühe Warnung.

Sitemaps und robots.txt

Storyblok generiert keines von beiden. Beide werden im Frontend erstellt:

  • Sitemap: Alle veröffentlichten Stories von der Content Delivery API abrufen und XML ausgeben. Astro: @astrojs/sitemap plus dynamische Routen von der Links API. Next.js: app/sitemap.ts oder next-sitemap nach dem Build. Mit starts_with eingrenzen, für große Websites paginieren und einen Rebuild über den Storyblok-Publish-Webhook auslösen, damit die Sitemap synchron bleibt.
  • robots.txt: ebenfalls frontend-generiert. Die Produktion sollte das Crawlen von öffentlichen Seiten erlauben; Vorschau/Staging sollte Disallow: / (und den X-Robots-Tag- Header von oben) tragen.

Strukturierte Daten / JSON-LD

Storyblok speichert Inhalte als strukturiertes JSON, aber schema.org-JSON-LD muss im Frontend generiert werden – Googlebot liest das gerenderte HTML, nicht die API- Antwort. Bauen Sie eine JsonLd-Komponente, die Inhaltsfelder und Story-Eigenschaften (story.published_at, story.updated_at, story.name) in ein serverseitig gerendertes <script type="application/ld+json"> abbildet. Article, BreadcrumbList, Organization, Product und FAQPage sind alle auf diese Weise implementierbar.

Bilder und Core Web Vitals

Storyblok-Assets werden über Amazon CloudFront ausgeliefert. Der Bilddienst ist ein echter CWV-Gewinn, aber nur bei korrekter Verwendung:

  • WebP + Transformationen werden aktiviert, wenn Sie /m/ an die Bild-URL anhängen – z. B. https://a.storyblok.com/f/xxxxx/image.jpg/m/800x600. Größenänderung, Zuschnitt, Qualität und Smart-Crop sind allesamt URL-Parameter; Ergebnisse werden nach der ersten Anfrage am Edge-Cache gespeichert. Ohne das /m/ erhalten Sie das unoptimierte Original.
  • Setzen Sie width und height für jedes Bild, um Layout-Shift (CLS) zu vermeiden.
  • fetchpriority="high" + loading="eager" für das LCP-Hero-Bild; loading="lazy" unterhalb des Falzes.
  • Fügen Sie alt-Text als explizites Feld in jeder Bildkomponente hinzu – das filename-Feld ist kein Alt-Text. (Siehe Alt-Text.)

Weiterleitungen, i18n und hreflang

Weiterleitungen. Storyblok hat keinen Redirect-Manager, und das Ändern eines Slugs erzeugt keine 301. Muster: eine redirects_config-Story mit verschachtelbaren redirect_entry-Blöcken (source_url, target_story), die zur Build-/Anfragezeit abgerufen und in das Framework-Routing injiziert werden; verwenden Sie resolve_relations, damit Ziele aktualisiert werden, wenn sich Slugs ändern, und aktualisieren Sie über den Publish-Webhook.

Internationalisierung. Storyblok unterstützt Übersetzungen auf Feld-, Ordner- und Space-Ebene, und API-Antworten enthalten ein alternates-Array aller übersetzten Versionen. Verwenden Sie es, um <link rel="alternate" hreflang="...">-Tags serverseitig zu rendern, und binden Sie immer x-default ein. (Siehe hreflang.)

GEO / KI-Suchbereitschaft

Storybloks strukturiertes, komponentenbasiertes Modell ist wirklich gut für KI-Konsum geeignet – “Storyblok was built around structured data from day one, thanks to its headless, API-first design.” (Übersetzung) „Storyblok wurde von Anfang an um strukturierte Daten herum aufgebaut, dank seines headless, API-first Designs.” Aber die Rendering-Regel gilt weiterhin: LLMs lesen gerendertes HTML, also sind SSR/SSG, korrektes JSON-LD und sauberes semantisches Markup die Eintrittskarte. Sie können auch llms.txt (einen Markdown-Index der wichtigsten Seiten) und llms-full.txt (ein vollständiges Inhaltsarchiv) im Frontend generieren. (Siehe KI-Suche und llms.txt.)

Das Fazit

Storyblok ist weder gut noch schlecht für SEO – es ist neutral und verlagert die gesamte SEO-Last auf das Frontend. Sorgen Sie für korrektes Rendering (SSR/SSG), rendern Sie die Meta-Felder, welche die SEO-Apps erfassen, schützen Sie die Vorschau mit serverseitigem noindex, erstellen Sie die Sitemap und robots.txt selbst und nutzen Sie den /m/-Bilddienst. Wenn Sie das tun, kann eine Storyblok-Site ein vernachlässigtes traditionelles CMS übertreffen. Wenn Sie es überspringen, ist die standardmäßig fehlende SEO-Ebene genau der Punkt, an dem die Site leise auseinanderfällt. Weiterführende Lektüre finden Sie unter Headless-CMS-SEO und JavaScript-SEO.

Add an expert note

Pin an expert quote

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