Magento CMS 2026: Wie gut ist Magento wirklich als Content-System?

Die Frage „Taugt das Magento CMS eigentlich als Content-System?” wird meist mit einer Feature-Liste beantwortet: CMS-Seiten, Blöcke, Widgets, Page Builder — klingt vollständig. Die Liste stimmt sogar. Sie beantwortet nur die falsche Frage.

Denn ob ein System ein gutes CMS ist, entscheidet sich nicht daran, ob man Seiten anlegen kann. Es entscheidet sich an den Feldern, die das System für Inhalte vorsieht — und an denen, die es nicht vorsieht. Ein Content-System, das keinen Autor kennt, kein Veröffentlichungsdatum und keinen Entwurfsstatus, kann beliebig viele Seiten verwalten und trotzdem keine Redaktion tragen.

Deshalb haben wir für diesen Artikel nicht Marketing-Seiten zusammengefasst, sondern im Quellcode nachgezählt: das Datenbankschema von Magento_Cms, die Bausteine des Page Builders, die GraphQL-Schnittstelle. Alle Zahlen unten stammen aus dem offiziellen Magento-Repository (Branch 2.4-develop, abgerufen am 07.08.2026) und sind mit den angegebenen Befehlen nachprüfbar.

Was das Magento CMS überhaupt ist

Magento ist in erster Linie eine E-Commerce-Plattform. Das CMS ist ein Modul darin — Magento_Cms, eines von 222 Modulen im Core (app/code/Magento, Branch 2.4-develop). Es besteht aus drei Bausteinen, die man kennen muss, bevor man über Eignung reden kann.

CMS-Seiten sind eigenständige URLs außerhalb des Katalogs: „Über uns”, „Versand und Zahlung”, „Impressum”, die Startseite. Sie liegen in der Tabelle cms_page.

CMS-Blöcke sind wiederverwendbare Inhaltsschnipsel ohne eigene URL. Ein Versandhinweis, ein Werbebanner, ein Footer-Textblock. Sie liegen in cms_block und werden an anderen Stellen eingebunden.

Widgets sind der Klebstoff: Sie bestimmen, wo ein Block erscheint — auf welchen Seitentypen, in welchem Layoutbereich, in welchem Store-View. Das Widget selbst enthält keinen Inhalt, es platziert nur.

Diese Dreiteilung ist sauber gedacht und für einen Shop völlig ausreichend, solange Inhalt bedeutet: ein paar statische Seiten und ein paar Banner. Sie wird zum Problem, sobald Inhalt bedeutet: laufend produzierte, datierte, von Menschen verantwortete Artikel.

Der harte Test: Was steht wirklich in der Datenbank?

Feature-Listen sind Absichtserklärungen. Das Datenbankschema ist die Wahrheit — es zeigt, welche Informationen ein System über einen Inhalt überhaupt speichern kann.

Hier ist das vollständige Schema der Tabelle cms_page, direkt aus app/code/Magento/Cms/etc/db_schema.xml. 20 Spalten:

page_id, title, page_layout, meta_keywords, meta_description,
identifier, content_heading, content, creation_time, update_time,
is_active, sort_order, layout_update_xml, custom_theme,
custom_root_template, custom_layout_update_xml, layout_update_selected,
custom_theme_from, custom_theme_to, meta_title

Selbst nachzählen:

curl -s https://raw.githubusercontent.com/magento/magento2/2.4-develop/app/code/Magento/Cms/etc/db_schema.xml \
  | grep -o '<column xsi:type="[^"]*" name="[^"]*"' | wc -l

Und cms_block hat sogar nur sieben Spalten: block_id, title, identifier, content, creation_time, update_time, is_active.

Jetzt der aufschlussreiche Teil — nicht was da steht, sondern was fehlt. Zum Vergleich das Schema von wp_posts, der zentralen Inhaltstabelle von WordPress (aus wp-admin/includes/schema.php, 23 Spalten). Diese redaktionellen Felder hat WordPress und Magentos cms_page hat sie nicht:

Methodik: Beide Schemata am 07.08.2026 aus den offiziellen Repositories abgerufen (magento/magento2, Branch 2.4-develop · WordPress/WordPress, Branch master) und automatisiert ausgezählt. Index- und Constraint-Definitionen wurden ausgeschlossen, nur echte Spaltendefinitionen gezählt.

Das ist kein Detail für Datenbank-Nerds. Jede einzelne fehlende Zeile ist eine Redaktionsfunktion, die dein Team im Alltag vermissen wird:

Kein Autor bedeutet: Magento weiß nicht, wer einen Inhalt verantwortet. Keine Autorenzeile im Artikel, keine Autoren-Übersichtsseite, kein author-Feld für strukturierte Daten. Für Google ist Autorschaft ein Signal, das sich schlecht nachrüsten lässt.

Kein Veröffentlichungsdatum bedeutet: Es gibt creation_time (wann angelegt) und update_time (wann zuletzt gespeichert) — aber kein Feld für „soll am 15. erscheinen”. Das ist ein technischer, kein redaktioneller Zeitstempel. Wer einen Tippfehler korrigiert, verschiebt update_time; das Erscheinungsdatum des Inhalts bleibt unbekannt.

Kein Status, nur ein Schalter. is_active ist ein smallint mit zwei Zuständen. Entwurf, in Prüfung, freigegeben, geplant, archiviert — all das existiert im Datenmodell nicht. Eine Seite ist sichtbar oder unsichtbar. Ein Redakteur, der einen halbfertigen Text speichert, hat keinen Ort dafür außer „aus”.

Keine Hierarchie. Ohne parent_id gibt es keine Seitenbäume. Eine Struktur wie /service/versand/international/ musst du über URL-Keys und Navigations-Konfiguration von Hand nachbilden. Verschiebt sich etwas, verschiebt es sich nirgendwo automatisch mit.

Bemerkenswert ist, was Magento stattdessen hat: page_layout, custom_theme, custom_root_template, layout_update_xml, custom_layout_update_xml, layout_update_selected, custom_theme_from, custom_theme_to. Acht von 20 Spalten — 40 % der Tabelle — betreffen Layout und Theme. Redaktionelle Metadaten: null.

Das Datenmodell verrät die Absicht dahinter sehr klar. cms_page ist nicht als Artikeltabelle entworfen, sondern als Ablage für gestaltete Sonderseiten in einem Shop. Für diesen Zweck ist sie gut geschnitten. Als Basis für eine Redaktion ist sie es nicht.

Der Page Builder: mächtiger Baukasten, dünne Inhaltsschicht

Seit Version 2.3.1 gibt es den Page Builder, seit 2.4.3 ist die Basisfunktionalität auch in Magento Open Source enthalten — vorher war er Adobe Commerce vorbehalten. Das ist die wichtigste Verbesserung, die das Magento CMS je bekommen hat, und sie wird oft unterschätzt.

Der Page Builder ersetzt das alte WYSIWYG-Feld durch eine Drag-and-drop-Oberfläche. Interessant ist, woraus er besteht. Der Code liegt in einem eigenen Repository (magento/magento2-page-builder), nicht im Core — der Grund, warum man ihn in app/code/Magento vergeblich sucht. Dort definieren XML-Dateien die verfügbaren Bausteine. Es sind genau 20:

banner, block, button_item, buttons, column, column-line, column_group,
divider, heading, html, image, map, products, row, slide, slider,
tab_item, tabs, text, video

Nachzählen:

curl -s "https://api.github.com/repos/magento/magento2-page-builder/contents/app/code/Magento/PageBuilder/view/adminhtml/pagebuilder/content_type?ref=develop" \
  | grep -c '"name": ".*\.xml"'

Wenn man diese 20 sortiert, wird die Bauart sichtbar:

• 11 Bausteine sind Struktur/Layout: row, column, column_group, column-line, divider, tabs, tab_item, slider, slide, buttons, button_item
• 9 Bausteine tragen tatsächlich Inhalt: heading, text, html, image, video, banner, map, products, block
• Davon sind 2 shop-spezifisch (products zeigt Produkte, block bindet einen CMS-Block ein)

Mehr als die Hälfte des Baukastens dient also dem Anordnen, nicht dem Schreiben. Das ist keine Kritik — für Landingpages ist genau das richtig. Es zeigt nur nochmal die Ausrichtung: Der Page Builder ist ein Layout-Werkzeug für Kampagnenseiten, kein Redaktionswerkzeug.

Was der Page Builder gut kann:

• Landingpages ohne Entwickler. Eine Kampagnenseite mit Hero-Banner, drei Spalten, Produktkarussell und Video ist in einer halben Stunde gebaut. Das war vor 2.3.1 ein Ticket ans Entwicklungsteam.
• Produkte direkt einbetten. Der products-Baustein zieht eine Auswahl aus dem Katalog in den Inhalt. Das ist der eine Punkt, an dem Magento jedes generische CMS schlägt: Produktdaten sind nicht importiert, sie sind dieselben Daten, live und mit korrektem Lagerstatus.
• Volle Layout-Kontrolle über Abstände, Hintergründe, Ränder, Sichtbarkeit — pro Baustein.

Wo es weh tut:

• Der Inhalt landet als HTML-Blob in content. Der Page Builder speichert seine Struktur als angereichertes HTML mit data--Attributen in derselben mediumtext-Spalte. Es gibt kein strukturiertes Feld pro Element. Eine Auswertung wie „alle Seiten mit Video-Baustein” ist eine Volltextsuche im HTML, keine Datenbankabfrage.
• Wer den Page Builder deaktiviert, bekommt Rohcode zu sehen. Ein Umstieg zurück oder auf einen anderen Editor ist eine Migration, keine Einstellung.
• Einarbeitung. Redakteure, die Wix oder WordPress mit Gutenberg kennen, brauchen einen Moment. Die Bedienung ist eigenwillig — insbesondere das Verschachteln von Zeilen und Spalten.

Ein Hinweis für alle, die auf ein modernes Frontend setzen: Wer Hyvä als Theme nutzt (und das tun 2026 viele neue Magento-Projekte, weil es die Frontend-Performance deutlich verbessert), sollte die Page-Builder-Kompatibilität früh prüfen. Hyvä bietet inzwischen mit Hyvä CMS eine eigene Editor-Lösung an — was für sich genommen schon eine Aussage über den Zustand des mitgelieferten Editors ist.

Die Blog-Lücke: Magento hat kein Blog-Modul. Punkt.

Das ist der Punkt, an dem die meisten Projekte auflaufen — und er ist einfach zu belegen. In den 222 Core-Modulen von Magento 2.4 gibt es kein einziges Blog-Modul:

curl -s "https://api.github.com/repos/magento/magento2/contents/app/code/Magento?ref=2.4-develop" \
  | grep '"name"' | grep -i blog
# (keine Ausgabe)

Content-nahe Module gibt es durchaus — Cms, CmsGraphQl, CmsUrlRewrite, Widget, CatalogWidget, MediaGalleryCmsUi — aber nichts, was Beiträge, Kategorien, Tags oder Autoren kennt. Aus dem Datenmodell weiter oben folgt das zwangsläufig: Ohne post_author, post_date, post_type und Hierarchie kann es kein Blog geben.

Praktisch heißt das: Wer mit Magento bloggen will, hat drei Wege.

Weg 1 — Blog-Erweiterung installieren. Magefan Blog, Mageplaza Blog, Amasty Blog Pro. Kostenpunkt zwischen 0 € (Magefan Basisversion) und mehreren hundert Euro. Diese Module bringen mit, was der Core nicht hat: eigene Tabellen mit Autor, Datum, Kategorien, Tags, Kommentaren. Das funktioniert gut — mit einem Preis, der erst später sichtbar wird: Bei jedem Magento-Upgrade hängt dein Blog an der Update-Geschwindigkeit eines Drittanbieters. Wer schon einmal auf ein Modul gewartet hat, während ein Sicherheitspatch bereitliegt, kennt das Gefühl.

