Bloggen mit Shopware 6: WordPress oder Blog-Plugin?

von Der Atilla | Aug. 14, 2026 | Alle, Shopware 6, Shopware Conversion Optimierung, Shopware Einstellungen, Shopware Plugins, Shopware SEO | 0 Kommentare

Wer heute einen neuen Shop mit Shopware 6 startet und Content-Marketing plant, stößt schnell auf eine Lücke: Ein Shopware 6 Blog ist im Kern nicht vorgesehen. Anders als bei WordPress, wo Bloggen die Grundfunktion ist, muss man sich bei Shopware entscheiden – Bordmittel zweckentfremden, ein Store-Plugin kaufen oder eine externe Lösung wie WordPress anbinden. Dieser Artikel ordnet den aktuellen Stand (Shopware 6.7.13.0, geprüft im August 2026) ein, vergleicht die real verfügbaren Plugins mit echten Preisen und zeigt, worauf es bei jeder Variante technisch ankommt. Wer nur schnell die Kernaussage braucht: Alle drei Wege sind praxistauglich, aber keiner ist ohne Kompromiss – welcher passt, hängt vor allem davon ab, wie eng Blog und Shop redaktionell und technisch verzahnt sein sollen.

„Im Standard von Shopware 6 gibt es keine Blog-Funktionalität. Somit ohne ein Plugin (=Anpassung) – gar nicht.“

sschreier, Shopware-Community-Mitglied, das im selben Beitrag auch sein eigenes Blog-Plugin anbietet – 30.05.2024, Forumsbeitrag

Shopware 6 Blog Bordmittel: Erlebniswelten und Custom Entities als Behelfslösung
Shopware 6 Blog-Plugins im Store: netzperfekt, Pixeleyes, Shop Studio und moorl im Preisvergleich
Shopware 6 Blog extern: WordPress als Alternative – und wie great2gether selbst bloggt
Shopware 6 Blog in der Praxis: Fehlerbilder aus der Community
Shopware 6 Blog FAQ: Häufige Fragen kurz beantwortet

1. Shopware 6 Blog Bordmittel: Erlebniswelten und Custom Entities als Behelfslösung

Fangen wir mit der ehrlichen Antwort an: Shopware 6 hat auch in Version 6.7.13.0 kein natives Blog-Modul. Das lässt sich nicht nur an der offiziellen Doku ablesen, sondern auch direkt im Quellcode nachvollziehen – im Core-Repository von Shopware existiert unter den CMS-Elementen von sw-cms kein Blog- oder Artikel-Element, keine eigene Blog-Datenbanktabelle und kein Blog-CLI-Befehl. Wer im Backend nach „Blog“ sucht, findet nichts.

Zwei Bordmittel werden trotzdem gelegentlich als Notlösung genutzt:

Erlebniswelten (Shopping Experiences): Landingpages lassen sich mit CMS-Blöcken so bauen, dass sie auf den ersten Blick wie Blogartikel wirken. Das Problem liegt dabei aber tiefer als eine fehlende Admin-Einstellung – es steckt strukturell im Datenmodell der Erlebniswelt selbst, wie sich im Code nachvollziehen lässt (dazu gleich mehr im Detail).
Custom Entities: Das generische Custom-Entity-System erlaubt es, über eine App und eine entities.xml beliebige eigene Datenstrukturen anzulegen. Shopware selbst nutzt „Blog“ intern als Lehrbeispiel dafür – im Schema-Updater des Core-Codes taucht der Anwendungsfall konkret auf: Ein Kommentar zur Mapping-Tabelle custom_entity_blog_products und die Beispiel-Assoziation product.customEntityBlogTopSeller sind dort im Quellcode nachlesbar. Zur Einordnung, wie reif dieser Weg tatsächlich ist: Das Custom-Entity-System für Apps ist seit Shopware 6.4.11.0 (Mai 2022) offiziell produktiv nutzbar, kein Beta- oder Experimentalfeature. Seit Shopware 6.7.0.0 gilt dabei eine wichtige Einschränkung: Es steht ausschließlich Apps zur Verfügung – klassische Plugins können entities.xml nicht mehr nutzen. Wichtig ist ohnehin ein anderer Punkt: Das ist ein Entwickler-Baukasten, kein Klick-Feature für Shopbetreiber. Ohne eigene App-Entwicklung kommt hier niemand zu einem fertigen Blog.

