Warum Traffic nach einer Headless-Migration einbricht, und wie man es stoppt
Client-seitiges Rendering, verlorene Canonicals und ein langsamer Origin. Die drei Wege, wie eine Headless-Migration leise organischen Traffic kostet — und wie Sie jeden schließen.
Ein Headless-CMS hat keine Meinung zu Ihrem HTML. Es gibt Inhalte über eine API zurück; alles, was eine Suchmaschine sieht, wird von Code erzeugt, den Sie geschrieben haben.
Deshalb ist „Ist Headless schlecht für SEO?“ die falsche Frage. Die richtige lautet: Was hat der Rebuild am HTML verändert? In der Praxis ist die Antwort eines von drei Dingen, und alle drei sind behebbar.
#Leck 1 — Inhalt, der erst existiert, nachdem JavaScript läuft
Das häufigste und das teuerste.
Sie sind zu einem Framework mit Server-Rendering gewechselt und haben dann den Artikeltext in einem Client-Effekt abgerufen, weil das Tutorial es so gemacht hat. Jetzt:
Googlebot bekommt beim ersten Durchlauf eine leere Hülle, und das Rendering wird für später eingereiht — manchmal viel später.
Andere Crawler (Bing, KI-Crawler, Social-Preview-Bots) rendern meist überhaupt nicht. Ihre Links entfalten sich leer.
Largest Contentful Paint misst den Inhalt, und Ihr Inhalt kommt einen Roundtrip nach der Hülle an.
Diagnose — ein Befehl, kein Tooling:
0 bedeutet, dass Ihr Inhalt nicht im HTML ist. Alles andere in diesem Artikel ist zweitrangig, bis das 1 zurückgibt.
Fix — auf dem Server abrufen. Im Next.js App Router ist das der Standard; der Fehler ist meist eine 'use client'-Grenze, die zu hoch im Baum platziert ist. Verschieben Sie sie nach unten zur interaktiven Komponente, statt die Seite zu umschließen.
#Leck 2 — Canonical, Meta und strukturierte Daten beim Rebuild verloren
Das alte CMS hatte ein SEO-Plugin, das Canonical-Tags, Meta-Beschreibungen, Open-Graph-Tags und Article-Schema für jede Seite erzeugte. Niemand hat sich ausdrücklich entschieden, das zu entfernen. Es stand nur nicht auf der Rebuild-Checkliste.
Symptome: Duplicate-Content-Cluster (Parameter-URLs, Trailing-Slash-Varianten, paginierte Archive, die alle separat indexiert werden), fehlende Rich Results und Social-Shares, die sich mit dem falschen Titel entfalten.
Fix — machen Sie diese Felder zum Teil des Inhaltsmodells, nicht des Themes. In corpusctl speichert das SEO-Modul Titel, Beschreibung, Canonical und Social-Image pro Eintrag neben dem Inhalt, sodass sie mit dem Eintrag mitreisen, statt in dem zu leben, was ihn rendert.
Dann prüfen Sie sie in der CI. Ein Test, der zehn repräsentative URLs abruft und prüft, dass jede genau ein selbstreferenzierendes Canonical, eine nicht leere Beschreibung unter 155 Zeichen und gültiges JSON-LD hat, kostet eine Stunde und fängt diese Klasse von Regressionen dauerhaft ab.
#Leck 3 — Ein langsamer Origin hinter einem Cache, über den Sie nicht nachgedacht haben
Headless macht die Performance meist besser. Es macht sie schlechter, wenn das Frontend bei jeder Anfrage vom CMS abruft und das CMS eine Datenbankabfrage entfernt ist.
Ihre TTFB ist jetzt die Antwortzeit des CMS plus Ihre Renderzeit, bei jedem Cache-Miss, und jeder Cache-Miss ist ein echter Nutzer, der wartet.
Fix — entscheiden Sie, wo Inhalte zur Anfragezeit leben. Drei Optionen, in aufsteigender Reihenfolge, wie gut sie sich halten:
Pro Anfrage abrufen. Das CMS liegt auf dem kritischen Pfad. In Ordnung für ein Dashboard, falsch für Inhalte, die ranken sollen.
ISR mit einem Zeitfenster. Der Inhalt ist höchstens N Sekunden veraltet; jeder Fensterablauf ist ein Cache-Miss, den jemand bezahlt.
Vorab bauen und aus dem Cache ausliefern. Zur Veröffentlichungszeit gerendert, als statisches Artefakt ausgeliefert. Am schnellsten und günstigsten — sofern die Invalidierung gehandhabt wird.
Der schwierige Teil von Option drei ist die Invalidierung, weil die Seite eine Kopie einer Berechnung ist, die sich jederzeit ändern könnte.
corpusctl beseitigt das Problem, statt es zu verwalten. Das Veröffentlichen schreibt Inhalte in eine unveränderliche, hash-adressierte Datei im Objektspeicher und aktualisiert ein Manifest; der Client löst den Slug lokal zu einem Manifest-Shard auf und ruft dann diese Adresse aus dem nginx-Edge-Cache ab. Die Adresse ist ein Content-Hash, sodass dieselbe Adresse niemals andere Inhalte zurückgeben kann — sie ist dreißig Tage lang cachebar, und das Veröffentlichen schreibt eine neue Adresse. Es gibt nichts zu leeren.
Für die Core Web Vitals ist das direkt relevant: Das Dokument kommt aus einem Cache statt aus einer Berechnung, sodass die TTFB nicht mehr mit der Datenbanklast schwankt und die LCP nicht mehr davon abhängt, ob Sie einen Cache-Treffer hatten.
Wenn Sie mehrere Sprachen betreiben — und ein Headless-CMS wird oft genau deshalb gewählt — ist das das vierte Leck.
Regeln, die leicht zu formulieren und leicht falsch zu machen sind:
Jede Sprachversion verlinkt auf jede andere Version, einschließlich sich selbst.
Es gibt ein x-default, das auf die Version für Besucher ohne Übereinstimmung zeigt.
Die Links sind reziprok. Ein einseitiges hreflang wird vollständig ignoriert.
Sprachcodes sind gültiges BCP 47. Vereinfachtes Chinesisch ist zh-Hans, nicht zh-CN, wenn Sie die Schrift statt der Region meinen.
Die URL in hreflang stimmt mit dem canonical auf der Seite überein, auf die sie zeigt.
Prüfen Sie das nicht von Hand. Rufen Sie jede URL ab und prüfen Sie den vollständigen Satz:
Verwandt: Die sprachverhandelnde Root-URL sollte 302, nicht 301 zurückgeben. Die Antwort variiert je nach Accept-Language, also ist sie nicht permanent; ein 301 wird im Browser gecacht, und die nächste Person an diesem Rechner kann ihre Sprache nicht ändern. Senden Sie Vary: Accept-Language, Cookie mit, sonst liefert ein zwischengeschalteter Cache die Sprache des ersten Besuchers an alle.
Mindestens zwei Wochen nach der Umstellung. Rankings bewegen sich nach ihrem eigenen Zeitplan, und eine dreitägige Panik sagt Ihnen nichts.
Search Console → Abdeckung. Ein Anstieg der 404er bedeutet eine übersehene Weiterleitung. Ein Anstieg von „Gecrawlt – zurzeit nicht indexiert“ bedeutet oft dünne oder doppelte Ausgabe aus einem Template.
Search Console → Leistung, nach Seitentyp segmentiert. Wenn ein Template mehr verloren hat als die anderen, liegt der Fehler in diesem Template, nicht in der Migration.
Server-Logs, nicht nur Search Console. Das Crawl-Log sagt Ihnen, was Googlebot tatsächlich angefordert und was es erhalten hat. Ein 404 dort ist heute kostenlos zu beheben und in einem Monat teuer.
Core-Web-Vitals-Felddaten, nicht Laborwerte. Laborwerte messen Ihren Laptop.
Ein Headless-CMS, das zu Next.js passt, statt gegen es zu kämpfen
Draft-Modus, ISR, der App Router und die Render-Ebene. Was wirklich zählt, wenn Sie ein Headless-CMS an Next.js anbinden — und die drei Wege, wie es schiefgeht.