„Wenn unsere Inhalte in einer API liegen, sieht Google sie dann überhaupt?“ Diese Frage stellt jedes Team, bevor es auf Headless umsteigt. Meist kommt sie von jemandem, der 2019 zugesehen hat, wie eine clientseitig gerenderte React-App einem Crawler ein leeres <div> auslieferte. Die Sorge ist veraltet, aber hinter der Frage steckt eine berechtigte: Mit Headless wandert die Verantwortung für SEO vom CMS zu dir. Hier steht, was jetzt alles bei dir liegt.
Die kurze Antwort
Suchmaschinen ranken HTML, das unter URLs auf deiner Domain ausgeliefert wird. Ob dieses HTML aus einer Datenbank, einer API oder Markdown-Dateien zusammengesetzt wurde, wissen sie nicht, und es ist ihnen egal. Ein Headless-Setup mit serverseitigem Rendering liefert genau dieselbe crawlbare Ausgabe wie ein klassisches CMS, oft sogar eine bessere, weil du jedes Byte der Seite selbst bestimmst.
Der Haken steckt in der Bedingung: mit serverseitigem Rendering. Stimmt das Rendering-Modell, ist der Rest gewöhnliches technisches SEO.
Rendering: die eine Entscheidung, auf die es ankommt
Es gibt drei Wege, aus API-Inhalten Seiten zu machen:
Clientseitiges Rendering (CSR): Der Browser lädt JSON und baut die Seite mit JavaScript auf. Google kann JavaScript ausführen, rendert aber zeitversetzt, und bei anderen Crawlern, Link-Vorschauen und Social-Media-Scrapern sieht es je nach Dienst anders aus. Für Inhalte, die ranken sollen, ist CSR die riskante Wahl.
Serverseitiges Rendering (SSR): Dein Server holt die Inhalte bei jeder Anfrage aus der Content-API und gibt fertiges HTML zurück. Immer crawlbar, immer aktuell; der Preis ist ein Abruf pro Anfrage (den du nach Bedarf cachst).
Statische Generierung (SSG): Die Seiten werden vorab gebaut und als Dateien ausgeliefert. Schneller geht die Auslieferung nicht; dafür braucht jede Änderung am Inhalt einen neuen Build oder eine Revalidierung.
Jedes moderne Framework (Next.js, Astro, Nuxt, SvelteKit, TanStack Start) sieht SSR oder SSG mit einer Content-API als Standardweg vor: Der API-Aufruf steckt in einem Loader oder läuft zur Build-Zeit. Wenn du aus diesem Beitrag nur eine Regel mitnimmst, dann diese: Öffentliche Inhaltsseiten werden auf dem Server gerendert.
Der Domain-Vorteil, über den kaum jemand spricht
Headless ist oft aus einem strukturellen Grund ein SEO-Gewinn: Die Inhalte landen auf deiner Hauptdomain. Gehostete Blog- und Doku-Plattformen laufen auf Subdomains oder eigenen Domains, und die Autorität, die deine Artikel aufbauen, sammelt sich dort. Mit Headless sind /blog, /help und /changelog Unterverzeichnisse der Domain, auf der dein Produkt läuft. Jeder Backlink auf einen Artikel stärkt dann alle anderen Seiten, die dir gehören. Dieser eine Faktor wiegt meist alle Meta-Tag-Details weiter unten auf.
Die Checkliste, die jetzt bei dir liegt
Ein klassisches CMS erledigt einiges davon im Hintergrund. Headless überlässt es dir. Das richtest du einmal in einer Hilfsfunktion ein, denn alles leitet sich aus denselben API-Antworten ab.
Metadaten pro Seite
Titel, Meta-Description, Open-Graph- und Twitter-Tags, Zeitstempel des Artikels. Pflege sie im CMS als Felder direkt neben dem Inhalt und gib sie im Head des Dokuments aus, aus demselben Abruf, der die Seite rendert. Sieht dein Content-Backend SEO-Felder pro Eintrag vor (Titel, Beschreibung, Bild), ist das eine Zuordnung und kein Projekt.
Kanonische URLs
Jede Seite gibt ihre kanonische URL an, berechnet aus dem Slug des Eintrags und nie aus der Request-URL übernommen. Sonst würden auch Varianten mit ?utm_source= und zufällige Abweichungen in der Groß- und Kleinschreibung kanonisch. Eine einzige Funktion, die einen Eintrag auf seinen Pfad abbildet und die Seiten, Sitemap und Feeds gleichermaßen nutzen, sorgt dafür, dass sich die drei nie widersprechen.
Echte Statuscodes
Ein unbekannter Slug muss HTTP 404 liefern, keine gestaltete Fehlerseite mit Status 200. Soft-404s verschwenden Crawl-Budget und verschmutzen den Index. Genauso gilt: Erreicht deine Server-Route die Content-API nicht, antworte mit einem 5xx und Cache-Control: no-store, statt eine leere 200 in deinem CDN zu cachen.
Sitemap und Feeds
Erzeuge die sitemap.xml aus denselben Listen-Endpunkten, die deine Übersichtsseiten nutzen, mit echtem lastmod aus den Zeitstempeln der Einträge. Ergänze RSS für Blog und Changelog: Feeds kosten wenig, und Leser wie Crawler nutzen sie.
Strukturierte Daten
Gib JSON-LD aus den Eintragsdaten aus (Article für Beiträge, FAQPage, wo es passt, Organization auf der Startseite). Ein Detail beim Einfügen von JSON-LD aus Servercode: Ersetze jedes < im serialisierten JSON durch \\u003c, damit ein verirrtes </script> in einem Titel nicht aus dem Script-Tag ausbrechen kann.
Mit noindex ausschließen, was nicht ranken soll
Suchergebnisseiten, Vorschau-Routen und paginierte Tag-Kombinationen verdienen oft ein noindex. Bietet deine Plattform neben der Auslieferung per API auch ein gehostetes Portal auf einer eigenen Domain, prüf, wie sie dort mit der Indexierung umgeht. Die gehosteten Portalseiten von Kookee stehen absichtlich auf noindex. So tritt in der Suche nur die Version auf deiner eigenen Domain an, und es gibt keine Unklarheit wegen Duplicate Content.
Aktualität und Cache-Disziplin
Mit SSR sind veröffentlichte Änderungen bei der nächsten Anfrage live. Mit SSG legst du pro Inhaltstyp fest, wie veraltet eine Seite sein darf: Ein Blog kann sich mit dem Neubau Zeit lassen, ein Changelog oder eine Seite, die vom aktuellen Status abhängt, braucht eine Revalidierung im Minutenbereich. In beiden Fällen cachst du im CDN mit Absicht: die URL als Cache-Key, sinnvolle TTLs und ein Purge beim Veröffentlichen, wenn deine Plattform Webhooks unterstützt oder du beim Veröffentlichen einen Build auslöst.
Mehrsprachige Inhalte
Bedienst du mehrere Sprachen, bekommst du mit Headless wieder die saubere Variante: Hol die Übersetzungen eines Eintrags aus der API, liefere jede Sprache unter ihrer eigenen URL aus und gib hreflang-Alternativen aus der Liste der Übersetzungen aus. Vor halbherzigen maschinellen Übersetzungen schützt dich Headless nicht. Veröffentliche nur Sprachen, die du auch pflegst.
Ein Test für heute
Nimm deine wichtigste Seite und prüf mit deaktiviertem JavaScript: Steht der vollständige Text im HTML-Quelltext? Passen Titel, Description und Canonical zu genau dieser Seite? Liefert ein unsinniger Slug 404? Ruf die sitemap.xml auf: Steht die Seite dort, mit einem plausiblen lastmod? Das dauert fünfzehn Minuten und deckt 90 % dessen ab, was schiefgeht.
Headless schadet SEO nicht. Nicht gerendertes JavaScript schadet SEO, falsche Statuscodes schaden SEO, und Subdomains von Anbietern kosten still und leise Reichweite. Entscheide dich für Server-Rendering, leite jedes Signal aus den Eintragsdaten ab, die du ohnehin abrufst, und halte die Autorität auf der einzigen Domain, die sie verdienen sollte: deiner.