Contentful-SEO

TL;DR — Contentful ist ein Ort, um Inhalte zu speichern und zu strukturieren, nicht ein Ort, der Webseiten erstellt. Es übergibt Ihre Inhalte über eine API an eine separate Website (erstellt mit etwas wie Next.js oder Astro), und diese Website ist es, die Suchmaschinen tatsächlich sehen. Contentful selbst “macht also kein SEO” – es gibt kein eingebautes Title-Tag, keine Sitemap und keine robots.txt. Die große Regel ist dieselbe wie bei jedem Headless-Setup: Erstellen Sie Ihre Seiten auf einem Server oder zur Build-Zeit, damit Suchmaschinen echtes HTML erhalten, und bauen Sie die SEO-Grundlagen (Titel, Beschreibungen, Sitemap) selbst wieder auf.

Was Contentful tatsächlich ist

Viel Verwirrung über Contentful-SEO verschwindet, sobald man eines versteht: Contentful ist ein Content-Repository, keine Website. In einem traditionellen CMS wie WordPress sind der Ort, an dem Sie Inhalte schreiben, und der Ort, der sie in eine Webseite verwandelt, dasselbe System. Contentful trennt diese. Sie modellieren und schreiben Inhalte in Contentful, und Contentful liefert diese Inhalte dann als Rohdaten (JSON) über eine API aus. Eine völlig separate Website – erstellt mit einem Framework wie Next.js, Astro, Gatsby oder Nuxt – ruft diese Daten ab und erstellt die tatsächlichen Seiten, die Menschen und Suchmaschinen sehen.

Wenn also jemand fragt: “Ist Contentful gut für SEO?”, lautet die ehrliche Antwort: Contentful selbst hat fast nichts mit Ihrem SEO zu tun. Das Frontend, das es konsumiert, schon.

Contentful hat kein SEO eingebaut

Das stolpert Leute, die von WordPress kommen. Es gibt kein Yoast-ähnliches Plugin in Contentful. Von Haus aus bietet Contentful nicht:

• Title-Tags oder Meta-Descriptions
• Eine XML-Sitemap
• Eine robots.txt
• Strukturierte Daten (den Code, der Ihnen Rich-Suchergebnisse verschafft)
• Canonical-Tags

Nichts davon ist ein Fehler – es ist einfach nicht Contentfuls Aufgabe. All das wird in Ihrem Frontend erstellt. Contentfuls eigener “SEO-Leitfaden” ist wirklich ein Leitfaden zum Einbauen von SEO in eine Contentful-basierte Website, keine Liste von Funktionen, die es mitbringt.

Die eine Entscheidung, die am wichtigsten ist: Rendering

Wenn Googlebot (oder eine Person) eine Ihrer Seiten anfordert, wo wird das fertige HTML erstellt? Zwei sichere Antworten, eine riskante:

• Zur Build-Zeit (SSG) – Seiten werden als einfache HTML-Dateien vorgebaut. Großartig für SEO.
• Auf einem Server, pro Anfrage (SSR) – der Server erstellt die vollständige Seite und sendet sie. Auch großartig für SEO.
• Im Browser des Besuchers (CSR) – der Server sendet eine fast leere Hülle, und JavaScript füllt sie danach aus. Das ist die riskante Variante.

Google kann CSR-Seiten irgendwann lesen, aber es ist langsamer und weniger zuverlässig – und Bing, plus die meisten KI-Crawler hinter Tools wie ChatGPT und Perplexity, sehen oft nur die leere Hülle. Rendern Sie also jede Contentful-Seite, die gefunden werden soll, auf dem Server oder zur Build-Zeit.

Was tatsächlich für Sie zu tun bleibt

• Fügen Sie SEO-Felder (Meta-Titel, Meta-Description usw.) zu Ihrem Content-Modell in Contentful hinzu, damit Redakteure sie ausfüllen können.
• Lassen Sie einen Entwickler diese Felder in das HTML der Seite einbinden.
• Erstellen Sie eine Sitemap und eine robots.txt im Frontend / bei Ihrem Host.
• Halten Sie Ihre Staging- und Vorschauseiten von Google fern – diese leaken oft.

Möchten Sie die tiefere Version – die vier Rendering-Modi, ein tatsächliches SEO-Content-Modell-Spezifikation, Sitemaps aus der Delivery-API, Preview-API-Schutz, Weiterleitungen und strukturierte Daten? Wechseln Sie zum Erweitert-Tab.

TL;DR — Contentful ist API-first und rendert kein HTML, daher sehen Suchmaschinen nur das, was Ihr Frontend produziert — jedes SEO-Ergebnis ist eine Frontend-Entscheidung. Rendering ist der Hebel Nr. 1: SSG und SSR liefern vollständig gerendertes HTML und sind bei Google, Bing und KI-Crawlern sicher; CSR ist die riskante Option (Google indexiert langsam, Bing/Yandex/Baidu und die meisten KI-Bots möglicherweise gar nicht); dynamisches Rendering ist veraltet. Contentful hat kein eingebautes SEO, also bauen Sie es selbst: explizite SEO-Felder im Content-Modell (integriert oder als eigener SEO-Typ), Metadaten im <head>, eine aus der Delivery API generierte Sitemap (ohne noindex/kanonisierte Einträge), eine robots.txt auf der Hosting-Ebene, die JS/CSS nie blockiert, serverseitige Redirects, JSON-LD aus Content-Typen und hreflang aus den Locale-Daten von Contentful. Das größte Contentful-spezifische Risiko ist die Preview API: Schützen Sie Entwürfe/Staging mit einem Host-Level X-Robots-Tag: noindex und/oder Authentifizierung — niemals nur mit robots.txt.

Der Architekturpunkt, der alles bestimmt

Contentful ist ein Content-Repository, kein Webserver. Es liefert strukturiertes JSON über seine REST Content Delivery API und eine GraphQL API; es rendert oder liefert nie HTML. Suchmaschinen berühren Contentful nie direkt — sie sehen, was Ihr Frontend aus diesen Daten rendert. Jedes SEO-Ergebnis wird also durch zwei Dinge bestimmt:

1. Was Ihr Frontend-Framework (Next.js, Astro, Gatsby, Nuxt, SvelteKit) mit den Daten von Contentful macht, und
2. ob Sie die unterstützende Infrastruktur — Sitemaps, robots.txt, Redirects — auf der Hosting/CDN-Ebene gebaut haben.

Das ist derselbe Punkt, den ich in meinem JavaScript-SEO-Leitfaden mache: Das Web hat sich von reinem HTML entfernt, und als SEO können Sie das annehmen, statt dagegen zu kämpfen. JavaScript ist nicht schlecht für SEO und nicht böse — aber wie Sie es rendern, ist das ganze Spiel. Contentful ist eine spezialisierte Anwendung von Headless-CMS-SEO; wenn Sie nur einen verwandten Artikel lesen, lesen Sie diesen.

Rendering ist die wichtigste Contentful-SEO-Entscheidung

Da Contentful für Crawler unsichtbar ist, entscheidet der Rendering-Modus des Frontends, ob Ihre Inhalte überhaupt indexiert werden. Die Reihenfolge der Präferenz:

SSG / statisches Rendering. HTML wird zur Build-Zeit generiert und als statische Dateien von einem CDN ausgeliefert. Best-Case-SEO: vollständig gerendertes HTML bei der ersten Anfrage, sehr schnelles TTFB. Der Kompromiss ist die Aktualität — geänderte Inhalte benötigen einen Rebuild (ISR mildert das). Astro und Gatsby sind SSG-first; Next.js macht es pro Route über getStaticProps / statische Routen.

SSR — serverseitiges Rendering. HTML wird pro Anfrage gerendert. Immer aktuelles, vollständig gerendertes HTML beim ersten Abruf. Höhere Infrastrukturkosten. Wie Contentful selbst sagt: “Server-side rendering is guaranteed to provide results if done right.” (Übersetzung) „Serverseitiges Rendering liefert garantiert Ergebnisse, wenn es richtig gemacht wird.” Next.js (getServerSideProps), Nuxt SSR, SvelteKit, Remix.

ISR — inkrementelle statische Regeneration. Statische Seiten werden im Hintergrund nach einem Revalidierungsfenster regeneriert. Ein starker Mittelweg für Inhalte, die sich stündlich oder täglich ändern — aber achten Sie auf die Falle, dass die erste Anfrage nach dem Fenster immer noch die veraltete gecachte Seite erhält (Googlebot kann diese Anfrage sein).

Hybrid. Mischen Sie SSG/SSR/ISR pro Route. Am praktischsten für große Contentful-Sites und Contentfuls empfohlener Standard: “Hybrid rendering combines the benefits of SSR and CSR, serving content within initial HTML while still maintaining a more flexible front end. This approach to JavaScript rendering is most ideal for serving content to users and search engines alike.” (Übersetzung) „Hybrides Rendering kombiniert die Vorteile von SSR und CSR, liefert Inhalte im initialen HTML und behält gleichzeitig ein flexibleres Frontend. Dieser Ansatz für JavaScript-Rendering ist am idealsten, um Inhalte sowohl für Nutzer als auch für Suchmaschinen bereitzustellen.”

CSR — client-side rendering. Ein minimales Grundgerüst wird ausgeliefert, dann holt Browser-JavaScript Inhalte von Contentful und baut das DOM auf. Dies ist die schlechteste SEO-Option. Google stellt die Seite für eine spätere Render-Welle mit unvorhersehbarem Timing in die Warteschlange; Bing, Yandex und Baidu indizieren sie möglicherweise überhaupt nicht, und das Rendering von KI-Crawlern variiert je nach Anbieter, sodass jeder Abrufer, der nur das anfängliche HTML verwendet, das leere Grundgerüst sieht. Migrationen, die auf CSR setzen, haben dokumentierte Traffic-Verluste im Bereich von 40–80 %. Rohe React/Vue/Angular-SPAs ohne Server-Rendering-Framework landen standardmäßig hier — vermeiden Sie CSR für alles, was gefunden werden soll.

Der Bing-Punkt verdient besondere Betonung, weil alle auf Google überfokussieren: Eine reine CSR-Contentful-Bereitstellung ist ein Bing-SEO-Fehler, selbst wenn Google sie problemlos verarbeitet. Allein das ist das Argument für SSR/SSG, unabhängig von Googles verbesserter JS-Verarbeitung.

Dynamic Rendering ist veraltet

Bots eine vorgerenderte Version zu servieren, während Nutzer die SPA erhalten, war einst eine vernünftige Problemumgehung. Google hat das revidiert: Es empfiehlt jetzt “server-side rendering, static rendering, or hydration” (Übersetzung) „serverseitiges Rendering, statisches Rendering oder Hydration“ und bezeichnet Dynamic Rendering als Problemumgehung, die “creates additional complexities and resource requirements.” (Übersetzung) „schafft zusätzliche Komplexität und Ressourcenanforderungen.“ Es ist nicht automatisch Cloaking — aber bauen Sie kein neues Contentful-Frontend darauf auf.

Aufbau eines Contentful-Content-Modells für SEO

Contentful gibt Ihnen nichts, bis Sie es modellieren. Das Content-Modell ist das SEO-Fundament — wie Contentful es formuliert: “Ein Content-Modell umfasst die Struktur und Organisation Ihrer Inhalte und dient als Fundament für alles, was Sie erreichen können.” Zwei Muster:

• Integrierter Ansatz — SEO-Felder leben in jedem Seiten-Content-Typ. Einfach; gut für kleine Websites.
• Eigener SEO-Content-Typ — ein wiederverwendbarer seoMetadata-Typ, auf den jeder Seiten-Typ verweist. Einzige Quelle der Wahrheit, einfacher websiteweit zu aktualisieren. Meine Standardempfehlung für alles Nicht-Triviale.

Ein solides Kern-SEO-Feldschema pro Seite (oder im eigenen Typ):

Geben Sie dem noindex-Umschalter echten Hilfetext. Contentfuls eigene empfohlene Editor-Kopie: “Selecting yes will keep the page from showing up in organic search results.” (Übersetzung) „Wenn Sie Ja auswählen, wird die Seite nicht in den organischen Suchergebnissen angezeigt.“ Und Denken Sie auch an die Headless-Falle — diese Felder bewirken nichts, bis das Frontend sie tatsächlich liest und die Tags in das servergerenderte <head> rendert. Selbstreferenzierende Kanonikale müssen auch implementiert werden, wenn kein benutzerdefiniertes canonicalUrl gesetzt ist; das Vergessen ist einer der häufigsten Contentful-Kanonikalfehler, insbesondere bei automatisch generierten Seiten (Paginierung, Tag, Filter).

Metadaten, Sitemaps, robots.txt — das Plugin neu aufbauen

Metadaten werden aus den SEO-Feldern mithilfe des framework-nativen Head-Managements in das <head> gemappt: Next.js App Router generateMetadata (setzen Sie metadataBase, sonst brechen relative Kanonikale), Nuxt useSeoMeta, Gatsbys <Seo> / react-helmet oder Astros Layout-<head>. Die Zuverlässigkeitsregel: HTML-Ebene-Metadaten schlagen JS-injizierte Metadaten, weil Google sie beim ersten Abruf sieht und KI-Crawler sie überhaupt sehen.

Sitemaps müssen erstellt werden — Contentful hat keine. Fragen Sie die Delivery-API nach allen veröffentlichten Einträgen ab, paginiert (die API begrenzt Ergebnisse pro Anfrage, also mit skip/limit schleifen), entfernen Sie jeden Eintrag mit noindex: true oder einem nicht-selbstreferenzierenden Kanonikal und geben Sie XML unter https://domain.com/sitemap.xml aus. Für SSG beim Build generieren; für SSR eine dedizierte /sitemap.xml-Route, die Contentful abfragt und XML zurückgibt. Bei Websites mit hohem Veröffentlichungsvolumen nach Content-Typ neu generieren / segmentieren, damit sie nie veraltet.

