Headless und Sichtbarkeit — was das SEO-Plugin nicht mehr macht.

Der Grundsatz.

Für Suchmaschinen ist es gleichgültig, womit eine Seite gebaut wurde. Was zählt, ist das ausgelieferte Dokument: Gibt es einen sinnvollen Titel, eine Beschreibung, eine saubere Überschriftenstruktur, erreichbare Links und lesbaren Inhalt?

Headless ist also weder gut noch schlecht fürs Ranking. Es verschiebt nur die Zuständigkeit: Was früher ein Plugin automatisch erledigt hat, muss jetzt jemand bauen. Wird das vergessen, fehlt es — und zwar vollständig, nicht teilweise.

Titel und Beschreibungen.

Die Redaktion pflegt sie weiterhin im SEO-Plugin in WordPress — die Felder bleiben ja. Nur ausgegeben werden sie nicht mehr automatisch.

Zwei Schritte: Die Felder müssen über die Schnittstelle herausgegeben werden, und das Frontend muss sie je Seite setzen. Für die verbreiteten SEO-Plugins gibt es Erweiterungen, die genau das tun — prüfe vor der Technikentscheidung, ob dein Plugin die gewählte Schnittstelle bedient (REST oder GraphQL).

Dazu gehören auch die Angaben für die Vorschau beim Teilen in sozialen Netzwerken. Die fallen sonst ersatzlos weg, und geteilte Links sehen danach nackt aus.

Canonical.

Die Angabe, welche Adresse die maßgebliche ist. Klassisch setzt das Plugin sie automatisch. Im Frontend muss sie je Seite erzeugt werden — und zwar mit der öffentlichen Adresse, nicht mit der des Redaktionssystems.

Das ist ein Fehler, den ich regelmäßig sehe: Die Angabe wird direkt aus WordPress übernommen und zeigt dann auf die interne Adresse. Damit verweist jede Seite auf ein Dokument, das Besucher nie sehen sollen.

Zwei Adressen.

Der folgenschwerste Fehler überhaupt. WordPress läuft unter einer eigenen Adresse, und wenn die erreichbar und indexierbar ist, existiert die Website zweimal: einmal als Frontend, einmal als klassische WordPress-Ausgabe.

Gegenmittel, am besten mehrere gleichzeitig:

• Zugang beschränken — Passwortschutz auf Serverebene oder Beschränkung auf bestimmte Adressen.
• Indexierung sperren über die entsprechenden Angaben.
• Das Theme abschalten oder auf eine leere Seite umleiten.
• Keine Links von der öffentlichen Seite auf die interne Adresse.

Prüfe nach dem Start, ob die interne Adresse im Index auftaucht — eine Suche nach ihr genügt. Taucht sie auf, gehört sie entfernt und gesperrt (Indexierung steuern).

Ausgabe ohne JavaScript.

Suchmaschinen können JavaScript verarbeiten, tun es aber verzögert und nicht immer vollständig. Eine Seite, deren Inhalt erst im Browser nachgeladen wird, läuft Gefahr, unvollständig erfasst zu werden.

Deshalb gilt: Der inhaltliche Kern gehört ins ausgelieferte Dokument. Das ist bei statisch erzeugten oder serverseitig gebauten Seiten automatisch der Fall — eben deshalb sind diese Bauweisen die richtige Wahl. Nur im Browser aufgebaute Seiten sind für öffentliche Inhalte die falsche.

Prüfen lässt sich das einfach: Seitenquelltext anzeigen und nachsehen, ob der Text dort steht. Steht dort nur ein leeres Gerüst, hast du ein Problem (Rendering-Arten).

Sitemap.

Klassisch vom Plugin erzeugt, im Frontend eine eigene Aufgabe. Sie muss alle öffentlichen Adressen enthalten, sich bei neuen Inhalten aktualisieren und das Änderungsdatum mitführen.

Bei vielen tausend Seiten kommt dazu, dass eine Sitemap begrenzt ist und in mehrere aufgeteilt werden muss, verbunden über eine Übersichtsdatei. Das ist kein großer Aufwand, wird aber gern übersehen, bis die Datei zu groß wird.

Achte darauf, dass die Sitemap nur die öffentlichen Adressen enthält — nicht die interne WordPress-Adresse und keine Seiten, die auf nicht indexieren stehen.

robots.txt.

Muss das Frontend ausliefern, mit Verweis auf die Sitemap. Und die interne WordPress-Adresse braucht eine eigene, die alles sperrt.

Ein Hinweis aus der Praxis: Viele Frontend-Projekte starten mit einer Sperre für alles, damit die Testfassung nicht in den Index gerät. Diese Sperre nach dem Start zu entfernen, wird vergessen — und dann wundert man sich wochenlang, warum nichts indexiert wird. Das ist einer der häufigsten teuren Fehler bei Umstellungen überhaupt (Nicht bei Google).

Strukturierte Daten.

Angaben, die Suchmaschinen den Inhalt maschinenlesbar beschreiben — Artikel, Produkt, Veranstaltung, Unternehmen, Brotkrumenpfad, häufige Fragen. Klassisch erzeugt sie das SEO-Plugin oder das Theme.