Ein Blick in den Shopware-Kern zeigt, warum die Erlebniswelt strukturell kein Blog-Ersatz ist – und das lässt sich an konkreten Codestellen festmachen, nicht nur an einer einzelnen Forums-Aussage. Die CMS-Seite selbst (CmsPageDefinition.php, Entity cms_page) besitzt außer einem übersetzbaren name-Feld gar kein Meta-Title- oder Meta-Description-Feld – wer eine Erlebniswelt als Kategorie-Layout einhängt, bekommt seine Meta-Angaben stattdessen aus der Kategorie (category/category_translation), wie NavigationPageLoader.php zeigt: metaTitle und metaDescription werden dort aus category.getTranslation('metaTitle'/'metaDescription') gezogen, mit name/description als Fallback. Die einzige Variante mit eigenen Meta-Feldern ist die „Landing Page“ (LandingPageDefinition.php: metaTitle, metaDescription, keywords), die LandingPageLoader.php befüllt – doch selbst die bleibt auf reinen Text beschränkt. Denn die zentrale MetaInformation-Klasse, aus der das Storefront-Template layout/meta.html.twig sämtliche Tags zieht, kennt überhaupt kein Bildfeld: og:image und twitter:image sind dort hart mit theme_config('sw-logo-desktop') verdrahtet – jede Erlebniswelt und jede Landing Page teilt sich für Facebook- und Twitter-Vorschauen also dasselbe Shop-Logo, unabhängig vom Inhalt. Ein eigenes Social-Bild pro Artikel, wie es die Produktdetailseite mit ihrem dedizierten openGraphMediaId-Feld und individuellen ogTitle/ogDescription-Übersetzungen längst besitzt, existiert für Content-Seiten schlicht nicht. Gleiches beim strukturierten Datenmarkup: Die JSON-LD-Templates im Storefront-Layout decken Website, Organization, WebPage/CollectionPage/ItemPage, Product und BreadcrumbList ab – ein Article- oder BlogPosting-Schema, wie es jeder Artikel bräuchte, taucht im gesamten Kern nicht auf. Selbst die Sitemap-Anbindung war lange lückenhaft: Der LandingPageUrlProvider, der Landing Pages überhaupt erst ins XML-Sitemap aufnimmt, wurde erst nachträglich über ein eigenes Core-Ticket ergänzt – vorher fehlten diese Seiten dort komplett. Zum Vergleich: Ein echtes Blog-Setup mit Yoast SEO liefert pro Artikel serienmäßig eine editierbare Meta-Title/-Description mit Live-Vorschau der Google-Snippet-Darstellung, automatisch generierte Open-Graph-Tags samt frei wählbarem Social-Vorschaubild, vollständige Twitter Cards, automatisches Article-, BreadcrumbList- und Organization-Schema als JSON-LD, eine laufend aktualisierte XML-Sitemap, dazu Lesbarkeits- und SEO-Score, Vorschläge für interne Verlinkung, einen Redirect-Manager und eigene Breadcrumb-Ausgabe – Funktionen, die seit Jahren zum bekannten Yoast-Standard gehören und hier bewusst nicht neu recherchiert, sondern als etabliertes Fachwissen eingeordnet werden. Der Unterschied ist also kein gefühlter, sondern ein struktureller: Die Erlebniswelt wurde als Layout-Werkzeug für Kategorie- und Produktseiten gebaut, nicht als eigener Content-Typ mit Metadaten- und Social-Media-Modell – und genau diese Bausteine fehlen im Code, nicht nur in der veröffentlichten Dokumentation.

Wer trotz dieser Lücken auf Erlebniswelten verzichten und stattdessen den Custom-Entity-Weg konsequent zu Ende denken will, sollte wissen, worauf er sich einlässt. „Entwickler-Baukasten“ klingt abstrakt – deshalb hier der Reality-Check: Das sind die Bausteine, die tatsächlich zusammenkommen müssen, bevor daraus ein benutzbares Blog wird. Die folgenden Aufwandsschätzungen gehen von klassischer, manueller Entwicklung ohne KI-Unterstützung aus und sind grobe Richtwerte für einen erfahrenen Shopware-Entwickler, keine belastbaren Angebote – je nach Anspruch an Design und Redaktions-Komfort geht es auch deutlich darüber hinaus. Wie sich das Bild verschiebt, wenn man wie wir mit einem KI-Coding-Agenten arbeitet, ordnen wir direkt im Anschluss ein.

Was der Selbstbau konkret bedeutet: sechs Bausteine