robots.txt lebt auf der Hosting-Ebene – Vercel, Netlify, Cloudflare Pages – nicht in Contentful. Es muss auf Ihre Sitemap verweisen, Staging-/Preview-Hosts separat blockieren, und die eine Regel, die Sie nicht brechen dürfen: .js oder .css niemals disallowen (das blockiert das Rendering vollständig).

Schutz von Staging und der Preview-API – das schärfste Contentful-Risiko

Contentful hat zwei Delivery-Endpunkte: die Content Delivery API (veröffentlichte Inhalte) und die Content Preview API (ein anderer Schlüssel/Endpunkt, der Entwurfs-Inhalte ausliefert). Preview-/Staging-Frontends, die gegen die Preview-API gebaut sind, sind häufig öffentlich erreichbar, und wenn Google sie findet, erhalten Sie eine vollständige Kopie Ihrer Website, die auf einem anderen Host indexiert wird.

Die Falle, die in den meisten Anleitungen falsch beschrieben wird: robots.txt ist beratend, keine Zugriffskontrolle. Google respektiert ein Disallow und wird den Pfad nicht crawlen – aber wenn eine Staging-URL irgendwo verlinkt ist (eine E-Mail, Slack, eine andere Website), kann Google sie trotzdem entdecken und indexieren, ohne sie zu crawlen. Schützen Sie Preview-Umgebungen daher mit:

• Ein Host-Level-X-Robots-Tag: noindex-HTTP-Header auf allen Preview-Routen (am CDN/Edge, nicht ein spät per JS injiziertes Meta-Tag, das eine CSR-Shell vielleicht nie rendert), und/oder
• Authentifizierung (signierte Token / ein Login-Gate), und
• Umgebungsbewusste Kanonische, damit Staging nie selbst auf die Produktions-URL kanonisiert.

Verwenden Sie kurzlebige Preview-Hosts und beobachten Sie die Search Console auf unerwartete Domains – das ist Ihre Frühwarnung.

Redirects in einem Headless-Contentful-Setup

Contentful übernimmt auch keine Redirects. Drei praktikable Muster:

1. Redirects in Contentful modellieren – ein redirect-Inhaltstyp mit Quell-, Ziel- und Typ-Feldern (301/302) – und diese Einträge auf der Server-/Edge-Ebene lesen, um echte HTTP-Redirects auszugeben. Contentfuls eigener Composable-Redirect-Workflow macht das editorfreundlich: “open an existing piece of content (or create a new page), indicate that this page will be located at a different URL by updating the URL path, set up a redirect to indicate the page has moved permanently.” (Übersetzung) „Öffnen Sie einen bestehenden Inhalt (oder erstellen Sie eine neue Seite), geben Sie an, dass diese Seite unter einer anderen URL erreichbar sein wird, indem Sie den URL-Pfad aktualisieren, und richten Sie einen Redirect ein, um anzuzeigen, dass die Seite dauerhaft verschoben wurde.“
2. Webhook + Automatisierung – einen Contentful-Publish-Webhook in Make/Zapier und einen Redirect-Microservice (EasyRedir, redirect.pizza) auslösen.
3. Bringen Sie Editoren den Unterschied bei: 301er geben Link-Equity weiter, 302er nicht. Und vermeiden Sie JavaScript-Redirects (window.location) – sie sind langsamer, geben möglicherweise keine Equity weiter, und Nicht-Google-Crawler folgen ihnen möglicherweise nicht.

Strukturierte Daten, hreflang und Performance

Strukturierte Daten sind der seltene Bereich, in dem Headless einfacher ist. Contentfuls strukturierter Inhalt lässt sich natürlich auf JSON-LD abbilden: Ein FAQ-Inhaltstyp rendert FAQ-Schema, ein Artikel-Typ rendert Article/BlogPosting, ein Produkt-Typ rendert Product, und Organization-Schema lebt in einem globalen Site-Settings-Inhaltstyp. Das Frontend leitet das JSON-LD aus Inhaltsfeldern ab und injiziert es serverseitig – Editoren schreiben nie JSON-LD. Validieren Sie nach jeder Rendering-Änderung mit dem Rich-Suchergebnisse-Test.

International / hreflang. Contentful hat eine eingebaute Feld-Level-Lokalisierung (ein locale-Parameter in API-Anfragen, mit ISO-Codes wie en-US, de-AT). Aber das ist Inhalts-Auslieferung, kein SEO-Signal – hreflang-Tags müssen vom Frontend aus Contentfuls Locale-Daten generiert werden, mit x-default auf jeder lokalisierten Seite. Hreflang im <head>, in HTTP-Headern oder in der XML-Sitemap sind alle gültig; <head> ist bei Contentful-Frontends am häufigsten.

Performance. Die Contentful-Delivery-API wird über ein globales CDN mit sehr hohen Cache-Trefferquoten ausgeliefert, was TTFB hilft, wenn Sie Inhalte zur Build- oder Server-Render-Zeit abrufen. Aber die TTFB und LCP der echten Nutzer werden von Ihrem Frontend-Host und Rendering-Modus dominiert, nicht von der API-Latenz von Contentful – daher ist die Framework-Wahl (statisches Astro, Next.js statisch/ISR) für Core Web Vitals weitaus wichtiger als Contentful selbst.

Migration zu Contentful, ohne den Traffic zu gefährden

Migrations sind der Punkt, an dem Headless-SEO tatsächlich schiefgeht. Die vorhersehbaren Fehler: kaputte 301-Weiterleitungen (insbesondere bei Kategorie-, Tag- und paginierten Archiv-URLs, die jeder vergisst), Metadaten, die nicht übernommen wurden, und ein Rendering-Modus, der stillschweigend auf CSR zurückfiel. Vor dem Go-Live: jede URL inventarisieren (nicht nur Beiträge), eine vollständige 301-Zuordnung erstellen, Metadaten und Kanonische Tags im neuen Frontend überprüfen, einen Screaming-Frog-Crawl-Vergleich vorher/nachher durchführen, Sitemaps erneut an sowohl Google Search Console als auch Bing Webmaster Tools übermitteln und URL Inspection als Quelle der Wahrheit dafür verwenden, was Googlebot tatsächlich rendert.

Weiterführende Lektüre: Headless-CMS-SEO, JavaScript-SEO und die breiteren Rendering-Themen — Contentful-SEO ist wirklich eine spezialisierte Anwendung aller drei.

KI-Zusammenfassung

Eine komprimierte Sicht auf die Advanced-Version:

• Contentful ist ein Content-Repository, kein Webserver. Es liefert JSON über REST- und GraphQL-APIs und rendert kein HTML — Suchmaschinen sehen nur das, was Ihr Frontend produziert. Jedes SEO-Ergebnis ist eine Frontend-Entscheidung.
• Rendering ist der Hebel Nr. 1. SSG und SSR liefern vollständig gerendertes HTML und sind überall sicher; ISR/hybrid sind starke Mittelwege; CSR ist riskant (Google indexiert es langsam; Bing/Yandex/Baidu und die meisten KI-Crawler möglicherweise gar nicht). Eine reine CSR-Contentful-Site ist ein Bing-SEO-Fehler, selbst wenn Google damit zurechtkommt.
• Dynamisches Rendering ist veraltet — Google empfiehlt stattdessen SSR, statisches Rendering oder Hydration.
• Contentful hat kein eingebautes SEO — keine Title-Tags, Sitemap, robots.txt, Schema oder Kanonische Tags. Sie bauen das alles im Frontend.
• SEO-Felder explizit modellieren: seoTitle, seoDescription, canonicalUrl, noindex (steuert Meta-Robots und Sitemap-Ausschluss), ogImage. Integriert pro Typ oder als wiederverwendbarer dedizierter SEO-Typ. Felder bewirken nichts, bis das Frontend sie in den serverseitig gerenderten <head> rendert; denken Sie an selbstreferenzierende Kanonische Tags.
• Sitemap = Delivery-API abfragen, paginiert, noindex/kanonisierte Einträge ausschließen, XML ausgeben. robots.txt lebt auf der Hosting-Ebene und darf .js/.css niemals blockieren.
• Preview-API-Risiko: Entwurf/Staging muss mit einem Host-Level X-Robots-Tag: noindex und/oder Authentifizierung geschützt werden — robots.txt allein reicht nicht (verlinkte URLs werden indexiert, ohne gecrawlt zu werden).
• Weiterleitungen sind serverseitig (modellieren Sie Weiterleitungen in Contentful oder verwenden Sie einen Webhook + Weiterleitungs- dienst); 301 gibt Equity weiter, 302 nicht; vermeiden Sie JS-Weiterleitungen.
• JSON-LD wird aus Inhaltstypen abgeleitet und serverseitig injiziert (Redakteure schreiben es nicht). Hreflang wird vom Frontend aus Contentfuls Lokalisierungsdaten generiert (eingebaute Lokalisierung ist Auslieferung, kein SEO-Signal).
• Migrations scheitern an kaputten 301-Weiterleitungen, verlorenen Metadaten und versehentlichem CSR — vollständige URL- Inventarisierung + Weiterleitungszuordnung vor dem Go-Live; URL Inspection ist die Quelle der Wahrheit.

Offizielle Dokumentation

Primärquellen-Dokumentation von den Suchmaschinen und von Contentful.

Google

• JavaScript-SEO-Grundlagen verstehen – die Crawl-→-Render-→-Index-Pipeline, JS-Kanonische, Soft-404s in SPAs und die History-API-Anleitung (direkt relevant für jede Contentful-SPA).
• Dynamisches Rendering (veralteter Workaround) – warum Google es abgekündigt hat und was stattdessen verwendet werden sollte (SSR, statisches Rendering, Hydration).
• Suchbezogene JavaScript-Probleme beheben – Diagnose von Problemen im gerenderten DOM und zustandsloses Rendering.
• Rendering für inhaltsorientierte Web-Apps – SSR mit Headless-Chrome; die Abwägungen für Inhaltsseiten.
• Einführung in robots.txt – was robots.txt tut und nicht tut (relevant, da Sie es auf der Host-Ebene für Contentful erstellen).

Bing / Microsoft

• Bing-Webmaster-Richtlinien – Bings strengere Haltung zum JavaScript-Rendering und seine Sitemap-/Robots-Unterstützung.
• IndexNow / indexnow.org – das Push-Protokoll, das Sie an Ihren Contentful-Publish-Webhook anbinden können.

Contentful

• Der Contentful-SEO-Leitfaden – Contentfuls eigener mehrteiliger Leitfaden (es ist ein Leitfaden zum Einbauen von SEO in ein Contentful-Frontend, keine Feature-Liste).
• Headless-SEO erklärt – Contentfuls Rendering-Framing, einschließlich der Empfehlung für Hybrid-Rendering.
• Content-Modellierung für SEO – das Kapitel über das Content-Modell als SEO-Grundlage.
• Content-Preview-API – der Endpunkt für Entwurfsinhalte, der aus dem Index ferngehalten werden sollte.
• Best Practices für Umgebungen und Umgebungsaliase – Handhabung von Staging-/Preview-Umgebungen.

Zitate aus der Quelle

Aussagen für die Öffentlichkeit, die für Contentful-SEO relevant sind. Jeder Link ist ein Deep-Link, der zur zitierten Passage auf der Quellseite springt.

Contentful – Rendering für SEO

• “Serve the elements you deem essential to your page in the initial HTML layer to search engines.” (Übersetzung) „Liefern Sie die Elemente, die Sie für Ihre Seite als wesentlich erachten, in der anfänglichen HTML-Ebene an Suchmaschinen aus.“ — Contentful, Headless-SEO erklärt. Zum Zitat springen
• “Hybrid rendering combines the benefits of SSR and CSR, serving content within initial HTML while still maintaining a more flexible front end. This approach to JavaScript rendering is most ideal for serving content to users and search engines alike.” (Übersetzung) „Hybrid-Rendering kombiniert die Vorteile von SSR und CSR, liefert Inhalte im anfänglichen HTML und behält dennoch ein flexibleres Frontend bei. Dieser Ansatz für JavaScript-Rendering ist am idealsten, um Inhalte sowohl für Nutzer als auch für Suchmaschinen bereitzustellen.“ Zum Zitat springen
• “server-side rendering is guaranteed to provide results if done right.” (Übersetzung) „Server-seitiges Rendering liefert garantiert Ergebnisse, wenn es richtig gemacht wird.“ — Contentful, Werden Suchmaschinen meine Inhalte indexieren? Es liegt alles am Rendering. Zum Zitat springen

Contentful – Content-Modell & Weiterleitungen

• “A content model comprises the structure and organization of your content, and it serves as the foundation of everything you can accomplish.” (Übersetzung) „Ein Content-Modell umfasst die Struktur und Organisation Ihrer Inhalte und dient als Grundlage für alles, was Sie erreichen können.“ — Contentful, “Content Modeling for SEO” (Übersetzung) „Content-Modellierung für SEO“. Zum Zitat springen
• On the noindex editor toggle: “Selecting yes will keep the page from showing up in organic search results.” (Übersetzung) „Wenn Sie Ja auswählen, wird die Seite nicht in den organischen Suchergebnissen angezeigt.“ — Contentful, Technical SEO Elements (empfohlener Editor-Hilfetext). Zum Zitat springen

Google — dynamisches Rendering ist veraltet

• “Instead, we recommend that you use server-side rendering, static rendering, or hydration as a solution.” (Übersetzung) „Stattdessen empfehlen wir, Server-Side Rendering, Static Rendering oder Hydration als Lösung zu verwenden.“ — Google Search Central-Dokumentation. Zum Zitat springen

Patrick Stox — JavaScript & Headless-SEO

• “JavaScript is not bad for SEO, and it’s not evil.” (Übersetzung) „JavaScript ist nicht schlecht für SEO und es ist nicht böse.“ — ich, JavaScript SEO Issues & Best Practices (Ahrefs). Zum Zitat springen
• “Any kind of SSR, static rendering, and prerendering setup is going to be fine for search engines.” (Übersetzung) „Jede Art von SSR-, Static-Rendering- und Prerendering-Setup ist für Suchmaschinen in Ordnung.“ Zum Zitat springen

