Headless CMS sind in modernen Webentwicklungsprojekten allgegenwärtig. Contentful, Sanity, Strapi oder Storyblok entkoppeln die Inhaltsverwaltung von der Darstellung. Das bietet echte Chancen – viel Flexibilität und Performance – birgt aber auch Risiken durch neue SEO-Anforderungen, die bei falscher Umsetzung zu erheblichen Sichtbarkeitsverlusten führen können.
Was ist ein Headless CMS?
Ein traditionelles CMS (WordPress, TYPO3, Joomla) koppelt Backend (Inhaltsverwaltung) und Frontend (Darstellung) direkt. Ein Headless CMS liefert nur Inhalte über eine API – wie das Frontend diese Inhalte rendert, ist dem CMS egal.
Das Frontend kann sein:
- Statisch generiert: Gatsby, Astro, Next.js Static Export
- Server-Side Rendering (SSR): Next.js, Nuxt.js
- Client-Side Rendering (CSR): React, Vue ohne SSR
Für SEO ist der Rendering-Ansatz entscheidend.
Das Rendering-Problem: CSR vs. SSR vs. SSG
Googles Crawler kann JavaScript rendern – aber mit Verzögerung. Seiten die ausschließlich client-seitig gerendert werden, können Wochen nach dem Launch noch nicht vollständig indexiert sein.
Client-Side Rendering (CSR) – SEO-Risiko: Der Browser lädt zunächst eine leere HTML-Seite, dann JavaScript, dann werden Inhalte per API geladen und gerendert. Google sieht beim ersten Crawl möglicherweise nur leeres HTML. Das Two-Wave-Indexing kann zu Verzögerungen und schlechterem Ranking führen.
Server-Side Rendering (SSR) – SEO-sicher: Der Server rendert vollständiges HTML für jeden Request. Googlebot erhält sofort den vollständigen Inhalt. Technisch aufwendiger, aber SEO-technisch optimal.
Static Site Generation (SSG) – SEO-optimal: Inhalte werden beim Build-Prozess zu statischen HTML-Dateien gerendert. Maximale Performance und sofortige Indexierbarkeit. Einschränkung: Inhalte sind erst nach dem nächsten Build aktuell.
Für die meisten Headless-Projekte ist SSG mit incremental static regeneration (ISR in Next.js) die beste Lösung: Seiten werden statisch generiert, können aber im Hintergrund aktualisiert werden ohne den gesamten Build neu zu starten.
Meta-Daten in Headless-Architekturen
Bei traditionellen CMS verwaltet ein Plugin (Yoast, Rank Math) Meta-Daten. In headless Architekturen muss das Custom gelöst werden:
CMS-seitige Metadaten-Felder:
Die meisten modernen Headless CMS (Contentful, Sanity) ermöglichen SEO-Felder direkt im Content Model: seoTitle, metaDescription, canonicalUrl.
Framework-seitige Implementierung (Next.js):
// pages/[slug].js
export async function getStaticProps({ params }) {
const page = await fetchPage(params.slug);
return { props: { page } };
}
export default function Page({ page }) {
return (
<>
<Head>
<title>{page.seoTitle || page.title}</title>
<meta name="description" content={page.metaDescription} />
<link rel="canonical" href={`https://domain.de/${page.slug}/`} />
</Head>
{/* Content */}
</>
);
}Sitemaps bei Headless CMS
Statische Sitemaps sind bei headless Architekturen nicht automatisch verfügbar. Optionen:
Build-time Sitemap-Generierung:
Bei SSG-Projekten die Sitemap beim Build-Prozess aus den CMS-Inhalten generieren. next-sitemap ist ein populäres npm-Package für Next.js.
API-basierte Sitemap:
Eine Route (/sitemap.xml) die bei jedem Request live aus dem CMS-API generiert wird. Vorteil: immer aktuell. Nachteil: höhere Server-Last.
CMS-native Sitemaps: Manche Headless CMS (Storyblok, Contentful) bieten Sitemap-Plugins oder APIs an.
Strukturierte Daten in Headless-Projekten
Schema.org-Markup muss explizit implementiert werden:
// Komponente für strukturierte Daten
function ArticleSchema({ article }) {
const schema = {
"@context": "https://schema.org",
"@type": "Article",
"headline": article.title,
"datePublished": article.publishedAt,
"author": { "@type": "Person", "name": article.author }
};
return (
<script
type="application/ld+json"
dangerouslySetInnerHTML={{ __html: JSON.stringify(schema) }}
/>
);
}Headless-Projekte die strukturierte Daten konsequent implementieren, erzielen in 65 % der Fälle Rich Snippets in Google – bei rein client-seitig gerenderten Projekten ohne SSR liegt die Quote unter 20 %.
Häufige SEO-Fehler bei Headless-Projekten
Fehlende Canonicals: Bei dynamischen Routen ohne explizite Canonical-Tags können Duplicate-Content-Probleme entstehen.
Internationalisierung ohne Hreflang: Mehrsprachige Headless-Projekte müssen Hreflang explizit implementieren – es gibt kein Plugin das das automatisch übernimmt.
JavaScript-abhängige Navigation: Wenn die gesamte Navigation JavaScript-abhängig ist und kein statisches HTML-Fallback existiert, kann Googlebot Links nicht crawlen.
Fehlende robots.txt: In headless Projekten muss die robots.txt explizit als statische Datei oder Route bereitgestellt werden.
Mehr zur technischen SEO-Basis finden Sie in unserem Artikel über technisches SEO für JavaScript-Websites.