Datenmodell (App-Manifest + entities.xml). Felder für Titel, Slug, Inhalt, Autor, Kategorie/Tags (als many-to-many-Referenz), Veröffentlichungsdatum, Titelbild (Media-Assoziation) und SEO-Meta-Felder definieren, Übersetzbarkeit und Pflichtfelder flaggen, App installieren, Schema über ein paar Testläufe feintunen. Nachträgliche Schema-Änderungen sind bei Custom Entities unbequemer als bei echten Datenbank-Migrationen – das kostet in der Praxis ein, zwei Anläufe mehr. Schätzung: 1,5–2,5 Personentage.
Admin-Oberfläche für Redakteure. Shopware generiert über eine Admin-UI-Konfiguration inzwischen tatsächlich automatisch eine Listing- und Detailseite im Content-Bereich, inklusive Tabs/Cards und wählbaren Feld-Komponenten. Das ist mehr, als die reine Kurzformel „kein Admin-UI“ vermuten lässt – bleibt aber generisch: kein Live-Preview, keine eigene Validierungslogik, kein Freigabe-Workflow, keine Drag-&-Drop-Sortierung. Für ein wirklich redaktionsfreundliches Erlebnis (sauberer Bild-Upload, Slug-Vorschau, Entwurf/Veröffentlicht-Status, Suche in der Liste) kommt man selten ohne zusätzliche Admin-Anpassungen aus. Schätzung: 1 PT für die Basis-Oberfläche, plus 2–4 PT Feinschliff.
Storefront-Ausgabe. Hier kippt die Rechnung: Apps dürfen aus Sicherheitsgründen keinen eigenen PHP-Code im Shop ausführen, sie sprechen nur über Webhooks und die Admin-/Store-API mit dem Kern. Eigene Route, ein Controller mit Pagination-Logik, Breadcrumbs, Twig-Templates für Übersicht und Einzelartikel – das verlangt in der Praxis ein zusätzliches klassisches PHP-Plugin neben der App. „Nur mit einer App“ bleibt für den vollen Blog-Funktionsumfang eher Theorie. Schätzung: 3–5 Personentage.
SEO. Meta-Title/-Description pro Artikel sind reine Datenfelder – die einfache Hälfte. Kanonische, sprechende URLs brauchen eine eigene SEO-URL-Route, strukturierte Daten (Article-Schema) ein eigenes Twig-Partial, der Sitemap-Eintrag eine Klasse, die sich per Dependency-Injection-Tag in Shopwares Sitemap-Exporter einklinkt. Auch das läuft technisch über das Plugin, nicht über die App. Schätzung: 2–4 Personentage.
Komfortfunktionen. Chronologische Übersicht und Pagination sind mit Baustein 3 quasi erledigt. On top kommen Tag-/Kategorie-Filter, ein RSS-Feed als eigener XML-Response-Controller und „verwandte Artikel“ per Tag-/Kategorie-Abgleich. Eine native Kommentarfunktion ist dagegen ein eigenes Mini-Projekt (Speicherstruktur, öffentlicher Schreib-Endpunkt, Spamschutz, Moderation) und wird beim Selbstbau in der Praxis oft bewusst weggelassen oder durch ein eingebettetes Drittanbieter-Widget ersetzt. Schätzung: 3–5 PT ohne Kommentare, plus 3–6 PT wenn Kommentare nativ entstehen sollen.
Pflegeaufwand bei Core-Updates. Der App-Teil (Manifest, entities.xml) ist vergleichsweise stabil, weil er nur über die versionierte API kommuniziert. Das zusätzliche PHP-Plugin aus Baustein 3/4 trägt dagegen das normale Breaking-Change-Risiko jedes klassischen Plugins: geänderte Twig-Blöcke, Service-Signaturen, Deprecations zwischen Hauptversionen. Die Erzählung „Apps sind update-sicherer“ stimmt also nur für den Datenmodell-Teil, nicht fürs Gesamtpaket. Laufender Aufwand: grob 0,5–2 PT pro größerem Update, auf unbestimmte Zeit.

Lohnt sich das?

Grob summiert landet man bei 15–20 Personentagen für ein solides Ergebnis ohne native Kommentare, bei ambitioniertem Umfang auch bei 25 und mehr – Schätzwerte, keine Angebote, und ausdrücklich für klassische, manuelle Entwicklung ohne KI-Unterstützung gerechnet. Was das in Euro bedeutet, hängt zu stark vom eigenen oder externen Tagessatz ab, um das seriös zu beziffern – klar ist nur die Größenordnung: mehrere Personenwochen Entwicklungszeit stehen einem Store-Plugin gegenüber, das mit 15–25 €/Monat läuft. Schon dieser Unterschied in der Größenordnung macht deutlich, dass sich der Selbstbau finanziell nur in Ausnahmefällen rechnet, egal wie viele Jahre man den Blog am Ende betreibt.

Diese Rechnung gilt aber nur, wenn tatsächlich jeder Baustein von Hand getippt wird. Bei great2gether bauen wir genau solche Dinge regelmäßig mit einem KI-Coding-Agenten wie Claude Code – und da verschiebt sich das Bild spürbar: Mit dem nötigen Vorwissen über Shopwares App-System ist das kein Mehrtage-Projekt, sondern eher eine Sache von einem Nachmittag – nicht länger. Der Flaschenhals verschiebt sich dabei weg vom reinen Tippen des Codes hin zu dem, was sich nicht wegautomatisieren lässt: wissen, welche Felder eine Blog-Entity wirklich braucht, wie der Redaktions-Workflow aussehen soll, und was bei einem Core-Update brechen könnte. Die 15–20-Personentage-Kalkulation oben ist deshalb eine Obergrenze für „klassisch ohne KI“ – mit Vorwissen und einem Coding-Agenten an der Seite sieht die Rechnung 2026 anders aus.