Zwei Checklisten: Contentful-SEO-Gesundheit + Migration

Contentful-SEO-Gesundheitscheck

• Seiten rendern ihren Inhalt als HTML bei der ersten Anfrage (SSG/SSR/hybrid), nicht erst nachdem clientseitiges JavaScript ausgeführt wurde.
• Keine Inhaltsseite, die gefunden werden soll, ist von CSR abhängig (denken Sie an Bing und die meisten KI- Crawler).
• SEO-Felder (seoTitle, seoDescription, canonicalUrl, noindex, ogImage) existieren im Content-Modell — integriert oder als eigener SEO-Typ.
• Das Frontend liest diese Felder tatsächlich und rendert sie in den servergerenderten <head> (überprüfen Sie mit View Source / URL Inspection).
• Selbstreferenzierende Kanonische werden auch dann gerendert, wenn keine benutzerdefinierte canonicalUrl gesetzt ist.
• Eine Sitemap wird aus der Delivery API generiert, paginiert und schließt noindex- und kanonisierte Einträge aus.
• robots.txt wird auf der Hosting-Ebene ausgeliefert, verweist auf die Sitemap und blockiert nicht .js oder .css.
• Vorschau/Staging gibt ein host-level X-Robots-Tag: noindex zurück und/oder ist auth-geschützt (nicht nur robots.txt).
• Weiterleitungen sind serverseitige 301s (in Contentful modelliert oder über einen Webhook + Weiterleitungsdienst) — keine JS-Weiterleitungen.
• JSON-LD wird aus Inhaltstypen abgeleitet und serverseitig injiziert; besteht den Rich-Suchergebnisse-Test.
• hreflang (mit x-default) wird vom Frontend aus den Locale-Daten von Contentful generiert.

Migrations-Checkliste (traditionelles CMS → Contentful)

• Vollständiges URL-Inventar — nicht nur Beiträge: Autor, Tag, paginierte Archive, Parameter-URLs.
• 301-Redirect-Map für jede geänderte URL, vor dem Go-Live erstellt.
• Metadaten (Titel, Beschreibung) migriert und pro URL im neuen Frontend verifiziert.
• Kanonische Tags im neuen Frontend verifiziert.
• Rendering-Modus als SSG/SSR/hybrid bestätigt (kein versehentlicher CSR-Standard).
• Strukturierte Daten aus Inhaltstypen neu aufgebaut und validiert.
• Sitemaps erneut an Google Search Console und Bing Webmaster Tools übermittelt.
• Crawl-Vergleich (Screaming Frog) vor und nach dem Launch durchgeführt.
• URL Inspection als Quelle der Wahrheit dafür verwendet, was Googlebot rendert.

Die mentalen Modelle

1. Contentful ist für Crawler unsichtbar. Suchmaschinen sehen Contentful nie — nur die Ausgabe deines Frontends. Bevor du ein Contentful-SEO-Problem debuggen, beantworte eine Frage: welches HTML liefert das Frontend tatsächlich für diese URL? (View Source / URL Inspection, nicht der Contentful-Eintrag.) Fast alles lässt sich darauf zurückführen.

2. Die Entscheidungsregel für den Rendering-Modus. Wähle danach, wie oft sich der Inhalt ändert und ob du ihn überall indexiert brauchst:

• Größtenteils statisch (Blogs, Doku, Marketing) → SSG (Rebuild oder ISR per Timer).
• Muss immer aktuell sein (Preise, Lagerbestand) → SSR.
• Stündliche/tägliche Änderungen, statische Geschwindigkeit gewünscht → ISR (Achtung vor der Stale-First-Request-Falle).
• Große gemischte Website → hybrid.
• Öffentlicher Inhalt, den du von KI ranken oder zitieren lassen willst → niemals CSR.

3. „Baue neu, was das Plugin getan hat.“ Contentful liefert kein SEO. Jedes WordPress-Plugin-Verhalten ist jetzt ein bewusster Build- Schritt: SEO-Felder im Content-Modell → in den <head> gemappt → Sitemap → robots.txt → Kanonische Tags → strukturierte Daten. Wenn etwas „fehlt“, hat es niemand gebaut.

4. Eine einzige Quelle der Wahrheit für URLs. Kanonische Tags, Sitemap-Einträge, hreflang und interne Links sollten alle aus einer einzigen SITE_URL und dem Routing des Frameworks abgeleitet werden — nicht aus Slugs, die über die CMS-, Framework- und Komponenten-Ebenen hinweg von Hand zusammengesetzt werden. Eine Quelle der Wahrheit beendet die kanonische Fragmentierung.

5. robots.txt ist beratend; noindex ist die Kontrolle. Um Preview/Staging aus dem Index herauszuhalten, verwende einen Host-Level-noindex-Header und/oder Authentifizierung — niemals nur robots.txt, weil verlinkte URLs ohne gecrawlt zu werden indexiert werden. Um eine echte Seite zu entfernen, erlaube Crawling und liefere noindex aus.

Contentful-SEO — Spickzettel

Rendering-Modi auf einen Blick

Wer baut was

Empfohlene SEO-Inhaltsfelder

seoTitle (Pflicht, ~60) · seoDescription (100–150) · canonicalUrl (optional) · noindex (boolesch → meta robots + Sitemap-Ausschluss) · nofollow (optional) · ogImage · ogTitle/ogDescription (optional)

Schnelle Regeln

• Contentful rendert kein HTML – das Frontend entscheidet über das gesamte SEO.
• Nie .js / .css in robots.txt disallowen.
• Kanonische URLs: absolute URLs von einer SITE_URL, serverseitig gerendert; inklusive selbstreferenzierender kanonischer URLs.
• Preview/Staging: Host-Level X-Robots-Tag: noindex + Authentifizierung, nicht nur robots.txt.
• Sitemap: Delivery API abfragen, paginiert, noindex/kanonisierte Einträge ausschließen.
• 301 leitet Equity weiter, 302 nicht – keine JS-Redirects.
• Nur CSR = Bing-SEO-Fehler + für die meisten KI-Crawler unsichtbar.
• Dynamisches Rendering ist veraltet – verwenden Sie SSR / statisches Rendering / Hydration.

Veröffentlichte Routen mit ihrer Live-Ausgabe vergleichen

Exportieren Sie repräsentative veröffentlichte URLs aus dem Frontend-Routeninventar in urls.txt. Dies erfasst den crawler-sichtbaren Status, Titel und die kanonische URL:

while IFS= read -r url; do
  html=$(mktemp)
  status=$(curl -sSL -o "$html" -w '%{http_code}' "$url")
  title=$(grep -Eio '<title>[^<]*</title>' "$html" | head -1)
  canonical=$(grep -Eio '<link[^>]+rel=["'"']canonical["'"'][^>]*>' "$html" | head -1)
  printf '%s\t%s\t%s\t%s\n' "$status" "$url" "$title" "$canonical"
  rm -f "$html"
done < urls.txt

