Headless-Commerce-Plattformen

TL;DR — Eine Headless-Commerce-Plattform ist die Engine für Produkte, Warenkorb und Checkout. Sie übergibt diese Daten an ein separates, von Ihnen gebautes Storefront. Die Behauptung, solche Plattformen seien sofort SEO-optimiert, stimmt nur teilweise. Shopify Hydrogen und BigCommerce Catalyst liefern echte SEO-Bausteine wie Sitemap, robots.txt und Metadatenhilfen. Medusa, Saleor und Elastic Path überlassen diese Aufgaben vollständig Ihrem Team. Entscheidend ist, wie viel Sie selbst bauen möchten und wie viel die Plattform bereits mitbringt.

Was hier tatsächlich verglichen wird

In einem gewöhnlichen Shopify- oder WooCommerce-Shop erledigt ein System alles: Es speichert Produkte, verarbeitet Bestellungen und rendert die Seiten, die Käufer und Google sehen. Ein Headless-Setup trennt diese Aufgaben. Eine Commerce-Engine verwaltet Produkte, Bestand und Checkout und übergibt die Daten per API an ein separates Frontend, das die sichtbare Website rendert.

Diese Commerce-Engine ist die Headless-Commerce-Plattform. Zu den wichtigsten Angeboten Mitte 2026 gehören Shopify mit Hydrogen und Storefront API, BigCommerce mit Catalyst, commercetools, Salesforce Commerce Cloud mit PWA Kit sowie Medusa, Saleor und Elastic Path.

Das wichtigste Auswahlkriterium

Für SEO unterscheiden sich die Plattformen kaum darin, ob Ihre Seiten crawlbar sein können. Das hängt vom Rendering des Frontends ab; der Hub zu Headless-Ecommerce-SEO behandelt SSR, SSG und CSR ausführlich. Der eigentliche Unterschied ist, wie viele SEO-Bausteine Sie erhalten und wie viel Sie selbst entwickeln müssen.

Es gibt drei Gruppen:

• Viele fertige Bausteine. Shopify Hydrogen und BigCommerce Catalyst liefern ein funktionsfähiges Referenz-Storefront mit Sitemap, robots.txt und vorbereiteter Verwaltung von Title-Tags und Metabeschreibungen.
• Hilfen statt fertiger Lösung. commercetools und Salesforce PWA Kit stellen Werkzeuge zum Aufbau einer Sitemap bereit, deren Routen Sie selbst zusammensetzen.
• Keine SEO-spezifischen Bausteine. Medusa, Saleor und Elastic Path liefern Produktdaten über APIs. Sitemap, Metadaten und robots.txt liegen vollständig beim Frontend, meist auf Basis von Next.js.

Der häufigste Irrtum

„Sofort SEO-optimiert“ beschreibt ein Spektrum, kein Ja-Nein-Merkmal. Fast jeder Anbieter wirbt damit. Der eigene SEO-Beitrag von Elastic Path erwähnt jedoch weder Sitemaps noch Canonicals oder Weiterleitungen. Fragen Sie deshalb konkret: Welche Funktionen liefert die Plattform für Sitemaps, Metadaten, Weiterleitungen und den Schutz der Staging-Website vor der Indexierung? Die Antworten unterscheiden sich erheblich.

Den vollständigen Plattformvergleich, die Risiken von Preview-Umgebungen und eine Entscheidungshilfe finden Sie im Tab Fortgeschritten.

TL;DR — Headless-Commerce-Plattformen reichen von umfangreichen SEO-Bausteinen bis zur vollständigen Eigenverantwortung. Shopify Hydrogen bietet mit getSeoMeta, Sitemap-Routen, robots.txt und der automatischen Crawler-Sperre von Oxygen den größten fertigen Umfang. BigCommerce Catalyst reicht den BigCommerce-Sitemap-Index durch und nutzt generateMetadata des Next.js App Routers. commercetools Frontend und Salesforce PWA Kit liefern SDK- beziehungsweise API-Hilfen, aber keine fertigen Routen. Medusa, Saleor und Elastic Path überlassen die gesamte SEO-Schicht dem Frontend. Plattformabhängig sind vor allem ungewollt indexierbare Preview-Umgebungen und Weiterleitungspläne. Die Plattform bestimmt die mitgelieferten Bausteine; die Crawlability bleibt eine Frage des Renderings.

Plattformwahl und Rendering sind getrennte Entscheidungen

Ob Googlebot vollständiges HTML oder nur eine leere Hülle erhält, entscheidet das Rendering-Modell des Frontends: serverseitiges Rendering (SSR), statische Generierung (SSG) oder clientseitiges Rendering (CSR). Diese Aufgabe gehört zum Frontend-Framework und wird im Hub zu Headless-Ecommerce-SEO ausführlich behandelt. SSR und CSR werden hier daher nicht erneut erklärt.

Die Commerce-Plattform entscheidet dagegen über den geerbten SEO-Unterbau: Sitemap, Metadatenlogik, robots.txt und die Behandlung von Preview-Umgebungen. Auch ein sauberes SSR-Setup auf Medusa hat keine Sitemap, bis Sie eine erstellen. Umgekehrt kann ein CSR-Fehler in Hydrogen eine Produktseite unbrauchbar machen, obwohl alle übrigen Bausteine vorhanden sind. Halten Sie beide Achsen getrennt: Rendering = Crawlability; Plattform = SEO-Unterbau.

Das Spektrum der SEO-Tools

So ordnen sich die sieben Plattformen ein:

Fertige Werkzeuge und ein angebundenes Referenz-Storefront: Shopify Hydrogen, BigCommerce Catalyst.

SDK-Hilfen statt fertiger Routen; die Sitemap wird selbst zusammengesetzt: commercetools Frontend, Salesforce PWA Kit.

Keine SEO-spezifischen Bausteine; das Frontend übernimmt alles: Medusa, Saleor, Elastic Path.

Diese Einordnung bildet den Rahmen für die folgenden Plattformdetails.

Shopify Hydrogen (Storefront API)

Hydrogen ist Shopifys Headless-Framework und bietet den vollständigsten SEO-Unterbau der hier untersuchten Plattformen. Eine wichtige Korrektur: Hydrogen basiert nicht mehr auf Remix. Laut npm-Register verwendet @shopify/hydrogen 2026.4.4 react-router ~7.16.0 als Peer-Abhängigkeit und besitzt keine Remix-Abhängigkeit; @shopify/remix-oxygen trägt inzwischen einen formellen Veraltungshinweis und verweist auf Importe aus react-router. Shopifys SEO-Dokumentation hinkt den Paketmetadaten hinterher und enthält weiterhin den exakten Satz “Hydrogen uses Remix’s built-in meta features for SEO tags” (Übersetzung) „Hydrogen verwendet die integrierten meta-Funktionen von Remix für SEO-Tags.“ Prüfen Sie bei einem neuen Projekt deshalb package.json statt nur den Fließtext.