Sinn ergibt der Custom-Entity-Weg deshalb selten wegen der Artikelmenge, sondern wegen fehlender Alternativen oder eines veränderten Werkzeugkastens: wenn kein Blog-Plugin die gewünschte Datentiefe abbildet, etwa eine enge Verzahnung mit bereits bestehenden eigenen Custom-Entity-Strukturen; wenn dieselbe Infrastruktur gleich für mehrere Content-Typen genutzt wird und sich die Baukosten so auf mehrere Features verteilen; wenn ohnehin ein eigenes Entwicklerteam vorhanden ist, dessen Zeit nicht als externe Tagessätze eingepreist werden muss; oder wenn im Team ohnehin mit KI-Coding-Agenten gearbeitet wird und die klassische Tagessatz-Rechnung von vornherein nicht mehr zutrifft. Für ein simples „wir wollen bloggen“ bleibt das trotzdem eher ein Kontroll- als ein reines Geschwindigkeitsargument – ein Store-Plugin nimmt einem weiterhin Redaktions-UX, SEO-Vollständigkeit und laufende Pflege bei Core-Updates ab, unabhängig davon, wie schnell der Code selbst entsteht.

Für die Praxis heißt das in der Zusammenfassung: Wer ohne Plugin und ohne eigene App-Entwicklung auskommen will, landet bei Erlebniswelten mit den genannten SEO-Einschränkungen – als echte Blog-Lösung taugt das nur bedingt. Wer Erlebniswelten trotzdem als Behelfslösung einsetzt, verzichtet in der Regel zusätzlich auf Komfortfunktionen, die ein dediziertes Blog-System mitbringt, etwa eine automatisch chronologisch sortierte Übersichtsseite, eine Tag- oder Kategorie-Filterung über mehrere Artikel hinweg oder einen RSS-Feed – schlicht weil dafür kein natives Konzept existiert und jede dieser Funktionen händisch nachgebaut werden müsste.

Zurück zur Übersicht

2. Shopware 6 Blog-Plugins im Store: netzperfekt, Pixeleyes, Shop Studio und moorl im Preisvergleich

Der pragmatischste Weg zu einem echten Blog innerhalb von Shopware 6 ist ein Store-Plugin. Im Shopware Store sind nach unserer Zählung vom 23.08.2026 rund 16 Blog-Extensions gelistet – wir haben vier davon im Detail auf Preis, Kompatibilität, Bewertung und Installationszahlen geprüft, jeweils direkt von der Store-Seite des Plugins zum selben Stichtag. Alle vier laufen im Abo-Modell, keines ist ein Einmalkauf.

Preis- und Kompatibilitätsübersicht

Blog Premium für SW 6 (netzperfekt): 17,50 €/Monat, monatlich kündbar, mit Gratis-Probemonat. Kompatibel laut Store von 6.1.4 bis 6.7.13.0. Bewertung: 4,2/5 bei 19 Rezensionen, 1.964 Installationen, letztes Update am 05.08.2026.
Blog for Shopware 6 (Pixeleyes): 17,99 €/Monat, im Jahresabo 16,67 €/Monat (200 €/Jahr). Kompatibel 6.5.5.0 bis 6.7.13.0. Bewertung: 5,0/5 bei 7 Rezensionen, 145 Downloads, letztes Update am 05.08.2026.
Blog/Magazine (Shop Studio): 14,99 €/Monat, im Jahresabo 12,50 €/Monat (149,99 €/Jahr). Kompatibel 6.5.0.0 bis 6.7.13.0. Bewertung 4,7/5 bei 7 Rezensionen und 709 Downloads – beide Werte waren im vorherigen Stand noch „nicht geprüft“ und sind jetzt nachgetragen. Letztes Update am 18.08.2026.
Blog Magazine Add-On inkl. WordPress-Import (moorl): 25,00 €/Monat bzw. 270 €/Jahr (10 % Rabatt im Jahresabo), kompatibel 6.2.0-RC1 bis 6.7.13.0, Bewertung 4,9/5 bei 7 Rezensionen, 630 Downloads, letztes Update am 19.08.2026. Zusätzlich wird laut Store-Angabe das moorl-„Foundation“-Plugin benötigt – die Basisversion davon ist kostenlos (Stand 23.08.2026). Moorl verkauft darüber hinaus aber ein separates, kostenpflichtiges Foundation-„Features Add-On“ (12,50 €/Monat bzw. 135 €/Jahr im Jahresabo); ob die Blog-Erweiterung davon zusätzliche Funktionen braucht, ließ sich aus den Store-Seiten nicht eindeutig klären – mindestens eine Nutzerbewertung nennt reale Gesamtkosten von rund 40 €/Monat bei Kombination mehrerer moorl-Plugins. Vor dem Kauf lohnt hier eine direkte Nachfrage beim Hersteller, ob die kostenlose Basisversion für den Blog ausreicht.

