Strapi und SEO

TL;DR — Strapi ist ein „Headless“-CMS – es speichert Ihre Inhalte und gibt sie über eine API aus, hat aber keine Website daran angeschlossen. Das bedeutet, dass Strapi selbst nicht über Ihre SEO entscheidet; das Frontend, das Strapis Inhalte in Seiten verwandelt, tut das. Die große Regel ist dieselbe wie bei jedem Headless-Setup: Bauen Sie Ihr HTML auf einem Server oder zur Build-Zeit (SSR oder SSG), nicht vollständig im Browser des Besuchers. Und all das SEO- Zeug, das WordPress + Yoast für Sie erledigt hat – Titel, Sitemaps, robots.txt – richten Sie jetzt selbst ein.

Was Strapi tatsächlich ist

Strapi ist ein Open-Source-, Node.js-basiertes Headless-CMS. „Headless“ bedeutet, dass es nur die hintere Hälfte einer Website ist – der Ort, an dem Sie Inhalte schreiben und speichern – ohne vordere Hälfte (kein Theme, keine Seiten, kein Rendering). Sie erhalten Ihre Inhalte über eine REST- oder GraphQL-API. Sie können Strapi auf Ihrem eigenen Server ausführen oder Strapi Cloud nutzen, um es von ihnen hosten zu lassen.

Da es keine eingebaute Website gibt, arbeitet Strapi mit einem separaten Frontend- Framework zusammen – Next.js, Nuxt, Astro oder Gatsby sind die gängigen –, das Inhalte von Strapi abruft und die tatsächlichen Seiten erstellt, die Menschen (und Googlebot) sehen.

Das eine, was Sie verstehen müssen

Strapi ist neutral für SEO. Es ist weder gut noch schlecht für sich allein. Was zählt, ist, wie das Frontend die Seite aufbaut. Es gibt zwei sichere Wege und einen riskanten:

• Zur Build-Zeit (SSG) – Seiten werden in einfache HTML-Dateien vorgebaut. Schnell und suchfreundlich.
• Auf einem Server, pro Anfrage (SSR) – der Server baut die vollständige Seite und sendet sie. Ebenfalls suchfreundlich.
• Im Browser des Besuchers (CSR) – der Server sendet eine fast leere Hülle und JavaScript füllt sie später aus. Das ist der riskante Weg.

Google kann browser-gerenderte Seiten irgendwann lesen, aber es ist langsamer und weniger zuverlässig. Das Rendering-Verhalten von KI-Crawlern variiert je nach Anbieter – es gibt keinen einheitlichen Standard –, aber ein Crawler, der nur das anfängliche HTML abruft (mehrere der Bots hinter ChatGPT und Perplexity arbeiten derzeit so), sieht genau das, was CSR liefert: eine leere Hülle. Bauen Sie Ihr HTML auf dem Server oder zur Build-Zeit, damit der Inhalt im rohen HTML ist, egal wer es abruft.

Das Problem „Wo sind meine SEO-Einstellungen hin?“

Beim Wechsel von WordPress + Yoast zu Strapi sind die Leute schockiert, dass Titel, Meta- Beschreibungen, Sitemaps und Canonical-Tags nicht von selbst erscheinen. Es gibt keine Plugin-Ebene, die das still im Hintergrund erledigt. Mit Strapi müssen Sie:

• SEO-Felder (Titel, Beschreibung, Canonical, Social-Image) zu Ihren Inhaltstypen hinzufügen – es gibt ein offizielles-ish Community-SEO-Plugin, das diese für Sie hinzufügt.
• Diese Felder in das HTML der Seite im Frontend einbinden.
• Eine Sitemap und eine robots.txt erstellen.

Nichts davon ist schwierig; es passiert nur nicht von selbst.

Ein paar Dinge, die still kaputtgehen

• Entwürfe werden indexiert. Strapi hat einen Entwurf/Veröffentlichungs-Workflow. Halten Sie unveröffentlichte Inhalte aus der Suche heraus – setzen Sie sie nicht über die öffentliche API aus.
• Vorschauseiten werden indexiert. Teams erstellen Vorschau-/Staging-URLs, um Entwürfe zu überprüfen. Wenn Google eine findet, kann es eine ganze doppelte Kopie indexieren. Blockieren Sie sie.
• Das Admin-Panel und die rohe API. Ihr /admin-Login und der /api/...-JSON-Feed sollten nicht in der Suche auftauchen.

Möchten Sie die vollständige Version – die vier Rendering-Modi, das SEO-Plugin, Sitemaps, Entwurfs- und Vorschau-Hygiene, Strapi Cloud vs. selbst gehostet und Migrationen? Wechseln Sie zum Erweitert-Tab.

