Prüfen Sie Ihre Headless-CMS-Website dort, wo SEO wirklich entsteht.

Ist ein Headless-CMS gut oder schlecht für SEO?

Ihr Headless-CMS ist weder gut noch schlecht für die SEO, denn entscheidend ist Ihr Frontend. Rendern Sie HTML auf Ihrem Server, hilft Ihnen das. Liefern Sie eine rein clientseitige Anwendung aus, schadet es. Öffnen Sie den Quellcode einer Ihrer Artikel-URLs und suchen Sie nach Ihrem Titel, Ihrem kanonischen Link und Ihrem Fließtext. Sind diese vorhanden, erfasst Ihr Crawler sie. Sehen Sie stattdessen ein leeres `div`-Element und ein Skript-Bundle, bekommt der Crawler nichts, bis er Ihre Seite rendert (und das ist ein großes „bis“).

„Headless“ ist nicht automatisch besser für Ihre SEO. Canonical-Tags, Metadaten, strukturierte Daten, interne Verlinkung und Rendering-Strategie liegen jetzt in dem Code, den Ihr Team schreibt und pflegt. Client-gerenderte Websites ohne spezielles technisches SEO-Personal weisen in der Regel weniger indexierte Seiten auf, prüfen Sie also, ob das auf Sie zutrifft. Womöglich bemerken Sie die Einbußen erst, wenn Ihre Rankings sinken, und dann beheben Sie bereits alten Schaden. Die Bewertung erfasst, was Ihre Seiten tatsächlich ausliefern, und zeigt damit, auf welcher Seite der Grenze Ihre Website steht.

Wo ist SEO in einem Headless- oder Jamstack-Stack angesiedelt?

Ihre SEO findet im Frontend statt, nicht in Ihrem CMS. Das CMS hält strukturierte Inhalte vor und stellt sie über eine API bereit. Für Rendering, Routing und alles, was ein Crawler von Ihren Seiten ausliest, ist der Code zuständig, den Sie mit Next.js, Astro oder Remix ausliefern. Wählen Sie eine Seite aus und verfolgen Sie ihren Titel zurück: Suchen Sie das SEO-Titel-Feld in Ihrem CMS, dann die Zeile in Ihrer Vorlage, die es ausgibt. Finden Sie diese Zeile nicht? Dann ist das Feld reine Dekoration.

Achten Sie besonders auf die Schnittstelle zwischen Ihrer API und Ihrer Darstellung. Dort entstehen die meisten Probleme bei Headless-SEO. Vielleicht gibt es ein Feld, das Ihre Vorlage nie verwendet. Oder Ihr Frontend gibt einen kanonischen Link aus und ignoriert die Überschreibung durch Ihren Editor. Für die Standardeinstellungen auf Vorlagenebene fühlt sich in der Regel niemand verantwortlich: Ihr CMS rendert nicht mehr, und Ihr Frontend-Team geht davon aus, dass das CMS die SEO-Optimierung übernimmt. Ihre Entwickler müssen deshalb Metadaten, Sitemaps, strukturierte Daten und die interne Verlinkung neu erstellen, die ein herkömmliches CMS über seine Benutzeroberfläche für Sie erledigt hätte (eine Aufgabe, die niemand in die Roadmap aufgenommen hat).

Wie entscheidet das Rendering im Frontend, was Crawler erhalten?

Ihre Rendering-Strategie entscheidet, was ein Crawler von Ihrer Website erhält: fertiges HTML oder eine leere Hülle, die erst JavaScript füllen muss. Rufen Sie Ihre Seite mit deaktiviertem JavaScript auf. Suchen Sie dann in der Antwort nach Ihrer Überschrift und Ihrem Fließtext, aber auch nach Navigationslinks, Meta-Beschreibung und Canonical-Tag. Fehlt eines davon, wetten Sie darauf, dass jeder Crawler Ihr JavaScript korrekt ausführt (was an manchen Tagen nicht der Fall sein wird). Diese Wette geht selten unbemerkt schief.

Google verarbeitet Ihre JavaScript-Webanwendung in drei Phasen: Crawling, Rendering und Indizierung. Liegen Ihre Inhalte erst nach dem Rendering vor, hängen Sie von der mittleren Phase ab, und über genau die haben Sie am wenigsten Kontrolle. Sie stützen sich also auf den Teil der Pipeline, den Sie nicht steuern können. Prüfen Sie, ob Ihre Vorlagen Sie in diese Lage bringen.

Zwei Details in Ihrer Vorlage sind entscheidend, und beide lassen sich prüfen. Google nennt HTML den besten Ort für Ihren kanonischen Link, und der kanonische Link, den Ihr JavaScript setzt, muss zu dem in Ihrem ursprünglichen HTML passen. Enthält Ihre Seite ein „noindex“-Tag, überspringt Google womöglich das Rendern ganz. JavaScript, das das Tag entfernt, kommt dann vielleicht gar nicht erst zum Zug. Dynamisches Rendern ist, falls Sie es einsetzen, nur eine Notlösung, kein Konzept. Für Ihre Seiten empfiehlt Google serverseitiges Rendern, statisches Rendern oder clientseitiges Rendern mit Hydration. Verlassen Sie sich aber nicht darauf, was andere über Ihre Methode sagen. Lesen Sie Ihren eigenen Quellcode, dann wissen Sie, welche Sie tatsächlich verwenden.