Am bekanntesten und am längsten am Markt ist netzperfekt mit „Blog Premium für SW 6“. Nach Angaben der plugin-eigenen Dokumentation läuft die Einrichtung über eigene Admin-Menüs für Sales-Channel-Zuordnung, Erlebniswelten-Verknüpfung sowie Autoren- und Kategorienverwaltung. Wichtig zur Einordnung: Diese Konfigurationsschritte sind plugin-eigene Admin-UI, nicht offiziell von Shopware dokumentiert – wir zitieren sie hier als Herstellerangabe, nicht als verifizierten Shopware-Standard.

netzperfekt Blog Premium Plugin-Konfiguration im Shopware-Backend (Admin-Menü mit Sales-Channel-Zuordnung, Autoren/Kategorien)

Zur Einordnung die Store-Seiten der drei anderen geprüften Plugins, Stand 23.08.2026:

Pixeleyes Blog for Shopware 6 Store-Seite mit Preisen und Bewertung im Shopware Store

Pixeleyes „Blog for Shopware 6“ im Shopware Store, Stand 23.08.2026.

Shop Studio Blog/Magazine Store-Seite mit Preisen und Bewertung im Shopware Store

Shop Studio „Blog/Magazine“ im Shopware Store, Stand 23.08.2026.

moorl Blog Magazine Add-On Store-Seite mit Preisen und Bewertung im Shopware Store

moorl „Blog Magazine Add-On“ im Shopware Store, Stand 23.08.2026.

Was für welches Plugin spricht

Wer die etablierteste, am häufigsten installierte Lösung sucht, landet meist bei netzperfekt – schon allein wegen der Installationszahl von knapp 2.000 Shops.
Wer Wert auf ein Jahresabo mit Rabatt legt, findet bei Pixeleyes und Shop Studio günstigere Monatspreise im Jahresvertrag.
Wer bestehende WordPress-Inhalte übernehmen will, ist bei moorl richtig – die als Abhängigkeit gelistete Foundation-Basisversion ist kostenlos, moorl bietet aber zusätzlich ein kostenpflichtiges Foundation-„Features Add-On“ (12,50 €/Monat) an, dessen Notwendigkeit für die Blog-Funktion sich nicht abschließend klären ließ.

Ein Punkt zur Transparenz: Die Kompatibilitätsangaben „bis 6.7.13.0“ stammen aus automatisierter Auswertung der Store-Seiten. Vor dem eigentlichen Kauf lohnt sich immer noch der direkte Blick auf die aktuelle Store-Seite, da sich Kompatibilitätsbereiche mit jedem Shopware-Minor-Release verschieben können.

Ein feature-seitiger Vergleich, welches Plugin „mehr kann“, lässt sich aus den geprüften Daten nicht seriös ableiten – dafür haben wir nur Preis und Kompatibilität, keine Tiefenanalyse der Funktionsumfänge durchgeführt. Was sich aber unabhängig vom konkreten Anbieter sagen lässt: Ein Blog-Plugin kauft man in Shopware nicht als Einmalinvestition, sondern als laufende Betriebskosten-Position. Bei einem Preis zwischen rund 15 und 25 Euro im Monat lohnt sich vorher die Überlegung, wie viele Jahre der Blog voraussichtlich betrieben wird – über drei oder fünf Jahre gerechnet, summiert sich das Abo zu einem Betrag, der in der Budgetplanung nicht unterschätzt werden sollte, gerade im Vergleich zu einer selbst gehosteten WordPress-Instanz, bei der die laufenden Kosten primär im Hosting liegen und nicht im Zusatz-Plugin selbst.

Zurück zur Übersicht

3. Shopware 6 Blog extern: WordPress als Alternative – und wie great2gether selbst bloggt

Die dritte Option: Der Blog läuft komplett außerhalb von Shopware, meist auf WordPress. In der Praxis wird das oft als Subdomain umgesetzt, zum Beispiel blog.mein-shop.de, oder als headless angebundene Content-Quelle über die WordPress-REST-API. Wichtig zur Einordnung: Für diesen Weg gibt es keine offizielle Shopware-Empfehlung – es handelt sich um reine Agentur- und Community-Praxis, die sich über Jahre etabliert hat, aber nicht Teil der offiziellen Doku ist.