Führen Sie dieselbe Stichprobe nach Änderungen am Content-Modell, Rendering oder Migration aus und vergleichen Sie die Ausgaben. Fragen Sie die Preview-API nicht aus einem öffentlichen oder gemeinsamen Skript ab.

Tools für ein Contentful-Frontend

• Render Gap Analyzer – erkennt Contentful-Felder oder Links, die erst nach clientseitiger Ausführung erscheinen.
• Staging vs. Production SEO Diff – vergleicht Releases auf Metadaten, Direktiven, kanonische URLs und strukturierte Daten.
• Sitemap Validator – verifiziert, dass Veröffentlichungs- und Routenstatus das beabsichtigte Sitemap-Inventar erzeugen.
• Schema Validator – testet JSON-LD, das aus Content-Modell-Feldern zusammengesetzt wird.
• Redirect Chain Mapper – validiert Migrations- und Slug-Änderungs-Redirect-Maps.

Ressourcen, die Ihre Zeit wert sind

Meine verwandten Artikel

• JavaScript SEO Issues & Best Practices – meine primäre Referenz zu Rendering-Modi, Googlebot-Verhalten, CSR vs. SSR und JS-Kanonischen; direkt auf jedes Contentful-Frontend anwendbar.
• React SEO – React-spezifische Muster, die in Contentful + Next.js-Stacks üblich sind.
• Canonicalization – relevant, weil Headless-CMS (einschließlich Contentful) so oft Probleme mit kanonischen Tags verursachen.
• Core Web Vitals – Ihre Framework- und Host-Wahl, nicht die Contentful-API, bestimmen die CWV.

Meine Vorträge

• How Search Works (SlideShare) – meine Erläuterung von Crawling, Rendering, Indexierung und Ranking – die Pipeline, die ein Contentful-Frontend erfüllen muss. (Ständiger Hinweis: Dies ist mein Verständnis dieser Systeme, nicht garantiert 100 % vollständig oder korrekt.)

Auf dieser Website

• Headless CMS SEO – das übergeordnete Thema; Contentful-SEO ist eine spezialisierte Anwendung davon.
• JavaScript SEO – die Rendering-Grundlagen, die dem Ganzen zugrunde liegen.

Aus der Branche

• Der Contentful-SEO-Leitfaden (Contentful) — Contentfuls eigener mehrteiliger Leitfaden; beginnen Sie hier für plattformaktuelle Verhaltensweisen, lesen Sie ihn jedoch als Build-Anleitung, nicht als Feature-Liste.
• Content-Modellierung für SEO (Contentful) — das stärkste Kapitel; spezifisch für Content-Modelle.
• Werden Suchmaschinen meine Inhalte indexieren? Es liegt alles am Rendering (Contentful) — das Argument „Rendering entscheidet über die Indexierung“ direkt von der Plattform.
• Composable URL Redirect (Contentful) — der editorfreundliche Workflow zur Modellierung von Weiterleitungen.
• Contentful SEO: 4 Schlüsselfunktionen (WebStacks) — eine gut strukturierte, unternehmensorientierte unabhängige Einschätzung.
• Headless-CMS-SEO: Vermeiden Sie diese häufigen Fallstricke (Successive Digital) — die wiederkehrenden Fehlermodi, mehrere für Contentful relevant.
• Das beste Headless-CMS für SEO im Jahr 2026 (FocusReactive) — gründlich, wie sich Architekturentscheidungen auf SEO-Ergebnisse auswirken.

Fehler, die ich bei Contentful-Builds immer wieder sehe

Dies sind die wiederkehrenden, konkreten Wege, auf denen Contentful-SEO schiefgeht – keine hypothetischen Risiken, sondern diejenigen, die tatsächlich auftreten, wenn ein Frontend-Team schnell liefert und niemand die gerenderte Ausgabe überprüft.

Eine rohe CSR-Shell als Standard-Frontend ausliefern

Zu einer einfachen React- oder Vue-Single-Page-App zu greifen (ohne SSR-Framework darunter) ist der häufigste Contentful-Fehler, weil es für einen Entwickler, der nur fetch-and-render möchte, der Weg des geringsten Widerstands ist. Warum es falsch ist: Google indexiert CSR langsam und unvorhersehbar, und Bing, Yandex, Baidu und die meisten KI-Crawler rendern das JavaScript möglicherweise überhaupt nicht – sie sehen eine leere Shell. Was stattdessen zu tun ist: Wählen Sie ein Framework, das beim ersten Request echtes HTML ausliefert – Next.js, Astro, Nuxt, Gatsby, SvelteKit – und verwenden Sie SSG oder SSR als Standard, nicht CSR.

robots.txt vertrauen, um die Preview-API zu verbergen

/preview oder eine Staging-Subdomain in robots.txt blockieren und annehmen, dass das ausreicht. Warum es falsch ist: robots.txt ist empfehlend, keine Zugriffskontrolle – wenn diese Staging-URL irgendwo verlinkt ist (eine E-Mail, eine Slack-Nachricht, eine andere Website), kann Google sie indexieren, ohne sie jemals zu crawlen. Was stattdessen zu tun ist: Liefern Sie einen Host-Level- X-Robots-Tag: noindex-Header auf jeder Preview-/Staging-Route (am CDN/Edge, nicht als spät per JS injiziertes Meta-Tag) und/oder sichern Sie die Umgebung hinter einer Authentifizierung.

Selbstreferenzierende Canonicals auf automatisch generierten Seiten vergessen

Ein canonicalUrl-Feld für den seltenen Cross-Site-Fall hinzufügen und dann annehmen, dass Canonical-Tags „erledigt“ sind. Warum es falsch ist: Selbstreferenzierende Canonicals müssen dennoch auf jeder Seite gerendert werden, auch wenn kein benutzerdefiniertes canonicalUrl gesetzt ist – und das wird am häufigsten bei automatisch generierten URLs wie Paginierungs-, Tag- und Filter-Seiten übersehen, was genau dort ist, wo Duplicate-Content-Probleme beginnen. Was stattdessen zu tun ist: Standardmäßig jede Vorlage auf ein selbstreferenzierendes Canonical setzen, das aus einer einzigen SITE_URL aufgebaut ist, und es nur überschreiben, wenn ein echtes Cross-Domain-Canonical benötigt wird.

.js oder .css in robots.txt blockieren

Eine breite Disallow-Regel auf Hosting-Ebene schreiben, die zufällig Asset- Pfade erfasst. Warum es falsch ist: Wenn Googlebot das JavaScript und CSS nicht abrufen kann, das ein Contentful-Frontend zum Rendern benötigt, kann es die fertige Seite überhaupt nicht sehen – das bricht das Rendering vollständig, nicht nur teilweise. Was stattdessen zu tun ist: Grenzen Sie Disallow-Regeln eng auf echte Staging-/Admin-Pfade ein und verifizieren Sie mit einem robots.txt- Tester, dass .js/.css weiterhin abrufbar sind.

SEO-Felder zum Content-Modell hinzufügen und sie nie verdrahten

