CMS-Auswahl für SEO: Was wirklich zählt

Wer nach dem richtigen CMS für SEO sucht, bekommt meistens eine Rangliste vorgesetzt: Platz 1 WordPress, Platz 2 dieses System, Platz 3 jenes System. Die ehrliche Antwort ist unbequemer: Bei den allermeisten Websites entscheidet nicht das CMS darüber, ob eine Seite rankt, sondern der Inhalt und die Links, die auf ihn zeigen. Fast jedes verbreitete System – vom klassischen Baukasten bis zum selbst gehosteten Open-Source-CMS – kann gut ranken, wenn die Inhalte stimmen.

Ein Artikel, der Content-Management-Systeme nach „SEO-Freundlichkeit“ sortiert, verkauft in der Regel etwas: eine Migration, eine Agenturleistung oder das eigene Produkt des Autors. Das heißt nicht, dass die Plattform völlig egal ist. Es heißt, dass die Unterschiede kleiner und anders gelagert sind, als Ranglisten suggerieren – und dass die Entscheidung sich an den eigenen Anforderungen orientieren sollte, nicht an einer Bestenliste.

Warum Ranglisten meistens ein Verkaufsargument sind

Ein CMS kann technisch nicht „für SEO optimiert“ sein in dem Sinn, dass es automatisch bessere Rankings liefert. Was ein System liefern kann, sind Voraussetzungen: saubere URLs, kontrollierbare Meta-Angaben, akzeptable Ladezeiten. Ob eine Seite tatsächlich rankt, hängt davon ab, ob sie eine Suchanfrage besser beantwortet als der Wettbewerb und ob andere Websites auf sie verlinken. Darüber entscheidet niemand im CMS-Backend.

Deshalb lohnt sich Misstrauen gegenüber jedem Vergleich, der ein System klar als „SEO-Sieger“ ausruft, ohne zu sagen, wofür genau. Ein System, das für eine zwanzigseitige Portfolio-Website die beste Wahl ist, kann für einen mehrsprachigen Onlineshop mit zehntausend Produktseiten die falsche sein – und umgekehrt. Die Frage ist nie „welches CMS ist am besten für SEO“, sondern „welches CMS passt zu dieser Website, diesem Team und diesem Wachstumsplan“.

Ein weiterer Grund für Vorsicht: Viele dieser Ranglisten testen Rankingfähigkeit gar nicht wirklich. Sie prüfen, ob eine Demo-Installation schnell lädt oder ob im Adminbereich ein Feld für Meta-Beschreibungen existiert. Beides sagt etwas über die Grundausstattung aus, aber nichts darüber, ob eine damit gebaute Seite tatsächlich eine Suchanfrage schlägt, hinter der bereits etablierte Wettbewerber mit starken Backlink-Profilen stehen.

Was zwischen Plattformen tatsächlich unterschiedlich ist

Auch wenn das CMS nicht über Rankings entscheidet, gibt es reale technische Unterschiede zwischen Systemen. Sie zeigen sich nicht in Tag-eins-Rankings, sondern in dem, was auf Dauer möglich oder mühsam ist:

• URL-Struktur und ob sie sich später ändern lässt, ohne die bestehende Historie zu zerstören – manche Systeme erzwingen ein starres URL-Schema, andere lassen praktisch jede Struktur zu.
• Weiterleitungsverwaltung: Wie einfach lassen sich 301-Weiterleitungen anlegen, wenn sich eine URL ändert oder eine Seite mit einer anderen zusammengelegt wird? In manchen Systemen ist das ein Formularfeld im Backend, in anderen eine Serverkonfiguration, die ein Entwickler anfassen muss.
• Kontrolle über Title-Tags, Meta-Beschreibungen, Überschriftenstruktur und strukturierte Daten nach Schema.org – manche Systeme geben jedes Feld frei zur Bearbeitung, andere erzwingen ein Muster, das sich nicht pro Seite anpassen lässt.
• Rendering: server-seitig oder client-seitig – und was das für das Crawling bedeutet. Eine Seite, die fertiges HTML direkt vom Server ausliefert, ist für Suchmaschinen unmittelbar lesbar. Eine Seite, deren Inhalt erst per JavaScript im Browser aufgebaut wird, verlangt vom Crawler einen zusätzlichen Rendering-Schritt – das funktioniert heute meist zuverlässig, bleibt aber eine zusätzliche Fehlerquelle, gerade bei komplexen Skripten.
• Die Geschwindigkeitsobergrenze der Plattform: Manche Systeme lassen sich bis in die Serverkonfiguration hinein optimieren, andere haben eine technische Decke, über die man mit noch so viel Aufwand nicht hinauskommt.
• Umgang mit Sitemap und robots.txt: automatisch gepflegt und korrekt, oder manuell verwaltet und damit fehleranfällig, sobald Seiten hinzukommen oder verschwinden.
• Internationalisierung: eingebaute Unterstützung für mehrsprachige Strukturen, hreflang-Auszeichnung und länderspezifische Domains oder Verzeichnisse, statt einer nachträglichen Bastellösung.
• Zugriff auf den rohen Quellcode überhaupt: Manche gehosteten Baukästen verstecken das HTML vollständig und lassen nur ausgewählte, vordefinierte Einstellungen zu.
• Caching- und CDN-Anbindung: ob Seiten serverseitig oder über ein Content Delivery Network zwischengespeichert werden können, wirkt sich direkt auf die Ladezeit aus – besonders bei Besuchern, die weit vom Hosting-Standort entfernt sind, etwa bei einer .de-Domain mit Lesern in der Schweiz oder Österreich.

Internationalisierung wiegt für deutschsprachige Seiten mehr

Keiner dieser Punkte entscheidet allein über Rankings. Zusammen bestimmen sie aber, wie viel Reibung eine SEO-Maßnahme künftig kostet – ob eine Änderung an der Überschriftenstruktur fünf Minuten dauert oder ein Ticket an die Entwicklung erfordert. Ein Punkt davon wiegt für deutschsprachige Websites besonders schwer: die Internationalisierung.

Bei einem rein englischsprachigen Projekt mit einem einzigen Zielland ist internationale SEO oft ein Randthema, das man später angehen kann. Für deutschsprachige Websites ist das anders: Deutschland, Österreich und die Schweiz teilen die Sprache, aber nicht immer den Markt, die Domain-Endung oder die Suchintention. Ein Shop, der auf .de, .at und .ch gleichzeitig verkaufen will, oder eine Seite, die Hochdeutsch für den deutschen Markt und leicht abweichende Begriffe für die Schweiz verwendet, braucht ein CMS, das hreflang-Auszeichnung, mehrere Domains oder Verzeichnisstrukturen und getrennte Sitemaps sauber verwaltet – nicht als nachträglich installiertes Zusatzmodul, sondern als eingebautes Konzept.

Das ist keine akademische Frage. Ein System, das Mehrsprachigkeit nur über einzelne übersetzte Beiträge ohne saubere Verzeichnisstruktur oder korrekte hreflang-Tags abbildet, erzeugt schnell doppelten Inhalt zwischen den Ländervarianten – mit der Folge, dass Suchmaschinen nicht sicher wissen, welche Version sie welchem Land oder welcher Sprache zeigen sollen. Wer weiß, dass mehrere deutschsprachige Märkte oder zusätzliche Sprachen wie Französisch oder Englisch mittelfristig dazukommen, sollte das bei der CMS-Wahl von Anfang an mitdenken. Ein nachträglicher Umbau der Sprachstruktur ist deutlich teurer und riskanter als eine früh getroffene Entscheidung.

Die Fragen, die vor der Entscheidung wirklich zählen