Weg 2 — WordPress danebenstellen. Der Shop auf shop.example.de, der Blog auf example.de/blog. Zwei Systeme, zwei Updates, zwei Backups, zwei Sicherheitsflächen, zwei Designs, die auseinanderdriften. Verbreitet, aber selten mit Freude gewählt. Wer diesen Weg erwägt, sollte vorher unseren Artikel über moderne WordPress-Alternativen lesen — es gibt inzwischen deutlich leichtere Optionen als eine zweite Vollinstallation.

Weg 3 — Content von Anfang an trennen. Dazu unten mehr, denn das ist 2026 der Weg, den wir bei neuen Projekten meist empfehlen.

Wo Magento als CMS echt stark ist

Bis hierhin klingt das nach einer Abrechnung. Ist es nicht — es gibt Dinge, die Magento als Content-System besser kann als jedes reine CMS, und die gehen in der Diskussion regelmäßig unter.

Mehrsprachigkeit und Mehr-Store-Fähigkeit sind eingebaut, nicht aufgesetzt. Das Schema zeigt es: Es gibt die Verknüpfungstabellen cms_page_store und cms_block_store mit Fremdschlüsseln auf store. Jede Seite und jeder Block kann pro Store-View gezielt aktiviert werden. Wer schon einmal WordPress mit WPML oder Polylang für sechs Länder-Shops eingerichtet hat, weiß, was dieser Satz wert ist. Bei Magento ist das kein Plugin, sondern Fundament.

Inhalt und Katalog leben im selben System. Ein Produktkarussell auf einer Landingpage zeigt echte Lagerbestände, echte Kundengruppen-Preise, echte Verfügbarkeiten. Kein Sync, kein Cache-Abgleich, keine Nacht, in der der Feed hängt. Für Shops mit häufig wechselndem Sortiment ist das ein handfester Vorteil.

Die Volltextsuche ist mitgedacht. Beide CMS-Tabellen haben fulltext-Indizes über title, identifier und content — bei cms_page zusätzlich über die Meta-Felder. CMS-Inhalte sind damit in der Shop-Suche auffindbar, ohne dass man etwas dafür tut.

Die SEO-Grundausstattung ist vollständig. meta_title, meta_description, meta_keywords und ein sauberer identifier als URL-Key stehen pro Seite zur Verfügung. Das ist nicht viel — aber es ist genau das, was gebraucht wird, und es ist ohne Plugin da. (Was fehlt, sind Canonicals und strukturierte Daten für Artikel; beides kommt in der Praxis über Erweiterungen.)

Die Inhalte sind über GraphQL abrufbar. Das Modul Magento_CmsGraphQl liefert cmsPage(identifier:) und cmsBlocks(identifiers:) — inklusive title, content, content_heading, page_layout und aller Meta-Felder. Das ist der Schlüssel zur Headless-Architektur und der Grund, warum der nächste Abschnitt überhaupt funktioniert.

Die ehrliche Empfehlung: Shop und Content trennen

Nach allem, was das Datenmodell zeigt, ist die naheliegende Schlussfolgerung nicht „Magento ist ein schlechtes CMS”, sondern: Magento ist ein E-Commerce-System mit einer brauchbaren Seitenverwaltung — und man sollte es genau dafür einsetzen.

Die Architektur, die sich in der Praxis bewährt:

• Alles Kommerzielle bleibt in Magento. Kategorieseiten, Produktseiten, Kampagnen-Landingpages mit echten Produktdaten, rechtliche Pflichtseiten, Shop-Hilfeseiten. Also genau das, wofür cms_page gebaut ist — inklusive Page Builder.
• Alles Redaktionelle kommt aus einem echten CMS. Blog, Ratgeber, Magazin, Fallstudien, Pressemitteilungen. Dort, wo Autor, Datum, Status, Kategorien und Workflows gebraucht werden.
• Verbunden wird über die API. Magentos GraphQL liefert Produktdaten ins Content-System, das Content-System liefert Artikel ins Shop-Frontend. Beide bleiben unabhängig aktualisierbar.