Metadaten – eine eigens entwickelte Hilfe. Unabhängig von der Router-Bezeichnung liefert Hydrogen getSeoMeta, um SEO-Metadaten konsistent zu rendern. Die Hilfe deckt Titel, Beschreibungen, Bilder, Canonical-URLs und JSON-LD ab und ist damit eine echte Abstraktion statt einer bloßen Aufforderung, einen eigenen <head> zu bauen. Shopify merkt außerdem an: “By default Hydrogen removes query parameters from canonical URLs” (Übersetzung) „Standardmäßig entfernt Hydrogen Abfrageparameter aus Canonical-URLs.“ Diesen sinnvollen Standard können Sie in den Meta-Exports überschreiben.

Sitemap – mitgeliefert und selbstaktualisierend. Das Hydrogen-Grundgerüst enthält sitemap.xml und typspezifische Sitemap-Routen. getSitemap erzeugt Sitemaps je Ressourcentyp einschließlich Sprachalternativen. Die Dateien werden 24 Stunden zwischengespeichert; veröffentlichte oder entfernte Produkte erscheinen innerhalb dieses Fensters automatisch, ohne dass Sie einen geplanten Auftrag betreuen müssen.

robots.txt – mit Preview-Schutz. Das Template enthält eine robots.txt-Route. Shopify beschreibt den Unterschied so: “If you make a non-production deployment accessible with a shareable link or an auth bypass token, then Oxygen overrides the deployment’s robots.txt file with a disallow rule for all bots and crawlers.” (Übersetzung) „Wenn ein Nicht-Produktions-Deployment über einen teilbaren Link oder ein Token zur Umgehung der Authentifizierung erreichbar wird, überschreibt Oxygen dessen robots.txt mit einer Sperrregel für alle Bots und Crawler.“ Oxygen blockiert Crawler auf solchen Deployments automatisch und verhindert damit die Indexierung doppelter Staging-Inhalte, die bei anderen Plattformen manuell unterbunden werden muss.

Was bei Ihnen bleibt: Prüfen Sie, dass keine Produkt- oder Kategorieroute versehentlich als Resource-Route ohne SSR angelegt wurde. Der Framework-Modus von React Router verwendet dasselbe Server-Loader-Muster wie Remix vor der Hydrogen-Migration. Konfigurieren Sie außerdem das Oxygen-Caching; die fortgeschrittene Hub-Linse behandelt veraltete Caches.

Headless-BigCommerce (Catalyst)

Catalyst ist das Referenz-Storefront von BigCommerce für den Next.js App Router. Sein SEO-Unterbau ist real, architektonisch jedoch anders als bei Hydrogen.

Sitemap – durchgereicht statt generiert. Laut Catalyst-Dokumentation gilt: “Catalyst acts as an intermediary when handling requests to /sitemap.xml.” (Übersetzung) „Catalyst fungiert bei Anfragen an /sitemap.xml als Vermittler.“ Catalyst ruft den Sitemap-Index anhand der Canonical-URL des Kanals aus BigCommerce ab und gibt das XML zurück. Die Sitemap scheint vom Storefront zu kommen, ihre Daten liegen jedoch in BigCommerce – anders als bei Hydrogen, wo die Route Teil der App ist. BigCommerce warnt außerdem: “If your storefront also uses third-party systems that generate content with different URLs, you will need to submit multiple sitemaps to cover the URLs from various sources,” (Übersetzung) „Wenn Ihr Storefront zusätzlich Drittsysteme verwendet, die Inhalte unter anderen URLs erzeugen, müssen Sie mehrere Sitemaps für die verschiedenen Quellen einreichen.“ Sitemaps “don’t need to reside on the same domain as the website they represent” (Übersetzung) „müssen nicht auf derselben Domain liegen wie die Website, die sie abbilden“. Das ist für mehrere Kanäle flexibel, aber riskant, wenn deren Canonical-Domains falsch konfiguriert sind.

Metadaten – Next.js-Konventionen. Catalyst befüllt generateMetadata und alternates.canonical je Route serverseitig aus GraphQL-Daten der Storefront API. Das entspricht dem Standardmuster des App Routers, das der Next.js-SEO-Artikel erläutert.

Migrationswarnung. Beim Wechsel vom älteren Stencil-Theme zu Catalyst ist URL-Parität entscheidend. Dan Kogan von 1Digital Agency formuliert es im Catalyst-SEO-Leitfaden so: “Do not change established URLs on a Stencil-to-Catalyst migration. Every product, category, and content URL should match the legacy structure exactly, or you need a complete 301 redirect map.” (Übersetzung) „Ändern Sie bei einer Migration von Stencil zu Catalyst keine etablierten URLs. Jede Produkt-, Kategorie- und Inhalts-URL sollte der bisherigen Struktur exakt entsprechen; andernfalls benötigen Sie eine vollständige 301-Weiterleitungsmap.“ Er nennt außerdem wiederkehrende Catalyst-Regressionen: generateMetadata fällt wegen einer in eine Client-Komponente verschobenen GraphQL-Abfrage auf einen reinen Client-Fallback zurück, Canonicals fehlen in paginierten Listen oder Product-JSON-LD wird doppelt ausgegeben. Prüfen Sie all das vor dem Start.

commercetools (Frontend / composable storefronts)

commercetools ist die Composable-/MACH-Option für Unternehmen. Der SEO-Unterbau fällt schlanker aus: Sie erhalten SDK-Hilfsmethoden, aber keine fertigen Routen.

Laut Frontend-Dokumentation verwendet commercetools drei getrennte Sitemaps für statische Seiten, Produktseiten und Kategorieseiten, die in einem Sitemap-Index zusammenlaufen. Statische Seiten stammen aus sdk.page.getPages(), Produkte aus extensions.product.query() und Kategorien aus extensions.product.queryCategories(). Die Einrichtung erfolgt nicht automatisch: Sie benötigt das Frontend Add-On und drei manuell angelegte Next.js-Route-Handler (sitemap-static.xml/route.tsx, sitemap-products.xml/route.tsx, sitemap-categories.xml/route.tsx) sowie ein Postbuild-Skript für die endgültige /sitemap.xml. Produkt- und Kategorieabfragen sind cursorbasiert paginiert und auf 500 Elemente pro Anfrage begrenzt. Große Kataloge benötigen daher Paginierungslogik innerhalb des Sitemap-Generators. Unter den Unternehmensplattformen verlangt commercetools bei Sitemaps den größten Eigenbau, passend zum bewusst unvoreingenommenen Frontend-Ansatz.