Im Frontend wird das selbst gebaut, und das hat einen Vorteil: Man kann es genauer machen als ein allgemeines Plugin, weil man die eigenen Datenfelder kennt. Bei einem Produktkatalog oder einem Veranstaltungskalender lohnt sich das spürbar.

Wichtig ist, dass die Angaben zum sichtbaren Inhalt passen. Strukturierte Daten, die etwas anderes behaupten als die Seite zeigt, sind ein Verstoß gegen die Richtlinien.

Weiterleitungen.

Der Punkt mit dem größten Schadenspotenzial bei einer Umstellung. Weiterleitungs-Plugins arbeiten in WordPress und werden nicht mehr ausgeführt — alle bestehenden Regeln sind weg, sofern sie nicht übernommen werden.

1. Bestehende Regeln exportieren, bevor irgendetwas umgestellt wird.
2. Vollständige Adressliste ziehen aus Sitemap, Serverprotokollen und der Search Console.
3. Abgleichen, welche Adressen sich ändern.
4. Regeln im Frontend anlegen, dauerhaft weiterleitend.
5. Nach dem Start prüfen, ob alte Adressen ankommen.
6. Fehlerseiten beobachten in den Wochen danach.

Punkt zwei ist die eigentliche Arbeit. Serverprotokolle zeigen Adressen, die in keiner Sitemap stehen und trotzdem aufgerufen werden — alte Kampagnenseiten, verlinkte PDF-Dateien, Bilder (Umstellung).

Mehrsprachigkeit.

Die Angaben, welche Sprachfassung zu welcher gehört, kommen klassisch vom Übersetzungs-Plugin. Im Frontend müssen sie erzeugt werden — vollständig und wechselseitig, einschließlich eines Verweises auf die Standardfassung.

Dazu kommt die Adressstruktur je Sprache und ein Sprachumschalter, der auf die entsprechende Seite führt statt auf die Startseite. Letzteres ist eine Kleinigkeit mit spürbarer Wirkung (Mehrsprachigkeit).

Wo headless hilft.

Damit es nicht nur nach Mehrarbeit klingt — es gibt auch Gewinne:

• Tempo als schwacher Rankingfaktor, vor allem aber für das Nutzerverhalten (Core Web Vitals).
• Sauberes HTML ohne das Gewicht von zwanzig Plugins.
• Volle Kontrolle über jede Angabe im Kopfbereich.
• Genauere strukturierte Daten, weil man die eigenen Felder kennt.
• Keine Plugin-Überraschungen, die nach einem Update plötzlich etwas anders ausgeben.

Der letzte Punkt ist unterschätzt: Wer schon einmal nach einem Plugin-Update plötzlich geänderte Titel auf allen Seiten hatte, weiß den Wert von Kontrolle zu schätzen.

Vor dem Start prüfen.

1. Quelltext ansehen: Steht der Inhalt drin, ohne JavaScript?
2. Titel und Beschreibung auf mehreren Seitentypen stichprobenartig prüfen.
3. Canonical auf die öffentliche Adresse geprüft?
4. Sitemap erreichbar, vollständig, ohne interne Adressen?
5. robots.txt freigegeben, nicht mehr gesperrt?
6. Interne WordPress-Adresse gesperrt und nicht indexiert?
7. Weiterleitungen mit einer Stichprobe alter Adressen testen.
8. Strukturierte Daten mit einem Prüfwerkzeug gegenlesen.
9. Nach dem Start die Search Console wochenlang beobachten.

Punkt fünf ist der, der am häufigsten schiefgeht, und der mit der größten Wirkung. Setz dir dafür eine Erinnerung auf den Tag nach dem Start.

Wenn du weiterkommen willst.

Wenn du umstellen willst, ohne dabei Sichtbarkeit zu verlieren. Ich schaue mir an, was du vorhast, und sage dir, ob headless passt — und wenn nicht, was stattdessen: Headless WordPress. Geht es nur um Tempo, ist oft Ladezeitarbeit an der bestehenden Seite der günstigere Weg.

Orientierungswerte, keine Fixpreise — nach einem kurzen Gespräch bekommst du ein Festpreisangebot.

Wer hilft.

Ich bin Manuel Killert, Webentwickler aus Quakenbrück. Ich arbeite seit Jahren mit WordPress und baue daneben eigene Plattformen mit Next.js — Lernplattformen mit mehreren tausend Seiten, bei denen WordPress als Redaktionssystem im Hintergrund läuft und das Frontend davon getrennt ist. Das ist also keine Theorie, sondern das, womit ich meine eigenen Projekte betreibe.

Genau deshalb sage ich auch offen, wann es sich nicht lohnt. Headless ist aufwendiger im Bau und im Betrieb, und für eine normale Unternehmenswebsite ist es fast immer die falsche Antwort. Wer mir schreibt und eine fünfzehnseitige Firmenwebsite headless bauen lassen will, bekommt von mir eine Rückfrage und keinen Kostenvoranschlag.

Was ich nicht mache: große Teams begleiten oder bestehende Frontends in anderen Frameworks übernehmen. Mein Feld ist WordPress als Redaktionssystem plus ein Frontend in Next.js — überschaubar im Umfang, von einer Person wartbar.