Der entscheidende Vorteil ist keine Funktion, sondern ein Risiko, das verschwindet: Ein Magento-Upgrade kann deinen Blog nicht mehr kaputt machen, und ein CMS-Update kann deinen Checkout nicht mehr kaputt machen. Wer beide Systeme schon einmal in einem Deployment hatte, kennt den Wert dieser Trennung.

Wir gehen bei getmind.io den gleichen Weg, nur konsequenter: Diese Seite hier — der Artikel, den du gerade liest — läuft nicht auf einem Shopsystem, sondern auf Astro; die Inhalte liegen als Dateien im Git-Repository. Der Grund ist derselbe: Redaktion und Verkauf haben unterschiedliche Anforderungen an Geschwindigkeit, Versionierung und Ausfallsicherheit. Ein System, das beides gleichzeitig gut macht, gibt es nicht — es gibt nur Systeme, die eins davon gut machen und das andere mitschleppen.

Der Elefant im Raum: Wie lange gibt es Magento Open Source noch?

Diese Frage gehört in jeden Magento-Artikel des Jahres 2026, weil sie über jeder Technikentscheidung schwebt.

Der Stand, direkt aus Adobes offizieller Versionsübersicht (Stand der Seite: 02.06.2026):

Version 2.4.9 erschien am 12. Mai 2026. Wer heute auf 2.4.6 läuft, hat also nur noch wenige Tage regulären Support — das ist kein theoretisches Datum, sondern eine Aufgabe für diesen Monat.

Die vielzitierte These „Adobe lässt Open Source sterben” ist trotzdem zu einfach. Sie stimmt in der Richtung: Adobes Investitionen fließen erkennbar in die kommerzielle und SaaS-Seite, und Open Source bekommt keinen erweiterten Support wie zahlende Kunden. Sie stimmt nicht im Ergebnis: Es gibt weiter Releases, weiter Sicherheitspatches, und die Support-Zusage für 2.4.9 reicht bis 2029.

Dazu kommt eine Entwicklung, die das Risiko strukturell verändert: Mage-OS, eine unabhängige, gemeinnützige Distribution von Magento Open Source. Der Fork ist aktiv, veröffentlicht eigene Distributionen mit den Magento-Sicherheitspatches und hat ein offenes Governance-Modell. Das Projekt betont ausdrücklich, nicht mit Adobe verbunden zu sein. Wer sich Sorgen um die Zukunft der freien Variante macht, hat damit eine Rückfalloption, die es 2021 noch nicht gab.

Zu den Marktanteilszahlen eine Warnung, weil sie überall zitiert werden: Die verbreiteten Angaben — „7–8 % Marktanteil”, „rund 100.000 aktive Shops”, „11 % Rückgang gegenüber Vorjahr” — stammen fast alle aus derselben Quelle (BuiltWith) und werden über Sekundärartikel weitergereicht. BuiltWith erkennt Technologien anhand von Signaturen im HTML. Ein Shop mit modernem Headless-Frontend oder Hyvä-Theme sieht von außen möglicherweise nicht mehr nach Magento aus. Ein Teil des gemessenen „Rückgangs” könnte also Modernisierung sein, nicht Abwanderung. Wir nennen die Zahlen deshalb mit dieser Einschränkung — und würden keine Plattformentscheidung darauf stützen.

Magento CMS vs. die Alternativen

Ein kurzer Realitätsabgleich, wo Magento inhaltlich steht:

Gegenüber Shopware 6: Shopware hat mit den „Erlebniswelten” ein vergleichbares Baukastenkonzept und ebenfalls kein natives Blog-Modul im Standard. Der Gleichstand bei Content ist also weitgehend echt; die Unterschiede liegen woanders. Wenn du zwischen beiden schwankst, hilft unser Kostenvergleich zu Shopware 6 mehr als ein Feature-Duell.