Subdomain-Variante: WordPress läuft als eigenständige Installation, meist mit eigenem, optisch an den Shop angeglichenem Theme – technisch der einfachste Einstieg, aber zwei getrennte Systeme mit getrennter Pflege.
Headless-Variante: Der Shop zieht sich Blog-Inhalte per REST-API aus WordPress und rendert sie im eigenen Storefront-Layout – wirkt für Besucher wie ein einziges System, verlangt aber mehr Entwicklungsaufwand für Anbindung und Caching.

Zwischen beiden Varianten liegt im Kern ein klassischer Trade-off zwischen Einfachheit und Integrationstiefe. Es gibt aber noch eine dritte, in der Praxis oft übersehene Variante – und gerade bei der Frage, wie eng Blog und Shop technisch und aus Nutzersicht zusammengehören sollen, lohnt sich ein genauerer Blick auf alle drei nebeneinander:

Drei Varianten im Vergleich: Subdomain, Unterverzeichnis, Headless

Neben Subdomain (blog.shop.de) und Headless-Anbindung gibt es eine dritte, oft übersehene Option: das Unterverzeichnis per Reverse-Proxy (shop.de/blog). Dabei läuft WordPress auf einem eigenen oder gemeinsamen Server, und ein Reverse-Proxy vor der Haupt-Domain leitet alle Aufrufe unter /blog intern dorthin weiter – bei Nginx über einen location /blog { proxy_pass ...; }-Block, bei Apache über ProxyPass/ProxyPassReverse. Nach außen wirkt es wie ein normaler Shop-Pfad, im Hintergrund bedient ein komplett separates CMS die Anfrage.

Der Infrastruktur-Preis dafür ist überschaubar, aber real:

SSL: Ein Zertifikat für shop.de deckt /blog automatisch mit ab – die Subdomain braucht dafür zusätzlich ein SAN-Zertifikat oder einen Wildcard-Eintrag (*.shop.de).
Pfad-Rewriting: Der Proxy muss neben /blog auch /wp-content, /wp-includes, /wp-json und /wp-admin sauber durchreichen, sonst brechen Assets, Login oder REST-Endpunkte.
Siteurl-Konfiguration: WP_HOME/WP_SITEURL (bzw. „Standard-“/„WordPress-Adresse“ in den Einstellungen) müssen exakt auf https://shop.de/blog zeigen, inklusive Permalink-Basis – sonst erzeugt WordPress falsche interne Links oder leitet auf seine „echte“ Installations-URL um.

SEO: Wo die drei Varianten wirklich auseinanderlaufen

In der SEO-Szene hält sich seit Jahren die Faustregel, Suchmaschinen würden Subdomains tendenziell etwas eigenständiger bewerten als Verzeichnisse derselben Domain – Linkjuice flösse entsprechend schlechter zwischen blog.shop.de und shop.de als zwischen shop.de/blog und shop.de. Zur Einordnung: Das ist eine diskutierte Branchen-Faustregel, kein von Google offiziell bestätigter Fakt – Google selbst betont, beide Strukturen gleichwertig verarbeiten zu können. In der Praxis vieler SEOs profitieren Inhalte im Unterverzeichnis tendenziell zügiger von der Autorität der Hauptdomain, weil für Crawler eindeutiger ist, dass es dieselbe Property ist.

Unstrittiger sind die administrativen Unterschiede: Eine Subdomain braucht zwingend eine eigene robots.txt und eigene Sitemap (robots.txt gilt immer nur für den Host, unter dem sie liegt) – zwei Systeme, die synchron gehalten werden müssen. Beim Unterverzeichnis reicht eine robots.txt, die Blog-Sitemap hängt in den Sitemap-Index des Shops ein. Bei der internen Verlinkung sind Verweise Shop↔Blog im Unterverzeichnis normale interne Links ohne Domain-Grenze; bei der Subdomain bleiben es technisch funktionierende, aus Crawler-Sicht aber Cross-Host-Links. Bei Headless verschwindet die Unterscheidung ganz, weil der Blog-Content direkt auf Shop-URLs ausgeliefert wird.

Warum Kunden beim Wechsel von Blog zu Shop „ausgeloggt“ wirken

Cookies werden über das Domain-Attribut skaliert. Ohne explizites Domain-Attribut ist ein Cookie „host-only“ und gilt nur für die Domain, auf der es gesetzt wurde – blog.shop.de bekommt das Shop-Cookie nie zu sehen, obwohl beide Hosts derselben registrierbaren Domain angehören. Man könnte das Cookie explizit auf Domain=shop.de setzen, damit es auch auf der Subdomain ankommt – das allein reicht aber nicht: WordPress-Login-Cookies und Shopware-Kundensessions sind zwei grundverschiedene Formate mit getrennter Speicherung. Ohne echte SSO-Brücke bleibt ein Kunde, der vom Blog in den Shop wechselt, ein anonymer Besucher: kein gemeinsamer Login-Status, kein geteilter Warenkorb – außer beide Systeme werden explizit dafür verdrahtet.