Warum laufen Canonicals und Slugs zwischen CMS und Website auseinander?

Ihre Canonical-Tags und Slugs weichen voneinander ab, weil Ihr CMS einen Wert speichert, Ihre Route einen anderen erzeugt und nichts in Ihrem Stack beide miteinander vergleicht. Sehen Sie sich den Canonical-Tag im Quellcode von drei Produktseiten an. Verweisen alle drei auf dieselbe URL, ist sie in Ihrer Vorlage fest codiert oder wird vererbt. Auch Ihre Redakteure verlieren Steuerungsmöglichkeiten, die sie bisher hatten. In einem herkömmlichen CMS konnten Sie Canonicals, Weiterleitungen, Meta-Beschreibungen und Schema-Angaben ändern, ohne eine Supportanfrage zu stellen. Ihre Headless-Konfiguration hat diese eingebauten Kontrollen womöglich stillschweigend entfernt.

Eine Überschreibung in Ihrem CMS wirkt nur, wenn Ihre Vorlage sie berücksichtigt. Das Kursmodell von Sanity sieht ein optionales SEO-Objekt vor: Ein SEO-Titel überschreibt, sofern angegeben, das Feld „Seitentitel“, und „generateMetadata“ von Next.js gibt ihn aus. Lassen Sie diesen Schritt weg, haben Sie ein Feld ohne Funktion. Suchen Sie in Ihrer Vorlage nach diesem Aufruf, bevor Sie sich auf das Feld verlassen. Auch Ihre Sitemap ist nicht auf dem neuesten Stand. Generieren Sie sie zum Zeitpunkt der Bereitstellung, fehlen Artikel, die Sie vor einer Stunde geändert haben. Prüfen Sie, wann Ihre Sitemap erstellt wurde.

Bei welchen Headless-Konfigurationen gelangen Vorschau- und Staging-URLs in den Index?

Sie geben diese Informationen preis, wenn Ihre Vorschau- oder Staging-Umgebung auf einem öffentlichen Host liegt, ohne „noindex“-Header und ohne Anmeldung. Eine Staging-Subdomain auf einer eigenen Domain ist der klarste Fall; prüfen Sie daher zuerst Ihre. Rufen Sie Ihre Staging-URL auf und suchen Sie in den Antwort-Headern nach „X-Robots-Tag: noindex“. Vercel-Vorschau-Deployments senden diesen Header standardmäßig. Weisen Sie Ihrem Nicht-Produktions-Zweig jedoch eine eigene Domain wie „staging.example.com“ zu, lässt Vercel ihn weg (leicht zu übersehen). Dann müssen Sie ihn selbst setzen.

„Noindex“ ist eine Anweisung, keine Sperre. Wer Ihre URL kennt, kann Ihre Vorschau weiterhin aufrufen. Soll vor dem Laden der Seite eine Anmeldung stehen, brauchen Sie „Deployment Protection“ von Vercel. Für die Vorschau-URLs Ihres Headless-CMS gilt dasselbe: Setzen Sie ein „noindex“-Meta-Tag oder verlangen Sie einen Autorisierungs-Header, damit Ihre Entwürfe nicht als veröffentlichte Seiten im Index landen. Verlassen Sie sich nicht auf „robots.txt“. Google muss Ihre Seite crawlen, um „noindex“ zu erkennen, und unterstützt „noindex“ in der „robots.txt“ nicht; die Datei allein schützt Sie also nicht.

Wie prüfen Sie eine Headless-Website von außen?

Sie prüfen Ihre Headless-Website von außen, indem Sie auswerten, was sie ausgibt, denn nur die ausgegebene Seite liest ein Crawler. Starten Sie die kostenlose Bewertung mit Ihrer Startseite, dann werden bis zu acht weitere Ihrer Seiten untersucht. Ausgewertet werden Antwort-Header, Markup, strukturierte Daten, Überschriften, die Größe von Skripten und Bildern sowie Robots- und Canonical-Signale. Das Ergebnis: eine Punktzahl von 0 bis 100 für Ihre Website, mit Belegen für jede der acht gewichteten Säulen.

Die Bewertung dauert etwa zwei Minuten und kostet nichts. Sie geben eine geschäftliche E-Mail-Adresse ein, erhalten einmalig einen Link zu Ihrem Bericht und können pro Verbindung drei Überprüfungen pro Stunde durchführen. Die Auswertung hat jedoch Grenzen. Das Tool meldet sich nicht auf Ihrer Website an, liest keine Analysedaten aus, zieht keine Leistungsdaten vor Ort heran und befragt Ihr Team nicht. Sie erhalten also einen Bericht über Ihre Seiten, nicht über die Prozesse hinter Ihrer Website. Prüfen können Sie aber, ob jede untersuchte Seite einen eigenen kanonischen Link, eine Meta-Beschreibung, ein Schema und einen vom Server gerenderten Textkörper hat. Vergleichen Sie jede Seite mit Ihren Vorlagen.

Fragen und Antworten.

Weiterlesen.

1. 01Next.js-SEO-AuditRendering-Modus, Metadaten, Hydration-Kosten.
2. 02Astro-SEO-CheckIslands, Content Collections, strukturierte Daten, Web Vitals.
3. 03Website wiederherstellenAusgefallen, gehackt oder defekt: was bleibt und was neu gebaut wird.