Modellierung von seoTitle, seoDescription und noindex, damit Redakteure sie ausfüllen können, und dann die Aufgabe als erledigt betrachten. Warum es falsch ist: Diese Felder bewirken allein nichts – bei Headless speichert Contentful nur den Wert, das Frontend muss ihn tatsächlich lesen und in den serverseitig gerenderten <head> einfügen. Ein noindex-Umschalter, der nicht in die Antwort-Header oder das Meta-Robots-Tag eingebunden ist, schützt nichts. Was stattdessen zu tun ist: Überprüfen Sie mit „View Source“ (nicht DevTools), dass jedes SEO-Feld in die anfängliche HTML-Antwort gerendert wird, nicht nur in den CMS-Eintrag.

Verwendung von window.location für Weiterleitungen

Behandlung einer verschobenen Seite mit einer clientseitigen JavaScript-Weiterleitung, weil sie schnell aus einer Frontend-Komponente ausgeliefert werden kann. Warum es falsch ist: JS-Weiterleitungen sind langsamer, geben möglicherweise nicht die Link-Equity weiter wie ein 301, und Nicht-Google-Crawler folgen ihnen häufig überhaupt nicht. Was stattdessen zu tun ist: Echte HTTP-301-Weiterleitungen auf der Server-/Edge-Ebene ausgeben – modellieren Sie Weiterleitungen als Contentful-Einträge oder routen Sie deren Regeln über einen Webhook an einen Weiterleitungsdienst weiter, aber lösen Sie alle Weiterleitungen immer auf, bevor HTML ausgeliefert wird.

Häufige Contentful-SEO-Probleme und wie man sie behebt

Symptomorientierte Suche nach den Problemen, die tatsächlich auf Contentful-Websites auftreten, mit der wahrscheinlichen Ursache und der Lösung, um zu bestätigen, dass sie funktioniert hat.

Staging- oder Vorschauseiten, die bei Google erscheinen

Symptom: Eine Vorschau-/Staging-URL (oft auf einer Subdomain wie preview.example.com) erscheint in den Google-Suchergebnissen oder in der Indexabdeckung der Search Console. Wahrscheinliche Ursache: Die Umgebung verlässt sich allein auf robots.txt, und die URL wurde irgendwo verlinkt, wo Google sie entdecken konnte, ohne sie zu crawlen. Lösung: Fügen Sie einen Host-Level-X-Robots-Tag: noindex-Header auf jeder Vorschau-Route hinzu und/oder schützen Sie die Umgebung mit einer Authentifizierung. Bestätigen Sie mit curl -I gegen die Vorschau-URL – Sie sollten den Header in der Antwort sehen – und beobachten Sie die Search Console, ob die URL in den folgenden Tagen verschwindet.

Seiten werden korrekt veröffentlicht, scheinen aber nie indexiert zu werden

Symptom: Der Inhalt ist in Contentful veröffentlicht, die URL wird aufgelöst, aber die Search Console zeigt über einen längeren Zeitraum „Entdeckt – derzeit nicht indexiert“ an, oder die Seite erscheint einfach nie in der Suche. Wahrscheinliche Ursache: Das Frontend rendert clientseitig (CSR) – Googlebot muss die Seite für einen zweiten Crawl-Durchlauf mit JavaScript-Ausführung in die Warteschlange stellen, und diese Warteschlange ist langsam und nicht garantiert. Lösung: Überprüfen Sie mit „View Source“, was tatsächlich bei der ersten Anfrage ausgeliefert wird, oder führen Sie die URL durch mein Render Gap-Tool, um das rohe HTML mit dem gerenderten DOM zu vergleichen. Wenn der SEO-Inhalt im rohen HTML fehlt, stellen Sie diese Route auf SSR oder SSG um. Bestätigen Sie mit dem Tab „Gecrawlte Seite anzeigen“ der URL-Inspektion nach einem erneuten Crawl.

Duplicate-Content-Warnungen auf Paginierungs-, Tag- oder Filterseiten

Symptom: Die Search Console meldet „Duplikat, Google hat ein anderes kanonisches Element als der Benutzer gewählt“ auf automatisch generierten Contentful-Seiten – paginierte Archive, Tag-Seiten, gefilterte Auflistungen. Wahrscheinliche Ursache: Diese Vorlagen haben nie ein selbstreferenzierendes kanonisches Element erhalten, weil das Feld canonicalUrl leer ist und niemand es standardmäßig setzt. Lösung: Überprüfen Sie das gerenderte kanonische Element auf einigen betroffenen URLs mit dem Canonical Checker, und setzen Sie dann standardmäßig für jede Vorlage ein selbstreferenzierendes kanonisches Element, das aus einer SITE_URL aufgebaut ist. Überprüfen Sie dieselben URLs nach dem Deployment erneut, um zu bestätigen, dass das Tag jetzt auf sich selbst zeigt.

Sitemap enthält fehlende Einträge oder Seiten, die nicht dort sein sollten

Symptom: Die Anzahl der Einträge in der Sitemap stimmt nicht mit der Anzahl der veröffentlichten Einträge in Contentful überein, oder eine mit noindex versehene Seite erscheint in der Sitemap. Wahrscheinliche Ursache: Die Delivery-API-Abfrage für die Sitemap, durchläuft nicht die skip/limit-Paginierung (wodurch sie stillschweigend abgeschnitten wird), oder sie filtert Einträge mit noindex: true oder einem nicht selbstreferenziellen Canonical nicht heraus. Behebung: Überprüfen Sie das Sitemap-Generierungsskript auf eine Paginierungsschleife und einen Noindex-/Canonical-Filter und vergleichen Sie dann die Anzahl der Sitemap-Einträge mit einer frischen Delivery-API-Abfrage für veröffentlichte Einträge. Reichen Sie die Sitemap erneut in der Search Console und in den Bing Webmaster Tools ein, sobald sie korrekt ist.

Strukturierte Daten hinzugefügt, aber Rich-Suchergebnisse erscheinen nie

Symptom: JSON-LD wurde für einen FAQ-, Artikel- oder Produkt-Inhaltstyp hinzugefügt, aber der Rich-Results-Test zeigt keine berechtigten Elemente, oder Rich-Suchergebnisse erscheinen nie in der SERP. Wahrscheinliche Ursache: Das JSON-LD wird clientseitig nach der Hydration injiziert, anstatt im serverseitig gerenderten HTML, sodass die rohe Antwort, die Google tatsächlich abruft, es nicht enthält – oder eine erforderliche Feldzuordnung vom Inhaltstyp fehlt. Behebung: Zeigen Sie den Quelltext der Seite an (nicht das gerenderte DOM der DevTools), um zu bestätigen, dass der <script type="application/ld+json">-Block in der ersten Antwort vorhanden ist, und validieren Sie ihn dann mit dem Schema-Validator oder dem Rich-Results-Test von Google. Testen Sie nach jeder Korrektur erneut – Rich-Suchergebnisse können Tage bis Wochen brauchen, um zu erscheinen, selbst wenn das Markup gültig ist.

Welchen Rendering-Modus sollte diese Contentful-Route verwenden?