Beim Unterverzeichnis entfällt das Problem strukturell, weil keine Domain-Grenze existiert. Bei Headless entfällt es ebenfalls, aber anders: Der Blog hat gar keine eigene Session, weil er nicht als eigenständige Anwendung läuft, sondern seine Inhalte per REST-API abruft und im Shop-Frontend rendert – Login und Warenkorb bleiben durchgehend in einem System.

Die Wartungslast, die im Angebot selten steht

Subdomain und Unterverzeichnis haben eines gemeinsam: Zwei vollständige CMS-Stacks laufen nebeneinander. Das bedeutet:

Zwei Patch-Zyklen – WordPress-Core, Theme und Plugins mit eigenen PHP-Versionsanforderungen, unabhängig vom PHP-Stand des Shops.
Zwei Backup-Regime – Datenbank und Dateisystem je System, oft mit unterschiedlichen Tools und Zeitplänen.
Zwei Stellen für Cookie-/Consent-Banner – die DSGVO-Einwilligung muss auf Shop und Blog sauber eingebunden sein, mit zwei Consent-Tools, die inhaltlich zueinander passen müssen.
Zwei Angriffsflächen – WordPress ist allein wegen seines hohen Marktanteils häufig Ziel automatisierter Angriffe, ein zusätzlicher Grund für konsequente Updates.
Bei der Subdomain zusätzlich: laufende DNS-Pflege (A/CNAME, Zertifikatsverlängerung) und ggf. eine zweite Hosting-Rechnung.

Headless spart sich das nicht komplett – WordPress bleibt als Content-Backend update- und backup-pflichtig –, eliminiert aber Consent-Duplikation und Angriffsfläche im ausgelieferten Frontend, weil Besucher WordPress nie direkt zu Gesicht bekommen.

Fazit: Welche Variante passt zu wem?

Subdomain: pragmatisch für kleine Teams/Agenturen, die schnell einen Blog wollen, ohne die Shop-Infrastruktur anzufassen – SEO-Kompromiss und doppelte Wartung werden bewusst in Kauf genommen.
Unterverzeichnis per Reverse-Proxy: die richtige Wahl, sobald SEO-Konsolidierung unter einer Domain Priorität hat und Server-/Proxy-Know-how für die einmalige Einrichtung vorhanden ist.
Headless: sinnvoll für Teams mit Entwicklungskapazität, die ein einheitliches Frontend, durchgehende Sessions und volle Design-Kontrolle wollen und WordPress konsequent auf reine Content-Verwaltung reduzieren.

An dieser Stelle einmal transparent: great2gether.com betreibt seinen eigenen Blog auf WordPress. Das ist kein verstecktes Cross-Selling für ein eigenes Plugin – wir haben kein Blog-Produkt im Sortiment und wollen an dieser Stelle auch keins künstlich hineinschreiben. Für ein reines Content-Thema wie Bloggen ist WordPress für uns schlicht das pragmatischere Werkzeug, während unsere Shopware-Arbeit sich auf Theme und Shop-nahe Funktionen konzentriert. Wer overhead-arm bloggen will und sowieso schon WordPress-Erfahrung hat, trifft mit dieser Kombination selten eine falsche Entscheidung.

Zurück zur Übersicht

4. Shopware 6 Blog in der Praxis: Fehlerbilder aus der Community

Wer die drei Wege abwägt, sollte auch die typischen Stolperfallen kennen, die in der Shopware-Community dokumentiert sind.

Anbieterabhängigkeit bei kostenlosen Plugins: Ein Forumsnutzer berichtete Anfang 2024, dass das bis dahin einzige kostenlose Blog-Plugin für Shopware 6 kostenpflichtig wurde. Seine Reaktion: Umstieg auf eine selbstgebaute Headless-WordPress-Anbindung per REST-API, inklusive eigenem Datenbank-Caching der WordPress-Artikel, um die API nicht bei jedem einzelnen Seitenaufruf neu abzufragen. Das ist eine Einzelmeinung, kein Herstellerrat – zeigt aber ein reales Risiko von kostenlosen Nischen-Plugins: Das Geschäftsmodell kann sich jederzeit ändern.
SEO-Lücken bei Erlebniswelten als Blog-Ersatz: Wie oben ausführlich anhand des Codes gezeigt, fehlen bei reinen Landingpage-Lösungen ohne Plugin eigene Meta-Felder, ein individuelles Social-Bild und strukturierte Daten pro Artikel – ein technisch relevanter Nachteil für alle, die versuchen, sich ein Blog-Plugin zu sparen.
Offene Bugs bei Open-Source-Alternativen: „OpenBlogware“ auf GitHub, ein Fork eines älteren MIT-lizenzierten Plugins, dessen Original-Quellcode nicht mehr öffentlich verfügbar ist, setzt ab Version 5 Shopware 6.7+ voraus. Aktuell listet das Repository zwei offene Issues: Der Blog wird nach der Installation teilweise nicht angezeigt (gemeldet Juli 2026) und es gibt einen Bug im Auflistungs-Element (gemeldet April 2026). Als kostenlose Option durchaus erwähnenswert – aber wer produktiv geht, sollte diese offenen Punkte einplanen, nicht als sorgenfreie Lösung erwarten.