TL;DR — Strapi ist ein reines Backend-Headless-CMS (REST + GraphQL, selbst gehostet oder Strapi Cloud) ohne Rendering-Ebene, daher ist es SEO-neutral – die Rendering-Art des Frontends entscheidet alles. SSG/SSR liefern vollständig gerendertes HTML und sind sicher; CSR ist riskant (ein Crawler, der nur das anfängliche HTML abruft, sieht eine leere Hülle – so verhalten sich derzeit mehrere große KI-Crawler); ISR hat die Falle mit veraltetem Inhalt bei der ersten Anfrage. Modellieren Sie SEO-Felder in Ihren Inhaltstypen (das Community-Plugin @strapi/plugin-seo speichert und zeigt sie in der Vorschau, gibt aber kein HTML, keine Sitemaps und keine robots.txt aus – das ist die Aufgabe des Frontends). Halten Sie Entwürfe über den Veröffentlichungs-Workflow fern (übergeben Sie niemals Auth-Tokens in öffentlichen Anfragen), setzen Sie noindex für Vorschau/Staging auf Host-Ebene, halten Sie /admin und rohes /api/*-JSON aus der Suche heraus und erstellen Sie sitemap.xml + robots.txt im Frontend. Strapi ist neutral; Ihre Architektur ist das Produkt.

Strapi ist nicht die SEO-Entscheidung – das Frontend ist es

Das wichtigste Konzept bei Strapi-SEO: Strapi hat keine Rendering-Ebene. Es ist eine Inhaltspeicherung, ein Inhaltsmodell, eine Bearbeitungsoberfläche und eine API. Jedes SEO- Ergebnis – Indexierbarkeit, Metadaten, Geschwindigkeit, strukturierte Daten – wird durch das Frontend-Framework bestimmt, das die Strapi-API nutzt. Strapis Aufgabe ist es ausschließlich, die richtigen Felder zu speichern und bereitzustellen.

Das macht „Strapi ist schlecht für SEO“ zum falschen Rahmen. Strapi ist neutral. Wie Strapis eigenes Team es ausdrückt: “headless architectures require developers to take ownership of SEO aspects that traditional content management systems handle automatically.” (Übersetzung) „Headless-Architekturen erfordern, dass Entwickler die Verantwortung für SEO-Aspekte übernehmen, die traditionelle Content-Management-Systeme automatisch handhaben.“ Eine Strapi- + Next.js-Site, die mit SSG rendert und eine disziplinierte Metadaten-Ebene hat, wird besser abschneiden als eine vernachlässigte WordPress-Installation. Eine Strapi-Site mit einem client-gerenderten React-SPA ohne Metadaten-Anbindung wird stillschweigend auseinanderfallen. Gleiches Backend, gegenteilige Ergebnisse – weil die Rendering-Entscheidungen unterschiedlich sind. Dies ist derselbe Punkt, den ich zu JavaScript-SEO allgemein mache: Die Frage, mit der man beginnen sollte, ist immer wie rendert das Frontend diesen Inhalt?

Die vier Rendering-Modi (die kritischste Entscheidung)

• SSG – Static Site Generation. HTML wird zur Build-Zeit erstellt und als statische Dateien ausgeliefert. Best-Case-SEO: vollständig gerendertes HTML beim ersten Abruf, schnelle TTFB und Core Web Vitals. Kompromiss: Neue/geänderte Inhalte benötigen einen Rebuild. Gatsby und Astro sind SSG-first; Next.js macht es pro Route.
• SSR – Server-Side Rendering. HTML wird pro Anfrage auf einem Server oder Edge gerendert. Immer aktuelle, vollständig gerenderte HTML. Kompromiss: Die Strapi-API-Latenz fließt direkt in Ihre TTFB bei jeder Anfrage ein. Next.js, Nuxt, SvelteKit, Remix.
• ISR – Incremental Static Regeneration. Statische Seiten werden im Hintergrund nach einem Revalidierungsfenster neu generiert. Ein guter Mittelweg mit einer Falle (unten).
• CSR – Client-Side Rendering. Eine fast leere Hülle wird ausgeliefert und der Browser ruft von Strapi ab und baut das DOM auf. Schlechteste SEO-Option: Google muss die Seite für eine spätere Rendering-Welle in die Warteschlange stellen – “Googlebot queues all pages with a 200 HTTP status code for rendering, unless a robots meta tag or header tells Google not to index the page” (Übersetzung) „Googlebot stellt alle Seiten mit einem HTTP-Statuscode 200 für das Rendering in die Warteschlange, es sei denn, ein Robots-Meta-Tag oder -Header teilt Google mit, die Seite nicht zu indexieren“ – Ihr Inhalt existiert also nicht, bis diese Welle läuft. KI-Crawler und Bing gehen damit weitaus schlechter um als Google. Nur akzeptabel für eingeloggte Dashboards, die Sie ohnehin nicht indexiert haben möchten. Ein rohes React/Vue-SPA über Strapi landet hier standardmäßig – vermeiden Sie es für öffentliche Inhalte.

Die ISR-Falle: Wenn das Revalidierungsfenster abläuft, erhält die nächste Anfrage – die von Googlebot sein könnte – immer noch die veraltete gecachte Seite; die frische wird nur bei der darauffolgenden Anfrage ausgeliefert. Für volatile Daten (Preise, Bestände) bevorzugen Sie SSR. ISR ist ideal für Inhalte, die sich im Bereich von Stunden oder Tagen ändern.

Inhaltsmodellierung für SEO in Strapi

Strapi gibt dem Frontend nichts zum Rendern, es sei denn, Sie fügen die Felder in das Inhaltsmodell ein. Fügen Sie für jeden öffentlichen Inhaltstyp eine SEO-Komponente mit mindestens Folgendem hinzu:

• metaTitle, metaDescription
• canonicalURL
• ogImage (und Open-Graph-/Twitter-Felder)
• eine Robots-Direktive – z. B. ein preventIndexing-Boolean für die Noindex-Steuerung pro Eintrag

Verwenden Sie Strapis UID-Feld für Slugs – es wird automatisch aus dem Titel generiert und erzwingt Eindeutigkeit. Für mehrsprachige Websites aktivieren Sie Strapis integriertes i18n pro Inhaltstyp, lokalisieren Sie Slug und SEO-Felder pro Locale und geben Sie dann im Frontend <link rel="alternate" hreflang="..."> aus, indem Sie die localizations-Beziehung nutzen, die jeder Eintrag bereitstellt. Wie SALT.agency anmerkt, kann der Titel “can either be populated with the Strapi SEO Plugin or by creating a text field where the title tag will be stored, with conditions added such as not being shorter than or not exceeding a set amount of characters.” (Übersetzung) „Er kann entweder mit dem Strapi-SEO-Plugin befüllt werden oder durch die Erstellung eines Textfelds, in dem der Title-Tag gespeichert wird, mit Bedingungen wie einer Mindest- oder Höchstlänge.“

Das Frontend liest diese Felder dann aus der API und füllt den <head> – Next.js generateMetadata, Nuxt useSeoMeta, Astros Layout-<head>. Die Zuverlässigkeitsregel ist dieselbe wie bei allen Headless-SEO: HTML-Ebene-Metadaten schlagen JS-injizierte Metadaten, weil Google sie beim ersten Abruf sieht.

Das Strapi-SEO-Plugin – was es tut und was nicht

Das Community-SEO-Plugin (@strapi/plugin-seo, früher @strapi-community/plugin-seo, im Strapi-Market gelistet) ist das Standardwerkzeug. Es “embeds a side panel in every Content-Type edit view where you can set meta titles, descriptions, canonical URLs, and social share images,” fügt eine SERP-Vorschau hinzu und führt eine In-Content-Analyse durch – grüne, orange oder rote Indikatoren für Lesbarkeit, Keyword-Verteilung und Schema-Konformität. (Übersetzung) „Es bettet ein Seitenpanel in jede Bearbeitungsansicht eines Inhaltstyps ein, in dem Sie Meta-Titel, Beschreibungen, kanonische URLs und Social-Sharing-Bilder festlegen können.“

Was es nicht tut, und das ist das häufigste Missverständnis:

• Es generiert nicht das <head>-HTML – das Frontend rendert die Felder.
• Es generiert keine Sitemap – das ist ein separates Plugin (bei Strapi 5 das Webtools-Sitemap-Add-on oder strapi-5-sitemap-plugin).
• Es schreibt kein robots.txt und implementiert keine strukturierten Daten – das ist Aufgabe des Frontends.

Mit anderen Worten: Das Plugin bietet Redakteuren eine gute Authoring-UX und speichert saubere Felder. Das Frontend muss die eigentliche SEO-Ausgabe übernehmen.

Entwürfe, Vorschau, /admin und /api – die falschen Dinge aus dem Index heraushalten

Hier hat Strapi mehr Fehlermodi als eine gehostete Plattform wie Shopify.

• Entwurf/Veröffentlichung. Strapi markiert Entwürfe mit publishedAt: null; die API gibt nur veröffentlichte Einträge an nicht authentifizierte Anfragen zurück. Die kritische Disziplin: Übergeben Sie niemals ein authentifiziertes API-Token in öffentlichen Frontend-Anfragen, sonst werden alle Entwurfsinhalte abrufbar. Das Sitemap-Plugin/Add-on respektiert den Veröffentlichungsstatus und nimmt nur veröffentlichte URLs auf.
• Vorschau-/Staging-Umgebungen. Vercel-Branch-Deploys, Netlify-Deploy-Previews und dedizierte Vorschau-Hosts, die Strapi-Entwürfe konsumieren, sind in der Regel öffentlich erreichbar. Blockieren Sie sie mit einem mehrschichtigen Ansatz: ein X-Robots-Tag: noindex-Header auf Host-Ebene (nicht nur ein Meta-Tag, das eine CSR-Seite spät injiziert), Disallow: / in robots.txt, ein noindex-Meta-Tag auf jeder Seite und HTTP-Authentifizierung, wo möglich. Beobachten Sie die Search Console auf unerwartete Hostnamen – das ist Ihre Frühwarnung.
• Das /admin-Panel. Strapis Admin ist eine React-SPA; stellen Sie sicher, dass es <meta name="robots" content="noindex"> trägt (Strapi v4+ tut das), halten Sie es von öffentlichen Links fern und schützen Sie es mit einem Passwort – ein ungeschütztes /admin ist per Google-Dorking auffindbar.
• Das rohe /api/*-JSON. Es wird nicht als Seite ranken, aber es verschwendet Crawl-Budget und kann Daten leaken. Die meisten Produktions-Setups platzieren die API auf einer eigenen Subdomain (cms.example.com / api.example.com); blockieren Sie diese Subdomain vollständig in robots.txt und halten Sie sie von der Sitemap fern. Wenn API und Frontend dieselbe Domain teilen, Disallow: /api/.

Sitemaps und robots.txt – im Frontend erstellt

Es gibt kein Yoast, also sind beide explizit. Zwei Sitemap-Routen:

1. Ein Sitemap-Plugin in Strapi – generiert XML und enthält nur veröffentlichte Einträge. Auf Strapi 5 ist die gepflegte Option das Webtools-Sitemap-Add-on (strapi-plugin-webtools + webtools-addon-sitemap) für größere, mehrsprachige Websites oder strapi-5-sitemap-plugin für einfachere. Das ältere eigenständige strapi-plugin-sitemap (pluginpal) endet bei Strapi 4 – seine eigene Dokumentation verweist v5-Nutzer stattdessen an Webtools, also installieren Sie es nicht in einem v5-Projekt. Zitat aus der Plugin-Dokumentation: Wenn Entwurf/Veröffentlichung aktiviert ist, “this setting will make sure that all draft pages are excluded from the sitemap.” (Übersetzung) „Diese Einstellung stellt sicher, dass alle Entwurfsseiten von der Sitemap ausgeschlossen werden.“
2. Frontend-generiert – Next.js sitemap.ts, Astro @astrojs/sitemap, Nuxt- Sitemap-Module, die veröffentlichte URLs von der Strapi-API abrufen. Mehr Kontrolle über kanonische URLs, lastmod und changefreq.

robots.txt wird vom Frontend ausgeliefert (Next.js robots.ts, Astro public/robots.txt). Fügen Sie eine Sitemap:-Direktive hinzu, blockieren Sie Vorschau-Hosts mit Disallow: / und – wie bei jedem Headless-Stack – blockieren Sie niemals .js oder .css (das blockiert das Rendering).

Das wertvolle Muster ist der Webhook-Workflow: Strapi feuert einen Webhook beim Veröffentlichen → löst einen Vercel/Netlify-Rebuild oder eine On-Demand-Revalidierung aus → generiert die Sitemap neu → pingt Google Search Console und IndexNow. Da Headless-Content-Updates über eine API statt über ein Plugin fließen, das Suchmaschinen pingt, ist IndexNow (Bing, Yandex und andere) besonders wertvoll, wenn es an diesen Veröffentlichungs-Webhook angeschlossen ist.

Strapi Cloud vs. Self-Hosting – die SEO-Auswirkungen

Das Hosting von Strapi beeinflusst die API-Antwortzeit, die je nach Rendering-Modus unterschiedlich wichtig ist:

• SSG/ISR: Die Geschwindigkeit der Strapi-API ist zur Build-Zeit wichtig, nicht zur Laufzeit – Seiten sind vorgebaut, daher berührt die API-Latenz nicht die TTFB des Nutzers.
• SSR: Die Strapi-API-Latenz addiert sich direkt zur TTFB bei jeder Anfrage → beeinflusst LCP → ein echtes Ranking-Eingangssignal. Das ist der Fall, den es zu optimieren gilt.

Strapi Cloud ist verwaltete Infrastruktur mit einem Asset-CDN – gut für Teams ohne DevOps. Self-Hosting gibt Ihnen volle Kontrolle über Caching (Redis), Datenbank-Indizierung und geografische Nähe zum Frontend. In jedem Fall: Cachen Sie Strapi-API-Antworten auf der CDN-Ebene oder verwenden Sie ISR mit kurzer Revalidierung, um die Frontend-Laufzeit von der Strapi-Latenz zu entkoppeln. Ein Hinweis, den man klar aussprechen sollte – das CDN von Strapi Cloud bedient die Strapi-API und Assets, nicht Ihre Frontend-Website; Ihre Core Web Vitals werden gegen das Frontend gemessen, das separat gehostet wird (Vercel, Netlify, Cloudflare Pages).

Migration zu oder von Strapi

WordPress → Strapi ist der häufige Weg, und Migrationen sind der Punkt, an dem Headless-SEO tatsächlich schiefgeht:

• Ordnen Sie jeden bestehenden Slug exakt dem UID-Feld von Strapi zu; jede Slug-Änderung benötigt eine 301-Weiterleitung (verwenden Sie strapi-plugin-redirect-urls oder Smart Redirect Manager, gelesen vom Frontend/Middleware).
• Migrieren Sie Meta-Titel, Beschreibungen und og:image von wp_postmeta in die SEO-Komponentenfelder und Bild-Alt-Texte in das alternativeText-Feld der Medienbibliothek.
• Erfassen Sie jede URL – nicht nur Beiträge: Tag-Seiten, paginierte Archive, Parameter-URLs – und erstellen Sie die Weiterleitungskarte vor dem Go-Live.
• Migrieren Sie Kanonische explizit; gehen Sie nicht davon aus, dass das Frontend sie automatisch korrekt generiert.
• Nach dem Launch: Führen Sie einen Screaming-Frog-Crawl-Vergleich durch, verifizieren Sie strukturierte Daten erneut mit dem Rich Results Test, reichen Sie Sitemaps erneut bei GSC und Bing ein und richten Sie IndexNow ein.

Strapi-SEO ist wirklich eine spezialisierte Anwendung von JavaScript SEO und Rendering – der verwandte Artikel zu Headless-CMS-SEO behandelt die plattformunabhängige Version von all dem.

KI-Zusammenfassung

Eine komprimierte Darstellung der erweiterten Version:

• Strapi ist SEO-neutral. Es ist ein reines Backend-Headless-CMS (REST + GraphQL, selbst gehostet oder Strapi Cloud) ohne Rendering-Ebene – das Frontend entscheidet alles. „Strapi ist schlecht für SEO“ ist ein Mythos.
• Der Rendering-Modus ist das Produkt: SSG/SSR liefern vollständig gerendertes HTML und sind sicher; CSR ist riskant (Inhalte existieren erst nach einer späteren Rendering-Welle, und KI-Crawler/Bing verarbeiten sie schlecht); ISR ist ein guter Mittelweg mit einer Stale-on-First-Request-Falle – verwenden Sie SSR für volatile Daten.
• Modellieren Sie SEO-Felder in Inhaltstypen: metaTitle, metaDescription, canonicalURL, ogImage, ein preventIndexing-Boolean; UID-Feld für Slugs; i18n + localizations für hreflang.
• Das SEO-Plugin speichert und zeigt Felder an, gibt aber kein <head>-HTML, Sitemaps oder robots.txt aus – das ist die Aufgabe des Frontends. Die Sitemap ist ein separates Plugin – auf Strapi 5 ist das das Webtools-Sitemap-Add-on oder strapi-5-sitemap-plugin; das ältere eigenständige strapi-plugin-sitemap ist nur für Strapi 4.
• Halten Sie die falschen Dinge aus dem Index heraus: Entwürfe (Publish-Workflow; geben Sie niemals Auth-Tokens öffentlich weiter), Vorschau/Staging (Host-Level-noindex + robots Disallow: /
  • Auth), /admin (noindex + Passwort) und rohes /api/*-JSON (blockieren, idealerweise auf einer eigenen Subdomain).
• Erstellen Sie sitemap.xml und robots.txt im Frontend; blockieren Sie niemals .js/.css; verdrahten Sie einen Publish-Webhook → Rebuild → Sitemap → GSC + IndexNow.
• Hosting: Bei SSR wirkt sich die Strapi-API-Latenz direkt auf TTFB/LCP aus – cachen Sie sie oder verwenden Sie ISR. Das CDN von Strapi Cloud ist für die API/Assets, nicht für die Core Web Vitals Ihres Frontends.
• Migrationen scheitern an kaputten 301ern, verlorenen Metadaten und versehentlichem CSR – vollständige URL-Inventur
  • Redirect-Map vor dem Go-Live.

Offizielle Dokumentation

Primärquellen-Dokumentation der Suchmaschinen (Strapi ist rendering-agnostisch, daher sind die SEO-relevanten Dokumente die JavaScript-/Rendering-Dokumente).

Google

• JavaScript-SEO-Grundlagen verstehen – die Crawl-→-Render-→-Index-Pipeline, die bestimmt, wie die Inhalte eines Strapi-Frontends indexiert werden.
• Dynamisches Rendering (veralteter Workaround) – warum Google es abgelehnt hat; verwenden Sie SSR, statisches Rendering oder Hydration anstelle von Prerendering eines CSR-Strapi-Frontends.
• Rendering für inhaltsgesteuerte Web-Apps – SSR- vs. SSG- vs. CSR-Kompromisse für Inhaltsseiten wie Strapi-betriebene Redaktionen.
• Suchbezogene JavaScript-Probleme beheben – Diagnose von Lücken im gerenderten DOM in einem JS-Frontend.
• Suchindexierung mit noindex blockieren – das Meta-Tag / der X-Robots-Tag-Header, um Entwürfe, Vorschau-Hosts und /admin aus dem Index herauszuhalten.
• Einführung in robots.txt – was robots.txt tut und nicht tut (relevant zum Blockieren der API-Subdomain und von Vorschau-Hosts).

Bing / Microsoft

• Der neue immergrüne Bingbot (Microsoft Edge) – Bingbot rendert JS, aber weniger konsistent als Google – ein weiterer Grund, warum SSR/SSG bei Strapi wichtig ist.
• IndexNow / indexnow.org – das Push-Protokoll, das Sie mit Ihrem Strapi-Publish-Webhook verbinden können.

Zitate aus der Quelle

Öffentliche Aussagen zum JavaScript-Rendering (Google) sowie vom Strapi-Team und Praktikern zu Headless-SEO. Jeder Link ist ein Deep Link, der zur zitierten Passage springt, wo die Quelle dies unterstützt.

Google — wie JavaScript-Seiten verarbeitet werden

• “Googlebot queues all pages with a 200 HTTP status code for rendering, unless a robots meta tag or header tells Google not to index the page.” — Google Search Central docs. Zum Zitat springen

Google — dynamisches Rendering ist veraltet

• “Dynamic rendering was a workaround and not a long-term solution for problems with JavaScript-generated content in search engines.” — Google Search Central docs. Empfohlen stattdessen: “server-side rendering, static rendering, or hydration.” Zum Zitat springen

Strapi – Headless verlagert die SEO-Verantwortung zu Entwicklern

• “SEO in headless CMS architectures is a more technical challenge that requires careful implementation, as headless architectures require developers to take ownership of SEO aspects that traditional content management systems handle automatically.” — Strapi Blog, Headless CMS & Strapi SEO best practices. Beitrag lesen
• “When using the draft/publish functionality in Strapi, this setting will make sure that all draft pages are excluded from the sitemap. This ensures that only published content appears in search engine sitemaps.” — Strapi Blog, Strapi SEO Plugins: Complete Guide for Strapi 5. Beitrag lesen
• “The official SEO plugin embeds a side panel in every Content-Type edit view where you can set meta titles, descriptions, canonical URLs, and social share images.” — Strapi Blog, Strapi SEO Plugins: Complete Guide for Strapi 5. Beitrag lesen

Praktiker – Headless entfernt die Standardeinstellungen

• “Headless CMS platforms remove a lot of the defaults that traditional CMS platforms handle automatically — meta tags, canonical URLs, structured data, sitemaps, none of these come out of the box in a headless setup.” — Successive Digital, Headless CMS SEO: Avoid These Common Pitfalls. Beitrag lesen
• “The title can either be populated with the Strapi SEO Plugin or by creating a text field where the title tag will be stored, with conditions added such as not being shorter than or not exceeding a set amount of characters.” — SALT.agency, The SEO guide to Strapi. Beitrag lesen

Zwei Checklisten: Strapi-SEO-Gesundheit + Migration

Strapi-SEO-Gesundheitscheck

• Das Frontend rendert Inhalte beim ersten Request als HTML (SSR oder SSG), nicht erst nachdem clientseitiges JavaScript ausgeführt wurde.
• Kein öffentlicher Inhaltstyp verlässt sich für seinen Hauptinhalt auf CSR (viele KI-Crawler holen nur das initiale HTML und führen nie JavaScript aus).
• Eine SEO-Komponente (metaTitle, metaDescription, canonicalURL, ogImage, preventIndexing) existiert auf jedem öffentlichen Inhaltstyp und wird in den <head> gemappt.
• Slugs verwenden das UID-Feld; Kanonische URLs sind absolute URLs, die aus einer einzigen SITE_URL aufgebaut werden, die auf der Rendering-Ebene gesetzt ist.
• Das Frontend sendet niemals ein authentifiziertes API-Token in öffentlichen Requests (sonst leaken Entwürfe).
• Vorschau-/Staging-Hosts geben einen Host-Level X-Robots-Tag: noindex zurück, plus Disallow: / in robots.txt (und HTTP-Auth, wo möglich).
• /admin ist noindexed und passwortgeschützt; nicht öffentlich verlinkt.
• Das rohe /api/*-JSON ist in robots.txt blockiert (idealerweise auf einer eigenen Subdomain, fern der Sitemap).
• sitemap.xml wird generiert (Sitemap-Plugin oder Frontend) und listet nur veröffentlichte, kanonische URLs.
• robots.txt existiert, enthält eine Sitemap:-Direktive und blockiert nicht .js/.css.
• Ein Webhook bei Veröffentlichung löst einen Rebuild/Revalidate aus → Sitemap-Regenerierung → GSC + IndexNow-Ping.

Migrations-Checkliste (WordPress → Strapi)

• Vollständiges URL-Inventar — Beiträge, Seiten, Tag-/Kategorie-Seiten, paginierte Archive, Parameter-URLs.
• Slugs exakt auf Strapi-UID-Felder gemappt; 301-Redirect-Map vor dem Go-Live erstellt (strapi-plugin-redirect-urls / Smart Redirect Manager).
• Meta-Titel, Beschreibungen, og:image in die SEO-Komponente migriert.
• Bild-Alt-Texte in das alternativeText-Feld der Media Library migriert.
• Kanonische URLs auf dem neuen Frontend verifiziert (nicht angenommen).
• Rendering-Modus als SSR/SSG bestätigt (kein versehentlicher CSR-Standard).
• Strukturierte Daten erneut mit dem Rich Results Test verifiziert.
• Sitemaps erneut an Google Search Console und Bing Webmaster Tools übermittelt; IndexNow eingerichtet.

Die mentalen Modelle

1. Strapi ist nicht die SEO-Entscheidung — das Frontend ist es. Strapi hat keine Rendering-Ebene. Bevor Sie irgendetwas debuggen, beantworten Sie eine Frage: Wie rendert das Frontend diesen Inhalt? Fast jedes Strapi-SEO-Problem löst sich darauf zurück.

2. Die Entscheidungsregel für den Rendering-Modus. Wählen Sie danach, wie oft sich der Inhalt ändert:

• Größtenteils statisch (Blogs, Doku, Marketing) → SSG.
• Immer aktuell / volatil (Preise, Lagerbestand) → SSR.
• Stündlich/täglich, statische Geschwindigkeit gewünscht → ISR (Vorsicht vor der Stale-First-Request-Falle).
• Eingeloggt, nicht zur Indexierung gedacht → CSR ist akzeptabel.
• Öffentlicher Inhalt, den Sie von KI ranken oder zitieren lassen möchten → niemals CSR.

3. „Baue nach, was das Plugin getan hat.“ Jedes automatische Yoast-Verhalten ist jetzt ein bewusster Schritt in Strapi + Frontend: SEO-Felder im Inhaltsmodell → in den <head> gemappt → Sitemap → robots.txt → Kanonische URLs → strukturierte Daten. Wenn etwas „fehlt“, wurde ein Plugin-Verhalten nie neu implementiert.

4. Das Plugin speichert; das Frontend rendert. Das SEO-Plugin gibt Redakteuren Felder und Vorschauen — es gibt kein HTML, Sitemaps oder robots.txt aus. Halten Sie diese beiden Verantwortlichkeiten im Kopf getrennt, dann erwarten Sie nicht, dass das Plugin die Arbeit des Frontends erledigt.

5. Vier Dinge dürfen niemals in den Index gelangen. Entwürfe, Vorschau-/Staging-Deployments, /admin und das rohe /api/*-JSON. Jedes hat eine andere Kontrolle (Veröffentlichungs-Workflow, Host-Level-noindex, Passwort + noindex, Robots-Block auf eigener Subdomain). Prüfen Sie alle vier explizit.

Strapi-SEO — Spickzettel

Rendering-Modi auf einen Blick

Was Strapi/Plugins tun vs. was das Frontend tut

Aus dem Index fernhalten – vier Kontrollen

Schnelle Regeln

• Strapi ist SEO-neutral – der Rendering-Modus ist das Produkt.
• Verwenden Sie das UID-Feld für Slugs; Canonicals = absolute URLs von einer SITE_URL.
• Das SEO-Plugin speichert Felder; es gibt kein HTML/Sitemap/robots aus.
• Niemals .js/.css in robots.txt disallowen.
• Richten Sie einen Veröffentlichungs-Webhook → Rebuild → Sitemap → GSC + IndexNow ein.
• Bei SSR die Strapi-API cachen (oder ISR verwenden), damit Latenz nicht LCP beeinträchtigt.

Wie sollte eine Strapi-Seite rendern?

Incident-Playbook: Veröffentlichte Strapi-Seiten verschwinden aus der Suche

1. Bestätigen Sie die öffentliche Antwort. Prüfen Sie Status, Weiterleitungen, rohes HTML, Canonical und robots-Direktiven. Beheben Sie einen Fetch- oder Indexierbarkeitsfehler, bevor Sie die Inhaltsanalyse durchführen.
2. Verfolgen Sie die Veröffentlichung. Gleichen Sie das Strapi-Veröffentlichungsereignis mit Webhook, Build/Revalidierung und Cache-Logs ab. Wenn die Live-Seite veraltet ist, reparieren Sie diese Kette.
3. Prüfen Sie den Template-Umfang. Vergleichen Sie betroffene und gesunde Inhaltstypen. Wenn ein Template fehlschlägt, untersuchen Sie dessen Frontend-Feldzuordnung und Routengenerierung.
4. Prüfen Sie die Exposition. Stellen Sie sicher, dass Entwürfe, Vorschau-Hosts, /admin und rohe API-Routen ausgeschlossen sind, während öffentliche HTML-Routen crawlfähig bleiben.
5. Validieren Sie die Wiederherstellung. Bestätigen Sie vollständiges Quell-HTML und einen sauberen Canonical-/Indexierbarkeitsstatus, und überwachen Sie dann den normalen Recrawl, anstatt unveränderte Seiten wiederholt erneut einzureichen.

Strapi-SEO-Fehler

• Ein SEO-Plugin als Rendering-Schicht behandeln. Es erstellt Felder; das Frontend muss sie ausgeben und validieren.
• Wesentliche Inhalte nur im Browser abrufen. Verwenden Sie SSG, Regenerierung oder SSR für Seiten, die ranken sollen.
• Entwürfe und Vorschau-Deployments exponieren. Zugriff verlangen und serverseitig sichtbare noindex-Signale senden.
• Rohe API-URLs in Sitemaps setzen. Sitemaps sollten kanonische öffentliche HTML-Routen auflisten, nicht /api-Ressourcen.
• Den gesamten API-Zugriff blockieren, ohne die Architektur zu prüfen. Schützen Sie private Endpunkte, aber brechen Sie keine Server-Builds oder das Rendering, das legitim von Strapi abhängt.

Inhalt ist in Strapi veröffentlicht, aber die Seite bleibt veraltet

Wahrscheinliche Ursache: Webhook-, Build-, Revalidierungs- oder Cache-Fehler. Behebung: Verfolgen Sie die Inhalts-ID durch jeden Schritt und leeren Sie die betroffene Route. Bestätigung: Das rohe Produktions-HTML enthält die veröffentlichte Revision.

SEO-Felder sind ausgefüllt, aber Tags fehlen

Wahrscheinliche Ursache: Die Frontend-Abfrage lässt die SEO-Komponente aus oder die Head-Vorlage mappt sie nicht. Behebung: Felder einbeziehen und während SSG/SSR rendern. Bestätigung: curl gibt die erwarteten Titel-, Canonical- und robots-Tags zurück.

Entwurfs- oder Vorschau-Inhalt ist indexierbar

Wahrscheinliche Ursache: ein öffentlicher Vorschau-Host oder eine reine Client-Noindex-Logik. Behebung: Authentifizierung und serverseitige Ausschlüsse hinzufügen. Bestätigung: Nicht authentifizierte Anfragen können nicht auf eine indexierbare Antwort zugreifen.

Ein Inhaltstyp fehlt in der Sitemap

Wahrscheinliche Ursache: die Frontend-Sitemap-Abfrage, der Veröffentlichungsfilter, die Locale-Beziehung oder das Routen-Mapping schließt ihn aus. Behebung: Korrigieren Sie die Abfrage und nehmen Sie nur kanonische veröffentlichte Routen auf. Bestätigung: Sitemap-Einträge lösen auf indexierbare 200-Seiten auf.

Strapi-API-Daten mit Produktions-HTML vergleichen

curl -fsS 'https://cms.example.com/api/articles/SLUG' > strapi.json
curl -fsSL 'https://www.example.com/SLUG/' > page.html
grep -Eio '<title>[^<]+|<link[^>]+rel="canonical"[^>]*|<meta[^>]+name="robots"[^>]*' page.html

Verwenden Sie die API-Antwort nur aus einer autorisierten Umgebung und geben Sie keine Tokens in Logs aus. Der Vergleich prüft die Auslieferung; er beweist nicht die Indexierungsentscheidung von Google.

Gerenderte Head-Werte prüfen

In der DevTools-Konsole ausführen:

({title: document.title, canonical: document.querySelector('link[rel="canonical"]')?.href, robots: document.querySelector('meta[name="robots" i]')?.content});

Eine Strapi-SEO-Änderung nachweisen

Content-Auslieferungstest

Durchzuführender Test: Veröffentlichen Sie eine kontrollierte Revision und verfolgen Sie Strapi, Webhook, Build/Revalidierung, Cache und Live-Quelle. Erwartetes Ergebnis: Eine kanonische Produktionsroute bedient dieselbe veröffentlichte Revision. Fehlerinterpretation: Auslieferung oder Invalidierung ist veraltet. Überwachungsfenster: Die normale Veröffentlichungs-SLA. Rollback-Auslöser: Gemischte Inhalts- und Metadatenversionen erreichen die Produktion.

Quell-Rendering-Test

Durchzuführender Test: Vergleichen Sie rohes und gerendertes HTML bei repräsentativen Inhaltstypen. Erwartetes Ergebnis: Primärinhalte, Links, Metadaten und Kanonische sind vorhanden und stimmen überein. Fehlerinterpretation: Wesentliche Ausgaben hängen von Browser-JavaScript ab. Überwachungsfenster: Jedes Frontend-Release. Rollback-Auslöser: Eine Schlüsselvorlage verliert Quellinhalte oder Indexierungssignale.

Expositionstest

Durchzuführender Test: Fordern Sie Vorschau-, Entwurfs-, Admin-, API- und öffentliche Routen ohne Anmeldeinformationen an. Erwartetes Ergebnis: Sensible Routen sind geschützt oder ausgeschlossen, während kanonische öffentliche Seiten crawlbar bleiben. Fehlerinterpretation: Zugriffs- und SEO-Kontrollen sind über- oder unterdimensioniert. Überwachungsfenster: Jede Routing- oder Sicherheitsänderung. Rollback-Auslöser: Entwürfe werden öffentlich oder öffentliche Seiten werden blockiert.

Tools für Strapi-SEO

• @strapi/plugin-seo (Community-SEO-Plugin) — fügt die SEO-Komponente, SERP-Vorschau und In-Content-Analyse zum Strapi-Admin hinzu. Installation über yarn add @strapi/plugin-seo. Speichert Felder; rendert sie nicht.
• Webtools-Sitemap-Add-on (strapi-plugin-webtools + webtools-addon-sitemap, pluginpal) — die gepflegte Strapi-5-Sitemap-Option; generiert sitemap.xml aus veröffentlichten Inhalten und teilt sie bei Skalierung automatisch in ein Sitemap-Index auf. strapi-5-sitemap-plugin ist eine leichtere Alternative für einfachere Websites. Das ältere eigenständige strapi-plugin-sitemap von Pluginpal unterstützt nur Strapi 4 — seine README verweist v5-Benutzer an Webtools.
• strapi-plugin-redirect-urls / Smart Redirect Manager — verwalten Sie 301/302- Weiterleitungen im Admin für Migrationen und Slug-Änderungen.
• URL Inspection (Google Search Console) — sehen Sie, wie eine einzelne Frontend-URL gecrawlt und gerendert wurde; das gerenderte HTML zeigt Ihnen, ob CSR Inhalte ausgelassen hat.
• Rich Results Test — bestätigen Sie, dass JSON-LD nach jeder Rendering-Änderung in der gerenderten Ausgabe vorhanden ist.
• Screaming Frog SEO Spider — crawlen Sie mit JS-Rendering an/aus, um rohes vs. gerendertes HTML zu vergleichen; erstellen Sie den Vorher/Nachher-Crawl-Vergleich für Migrationen; decken Sie versehentlich indexierbare Vorschau-/Admin-/API-URLs auf.
• Ahrefs Site Audit — deckt kaputte Kanonische, fehlende Metadaten, Weiterleitungsketten und Indexierungsprobleme im gesamten Frontend auf.
• Bing Webmaster Tools — Bings Rendering-/Indexierungsansicht und wo IndexNow- Übermittlungen angezeigt werden.

Testen Sie sich selbst: Strapi-SEO

Fünf kurze Fragen zur Funktionsweise von SEO auf einer Strapi-basierten Website. Wählen Sie eine Antwort für jede Frage und überprüfen Sie dann.

Ressourcen, die Ihre Zeit wert sind

Meine verwandten Artikel

• JavaScript-SEO: Probleme und Best Practices — meine primäre Referenz zum Rendering; der Kern dessen, wie ein Strapi-Frontend gecrawlt und indexiert wird.
• Der Anfängerleitfaden für technisches SEO — wo Rendering und Crawling in das größere Bild passen.

Meine Vorträge

• JavaScript SEO — Ungagged 2019 (SlideShare) — meine Erläuterung, wie Headless-/Decoupled-CMS Frontend und Backend trennen, plus das zustandslose Rendering des Googlebots. (Ständiger Hinweis: Die Empfehlung zum dynamischen Rendering in diesem Vortrag ist inzwischen veraltet — Google hat es eingestellt.)

Auf dieser Website

• SEO für ein Headless-CMS — die plattformunabhängige Version von allem hier.
• JavaScript-SEO — die Rendering-Säule, auf der Strapi-SEO aufbaut.

Aus der Branche

• React-SEO: Best Practices (Sam Underwood, Ahrefs) — React ist das am häufigsten mit Strapi verwendete Frontend und direkt anwendbar; verfasst von Patricks Ahrefs-Kollegen, nicht von Patrick.
• Headless-CMS- und Strapi-SEO-Best-Practices (Strapi-Blog) — Strapis eigene Übersicht darüber, wo die SEO-Verantwortung in einem Headless-Setup liegt.
• Strapi-SEO-Plugins: Vollständiger Leitfaden für Strapi 5 (Strapi-Blog) — was die SEO- und Sitemap-Plugins tun, einschließlich des Verhaltens von Entwurf/Veröffentlichung in der Sitemap.
• Der SEO-Leitfaden für Strapi (SALT.agency) — eine unabhängige technische SEO-Agentur-Erläuterung zur Modellierung von SEO-Feldern in Strapi.
• Strapi-SEO-Tipps und -Tricks (Notum Tech) — vom Team hinter dem ursprünglichen SEO-Plugin.
• Headless-CMS-SEO: Vermeiden Sie diese häufigen Fallstricke (Successive Digital) — die Probleme mit doppelten Umgebungen und fehlenden Standardwerten, die Strapi-Stacks betreffen.
• Webtools-Sitemap-Add-on (Dokumentation) — die gepflegte Strapi-5-Sitemap-Lösung; das ältere strapi-plugin-sitemap (GitHub) unterstützt nur Strapi 4.
• @strapi/plugin-seo (npm) — das SEO-Plugin-Paket und die Komponentenreferenz.

Statistiken, die sich zu zitieren lohnen

• Strapi ist Open Source und dual-deploybar. Es ist ein Node.js-Headless-CMS mit REST- und GraphQL-APIs, das selbst gehostet oder auf Strapi Cloud betrieben werden kann – die Deployment-Wahl beeinflusst die API-Latenz, was sich nur bei SSR (nicht SSG/ISR) auf die Core Web Vitals auswirkt. Quelle
• Das Sitemap-Add-on teilt automatisch ab 50 000 URLs in ein Sitemap-Index auf und schließt Entwürfe aus, wenn Entwurf/Veröffentlichung aktiviert ist – das ist die praktische Skalierungsgrenze für eine von Strapi generierte Sitemap. Für Strapi 5 ist das das Webtools-Sitemap-Add-on, nicht das ältere eigenständige Plugin (unten). Quelle
• Das Rendering-Verhalten ist bei KI-Crawlern nicht einheitlich, aber die sichere Annahme ist HTML-only. Es gibt keine gemeinsame Spezifikation – einige Fetcher führen JavaScript aus, die meisten heute nicht –, sodass ein Crawler, der nur die anfängliche HTML-Antwort liest, bei einer CSR-Seite eine leere Hülle sieht. SSR/SSG platziert den Inhalt im rohen HTML und beseitigt das Rätselraten, weshalb es die sicherere Standardeinstellung für KI-Sichtbarkeit sowie für Google/Bing ist. Kontext
• Google hat Dynamic Rendering eingestellt. Das Vorab-Rendern eines CSR-Strapi-Frontends ist nicht mehr die empfohlene Problemumgehung – Google verweist nun auf SSR, statisches Rendering oder Hydration. Quelle

Änderungsprotokoll