Rendering ist die einzige Entscheidung, die bestimmt, ob Suchmaschinen und KI-Crawler Ihre Inhalte jemals sehen. Gehen Sie dies für jede Route oder Vorlage durch – verschiedene Abschnitte derselben Contentful-Site landen oft bei unterschiedlichen Antworten.

Zu Contentful migriert und der Traffic ist eingebrochen – die nächsten Schritte

Ein Schritt-für-Schritt-Runbook für den häufigsten Contentful-Fehlermodus: Traffic-Einbruch nach einer Migration von einem traditionellen CMS. Arbeiten Sie es der Reihe nach durch – jeder Schritt zeigt entweder auf die Lösung oder sagt Ihnen, wo Sie als Nächstes suchen sollen.

1. Bestätigen Sie, dass der Einbruch tatsächlich mit der Migration zusammenfällt. Öffnen Sie den Leistungsbericht in der Search Console und legen Sie das Traffic-Diagramm über Ihr Go-Live-Datum. Wenn der Einbruch am oder direkt nach dem Start beginnt, fahren Sie mit Schritt 2 fort. Wenn er nicht mit dem Start zusammenfällt, ist dies kein Migrationsproblem – suchen Sie stattdessen nach einem Algorithmus-Update oder einer anderen Ursache.

2. Überprüfen Sie, was tatsächlich als HTML ausgeliefert wird. Zeigen Sie den Quelltext an (oder führen Sie die am stärksten betroffenen URLs durch mein Render-Gap-Tool) auf Ihren Seiten mit dem höchsten Traffic. Wenn die SEO-Inhalte – Titel, Fließtext, Links – im rohen HTML fehlen, ist das neue Frontend standardmäßig auf CSR umgestellt. Beheben Sie den Rendering-Modus auf SSR/SSG, bevor Sie etwas anderes tun, und überprüfen Sie diesen Schritt dann erneut.

3. Überprüfen Sie die Redirect-Zuordnung. Crawlen Sie die alte URL-Liste gegen die neue Site (oder prüfen Sie bekannte stark frequentierte alte URLs einzeln mit dem Redirect-Checker oder dem Redirect-Chain-Mapper). Wenn eine alte URL einen 404 zurückgibt oder mehr als einen Hop durchläuft, bevor sie landet, korrigieren Sie den Redirect-Eintrag – dies ist die häufigste Ursache für einen Migrations-Traffic-Einbruch, insbesondere bei Kategorie-, Tag- und paginierten Archiv-URLs, die jeder vergisst zu inventarisieren.

4. Stellen Sie sicher, dass Metadaten und Canonicals übernommen wurden. Überprüfen Sie stichprobenartig Titel, Beschreibungen und Canonical-Tags auf Ihren wichtigsten Landingpages im Vergleich zu vor der Migration, und verwenden Sie den Canonical-Checker für den Canonical-Teil. Wenn Metadaten fehlen oder Canonicals unerwartet zeigen, korrigieren Sie die Feldzuordnung im Frontend.

5. Bestätigen Sie, dass Sitemaps erneut eingereicht wurden. Überprüfen Sie, ob die neue Sitemap sowohl in der Google Search Console als auch in den Bing Webmaster Tools eingereicht wurde und ob sie die neue URL-Struktur widerspiegelt. Bei einer veralteten Sitemap oder Verweisen auf alte URLs reichen Sie die Sitemap erneut ein.

6. Nutzen Sie die URL Inspection als Quelle der Wahrheit. Für jede URL, die nach den Schritten 2–5 weiterhin Indexierungsprobleme aufweist, prüfen Sie jede betroffene URL mit dem Live-Test der URL Inspection und lesen Sie den Tab „View Crawled Page“ – das ist, was Googlebot tatsächlich gesehen hat, nicht das, was Sie annehmen, dass es gesehen hat.

7. Wenn alles oben in Ordnung ist, geben Sie ihm Zeit. Eine saubere Migration benötigt dennoch, dass Google die Website erneut crawlt und verarbeitet; ein normaler Rückgang nach der Migration kann zwei bis vier Wochen dauern, um sich zu erholen, sobald die technischen Probleme tatsächlich behoben sind. Nehmen Sie in diesem Zeitraum keine weiteren Änderungen vor – Sie verlieren die Fähigkeit zu erkennen, was die Behebung bewirkt hat.

Prompts für die Prüfung eines Contentful-Frontends

Kopierfertige Prompts für die wiederkehrenden Contentful-SEO-Checks. Fügen Sie echte Ausgaben von Ihrer Website ein – diese funktionieren nur so gut wie die Eingaben, die Sie ihnen geben.

1. Prüfen Sie, was tatsächlich in der rohen HTML-Antwort steht

Fügen Sie die View-Source-Ausgabe (nicht das in DevTools gerenderte DOM) einer Contentful-Seite ein:

Here is the raw HTML source (View Source, not the rendered DOM) of a page built on
Contentful:

[paste HTML here]

Check whether the following are present directly in this raw HTML, not injected
later by JavaScript: a <title> tag, a meta description, a self-referencing
canonical tag, and any JSON-LD structured data. List what's present and what's
missing.

Erwarten Sie eine einfache Liste, welche SEO-Elemente tatsächlich im HTML der ersten Anfrage vorhanden sind versus fehlend – alles, was hier fehlt, erreicht Google, Bing oder KI-Crawler nicht zuverlässig.

2. Finden Sie Lücken in Ihrem SEO-Inhaltsmodell

Fügen Sie Ihre Contentful-Feldliste des Inhaltstyps ein:

Here are the fields on my Contentful content type(s):

[paste field names + types, e.g. "title (Short text), body (Rich text), slug
(Short text)..."]

Compare this against a standard SEO field set: seoTitle, seoDescription,
canonicalUrl, noindex (boolean), nofollow (boolean), ogImage, ogTitle,
ogDescription. Which are missing, and what Contentful field type/validation would
you use for each one?

Erwarten Sie eine Lückenliste, die auf die bereits vorhandenen Felder abgebildet ist, mit vorgeschlagenen Feldtypen – ein Ausgangspunkt für eine Änderung des Inhaltsmodells, nicht etwas, das ohne Überprüfung veröffentlicht werden sollte.

3. Überprüfen Sie eine robots.txt auf Contentful-spezifische Fehler

Fügen Sie Ihre robots.txt-Datei ein:

Here is my robots.txt file, served at the hosting layer for a Contentful-powered
site:

[paste robots.txt contents]

Check specifically for two mistakes: (1) does any rule block .js or .css paths
that a rendering framework needs, and (2) does it correctly separate rules for a
preview/staging host from the production host? Flag anything that looks wrong.

Erwarten Sie eine kurze Liste aller Disallow-Regeln, die das Rendering blockieren könnten, und ob die Trennung von Vorschau/Produktion korrekt aussieht – behandeln Sie dies als ersten Durchgang und bestätigen Sie es dann mit einem Live-robots.txt-Tester.

Testen Sie sich selbst: Contentful-SEO

Fünf kurze Fragen zur Durchführung von SEO mit dem Contentful-Headless-CMS. Wählen Sie für jede eine Antwort und überprüfen Sie dann.

Änderungsprotokoll