Gegenüber Shopify: Shopify bringt ein Blog-System mit — Beiträge, Autoren, Tags, Kommentare, alles im Standard. Es ist funktional schlicht, aber es ist da und es wird gepflegt. Für inhaltsgetriebene Marken mit überschaubarem Katalog ist das ein echter Vorsprung.

Gegenüber WordPress/WooCommerce: Umgekehrtes Bild. WordPress ist ein exzellentes CMS mit einem angebauten Shop; Magento ist ein exzellenter Shop mit angebauter Seitenverwaltung. Welche Seite dir wichtiger ist, entscheidet die Wahl fast allein. Unser Vergleich der Shopsysteme geht darauf im Detail ein.

Gegenüber Headless-CMS (Payload, Directus, Strapi, Sanity, Storyblok): Hier verliert Magento inhaltlich klar — und das ist in Ordnung, weil diese Systeme nur eine Aufgabe haben. Genau deshalb ist die Kombination aus beidem so verbreitet.

Praxis: Worauf du beim Magento-CMS-Betrieb achten solltest

Ein paar Dinge, die wir aus dem Betrieb von Shopsystemen gelernt haben und die für Magento-CMS-Inhalte direkt relevant sind:

Der Cache ist dein häufigster Fehler. Inhalte werden aggressiv gecacht — Full Page Cache, oft in Redis oder Varnish. Eine geänderte CMS-Seite erscheint nicht sofort. Bevor du dich fragst, ob die Speicherung fehlgeschlagen ist: Cache leeren. Und wenn ein externer CDN davor liegt, teste den Ursprung direkt, sonst misst du nur den Zwischenspeicher.

Bilder sind das Performance-Problem, nicht das CMS. Der Page Builder macht es einfach, große Bilder einzusetzen. Die Startseite eines Shops trägt schnell mehrere Megabyte, wenn niemand aufpasst. Konvertiere zu WebP, definiere Breiten und Höhen, lade unterhalb des Falzes verzögert. Wie sich das messbar auswirkt, kannst du mit unserem Core-Web-Vitals-Test selbst prüfen.

Der HTML-Blob macht Massenänderungen teuer. Weil Page-Builder-Inhalte als HTML in einer Spalte liegen, ist „ändere auf allen 200 Seiten den Button-Text” kein Datenbank-Update, sondern eine Suchen-und-Ersetzen-Operation über HTML. Plane das ein, bevor du 200 Seiten baust.

Redaktionsprozesse musst du außerhalb organisieren. Da es keinen Entwurfsstatus gibt, braucht jedes Team eine Verabredung: Wo entsteht der Text, wer gibt frei, wann geht er live. Ohne diese Verabredung wird is_active zum Freigabeprozess — und das geht irgendwann schief.

Häufige Fragen zum Magento CMS

Ist Magento ein CMS? Magento enthält ein CMS-Modul, ist aber kein CMS im eigentlichen Sinn. Es verwaltet Seiten, Blöcke und Widgets und bietet seit 2.4.3 auch in der Open-Source-Variante einen visuellen Page Builder. Was fehlt, sind die Grundlagen redaktioneller Arbeit: Das Datenmodell kennt weder Autor noch Veröffentlichungsdatum, weder Entwurfsstatus noch Seitenhierarchie. Als Seitenverwaltung für einen Shop ist es geeignet, als Redaktionssystem nicht.

Kann man mit Magento einen Blog betreiben? Nicht mit Bordmitteln. In den 222 Core-Modulen gibt es kein Blog-Modul, und ohne Autor- und Datumsfelder ließe sich auch keins improvisieren. Üblich sind Erweiterungen wie Magefan, Mageplaza oder Amasty, ein separates CMS oder eine getrennte Content-Plattform mit API-Anbindung.