Statt eine Bestenliste zu lesen, hilft es, die eigene Situation ehrlich zu beantworten:

• Wer pflegt die Inhalte, und wie technisch ist diese Person? Ein Marketing-Team ohne Entwicklerkenntnisse braucht ein Backend, in dem sich Metadaten, Überschriften und URLs ohne Code ändern lassen. Ein Team mit eigenen Entwicklern kann auf mehr Rohkontrolle setzen, ohne dass das zur Bremse im Alltag wird.
• Geht es um zwanzig Seiten oder um mehrere hundert? Ein kleines Portfolio verzeiht fast jedes System. Eine Website, die auf hunderte oder tausende Seiten wachsen soll, braucht saubere Vorlagen, Massenbearbeitung und eine Struktur, die sich nicht bei jeder neuen Kategorie neu erfinden lässt.
• Wie viele Sprachen und Märkte sind geplant – jetzt und in zwei Jahren? Wie im vorherigen Abschnitt beschrieben, ist das für deutschsprachige Projekte oft relevanter als für rein einsprachige Vorhaben.
• Gibt es bereits eine Website mit gewachsener URL-Historie und bestehenden Backlinks? Eine Migration, die URLs verändert, ohne jede alte Adresse sauber per 301 auf die passende neue umzuleiten, kann einen Teil der bestehenden Sichtbarkeit kosten. Je mehr Historie existiert, desto vorsichtiger sollte die Entscheidung für einen Plattformwechsel ausfallen.

Headless-CMS: der Tausch, den man eingeht

Diese vier Fragen liefern zusammen fast immer eine klarere Antwort als jeder Plattformvergleich, weil sie sich auf die konkrete Website beziehen und nicht auf einen fiktiven Durchschnittsfall. Eine der Antworten führt besonders häufig zu einer großen Weichenstellung: Headless oder klassisches CMS.

Ein Headless-CMS trennt die Inhaltsverwaltung von der Darstellung: Das System liefert Inhalte über eine Schnittstelle aus, und ein separat entwickeltes Frontend entscheidet, wie und wo sie erscheinen. Der Vorteil ist echte Kontrolle – über Markup, Ladeverhalten, Struktur, jedes Detail der Auslieferung, ohne die Grenzen eines vorgefertigten Themes.

Der Preis dieser Kontrolle ist Verantwortung. Nichts an SEO-technischer Grundausstattung – korrektes Rendering für Suchmaschinen, Sitemap-Generierung, saubere Meta-Tags, funktionierende Weiterleitungen – ist automatisch vorhanden. Es muss im Frontend gebaut und aktiv gepflegt werden. Wird das Frontend rein client-seitig gerendert, ohne dass jemand server-seitiges Rendering oder statische Generierung einrichtet, kann das Crawling der Inhalte inkonsistent werden: Nicht jeder Crawler rendert JavaScript gleich zuverlässig, und ein Rendering-Fehler zeigt sich oft erst, wenn Rankings bereits leiden, nicht vorher. Für ein Team mit eigener Entwicklungskapazität ist Headless eine der stärksten Optionen, die es gibt. Für ein Team ohne diese Kapazität wird aus der Kontrolle schnell eine Dauerbaustelle, die jede kleine SEO-Änderung zu einem Entwicklungsticket macht.

Ein typisches Beispiel: Eine Produktseite wird beim ersten Aufruf nur als leeres Gerüst ausgeliefert, der eigentliche Text folgt erst, nachdem JavaScript vollständig ausgeführt wurde. Für einen Browser wirkt das nahezu augenblicklich. Ein Crawler, der die Seite zu einem ungünstigen Zeitpunkt abruft oder das Skript nicht vollständig ausführt, kann dieselbe Seite dagegen wochenlang leer im Index führen – ohne dass im Backend irgendetwas als fehlerhaft markiert ist. Solche Lücken fallen oft erst auf, wenn jemand gezielt nachschaut, wie die Seite ohne JavaScript aussieht.