Headless Salesforce Commerce Cloud (PWA Kit / Composable Storefront)

Unter den Plattformen mit offiziellem Referenz-Storefront ist das SEO-Werkzeugangebot von PWA Kit am stärksten fragmentiert und am manuellsten.

Sitemap – der Pfad verzweigt sich. Laut Salesforce erstellen Sie die Sitemap im Business Manager, wenn dort auch die Routen konfiguriert sind. Liegen die Routen außerhalb davon, etwa in einem eigenen PWA-Kit-Routing, bauen oder ergänzen Sie die Sitemap über einen API-Endpunkt. Es gibt keinen einheitlichen automatischen Weg. Für PWA-Kit-Deployments umfassen die manuellen Schritte einen Pfad in der ssr.js-Konfiguration, eine Aktualisierung von ssrShared, ein erneutes Deployment und die Prüfung der Erreichbarkeit. Salesforce empfiehlt einen geplanten Auftrag, der die Sitemap aktuell hält; anders als bei Hydrogens 24-Stunden-Aktualisierung reagieren Katalogänderungen nicht automatisch. Die integrierte Sitemap-Verarbeitung wurde im PWA-Kit-Repository als weiterhin manueller Bereich angefragt. Das ist ein Community-Signal für eine bekannte Lücke, keine offizielle Aussage.

Metadaten – an Page Designer gebunden. Der Hook usePage() aus @salesforce/commerce-sdk-react und die Komponente <Page> stellen Seitenname, Beschreibung und Route für SEO-Metadaten bereit. Die Felder hängen jedoch am CMS-ähnlichen Inhaltsmodell von Salesforce Page Designer und nicht an einer eigens entwickelten SEO-Hilfe wie Hydrogens getSeoMeta.

Medusa, Saleor und Elastic Path – reine APIs

Diese drei Plattformen überlassen die SEO-Schicht vollständig dem implementierenden Team.

Medusa ist ein reines Commerce-Backend ohne Vorgaben zum Frontend-Rendering und daher ohne eigene SEO-Dokumentation. Das Next.js-Starter-Storefront unterstützt den App Router mit React Server Components und damit SSR. Metadaten, Sitemap und Canonicals folgen jedoch vollständig Ihrer Next.js-Implementierung. Der Next.js-SEO-Artikel ist deshalb die relevante Referenz.

Saleor folgt demselben Muster: eine GraphQL-first Headless-API auf Python/Django mit Next.js-Storefront-Templates aus Community und Vercel. SEO hängt zu 100% vom gewählten Frontend ab und liegt damit in derselben Kategorie wie Medusa.

Elastic Path ist API-first und stellt Metadaten als Rohfelder bereit, die Sie selbst verdrahten. Produkt- und Kategorieentitäten unterstützen benutzerdefinierte SEO-Felder, die laut Elastic Path “accessed via APIs just like the content that you render to your customers” (Übersetzung) „genau wie die für Kunden gerenderten Inhalte über APIs abgerufen werden können“. Das ist ein Muster für ein eigenes Schema, keine fertige Hilfe. Die Slug-Ressource wird als “lower case, uri friendly string” (Übersetzung) „kleingeschriebene, URI-freundliche Zeichenfolge“ beschrieben. Der herstellereigene SEO-Beitrag zu Headless Commerce von Kirsten Aebersold sagt: “If you are dynamically building a page with a JavaScript framework alone, you might want to look into serving up cached versions of the pages to the bots.” (Übersetzung) „Wenn Sie eine Seite allein dynamisch mit einem JavaScript-Framework erstellen, sollten Sie erwägen, Bots zwischengespeicherte Versionen der Seiten auszuliefern.“ Sitemaps, Canonicals, Weiterleitungen und Preview-Umgebungen bleiben unerwähnt. „Sofort SEO-optimiert“ ist deshalb eine weitreichende Behauptung.

Keine dieser drei Plattformen ist grundsätzlich schlecht für SEO; es gibt keine plattformbedingte Obergrenze. Es gibt aber auch keinen mitgelieferten Unterbau. Das Ergebnis hängt vollständig vom entwickelten Frontend ab.

Preview- und Staging-Lecks – das plattformabhängige Risiko

Hier bewirkt die Plattformwahl einen konkreten, messbaren SEO-Unterschied.

Hydrogen/Oxygen sperrt alle Crawler automatisch auf Preview- und teilbaren Link- Deployments. Dieser integrierte Schutz verhindert, dass eine Staging-Website indexiert wird und als doppelter Inhalt mit der Produktion konkurriert. Für Catalyst, commercetools und PWA Kit ist keine gleichwertige automatische Garantie dokumentiert. 1Digital Agency nennt von Googlebot indexierte Preview-Deployments als wiederkehrenden Fehler bei Catalyst- Migrationen. Das ist eine einzelne Praktikerquelle, keine offizielle Plattformfeststellung. Die allgemeine Regel bleibt: Wenn die Plattform Preview-Crawler nicht automatisch blockiert, tun Sie es selbst – mit Authentifizierung sowie ergänzend robots.txt oder einem noindex-Header für jede Nicht-Produktionsumgebung.

Weiterleitungen – Migrationsthema statt Plattformfunktion

Keine geprüfte Plattform liefert ein automatisches Weiterleitungssystem. Jede Headless- Migration – von Stencil zu Catalyst, vom Monolithen zu Headless oder zwischen Commerce- Engines – benötigt eine ausdrückliche 301-Zuordnung alter zu neuer URLs. Berichte zu Migrationen führen Fehlschläge immer wieder auf fehlende Weiterleitungen, geänderte URL-Strukturen und Lücken bei strukturierten Daten zurück. Starten Sie nie ohne geprüfte 301-Map. Die vollständige Checkliste steht im Artikel zu Website-Migrationen. Für diese Plattformen gilt: Gehen Sie nicht davon aus, dass eine der Engines Weiterleitungen für Sie verwaltet.

Portabilität ist der unterschätzte Vorteil