Ein roter Faden zieht sich durch alle drei Fehlerbilder: Wer Kosten sparen will, indem er auf ein etabliertes, bezahltes Plugin verzichtet – sei es durch ein kostenloses Nischen-Plugin, durch Erlebniswelten als Behelfslösung oder durch ein Open-Source-Projekt mit offenen Issues – verschiebt den Aufwand meist nur von der Anschaffung auf den laufenden Betrieb. Das muss keine falsche Entscheidung sein, sollte aber bewusst getroffen werden und nicht als vermeintlich kostenlose Option missverstanden werden.

Zurück zur Übersicht

5. Shopware 6 Blog FAQ: Häufige Fragen kurz beantwortet

Hat Shopware 6.7 mittlerweile ein natives Blog-Modul?

Nein. Auch in Version 6.7.13.0 (Stand 23.08.2026) gibt es kein eigenes Blog-Element, keine Blog-Tabelle und keinen Blog-Befehl im Core. Das lässt sich sowohl über die offizielle Doku als auch direkt im Quellcode des Shopware-Repositories nachvollziehen. Wer diese Recherche selbst nachvollziehen möchte, findet die relevanten Core-Pfade in den Quellenangaben am Ende dieses Artikels.

Ist die 2022er-Blog-ADR ein Hinweis auf ein kommendes Feature?

Es gibt seit Juli 2022 tatsächlich ein dokumentiertes Konzept dafür, wie ein natives Blog auf Basis von Custom Entities und Erlebniswelten aussehen könnte (die Architecture Decision Record „Concept for blogs using Shopping Experiences“) – gebaut wurde daraus aber nie etwas: Die ADR trägt bis heute keine Status-Markierung wie „Accepted“ oder „Implemented“ und ist seit 2022 unverändert ein Konzept geblieben. Dass „kommt bald“-Ankündigungen zu diesem Thema bei Shopware eine lange, unerfüllte Geschichte haben, zeigt ein noch älterer Beleg: Schon im Februar 2020 kündigte ein Shopware-Mitarbeiter im Forum einen Entwicklungsstart „im 2. Halbjahr 2020“ an – das ist über sechs Jahre her und bis heute nicht eingetreten. Vorsichtshalber sollte man deshalb nicht mit einer baldigen nativen Umsetzung planen und stattdessen eine der drei hier vorgestellten Lösungen einsetzen, wenn ein Blog kurzfristig gebraucht wird.

Welches Blog-Plugin ist im Shopware Store am günstigsten?

Von den vier geprüften Plugins ist Shop Studios „Blog/Magazine“ mit 14,99 €/Monat (bzw. 12,50 €/Monat im Jahresabo) das günstigste. netzperfekt liegt bei 17,50 €/Monat, Pixeleyes bei 17,99 €/Monat, moorl bei 25 €/Monat. Die dafür benötigte Foundation-Basisversion ist kostenlos; ob zusätzlich das kostenpflichtige Foundation-„Features Add-On“ (12,50 €/Monat) für den vollen Blog-Funktionsumfang nötig ist, war aus den Store-Seiten nicht eindeutig zu klären – hier lohnt vor dem Kauf eine Nachfrage beim Hersteller. Alle Angaben Stand 23.08.2026, direkt von den Store-Seiten.

Kann ich statt eines Plugins auch einfach Erlebniswelten als Blog nutzen?

Technisch ja, aber mit strukturellen Einschränkungen: Wie im Abschnitt zu Erlebniswelten und Custom Entities im Detail anhand des Codes gezeigt, fehlen der Erlebniswelt eigene Meta-Title/-Description-Felder pro Content-Seite, ein individuelles Social-Vorschaubild und ein Article-Schema für strukturierte Daten – ein spürbarer SEO-Nachteil gegenüber einem echten Blog-System.

Empfiehlt Shopware offiziell eine WordPress-Subdomain für den Blog?

Nein, dafür gibt es keine offizielle Shopware-Empfehlung. Es handelt sich um eine in der Agentur- und Community-Praxis verbreitete Lösung, nicht um einen von Shopware dokumentierten Weg – das gilt genauso für die Unterverzeichnis- und Headless-Varianten.

Zurück zur Übersicht