Migrationskosten sind der eigentliche Lock-in

Die teuerste Eigenschaft eines CMS zeigt sich nicht bei der Einrichtung, sondern beim Ausstieg. Ein Wechsel bedeutet in der Regel: jede bestehende URL neu zuordnen und per 301 weiterleiten, jede Meta-Angabe und jede strukturierte Datenauszeichnung neu einrichten, die interne Verlinkung neu prüfen, und eine Übergangsphase durchstehen, in der Google die neue Struktur erst neu bewerten muss.

Das ist der eigentliche Grund, warum eine CMS-Entscheidung teuer zu revidieren ist – nicht, weil ein bestimmtes System einen technisch „gefangen hält“, sondern weil jede Migration eine technische Operation an einer laufenden, bereits rankenden Website ist. Je mehr Seiten und je mehr gewachsene Backlinks eine Website hat, desto größer ist dieses Risiko, und desto sorgfältiger muss die Migration geplant werden. Wer das im Kopf hat, wählt beim ersten Mal vorsichtiger und behandelt einen späteren Wechsel als eigenes Projekt mit Redirect-Mapping und Nachkontrolle über mehrere Wochen, nicht als Wochenendaktion.

Wann ein CMS-Wechsel wirklich hilft – und wann er nur ablenkt

Ein Wechsel ist gerechtfertigt, wenn die aktuelle Plattform eine konkrete, nicht behebbare technische Grenze hat: wenn sich URLs grundsätzlich nicht ohne störende Parameter darstellen lassen, wenn strukturierte Daten sich technisch nicht einbauen lassen, wenn die Ladezeit an einer Plattformgrenze hängt, die auch Caching und Bildoptimierung nicht mehr lösen, oder wenn eine mehrsprachige Struktur sich technisch nicht sauber abbilden lässt.

Häufiger ist aber ein anderer Fall: Eine Website rankt nicht, das CMS wird zum Verdächtigen erklärt, und ein Wechsel löst am Ende nichts, weil das eigentliche Problem dünner, redundanter oder veralteter Inhalt war. Bevor ein Wechsel beschlossen wird, lohnt sich eine ehrliche Prüfung: Beantworten die vorhandenen Seiten die Suchintention der Zielkeywords wirklich vollständig? Gibt es überhaupt externe Websites, die auf die eigene Domain verlinken? Wenn die Antwort auf beide Fragen „kaum“ lautet, wird eine neue Plattform daran nichts ändern. Die Migration kostet Zeit, Budget und ein Stück Sichtbarkeit während der Umstellung, und das eigentliche Problem bleibt danach genau bestehen.

Eine einfache Faustregel hilft bei der Einordnung: Wer die eigenen Zielseiten selbst über eine Suchmaschine sucht und feststellt, dass sie trotz ausführlichem, aktuellem Inhalt und regelmäßiger externer Verlinkung nicht einmal auf den ersten Ergebnisseiten auftaucht, hat eher ein technisches Problem, das eine Plattform tatsächlich lösen kann. Wer dagegen kaum externe Verlinkung besitzt und Inhalte hat, die spürbar kürzer oder oberflächlicher sind als die aktuell rankende Konkurrenz, hat ein Content- und Autoritätsproblem – und das behebt keine Migration, ganz gleich wie modern das neue System ist.

Am Ende bleibt die CMS-Wahl eine Entscheidung über Reibung, nicht über Sichtbarkeit: Sie bestimmt, wie leicht sich URLs pflegen, Metadaten anpassen und mehrsprachige Strukturen abbilden lassen – nicht, ob eine Seite rankt. Diese Reibung ehrlich einzuschätzen, bevor man sich für Jahre an ein System bindet, ist die eigentliche Aufgabe. Das Auswendiglernen einer Bestenliste ersetzt diese Arbeit nicht.