Ein Plattformwechsel bedeutet nicht, SEO von Grund auf neu zu bauen. Die Rendering- Schicht – Ihr Next.js- oder React-Router-Storefront – bestimmt die Crawlability und lässt sich weitgehend zwischen Commerce-Backends übertragen. Ein Next.js-Storefront kann mit vorwiegend auf die Datenschicht begrenzten Änderungen auf BigCommerce, Medusa, Saleor oder commercetools zugreifen. Beim Plattformwechsel ändert sich der Unterbau: Herkunft der Sitemap-Daten, vorhandene Metadatenhilfen sowie die Verwaltung von Weiterleitungen und Previews. Das ist eine bedeutsame Neuverdrahtung, aber kein kompletter Neustart.

Bewerten Sie auch die API-Qualität nicht übermäßig als SEO-Signal. Eine GraphQL- oder REST- API bestimmt lediglich, welche Daten für Metadaten und Sitemaps verfügbar sind. Ob diese Daten Google tatsächlich serverseitig erreichen, entscheidet das Frontend-Rendering.

Wie es weitergeht

• Headless-Ecommerce-SEO – der Hub zur Wahl zwischen SSR, SSG und CSR, zu strukturierten Daten (Product, ProductGroup/hasVariant) und zur Unabhängigkeit des GMC-Feeds vom Rendering.
• Next.js-SEO – die technische Referenz zu generateMetadata und sitemap.ts für Catalyst-, commercetools-, Medusa- und Saleor-Storefronts.
• JavaScript-SEO – allgemeine Fehlerbilder des JS-Renderings für jedes stark JavaScript-basierte Storefront.

KI-Zusammenfassung

Die wichtigsten Punkte der fortgeschrittenen Fassung:

• Plattformwahl ist nicht Renderingwahl. Die Crawlability folgt dem Rendering-Modell des Frontends (SSR, SSG oder CSR). Die Commerce-Plattform bestimmt den geerbten SEO-Unterbau.
• Drei Stufen:
  • Fertige Werkzeuge: Shopify Hydrogen mit getSeoMeta, Sitemap-Routen, robots.txt und Oxygen-Preview-Schutz sowie BigCommerce Catalyst mit durchgereichter Sitemap und Next.js-generateMetadata.
  • SDK-Hilfen statt Routen: commercetools Frontend mit drei manuell verdrahteten Sitemaps und 500-Element-Paginierung sowie Salesforce PWA Kit mit abhängig vom Routing gewähltem Sitemap-Pfad und geplanter Regenerierung.
  • Keine SEO-spezifischen Bausteine: Medusa, Saleor und Elastic Path sind reine Commerce-APIs; das Next.js-Frontend übernimmt die SEO-Schicht.
• Metadaten: Nur Hydrogen liefert mit getSeoMeta eine dedizierte SEO-Metadatenhilfe für Titel, Beschreibung, Bild, Canonical und JSON-LD. Alle anderen stellen Rohfelder bereit.
• Preview-/Staging-Lecks: Hydrogen/Oxygen blockiert Crawler auf teilbaren Preview-Links automatisch. Für Catalyst, commercetools und PWA Kit ist keine gleichwertige Garantie dokumentiert.
• Weiterleitungen: Keine Plattform automatisiert den 301-Plan einer Migration.
• Portabilität: Ein Next.js-Frontend lässt sich weitgehend wiederverwenden; beim Wechsel wird der SEO-Unterbau neu verdrahtet, nicht die gesamte SEO neu gebaut.
• Fazit: „Sofort SEO-optimiert“ beschreibt ein Spektrum und muss anhand konkreter Funktionen geprüft werden.

Welche Headless-Commerce-Plattform eignet sich für SEO?

Dieser Entscheidungsbaum behandelt den SEO-Unterbau, nicht Geschäftsmodell oder Preis. An jedem Knoten lautet die Frage: Was möchten Sie übernehmen und was selbst entwickeln?

Offizielle Dokumentation

Primärdokumentation der jeweiligen Commerce-Plattform.

Shopify Hydrogen

• Suchmaschinenoptimierung für Hydrogen — getSeoMeta, Canonical-Verarbeitung, Sitemap- und robots.txt-Routen sowie der Preview-Schutz von Oxygen.
• Hydrogen-Hilfe getSeoMeta — Eingaben für Titel, Beschreibung, Bild, Canonical und JSON-LD.
• Hydrogen-Hilfe getSitemap — Sitemap-Erzeugung je Ressourcentyp mit Sprachalternativen.

BigCommerce Catalyst

• Catalyst-Sitemap-Dokumentation — wie Catalyst den Sitemap-Index von BigCommerce durchreicht. Die URL wurde am 19. Juli 2026 vom alten, weiterleitenden Pfad developer.bigcommerce.com auf docs.bigcommerce.com aktualisiert.

commercetools

• Sitemaps | Frontend Development — Drei-Sitemap-Muster, SDK-Methoden (getPages, query, queryCategories), Route-Handler und Paginierungsgrenze von 500 Elementen.

Salesforce Commerce Cloud (PWA Kit)

• SEO mit einer Sitemap verbessern | Composable Storefront — die Entscheidung zwischen Business Manager und individuellem Routing sowie die manuellen Sitemap-Schritte.
• PWA-Kit-GitHub-Issue #1755 — Sitemap-Verarbeitung ergänzen — ein Signal aus der Community, dass eine integrierte Sitemap-Verarbeitung bislang manuell ergänzt werden musste.

Medusa / Saleor / Elastic Path

• Medusa Next.js Starter Storefront — App Router und React Server Components; die SEO-Umsetzung hängt von Ihrer Next.js-Implementierung ab.
• Elastic Path — SEO für Headless-Commerce-Websites — Anbieterbeitrag; nützlich als dokumentierte Position der Plattform, wobei Sitemaps, Canonicals und Weiterleitungen unerwähnt bleiben.

Zitate aus den Quellen

Wörtliche Aussagen aus Plattformdokumentationen und von einem namentlich genannten Praktiker. Die Deep Links führen, soweit verfügbar, direkt zur zitierten Passage.

Shopify Hydrogen — die Metadaten-Hilfsfunktion

