Was wir selbst gemessen haben
Kein Zusammenfassen fremder Quellen: eigene Testaufbauten, benannte Versionen, nachvollziehbare Ergebnisse. Jede Untersuchung nennt Fragestellung, Messaufbau, Ergebnis — und was daraus nicht folgt.
Zwanzig Storefront-Funktionen gegen die Store API
Untersucht: Welche Funktionen einer Shopware-Storefront lassen sich über die Store API nachbauen — und welche nicht?
Ergebnis
20 von 20 erreichbar
Alle zwanzig geprüften Handelsfunktionen antworten über die Store API. Was fehlt, ist keine Handelsfunktion, sondern die Maschinerie einer HTML-Storefront. Davon ist für ein Headless-Frontend genau eines relevant: das Captcha, für das es null Store-API-Routen gibt.
Ein Produkt, sieben indexierbare URLs
Untersucht: Wie viele indexierbare URLs erzeugt ein Shopware-Produkt mit Varianten, und worauf zeigt jede davon als kanonische Fassung?
Ergebnis
7 URLs, 6 selbstkanonisch, 6 in der Sitemap
Jede der sechs Varianten bekommt eine eigene SEO-URL, weist sich selbst als kanonisch aus, trägt index,follow und steht in der Sitemap des Kerns. Die Seite des Hauptprodukts kanonisiert nicht auf sich selbst, sondern auf die erste Variante — und steht selbst nicht in der Sitemap. In 6.6.10.6 und 6.7.13.1 identisch, bei zwei Produkten mit unterschiedlicher Variantenzahl und in beiden Sprachen.
Ein Artikel im Warenkorb kostet den HTTP-Cache
Untersucht: Unter welchen Bedingungen liefert Shopware eine Seite aus dem HTTP-Cache aus — und was kostet es, wenn diese Bedingungen nicht erfüllt sind?
Ergebnis
3,4 ms gegen 40 ms
Bei leerer Sitzung wird eine Kategorieseite nach dem ersten Aufruf aus dem Cache bedient und antwortet in 3,3 bis 3,5 ms. Liegt ein einziger Artikel im Warenkorb, fällt kein Abruf mehr unter 36 ms — Faktor gut zwölf, und zwar für jede Seite dieser Sitzung, nicht nur für den Warenkorb.
Unsichtbar im Shop, sichtbar im Index
Untersucht: Steuert die Sichtbarkeit eines Produkts im Verkaufskanal auch, ob seine Detailseite abrufbar und indexierbar ist?
Ergebnis
Nein — Sichtbarkeit und Indexierbarkeit sind getrennt
Die zehn Varianten beider Runtimes haben keine Zeile in product_visibility und erscheinen entsprechend in keinem Listing und keiner Suche. Ihre Detailseiten antworten trotzdem mit HTTP 200, tragen index,follow, sind selbstkanonisch und stehen in der Sitemap des Kerns. Wer ein Produkt aus dem Shop nimmt, hat es nicht aus dem Index genommen.
Wie groß das Datenmodell von Shopware wirklich ist
Untersucht: Wie viele Entitäten führt der Shopware-Kern tatsächlich, wie viele davon sind übersetzbar und wie viele erlauben Custom Fields — und was ändert sich zwischen 6.6 und 6.7?
Ergebnis
231 Kernentitäten in 6.7 gegen 217 in 6.6
Übersetzbar sind 49 davon (6.6: 44), Custom Fields erlauben 85 (6.6: 83). Die Rohsummen inklusive der installierten Erweiterungen liegen bei 247 und 228. Der Zuwachs von 14 Kernentitäten ist kein gleichmäßiges Wachstum: Ein neues Maßsystem bringt allein zwei Übersetzungstabellen mit.
Shopware hat einen MCP-Server — und er ist abgeschaltet
Untersucht: Was steckt an MCP-Unterstützung im Shopware-Kern, ist sie benutzbar, und was darf ein angeschlossener KI-Agent damit tun?
Ergebnis
11 Werkzeuge, 8 Ressourcen, ab Werk 404
6.7.13.1 trägt 61 MCP-Dateien und 54 Routen im Kern, 6.6.10.6 keine einzige. Ohne das Feature-Flag MCP_SERVER antwortet /api/_mcp mit 404. Mit Flag meldet der Server Protokollversion 2025-11-25 und elf Werkzeuge — drei davon schreiben, eines löscht.
Was ein Versionssprung an der Datenbank wirklich tut
Untersucht: Was ändert ein Sprung von Shopware 6.6 auf 6.7 tatsächlich am Datenbankschema — und welche dieser Änderungen können eine bestehende Integration brechen?
Ergebnis
23 neue Kerntabellen, 3 entfallene Spalten
Dazu 47 neue Spalten in bestehenden Tabellen und 12 Typänderungen. Keine Tabelle ist entfallen. Das Risiko für Integrationen liegt nicht bei den 23 neuen Tabellen — die stören niemanden —, sondern bei den drei entfallenen Spalten und vier Typänderungen, die aus einer erlaubten NULL eine Pflichtangabe machen.
Wie groß Shopwares API wirklich ist
Untersucht: Wie viele Endpunkte haben Shopwares Admin-API und Store-API tatsächlich — und wie viele davon sind eigens geschriebene Funktionen statt generierter CRUD-Operationen?
Ergebnis
87 Store-API gegen 2.248 Admin-API
Zahlen des Kerns, um die Routen der installierten Erweiterungen bereinigt. Von den 2.248 Admin-Routen sind 2.000 generierte CRUD-Operationen und 179 eigens geschriebene _action-Endpunkte. Die kundenseitige Store-API hat 87 Endpunkte. Wer eine Integration plant, rechnet mit 179 und 87 — nicht mit 2.248.
Wenn der Hoster den KI-Crawler blockt
Untersucht: Warum kamen zwei KI-Crawler nicht auf die eigene Website, obwohl die robots.txt allen Zugriff erlaubte?
Ergebnis
3 von 18 Kennungen ohne HTTP-Status abgewiesen
TLS-Handshake gelingt vollständig, dann schliesst der Server die Verbindung. Ursache ist eine Bot-Liste im Hosting-Panel, die als Teilzeichenkette im User-Agent greift — auf jedem Pfad, auch auf /robots.txt selbst.
Agentic-Commerce-Feed: was Shopware tatsächlich prüft
Untersucht: Welche Fehler in einem Agentic-Commerce-Produktfeed findet Shopware 6.7 selbst — und unter welchen Bedingungen prüft es gar nicht?
Ergebnis
10 von 10 Fehlerfällen erkannt
Jeder gezielt eingebaute Defekt wurde gemeldet, die korrekte Zeile ging fehlerfrei durch. Entscheidend ist aber die andere Hälfte des Befunds: Drei Vorbedingungen führen dazu, dass der Validator ohne jede Meldung gar nichts prüft.