Ist der Page Builder in Magento Open Source enthalten? Ja, die Basisfunktionalität seit Version 2.4.3. Der Code steht unter der Open Software License 3.0. Adobe Commerce ergänzt darüber hinaus Funktionen wie Staging, Vorschau und personalisierte Inhalte, die in Open Source fehlen.

Wie viele Bausteine hat der Page Builder? Zwanzig. Elf davon sind Layout-Elemente (Zeilen, Spalten, Tabs, Slider, Trenner, Buttons), neun tragen Inhalt (Überschrift, Text, HTML, Bild, Video, Banner, Karte, Produkte, CMS-Block). Nachzählbar im Repository magento/magento2-page-builder.

Was ist der Unterschied zwischen CMS-Seite und CMS-Block? Eine CMS-Seite hat eine eigene URL und ist direkt aufrufbar. Ein CMS-Block hat keine eigene URL, sondern wird an anderen Stellen eingebunden — über Widgets, Layout-XML oder direkt im Page Builder. Technisch sind es zwei Tabellen: cms_page mit 20 Spalten, cms_block mit sieben.

Kann ich Magento-Inhalte headless ausliefern? Ja. Magento_CmsGraphQl stellt die Abfragen cmsPage(identifier:) und cmsBlocks(identifiers:) bereit und liefert Inhalt und Metadaten als JSON. Zu beachten: Der content-Wert ist rohes HTML — dein Frontend muss es rendern und beim Page Builder auch dessen Struktur-Attribute verstehen.

Wie lange wird Magento Open Source noch unterstützt? Regulärer Support für 2.4.6 endet am 11. August 2026, für 2.4.7 am 9. April 2027, für 2.4.8 am 11. April 2028, für 2.4.9 im Mai 2029. Zusätzlich existiert mit Mage-OS eine unabhängige, gemeinnützige Distribution, die Sicherheitspatches weiterführt.

Lohnt sich Magento nur wegen des CMS? Nein, umgekehrt: Magento lohnt sich wegen des Katalogs, der Mehr-Store-Fähigkeit, der B2B-Funktionen und der Anpassbarkeit. Das CMS ist eine solide Zugabe. Wer primär Inhalte veröffentlichen will und nebenbei etwas verkauft, ist mit einem CMS plus leichtem Shop besser bedient.

Fazit

Das Magento CMS ist besser als sein Ruf und schlechter als die Feature-Liste verspricht — und beides lässt sich am Datenmodell ablesen statt am Gefühl.

Was es kann: Seiten und Blöcke pro Store-View und Sprache verwalten, mit dem Page Builder ohne Entwickler ansehnliche Landingpages bauen, Produktdaten live einbetten, alles über GraphQL nach außen geben. Für einen Shop, der ein paar Dutzend statische Seiten und regelmäßige Kampagnenseiten braucht, ist das vollkommen ausreichend.

Was es nicht kann: Redaktion. Ohne Autor, ohne Veröffentlichungsdatum, ohne Entwurfsstatus, ohne Hierarchie ist cms_page keine Artikeltabelle. Acht der 20 Spalten regeln Layout und Theme, keine einzige regelt, wer wann was veröffentlicht. Das ist keine Lücke, die man übersehen hat — das ist eine bewusste Entscheidung für einen anderen Zweck.

Die praktische Konsequenz: Nutze Magento für das, wofür sein Datenmodell gebaut ist, und hol dir für Inhalte ein System, dessen Datenmodell dafür gebaut ist. Die Trennung kostet eine Schnittstelle und spart dir die Kopplung zweier Systeme, die zu unterschiedlichen Zeiten aus unterschiedlichen Gründen aktualisiert werden müssen.

Und die Frage, ob Magento Open Source eine Zukunft hat, ist für die CMS-Entscheidung fast egal — denn wenn dein Content ohnehin außerhalb liegt, ist ein Plattformwechsel im Shop kein Content-Projekt mehr. Das ist vielleicht das beste Argument für die Trennung überhaupt.