• “Hydrogen uses Remix’s built-in meta features for SEO tags, and includes the getSeoMeta utility, which makes it easier and more consistent to render SEO meta tags.” (Übersetzung) „Hydrogen nutzt die in Remix integrierten meta-Funktionen für SEO-Tags und enthält die Hilfsfunktion getSeoMeta, mit der sich SEO-Meta-Tags einfacher und konsistenter ausgeben lassen.“ — Shopify.dev, Hydrogen-SEO-Dokumentation. Dieser genaue Satz steht weiterhin in der Dokumentation, ist aber veraltet: @shopify/hydrogen hängt nicht mehr von Remix ab, sondern verwendet react-router ~7.16.0 als Peer-Abhängigkeit; @shopify/remix-oxygen ist offiziell zugunsten von react-router veraltet. Die Hilfsfunktion getSeoMeta selbst ist korrekt und aktuell. Direkt zum Zitat
• “By default Hydrogen removes query parameters from canonical URLs.” (Übersetzung) „Standardmäßig entfernt Hydrogen Abfrageparameter aus kanonischen URLs.“ — Shopify.dev, Hydrogen-SEO-Dokumentation.

Shopify Hydrogen — Sperrung von Preview-Crawlern

• “If you make a non-production deployment accessible with a shareable link or an auth bypass token, then Oxygen overrides the deployment’s robots.txt file with a disallow rule for all bots and crawlers.” (Übersetzung) „Wenn Sie eine Nicht-Produktivbereitstellung über einen teilbaren Link oder ein Token zur Umgehung der Authentifizierung zugänglich machen, überschreibt Oxygen deren robots.txt mit einer Sperrregel für alle Bots und Crawler.“ — Shopify.dev, Hydrogen-SEO-Dokumentation.

BigCommerce Catalyst — Sitemap-Proxying

• “Catalyst acts as an intermediary when handling requests to /sitemap.xml.” (Übersetzung) „Catalyst fungiert bei der Verarbeitung von Anfragen an /sitemap.xml als Vermittler.“ — BigCommerce Developer Center, Catalyst-Sitemap-Dokumentation.
• “If your storefront also uses third-party systems that generate content with different URLs, you will need to submit multiple sitemaps to cover the URLs from various sources.” (Übersetzung) „Wenn Ihr Storefront zusätzlich Drittsysteme nutzt, die Inhalte unter anderen URLs erzeugen, müssen Sie mehrere Sitemaps einreichen, um die URLs aus den verschiedenen Quellen abzudecken.“ — BigCommerce Developer Center, Catalyst-Sitemap-Dokumentation.
• “The sitemaps don’t need to reside on the same domain as the website they represent.” (Übersetzung) „Die Sitemaps müssen nicht auf derselben Domain liegen wie die Website, die sie abbilden.“ — BigCommerce Developer Center, Catalyst-Sitemap-Dokumentation.

Dan Kogan, 1Digital Agency (Praktiker, Catalyst-SEO)

• “Do not change established URLs on a Stencil-to-Catalyst migration. Every product, category, and content URL should match the legacy structure exactly, or you need a complete 301 redirect map.” (Übersetzung) „Bei der Umstellung von Stencil auf Catalyst dürfen bestehende URLs nicht geändert werden. Produkt-, Kategorie- und Inhaltsadressen müssen die alte Struktur genau beibehalten; andernfalls ist eine vollständige Zuordnung mit 301-Weiterleitungen erforderlich.“ Leitfaden lesen
• “Use generateMetadata and SSR-emitted JSON-LD for every PDP and PLP. Do not rely on client-side schema injection.” (Übersetzung) „Verwenden Sie generateMetadata und serverseitig ausgegebenes JSON-LD für jede Produktdetail- und Produktlistenseite. Verlassen Sie sich nicht auf clientseitig eingefügtes Schema.“ Leitfaden lesen

Elastic Path (Anbieterbeitrag – als Position der Plattform einordnen, nicht als neutrale Quelle)

• “If you’re dynamically building a page with a JavaScript framework alone, you might want to look into serving up cached versions of the pages to the bots.” (Übersetzung) „Wenn Sie eine Seite ausschließlich mit einem JavaScript-Framework dynamisch aufbauen, sollten Sie erwägen, Bots zwischengespeicherte Versionen der Seiten auszuliefern.“ Beitrag lesen

Fehler, die teuer werden können

Konkrete Fehlermuster, die ich bei jeder Headless-Commerce-Implementierung prüfen würde.

„Von Haus aus SEO-optimiert“ ungeprüft glauben. Warum das falsch ist: Das ist ein Spektrum, keine Garantie. Hydrogen liefert echte Grundfunktionen; Medusa, Saleor und Elastic Path liefern nichts SEO-Spezifisches. Selbst im SEO-Beitrag von Elastic Path fehlen Sitemaps, Canonical-Tags und Weiterleitungen. Stattdessen: Fragen Sie je Plattform konkret, was für Sitemaps, Metadaten, Weiterleitungen und Preview-Sperren vorhanden ist, und planen Sie die Lücken als Entwicklungsaufwand ein.

Davon ausgehen, dass jede Plattform Staging aus Google fernhält. Warum das falsch ist: Nur Hydrogen/Oxygen sperrt Crawler automatisch auf Vorschau- und teilbaren Bereitstellungen. Für Catalyst, commercetools oder PWA Kit ist kein entsprechender Automatismus dokumentiert. Mindestens ein Praktiker von 1Digital Agency berichtet zudem von Catalyst-Previews, die in der Praxis von Googlebot indexiert wurden. (Einzelaussage – als glaubwürdigen Datenpunkt behandeln, nicht als abschließend geklärte Tatsache.) Stattdessen: Sperren Sie Nicht-Produktivumgebungen selbst – per robots.txt, HTTP- Authentifizierung oder noindex-Header auf jeder Preview- und Staging-URL. Verlassen Sie sich nicht auf eine undokumentierte Plattformfunktion.

Einen Plattformwechsel als kompletten SEO-Neubau behandeln. Warum das falsch ist: Die Rendering-Schicht – Ihr Next.js- oder React-Router-Frontend – bestimmt die Crawlbarkeit und lässt sich weitgehend zwischen Backends übertragen. Ein Next.js-Storefront kann mit vorwiegend Änderungen an der Datenschicht auf BigCommerce, Medusa, Saleor oder commercetools zugreifen. Stattdessen: Verdrahten Sie nur die tatsächlich abweichenden Grundfunktionen neu: Sitemap-Datenquelle, Metadaten-Hilfsfunktion, Weiterleitungen und Preview-Sperre. Verwenden Sie das Frontend weiter.

SEO anhand der API-Qualität beurteilen. Warum das falsch ist: Die GraphQL- oder REST-API bestimmt nur, welche Daten zum Aufbau von Metadaten und Sitemaps verfügbar sind. Ob diese Daten Google erreichen, hängt vom serverseitigen Rendering ab – einer Frontend- und keiner API-Entscheidung. Stattdessen: Bewerten Sie das Rendering-Modell wie im Hub getrennt von der API. Auch eine hervorragende API liefert mit einem CSR-Frontend leeres HTML an Crawler aus.

Bei der Migration auf die Weiterleitungskarte verzichten. Warum das falsch ist: Keine der geprüften Plattformen automatisiert Weiterleitungen. Fehler bei einem Plattformwechsel lassen sich fast immer auf fehlende 301-Zuordnungen, veränderte URL-Strukturen und Lücken in strukturierten Daten zurückführen. Stattdessen: Erstellen und prüfen Sie vor dem Start eine vollständige 301-Zuordnung von alten zu neuen URLs. Bei Stencil→Catalyst sollten die URLs identisch bleiben oder ausnahmslos zugeordnet werden. Die Checkliste steht im Artikel zu Website-Migrationen.

Product-JSON-LD doppelt oder clientseitig ausgeben. Warum das falsch ist: 1Digital nennt zwei häufige Catalyst-Regressionen: doppelt ausgegebenes Product-JSON-LD durch eine eigene Komponente plus Drittanbieter-App und einen nur clientseitigen Rückfall von generateMetadata, weil die GraphQL-Abfrage in einer Client-Komponente gelandet ist. Stattdessen: Geben Sie pro Produktdetailseite genau einen serverseitig gerenderten Product-Block aus und halten Sie die generateMetadata-Abfrage serverseitig. Prüfen Sie das Ergebnis mit dem Rich Results Test.

SEO-Grundfunktionen der Plattformen auf einen Blick

Was jede Plattform von Haus aus liefert

Kurzfakten

• Nur Hydrogen liefert eine eigene SEO-Metadaten-Hilfsfunktion (getSeoMeta).
• Nur Hydrogen/Oxygen sperrt Crawler auf Vorschau- und teilbaren Bereitstellungen automatisch.
• Catalyst leitet die BigCommerce-Sitemap durch – die Daten liegen in BigCommerce, nicht in Ihrer App.
• Sitemap-Abfragen von commercetools sind auf 500 Elemente pro Anfrage begrenzt – große Kataloge benötigen Paginierungslogik.
• Keine Plattform bietet eine automatische Weiterleitungsverwaltung – die 301-Zuordnung bleibt immer Ihre Aufgabe.
• Plattformwahl = Grundfunktionen; Rendering-Modell (SSR/SSG/CSR) = Crawlbarkeit.

Zusammenfassung in drei Stufen

• Liefert echte Werkzeuge: Hydrogen, Catalyst
• Liefert SDK-Hilfen, aber keine fertigen Routen: commercetools, PWA Kit
• Liefert nichts SEO-Spezifisches: Medusa, Saleor, Elastic Path

Checkliste zur SEO-Prüfung von Headless-Plattformen

Führen Sie diese Prüfung vor der Festlegung auf eine Plattform und erneut vor dem Start durch.

Prüfung der Grundfunktionen (was die Plattform bereitstellt)

• Geklärt, was für Metadaten mitgeliefert wird – eine Hilfsfunktion bei Hydrogen gegenüber rohen API-Feldern, die bei allen anderen selbst in generateMetadata verdrahtet werden.
• Geklärt, wie die Sitemap entsteht – über eine mitgelieferte Route bei Hydrogen, einen Proxy bei Catalyst oder über selbst zusammengesetzte SDK-/API-Funktionen bei commercetools, PWA Kit, Medusa, Saleor und Elastic Path.
• Bei commercetools: Paginierungslogik im Sitemap-Generator für Kataloge mit mehr als 500 Elementen pro Abfrage umgesetzt.
• Bei PWA Kit: den Sitemap-Weg zwischen Business Manager und individuellem Routing gewählt und einen Auftrag zur Neuerzeugung eingeplant.
• Geprüft, dass eine robots.txt-Route vorhanden ist oder selbst erstellt wurde.

Sicherheit von Preview und Staging

• Bei Hydrogen: Die automatische Crawler-Sperre von Oxygen wird genutzt und ihre Wirksamkeit auf teilbaren Links wurde geprüft.
• Bei jeder anderen Plattform: Nicht-Produktivumgebungen ausdrücklich gesperrt (per robots.txt, HTTP-Authentifizierung oder noindex-Header).
• Geprüft, dass derzeit keine Preview- oder Staging-URLs indexiert sind (site:-Suche nach der Preview-Domain).

Rendering (im Hub behandelt, aber je Plattform zu prüfen)

• Eine Produktseite mit curl geprüft – Titel und Beschreibung stehen im Roh-HTML und nicht nur in der clientseitig gerenderten Ausgabe.
• Bestätigt, dass Kategorie- und Kollektionsrouten ebenfalls serverseitig rendern.

Migration und Weiterleitungen

• Eine vollständige 301-Zuordnung von alter zu neuer URL erstellt und geprüft.
• Bei Stencil→Catalyst: URLs identisch beibehalten oder ausnahmslos zugeordnet.
• Product-JSON-LD genau einmal serverseitig ausgegeben, ohne doppelte Ausgabe durch eine Drittanbieter-App.

Prüfen, was ein Headless-Shop tatsächlich ausliefert

Der Kern dieses Artikels lautet: Verlassen Sie sich nicht auf die Aussage des Anbieters. So prüfen Sie die Behauptungen je Plattform an einer Live-Demo oder Ihrem eigenen Shop.

Wird die Produktseite serverseitig gerendert? (Shell)

Wenn der Produkttitel nicht im Roh-HTML steht, wird die Seite clientseitig gerendert. Das kann keine Grundfunktion der Plattform ausgleichen.

# Product name should appear in the raw HTML, before any JS runs.
curl -s https://yourstore.example/products/some-slug | grep -i '<title>'
curl -s https://yourstore.example/products/some-slug | grep -o 'og:title[^>]*'

Existiert die Sitemap, und woher stammt sie? (Shell)

# Hydrogen ships this route; Catalyst proxies it from BigCommerce; others may 404.
curl -sI https://yourstore.example/sitemap.xml
# Peek at the first URLs to confirm it's populated (not an empty shell).
curl -s https://yourstore.example/sitemap.xml | grep -o '<loc>[^<]*</loc>' | head

Ist die Preview- oder Staging-Umgebung gesperrt? (Shell)

Dies ist der Test für Hydrogen gegenüber allen anderen Plattformen. Auf einer Preview-URL sollte Oxygen eine vollständig sperrende robots.txt zurückgeben.

# On a preview/shareable deployment URL:
curl -s https://preview--yourstore.example/robots.txt
# Hydrogen/Oxygen preview: expect "User-agent: *  Disallow: /"
# If it returns your production robots.txt instead, previews can be indexed — block them.

Canonical und JSON-LD im gerenderten Head finden (DevTools-Konsole)

Fügen Sie den Code auf einer beliebigen Produktdetailseite in die Chrome-DevTools-Konsole ein. So sehen Sie, ob Canonical und Produktschema tatsächlich im DOM stehen und ob Product-JSON-LD doppelt ausgegeben wird – eine häufige Catalyst-Regression.

// Canonical URL the page declares:
document.querySelector('link[rel="canonical"]')?.href ?? '(no canonical)';

// Every JSON-LD block, parsed — watch for TWO Product blocks:
[...document.querySelectorAll('script[type="application/ld+json"]')]
  .map(s => { try { return JSON.parse(s.textContent); } catch { return s.textContent; } });

Canonical-Prüfung mit einem Klick (Bookmarklet)

Speichern Sie den Code als Lesezeichen. Ein Klick auf einer Produktseite zeigt das angegebene Canonical und die Anzahl der Product-JSON-LD-Blöcke; zwei oder mehr sind ein Problem.

javascript:(()=>{const c=document.querySelector('link[rel="canonical"]')?.href||'(none)';const p=[...document.querySelectorAll('script[type="application/ld+json"]')].filter(s=>/"@type"\s*:\s*"Product"/.test(s.textContent)).length;alert('Canonical: '+c+'\nProduct JSON-LD blocks: '+p);})();

Alle Produkt-URLs aus einer durchgereichten Catalyst-Sitemap extrahieren (Python)

Nützlich, wenn Sie die URL-Liste für eine Weiterleitungskarte oder eine Prüfung benötigen:

import urllib.request, re

url = "https://yourstore.example/sitemap.xml"
xml = urllib.request.urlopen(url).read().decode("utf-8")
locs = re.findall(r"<loc>(.*?)</loc>", xml)
for loc in locs:
    print(loc)

Ein curl-Ergebnis mit leerem <title> oder fehlender Sitemap sagt mehr aus als jede Behauptung „von Haus aus SEO-optimiert“ auf einer Preisseite.

Werkzeuge zur Prüfung einer Headless-Plattform

• curl / Seitenquelltext — die schnellste Prüfung, ob eine Seite tatsächlich serverseitig gerendert wird. Fehlt der Produkttitel im Roh-HTML, helfen die Plattformfunktionen noch nicht.
• Google Search Console – URL-Prüfung — „Live-URL testen“ zeigt, wie Googlebot eine Produkt- oder Kategorieseite rendert und welches Canonical erkannt wird. Das ist gegenüber Ihrer Vorlage die maßgebliche Ausgabe.
• Rich Results Test — prüft Product-JSON-LD je Produktdetailseite und erkennt doppelt ausgegebenes Schema, eine häufige Catalyst-Regression.
• Screaming Frog SEO Spider — crawlt einen Staging-Build und findet fehlende Canonicals in paginierten Listen, verwaiste Routen sowie erreichbare oder indexierbare Preview-URLs.
• Ahrefs Site Audit — deckt doppelte Inhalte, fehlende Metadaten und Weiterleitungsketten in großen Headless-Implementierungen auf.
• site:-Suche nach der Preview-Domain — ein grober, aber wirksamer Test, ob Ihre Staging-Umgebung bereits indexiert wurde.

Modelle zum Vergleich von Headless-Commerce-Plattformen

Das Zwei-Achsen-Modell: Rendering und Grundfunktionen

Bewerten Sie das Storefront auf zwei unabhängigen Achsen:

• Rendering bestimmt die Crawlbarkeit. SSR oder SSG sollte Produkt- und Kategorieinhalte in das anfängliche HTML schreiben; CSR kann Crawlern nur eine leere Hülle liefern.
• Die Plattformgrundfunktionen bestimmen, was Ihr Team bauen muss. Metadatenlogik, Sitemap-Routen, robots.txt, Preview-Sperren und Weiterleitungsfunktionen können mitgeliefert sein, selbst zusammengesetzt werden müssen oder vollständig fehlen.

Eine Plattform mit starken Grundfunktionen kann dennoch ein CSR-Implementierungsproblem haben. Eine reine API-Plattform kann wiederum hervorragend für SEO geeignet sein, wenn ihr Frontend die fehlende Schicht umsetzt. Fassen Sie die beiden Bewertungen nie in einer einzigen Anbieteraussage zusammen.

Das Modell „Übernehmen – Bauen – Betreiben“

Ordnen Sie jede SEO-Fähigkeit vor der Plattformwahl ein:

Bei der Plattformentscheidung geht es nicht nur um den Bauaufwand. Eine zum Start funktionierende manuelle Sitemap erzeugt weiterhin Betriebsaufwand, sobald sich Kataloggröße, Sprachversionen oder Routing ändern.

Die Belege-Leiter

Bewerten Sie eine Plattformbehauptung in dieser Reihenfolge:

1. Belege aus der Rohantwort: curl, Antwortheader und Seitenquelltext zeigen, was ein Crawler erhält.
2. Belege aus Routen: Verhalten von Live-Sitemap, Canonical, JSON-LD und robots.txt.
3. Belege aus Umgebungen: Produktiv- und Preview-Bereitstellungen unterscheiden sich dort, wo sie es sollen.
4. Anbieterdokumentation: Sie erklärt das beabsichtigte Verhalten, beweist aber nicht, dass die Implementierung korrekt ausgeliefert wurde.
5. Marketingsprache: Sie dient lediglich als Quelle für weitere Fragen.

Die Belege-Leiter verhindert, dass „SEO-bereit“ ein prüfbares Abnahmekriterium ersetzt.

Nachweis nach der Implementierung einer Headless-Plattform

Produkt-HTML und Canonical prüfen

Durchzuführender Test: Rufen Sie eine repräsentative Produkt-URL mit curl -s ab und prüfen Sie die Rohantwort auf Titel, Produktnamen, Canonical und genau einen Product-JSON-LD-Block.

Erwartetes Ergebnis: Produktinhalt und Canonical sind vor der JavaScript-Ausführung vorhanden, und es gibt genau ein serverseitig gerendertes Product-Objekt.

Fehlerdeutung: Die Route könnte auf CSR zurückgefallen sein, Metadaten könnten nur clientseitig vorliegen oder mehrere Schema-Erzeuger könnten aktiv sein.

Überwachungsfenster: Unmittelbar nach jeder Änderung an Produktvorlage oder Datenabruf.

Rollback-Auslöser: Eine Version entfernt indexierbare Produktinhalte aus dem Roh-HTML oder verdoppelt das Produktschema in der geprüften Vorlagengruppe.

Vollständigkeit der Sitemap prüfen

Durchzuführender Test: Rufen Sie Sitemap-Index und untergeordnete Dateien ab und gleichen Sie Stichproben von Produkt- und Kategorie-URLs mit dem Commerce-Katalog ab. Nehmen Sie bei commercetools Produkte auf beiden Seiten einer Paginierungsgrenze auf.

Erwartetes Ergebnis: Veröffentlichte kanonische URLs erscheinen genau einmal, liefern 200 und übernehmen die neuesten Katalogänderungen im dokumentierten Aktualisierungszyklus der Plattform.

Fehlerdeutung: Die Route fehlt, eine Quell-Sitemap wird nicht durchgereicht, die Paginierung endet zu früh oder ein geplanter Generator ist veraltet.

Überwachungsfenster: Nach dem Start und nach jeder Änderung an Katalog, Sprachversion, Routing oder Sitemap-Auftrag.

Rollback-Auslöser: Eine Bereitstellung entfernt einen wesentlichen Katalogbereich aus der Sitemap oder gibt nicht kanonische beziehungsweise fehlerhafte URLs aus.

Isolierung der Preview-Umgebung prüfen

Durchzuführender Test: Fordern Sie robots.txt und Header einer echten teilbaren Preview-URL an und verwenden Sie anschließend die URL-Prüfung oder einen externen Abruf ohne authentifizierte Cookies.

Erwartetes Ergebnis: Nicht-Produktiv-URLs sind für anonyme Crawler unzugänglich oder tragen eine umgebungsweite Sperre; die Produktion bleibt crawlbar.

Fehlerdeutung: Die Preview-Sicherung des Hostings fehlt, gilt nur für ein Preview-Muster oder Produktionsregeln sind in die Staging-Umgebung gelangt.

Überwachungsfenster: Unmittelbar für jede Bereitstellungsart, einschließlich Branch-Previews und Links zur Umgehung der Authentifizierung.

Rollback-Auslöser: Ein öffentliches Preview liefert ohne die vorgesehene Sperre indexierbare Inhalte aus oder die Korrektur sperrt versehentlich die Produktion.

Migrationsweiterleitungen prüfen

Durchzuführender Test: Fordern Sie das vollständige Inventar alter URLs ohne Folgen von Weiterleitungen an und gleichen Sie Status sowie Location mit der freigegebenen Zuordnung ab.

Erwartetes Ergebnis: Jede geänderte Bestands-URL liefert genau eine permanente Weiterleitung zum nächstliegenden kanonischen Ersatz; beibehaltene URLs bleiben bei 200.

Fehlerdeutung: Beim Plattformwechsel fehlt eine Regel, es wurde eine Kette eingeführt oder eine URL geändert, die stabil bleiben sollte.

Überwachungsfenster: Vor der Umstellung, unmittelbar danach und während der ersten Crawl-Prüfungen nach dem Start.

Rollback-Auslöser: Wertvolle Bestands-URLs liefern 404, eine Schleife, eine Kette oder eine Weiterleitung auf ein irrelevantes Ziel.

Selbsttest: Headless-Commerce-Plattformen

Fünf kurze Fragen dazu, wie sich die wichtigsten Headless-Commerce-Plattformen bei SEO unterscheiden. Wählen Sie jeweils eine Antwort und prüfen Sie anschließend das Ergebnis.

Lesenswerte Ressourcen

Meine verwandten Artikel

• Probleme und Best Practices bei JavaScript-SEO — die allgemeinen Rendering-Fehlermuster wie Parität, Interaktion, Zustand und Timing hinter jedem JavaScript-lastigen Headless-Storefront sowie der hier verwendete Ansatz „prüfen statt vertrauen“.
• Einsteigerleitfaden zur technischen SEO — ordnet Rendering und Crawlbarkeit in den größeren Zusammenhang ein.

Meine Vorträge

• So funktioniert die Suche (SlideShare) — Crawling, Rendering, Indexierung und Ranking, also die Pipeline, in die jede dieser Plattformen einspeist. Mein üblicher Hinweis gilt: “This is my understanding of systems… not going to be 100% complete or accurate.” (Übersetzung) „Dies ist mein Verständnis der Systeme und wird nicht zu 100% vollständig oder korrekt sein.“

Aus der Branche

• Suchmaschinenoptimierung für Hydrogen (Shopify.dev) — getSeoMeta, Sitemap- und robots-Routen sowie das Verhalten der Oxygen-Preview-Sperre direkt aus der Quelle.
• Catalyst-Sitemap-Dokumentation (BigCommerce Developer Center) — beschreibt, wie Catalyst den Sitemap-Index von BigCommerce durchreicht.
• Sitemaps | Frontend-Entwicklung (commercetools) — das SDK-Muster mit drei Sitemaps und die Paginierungsgrenze von 500 Elementen.
• SEO mit einer Sitemap verbessern | Composable Storefront (Salesforce Developers) — die Entscheidung zwischen Business Manager und individuellem Routing bei PWA Kit.
• BigCommerce-Catalyst-SEO | Best Practices für Next.js-Storefronts (Dan Kogan, 1Digital Agency) — ein ausführlicher Praktikerbeitrag zu Catalyst-SEO: URL-Parität bei der Migration, generateMetadata-Regressionen, doppeltes JSON-LD und Preview-Indexierung.
• SEO für Headless-Commerce-Websites (Kirsten Aebersold, Elastic Path) — die SEO-Position des Anbieters; nützlich als Fallstudie dafür, was „von Haus aus“ auslässt: Sitemaps, Canonicals und Weiterleitungen.
• Beste Headless-Commerce-Plattformen: Vergleich 2026 (Vendure) — ein breiter Vergleich von Geschäftskriterien und Technikstacks, bei dem die SEO-Achse auffällig fehlt – genau die Lücke dieses Artikels.
• Beste Headless-Commerce-Plattformen 2026 (Your Next Store) — ein weiterer Plattformvergleich zum Gegenprüfen der nicht SEO-bezogenen Auswahlkriterien.

Änderungsprotokoll