Salesforce-Commerce-Cloud-SEO

TL;DR — Salesforce Commerce Cloud – auch B2C Commerce, SFCC oder früher Demandware genannt – ist eine gehostete Shop-Plattform für Unternehmen. Sie bringt solide SEO- Werkzeuge mit: Sie können robots.txt bearbeiten, Sitemaps automatisch erzeugen, Seitentitel aus Vorlagen erstellen und Produktvarianten wie Farben oder Größen suchmaschinenfreundlich behandeln. Diese Werkzeuge erfordern dennoch eine websitespezifische Konfiguration und Tests der gerenderten Ausgabe durch jemanden, der die Plattform kennt.

Was „Salesforce Commerce Cloud SEO“ bedeutet

Salesforce Commerce Cloud ist eine gehostete SaaS-E-Commerce-Plattform für große Marken und Händler. Salesforce betreibt sie; anders als WordPress und WooCommerce wird sie nicht auf dem eigenen Server installiert. Der offizielle Name lautet B2C Commerce, der frühere Name war Demandware, und in der Branche heißt sie meist einfach SFCC. Sie konkurriert mit Shopify und BigCommerce, ist aber hinsichtlich Größe, Preis und Komplexität eine Stufe höher angesiedelt.

Fast jede Konfiguration, einschließlich SEO, erfolgt in der Administrationsoberfläche Business Manager. Salesforce-Commerce-Cloud-SEO bedeutet daher vor allem, die richtige Ansicht für jeden SEO-Hebel zu kennen und korrekt einzustellen.

Was SFCC bereits mitbringt

• Bearbeitbares robots.txt. Für jede Website lässt sich im Business Manager eine eigene Datei pflegen – anders als bei Shopify ohne zusätzliche Anpassung.
• Automatische Sitemaps. SFCC erzeugt XML-Sitemaps nach einem von Ihnen festgelegten Zeitplan; die Datei muss nicht manuell erstellt werden.
• Vorlagenbasierte Seitentitel und Beschreibungen. Mit Meta Tag Rules können Sie eine Formel wie „Kategoriename | Marke“ definieren und Titel katalogweit ausfüllen.
• Suchmaschinenfreundliche Produktvarianten. SFCC behandelt Farben und Größen als Varianten eines Masterprodukts. Einzelne Varianten sollen auf den Master verweisen, damit Google sie nicht als Duplikate betrachtet.

Was Sie weiterhin selbst umsetzen müssen

• Sprach- und Länderzuordnung mit hreflang. SFCC fügt diese Angaben nicht automatisch hinzu. Aktivieren Sie alternative URLs in den Sitemap-Einstellungen oder lassen Sie die Tags entwickeln.
• Filterseiten und Facettennavigation. Für Filter nach Farbe, Größe oder Preis erzeugt SFCC nicht eigenständig saubere, suchmaschinenfreundliche URLs; das erfordert Entwicklung.
• Rich Results und Schema. Strukturierte Daten für Sternebewertungen und Produkt- Rich-Results sind kein Schalter, sondern werden in den Shopvorlagen implementiert.
• Crawlbarkeit von PWA Kit oder Storefront Next. Nutzt der Shop eines der Headless- Frontends von Salesforce, müssen Sie prüfen, ob Google die Inhalte tatsächlich sieht. Details stehen in der fortgeschrittenen Perspektive.

Der häufigste Irrtum

Die Behauptung, SEO sei auf Salesforce Commerce Cloud nicht möglich, ist falsch. Die Plattform hat starke Werkzeuge, verlangt aber Kenntnis der Plattform. Allgemeine Hinweise wie „hreflang ergänzen“ oder „Filter-URLs bereinigen“ sind inhaltlich richtig, lassen sich in SFCC jedoch oft nicht auf dem naheliegenden Weg umsetzen. Die Plattform hat eigene Oberflächen und Regeln. Nicht sie ist die Begrenzung, sondern fehlende Vertrautheit.

Die fortgeschrittene Perspektive behandelt URL Rules und Aliases, die Canonical-Strategie für Master und Varianten, die hreflang-Architektur und die Prüfung eines Headless-Shops.

TL;DR — SFCC bietet starke native SEO-Grundlagen: je Website bearbeitbares robots.txt, automatisch geplante XML-Sitemaps, regelbasierte Meta-Tags für katalogweite Titel und Beschreibungen sowie ein kanonisches Master-/Variationsmodell, das nahezu genau zu Googles Schema ProductGroup/hasVariant/isVariantOf passt. Selbst zu entwickeln sind hreflang, Facetten-URLs, strukturierte Daten und die Crawlbarkeit von PWA Kit oder Storefront Next. Serverseitiges Rendering ist notwendig, reicht aber nicht; PWA Kit lässt sich mit ?__server_only prüfen. Die wichtigste Architekturentscheidung für mehrere Regionen lautet: eine Website mit mehreren Locales oder mehrere Websites. Sie bestimmt, wie viele vollständige SEO-Konfigurationen synchron gehalten werden müssen.

Der Rahmen: starke native Werkzeuge, hohe Anforderungen an Plattformkenntnis

Viele SFCC-SEO-Inhalte sind entweder oberflächliches Agenturmarketing oder Entwickler- Dokumentation ohne SEO-Einordnung. Die Wirklichkeit liegt dazwischen: SFCC hat mehr native, administrierbare SEO-Werkzeuge als viele konkurrierende Plattformen, doch ohne bewusste Einrichtung funktioniert nichts davon zuverlässig, und mehrere Standards schaden, wenn sie unangetastet bleiben. Ordnen Sie jede Aufgabe als native Grundlage oder Eigenentwicklung ein; dann verliert die Plattform ihre Unübersichtlichkeit.

Drei Dinge sollten Sie zuerst verstehen:

1. SEO befindet sich im Business Manager. Der zentrale Pfad lautet Merchant Tools → Website → SEO und umfasst Canonical-URL-Tags, URL Redirects, Sitemaps, Robots, Meta Tag Rules sowie URL Rules und Aliases. Jede Funktion hat eine eigene Ansicht und Regeln.
2. Das Master-/Variationsmodell prägt alles. Ein Masterprodukt besitzt mehrere Variationsprodukte, etwa nach Farbe oder Größe. Dieses Modell ist der zentrale SEO-Entscheidungspunkt und entspricht Googles gewünschter Variantenauszeichnung.
3. Benennen Sie die Storefront-Architektur vor der Lösung. Salesforce Commerce Cloud umfasst mindestens vier Generationen: SiteGenesis, SFRA, das Headless- PWA Kit und das neuere React-Framework Storefront Next. Administrationspfade, Cartridge-Verhalten und Rendering unterscheiden sich. Eine für eine Architektur geprüfte Lösung gilt nicht automatisch für eine andere. Die Business-Manager-Ansichten dieses Artikels gelten weitgehend für SFRA und SiteGenesis; PWA-Kit-spezifische Mechanismen werden ausdrücklich begrenzt.

Native Grundlagen: je Website bearbeitbares robots.txt, geplante automatische XML-Sitemaps mit optionalem hreflang und Änderungsdaten, URL Rules und Hostname Aliases für localeabhängige saubere URLs, kanonisch angelegte Variationsprodukte, regelbasierte Meta-Tags, automatische 301-Weiterleitungen bei URL-Änderungen im Business Manager und PWA-Kit-SSR für den ersten Aufruf.

Selbst zu entwickeln: hreflang, Facetten-/Refinement-URLs, strukturierte Daten, robots.txt für mehrere Locales, H1-Vorlagen und bei Headless-Aufbauten die gesamte Verwaltung der Onpage-Tags.

Die grundlegende Architekturentscheidung: Websites oder Locales

Klären Sie vor jeder SEO-Einstellung, ob eine internationale Marke als eine Website mit mehreren Locales oder als mehrere Websites je Locale beziehungsweise Region modelliert ist. Internationale SFCC-Storefronts werden im Business Manager häufig als getrennte Websites angelegt. Das ist entscheidend, weil jede Website eine vollständige eigene SEO- Konfigurationsoberfläche besitzt: Sitemap-Auftrag, robots.txt, Meta Tag Rules und URL Rules. Zehn Websites bedeuten zehn manuell synchron zu haltende Konfigurationen. Benennen Sie diese Entscheidung früh, weil sie jeden folgenden Bereich vervielfacht.

URL-Struktur: URL Rules vs. Hostname Aliases

SFCC bietet zwei Konfigurationswege; welcher passt, hängt von der Locale-Struktur ab:

• URL Rules (Merchant Tools → Website → SEO → URL Rules) ordnen Locale-, Kategorie- und Produktpfadsegmente einem Muster zu. Sie sind einfacher, aber weniger flexibel: Für Locale-Routing wählen Sie alternative Hostnamen, URL-Parameter oder Pfade.
• Hostname Aliases (Merchant Tools → Website → SEO → Aliases) werden als JSON-Datei gepflegt und ermöglichen Mischformen, etwa ccTLD-artige Hostnamen für einige Locales und Unterordner für andere innerhalb derselben Website. Gemischtes Routing muss über diese Alias-Datei umgesetzt werden.

Die wichtigsten Mechanismen:

• Kleinschreibung erzwingen. Salesforces URL-Leitfaden empfiehlt Lower Case, damit nicht mehrere URLs mit unterschiedlicher Groß-/Kleinschreibung desselben Textes entstehen.
• Bindestriche für Leerzeichen verwenden. Leerzeichen können als %20 codiert oder durch Plus, Unterstrich, Minus beziehungsweise Punkt ersetzt werden. Salesforce weist darauf hin, dass Suchmaschinen Bindestriche als Trenner, Unterstriche dagegen als Verbinder behandeln. Der Bindestrich ist daher die sauberste Wahl; NOVOS empfiehlt ihn ebenfalls gegenüber dem Standard %20.
• category oder category-path. Bei Websites mit mehr als zwei oder drei Kategorieebenen ist category meist besser. Gibt es gleichnamige Kategorien unter verschiedenen Eltern, sorgt category-path für Eindeutigkeit.
• Produkt-IDs werden automatisch angehängt. Die ID gehört nicht in die Regel; B2C Commerce ergänzt sie einschließlich .html selbst. Ohne Eigenentwicklung lässt sich diese Erweiterung laut Praktikern nicht entfernen.
• Produkte der Domain statt einem Kategoriepfad zuordnen. NOVOS empfiehlt das, um Duplikate und Komplexität zu reduzieren, da Produkte mehreren Kategorien angehören können und ein kategoriebasiertes URL-Segment dadurch instabil wird.
• Allgemeine URL-Hygiene: URLs kurz und lesbar halten, möglichst wenige Ordner und Parameter verwenden, relevante Begriffe integrieren und weder Seitentypkennzeichen noch die proprietäre Erweiterung sc.html oder das Wort demandware aufnehmen.

Der klassische Fallstrick: Nicht zugeordnete Pipelines Default-Start und Home-Show können doppelte Startseiten unter Varianten mit und ohne www erzeugen. Ordnen Sie sie ausdrücklich zu. Außerdem muss die Alias-Datei Version 1 deklarieren; andernfalls ignoriert das System sie vollständig.

Im Vergleich zu BigCommerce mit vorgegebenen URL-Strukturen und auswählbarer Präfix- Entfernung oder Shopify mit erzwungenem /products/ und /collections/ ist SFCCs URL- Ebene wesentlich flexibler – und verlangt entsprechend mehr eigene Konfiguration.

XML Sitemaps

Die Sitemap-Erzeugung ist ein geplanter Business-Manager-Auftrag, keine statisch gepflegte Datei. Sie finden ihn unter App Launcher → Merchant Tools → Website → SEO → Sitemaps und konfigurieren den Zeitplan im Tab Job. Salesforce empfiehlt verkehrsarme Zeiten am frühen Morgen, um CPU- und Speicherspitzen zu vermeiden, und einen Lauf nach der täglichen Datenreplikation aus Staging.

Drei Punkte führen häufig zu Fehlern:

• Je Instanztyp konfigurieren. Sitemap-Einstellungen lassen sich nicht zwischen Staging, Produktion und Entwicklung replizieren; sie werden auf jeder Instanz einzeln gesetzt. Das unterscheidet sie von den meisten Website-Einstellungen.
• changefreq und priority sind wirkungslos. Google ignoriert beide Angaben in Sitemaps. Investieren Sie keine Entwicklungszeit in ihre Optimierung. Halten Sie dagegen lastmod korrekt; es wird automatisch eingesetzt und ist ein echtes Recrawl-Signal.
• hreflang hängt an einem Kontrollkästchen. Include Alternate URLs ergänzt hreflang-Anmerkungen in den Standard-Sitemaps. Bei vielen Locales kann dadurch die Linkgrenze je Datei überschritten werden; dann sind gemeinsam mit einem Solution Architect entwickelte eigene Sitemaps nötig.

Headless nutzt einen eigenen Mechanismus. Für PWA Kit erklärt Salesforces Leitfaden „Improve SEO with a Sitemap“, Sitemaps gäben Such-Crawlern Anweisungen zu indexierbaren Seiten und Website-Hierarchie und könnten dadurch Rankings verbessern. Übersetzung des englischen Originals: „provide search crawlers with instructions on the pages to index and the site hierarchy, which can improve your SEO rankings.“ Sind die Routen im Business Manager konfiguriert, erzeugen Sie dort die Sitemap; andernfalls laden Sie sie über den SCAPI-Endpunkt uploadCustomSitemapAndTriggerSitemapGeneration hoch. Erforderlich sind eine Vanity-Domain, etwa die eingebettete CDN-Domain oder eine Subdomain wie seo.example.com, ein passender Hostname Alias und Erreichbarkeit unter example.com/sitemap_index.xml. In PWA Kit ergänzen Sie app.get('/sitemap_index.xml', runtime.serveStaticFile('static/sitemap_index.xml')) in ssr.js und geben die Datei über ssrShared in der App-Konfiguration frei.

Robots.txt

Es gibt zwei verschiedene Mechanismen. Ihre Verwechslung verursacht echte Bereitstellungsfehler:

1. Website-Einstellung im Business Manager, der empfohlene Standardweg. Unter App Launcher → Merchant Tools → Website → SEO → Robots können Sie je Website ein robots.txt mit bis zu 50.000 Zeichen schreiben. Es wird als Website-Einstellung gespeichert und kann zwischen Instanzen repliziert werden.
2. Statische Datei auf Cartridge-Ebene für eigene Storefronts oder SFRA. Ein robots.txt liegt in cartridge/static/default einer eigenen Cartridge und wird über UX Studio verwaltet. Es gelangt nur per Code-Replikation zwischen Instanzen, weil das statische Verzeichnis zur Cartridge und nicht zur Website gehört.

Zwei gotchas:

• Cache-Invalidierung. Bei aktiviertem Caching muss der Cache statischer Inhalte invalidiert werden, bevor ein neues Cartridge-robots.txt ausgeliefert wird.
• Robots gilt für die Domain, nicht je Unterordner. Werden mehrere Locales in Unterordnern betrieben, muss ein einziges robots.txt im Domain-Stamm alle abdecken.

Die sinnvolle Praxis lautet: robots.txt minimal halten. Canonical-Tags und noindex steuern, was in Ergebnissen erscheint; robots.txt steuert das Crawling, nicht die Indexierung. Eine zu starke Abhängigkeit davon ist das eigentliche Antimuster. Entwicklung und Staging bleiben über den ausgelieferten Cartridge-Standard nicht crawlbar, die Produktion wird bewusst konfiguriert. Plattformunabhängige Grundlagen stehen unter Crawling und Canonicalisierung.

Canonical-URLs und das Master-/Variationsmodell

Hier stimmen SFCCs Datenmodell und Googles Leitfaden nahezu perfekt überein – und hier enden viele andere SFCC-Inhalte zu früh.

SFCC stellt Farb- und Größenvarianten als ein Master- beziehungsweise Basisprodukt mit untergeordneten Variationsprodukten dar. Salesforce empfiehlt, deren URLs auf das Masterprodukt zu kanonisieren, um Rankings zu erhalten oder zu verbessern. Jede Varianten- PDP verweist also mit rel="canonical" auf das Basisprodukt, damit Ranking-Signale auf einer URL zusammenlaufen.

Googles Leitfaden für genau diesen Fall eines Produkts mit vielen Varianten empfiehlt die Klasse ProductGroup zusammen mit variesBy, hasVariant und productGroupID. Das entspricht konzeptionell dem Master-/Variationsmodell von SFCC:

• Das Masterprodukt entspricht Googles ProductGroup.
• Die Variationsprodukte sind hasVariant-Mitglieder; im getrennten Muster verweist jedes Product über isVariantOf auf die @id der Gruppe.
• Google dokumentiert ein verschachteltes Muster über ProductGroup.hasVariant als kompakteste und natürlichste Darstellung sowie ein getrenntes Muster über Product.isVariantOf, das für manche Content-Management-Systeme leichter zu erzeugen ist. Das getrennte Muster passt gut zu SFCC-Vorlagen mit eigenständigen PDP-Ausgaben.

Für eine Variantenauswahl auf einer Seite empfiehlt Google nur eine eindeutige Canonical- URL für die gesamte ProductGroup. Das entspricht genau SFCCs Regel Variante → Master.

Bringen Sie beide Ebenen in Einklang, denn Canonical-Signale müssen konsistent sein. Google bezeichnet rel="canonical" als starkes Signal, die Sitemap-Aufnahme als schwaches; kombiniert werden sie wirksamer. Widersprechen dürfen sie sich nicht. In SFCC müssen daher das rel="canonical" der Variante, Sitemap, hreflang und interne Links dieselbe Master- URL nennen. Auch die interne Navigation sollte zum Masterprodukt statt zu einzelnen Varianten-URLs führen.

Die allgemeinen Details stehen unter Produktvarianten-SEO und Canonicalisierung.

Meta-Tag-Regeln

Titel und Beschreibungen haben zwei Implementierungswege: manuelle Eingabe je Objekt über Category/Product → Page Title/Page Description oder regelbasierte dynamische Erzeugung über Meta Tag Rules unter Merchant Tools → Website → SEO → Meta Tags.

• Einfache dynamische Regel: ein Kategorietitel wie ${Category.Name} | Example Brand.
• Hybride Überschreibung mit Fallback: ${IF Category.pageTitle THEN Category.pageTitle ELSE Category.Name} erlaubt individuelle Seitentitel, während die Regel katalogweit Standard bleibt. Dieses Muster skaliert und lässt Ausnahmen zu.
• Verbindungswörter lokalisieren. Übersetzen Sie bei lokalisierten Regeln alle verbindenden Wörter rund um Trenner wie | und setzen Sie sie auf Sprach- oder Sprach-Länder-Ebene.
• H1 ist begrenzt. Anders als Titel und Beschreibungen lassen sich H1-Tags nicht mit einer standardmäßigen Meta-Tag-Rule-Syntax dynamisch vorlagenbasiert erzeugen; dafür ist Eigenentwicklung nötig.

Weiterleitungen

SFCC besitzt einige native automatische Weiterleitungsmechanismen und manuelle Werkzeuge:

• Automatische 301-Weiterleitungen werden ausgelöst, wenn eine Kategorie- oder Produkt-URL im Business Manager überschrieben wird. SFCC korrigiert zudem falsch geschriebene PDP-URLs, solange die zugrunde liegende Produkt-ID erhalten bleibt.
• Drei manuelle Werkzeuge: URL Redirects für 1:1-Zuordnungen, Static Mappings für alte URL-Muster zu statischen Ressourcen und Dynamic Mappings für komplexe Platzhaltermuster.
• Statuscodes: 301 für dauerhaft, 308 nach eigener Entwicklung und 307 für vorübergehend. Hintergründe bieten Ahrefs’ Leitfäden zu elf Weiterleitungstypen und 301 gegenüber 302.
• Auf Objekt-IDs statt fest codierter Pfade verweisen. NOVOS empfiehlt Objektarten und IDs, damit spätere Ziel-URL-Änderungen keine Fehler oder Schleifen erzeugen.

Die Vorrangregel ist wichtig. In der Entwicklerdokumentation steht: „If there’s a conflict between your URL redirects and your URL rules for SEO, the URL redirects take precedence.“ Übersetzung: Bei einem Konflikt zwischen URL-Weiterleitungen und SEO-URL-Regeln haben die Weiterleitungen Vorrang.

Migrationseinordnung: Bei einem SFRA-Relaunch ist die Weiterleitungsstrategie der wichtigste SEO-Baustein für den Erhalt von Rankings. Acxioms Salesforce-Team veranschlagt dafür 60 bis 70 % des SEO-Aufwands beim Start. Das entspricht der allgemeinen Erkenntnis, dass eine Migration mehr als eine Checkliste benötigt.

Strukturierte Daten und Schema: die Lücke klar benennen

Im Business Manager gibt es keinen nativen Schalter für Produktschema, der Meta Tag Rules oder Canonical-Verarbeitung entspräche. Anders als BigCommerce, dessen Cornerstone- Theme JSON-LD-Produktschema mitliefert, liegt Schema in SFCC in der Verantwortung von Vorlagen und Entwicklung. Die SFRA-Referenz-Storefront enthält etwas Produkt- und Breadcrumb-Schema im Vorlagencode, doch das ist keine Administrationsfunktion. Behandeln Sie Schema als Entwicklungsaufgabe und nutzen Sie das Muster ProductGroup/Variante als Zielstruktur. JSON-LD ist Googles empfohlenes Format, sofern die Einrichtung es erlaubt.

Eine wichtige Rendering-Vorgabe betrifft besonders Headless-Aufbauten: Strukturierte Daten sollten im serverseitig gerenderten HTML stehen und nicht erst bei clientseitiger Hydration eingefügt werden. Bei PWA Kit muss JSON-LD deshalb in der SSR-Ausgabe enthalten sein.

Hreflang und multi-site/locale Architektur

Zuerst B2B und B2C unterscheiden. Salesforces eigene Funktion „Alternate Language Links“ gehört zu B2B Commerce und existiert in B2C Commerce nicht als eigene Ansicht. Suchergebnisse und manche Agenturbeiträge vermischen beide Clouds. In B2C Commerce läuft hreflang über das Sitemap-Kontrollkästchen Include Alternate URLs und nicht über eine eigene Sprachadministration.

Damit bleiben zwei realistische Implementierungswege:

1. hreflang in der Sitemap über Include Alternate URLs – einfach, kann aber bei großem Umfang die Größenbegrenzung je Sitemap-Datei überschreiten.
2. Eigene <link rel="alternate" hreflang="x">-Tags direkt im <head> – nötig, sobald zu viele Locale-/URL-Kombinationen für die Sitemap-Methode entstehen.

Die üblichen hreflang-Regeln gelten weiterhin: Jede Seite enthält im <head> einen vollständigen, über alle Versionen identischen Satz von <link>-Elementen – einschließlich eines Verweises auf sich selbst – sowie x-default als Rückfall für nicht passende Sprachen. Google dokumentiert hreflang entweder als <link> im <head> oder in einer XML-Sitemap; das sind genau die beiden SFCC-Wege.

Hinweis zu Bing: Historisch hat Bing hreflang nicht wie Google unterstützt und stattdessen das HTML-Signal content-language gelesen. Eine SFCC-Website, die hreflang nur über die Sitemap setzt, liefert Bing womöglich nicht das gewünschte Sprachsignal. Prüfen Sie das aktuelle Verhalten, bevor Sie dies als feste Regel behandeln; Berichte zu Bings Unterstützung waren widersprüchlich.

Je tiefer die Multi-Site-Architektur, desto stärker vervielfacht sich der Aufwand. Jede Website besitzt eigenen Sitemap-Auftrag und eigenes robots.txt; eine als neue Website ergänzte Locale ist eine vollständige neue SEO-Oberfläche und nicht nur eine Sprachdatei. Internationale Grundlagen stehen unter hreflang.

Facettennavigation / refinement URLs

SFCC erzeugt standardmäßig keine SEO-freundlichen Filter- oder Refinement-URLs. Saubere URLs und korrekte Indexierung der Facettennavigation erfordern Eigenentwicklung. Es gibt kein natives Canonical-/noindex-Verhalten für Filterkombinationen; Sie müssen das Entscheidungsmodell selbst aufbauen. Die folgende Einteilung passt zu SFCC ebenso wie zu anderen Plattformen, weil das Grundproblem – eine kombinatorische Explosion crawlbarer Filter-URLs – plattformunabhängig ist:

Zwei Grundsätze ändern sich auch in SFCC nicht:

• robots.txt blockiert Crawling, nicht Indexierung. Eine gesperrte URL kann weiterhin indexiert werden, wenn andere Seiten auf sie verlinken. Google kann Canonical oder noindex nicht lesen, wenn die Seite nie abgerufen wird. Kombinieren Sie Parameterregeln daher mit Onpage-Canonical und noindex.
• Paginierte Seiten nicht auf noindex setzen. Google empfiehlt für jede paginierte Seite eine eigene Canonical-URL, statt Seite 2 und folgende in Seite 1 zusammenzufalten. noindex gehört auf Filter- oder Sortiervarianten, nicht auf Paginierung.

Die plattformunabhängigen Details stehen unter Facettennavigation.

Headless-SEO mit PWA Kit und Storefront Next

Eine Headless-Storefront läuft auf PWA Kit, Salesforces etabliertem React-Framework auf SCAPI und Managed Runtime, oder seit dem B2C-Commerce-Zyklus 2026 auf dem neueren Storefront Next. SEO ist hier vor allem eine Frage der Crawlbarkeit; so rahmt es auch Salesforces Dokumentation.

Geltungsbereich vor der Anwendung prüfen. Der Test ?__server_only, der Pfad app/ssr.js und die beschriebenen SSR-/Hydrationsmechanismen gelten für klassisches PWA Kit beziehungsweise Composable Storefront und wurden gegen Salesforces Entwickler- dokumentation geprüft. Storefront Next ist anders aufgebaut: React 19, dateibasiertes Routing mit React Router 7 statt React Router 5 und ein Fetch-then-render-Loader-Modell. Es läuft ebenfalls auf Managed Runtime, nutzt aber einen eigenen Streaming-SSR- und Hydrationsablauf. Salesforce bietet deshalb einen eigenen Leitfaden zur Migration von PWA Kit zu Storefront Next. Nehmen Sie bei Storefront Next nicht an, dass ?__server_only oder dieselben Dateipfade unverändert gelten. Bestätigen Sie den entsprechenden Prüfschritt in der Storefront-Next-Dokumentation. Das SEO-Prinzip bleibt gleich: crawlerkritische Inhalte wie Titel, Meta-Angaben, Canonical, Haupttext, Preis, Verfügbarkeit und JSON-LD müssen im serverseitig gerenderten oder gestreamten HTML stehen, nicht erst in clientseitiger Hydration.

Wie Rendering funktioniert. Beim ersten Seitenaufruf nutzt PWA Kit serverseitiges Rendering. Die Dokumentation erklärt: „For the critical first page load, we use server-side rendering because it offers a powerful tool for optimizing performance: caching.“ Übersetzung: Für den kritischen ersten Aufruf wird SSR verwendet, weil Caching ein leistungsfähiges Mittel zur Performance-Optimierung ist. SSR läuft über eine Express-App in app/ssr.js; der CDN-Cache der Managed Runtime kann zuvor gerenderte Seiten speichern und sofort ausliefern. Für Crawler ist der erste Aufruf damit echtes HTML.

Die Hydrationsgrenze ist der SEO-Risikopunkt. Nach dem ersten Aufruf gehen die Rendering-Aufgaben durch Hydration vom Server auf den Client über und die React-App läuft im Browser. Der Code muss isomorph, also auf beiden Seiten sicher sein: window.location ist nur clientseitig, req und res nur serverseitig verfügbar. Salesforce sieht bestimmte personalisierte oder häufig wechselnde Inhalte bewusst nur auf dem Client vor. Crawlerkritische Inhalte dürfen nicht in diesem Bereich landen, sonst sehen Crawler sie womöglich nie.

So prüfen Sie es nach Salesforces eigener Methode. Die PWA-Kit-Checkliste empfiehlt, Einstiegsseiten wie Startseite, PLP und PDP mit ?__server_only aufzurufen. Damit lässt sich bestätigen, dass serverseitig gerenderte Seiten genügend Daten für Crawler enthalten und der Layout-Shift zwischen Server und Client gering oder idealerweise nicht vorhanden ist. Das ist die nützlichste Headless-SEO-Prüfung in SFCC und erfordert keine Entwicklung: URL mit ?__server_only laden und Titel, Meta-Angaben, Canonical, Haupttext und Produktschema kontrollieren.

URL-Logik über SCAPI synchron halten. Der Endpunkt getUrlMapping ermöglicht einer Headless-Storefront lokalisierte, benutzerfreundliche URLs auf Grundlage der im Business Manager eingerichteten URL Rules und Redirects. Er löst Produkt-, Kategorie- einschließlich Refinement- und Content-Asset-URLs auf und fällt ohne Locale-Angabe auf die Standard-Locale zurück. Salesforce empfiehlt lange TTLs; Standard sind zwölf Stunden. Dadurch muss das Headless-Frontend kein paralleles URL-System pflegen.

Die zu schließende Lücke. Salesforces PWA-Kit-Dokumentation behandelt SEO fast nur als SSR- und Crawlbarkeitsproblem und sagt wenig zu Meta-Tags, Canonical, hreflang oder Schema; Sitemaps haben eine eigene Dokumentation. Onpage-Tags liegen damit in der Head-Verwaltung des Implementierungsteams, etwa React Helmet. Ohne klare Verantwortung kann eine technisch crawlbare Storefront dennoch ohne Titel, Canonicals oder Schema starten. Allgemeine Mechanismen erklären JavaScript SEO und Headless-CMS-SEO.

SFCC im Vergleich zu anderen Plattformen

Gegenüber Shopify, BigCommerce, Magento, WooCommerce und PrestaShop liegt SFCC am Enterprise-Ende. Unter den gehosteten Plattformen bietet es besonders tiefe native SEO- Konfiguration: je Website bearbeitbares robots.txt, URL Rules und Aliases, kanonisch angelegte Varianten und regelbasierte Meta-Tags. Gleichzeitig verlangt es die größte Plattformkenntnis. Shopify erzwingt URL-Präfixe und verwaltet robots.txt über eine Vorlage; BigCommerce liefert vorgegebene URL-Strukturen und natives JSON-LD. SFCC stellt die Hebel bereit und erwartet Kenntnis des Business Managers. Gutes SEO entsteht hier nicht standardmäßig, hervorragendes SEO aber durch bewusste Konfiguration.

KI-Zusammenfassung

Die Kurzfassung der fortgeschrittenen Perspektive:

• Salesforce Commerce Cloud ist gehostetes SaaS-E-Commerce für Unternehmen, offiziell B2C Commerce, früher Demandware, meist SFCC. Fast alle SEO-Einstellungen liegen im Business Manager unter Merchant Tools → Website → SEO.
• Vier Storefront-Generationen: SiteGenesis, SFRA, Headless-PWA-Kit und Storefront Next. Administrationspfade und Rendering unterscheiden sich; die Architektur muss vor jeder Lösung benannt werden.
• Native Grundlagen: je Website bearbeitbares robots.txt, geplante automatische XML-Sitemaps, URL Rules und Hostname Aliases, kanonische Master-/Variationsprodukte, regelbasierte Meta-Tags, automatische 301-Weiterleitungen und PWA-Kit-SSR.
• Architekturentscheidung: Eine Website mit mehreren Locales oder mehrere Websites. Jede Website besitzt eine getrennte vollständige SEO-Konfiguration.
• Canonical als Unterscheidungsmerkmal: Varianten-URLs verweisen auf den Master, der nahezu genau zu ProductGroup/hasVariant/isVariantOf passt. Canonical, Sitemap, hreflang und interne Links müssen dieselbe Master-URL nennen.
• Eigenentwicklung: hreflang über Sitemap oder eigene <link>-Tags, Facetten-URLs, strukturierte Daten, domainweites robots.txt für mehrere Locales und H1-Vorlagen.
• Sitemaps: je Instanztyp konfigurieren; changefreq und priority werden von Google ignoriert, lastmod muss korrekt bleiben.
• Weiterleitungen: URL Redirects haben Vorrang vor URL Rules; bei SFRA-Relaunches beansprucht die Strategie ungefähr 60 bis 70 % des SEO-Aufwands.
• PWA Kit und Storefront Next: SSR ist notwendig, aber nicht hinreichend. PWA-Kit- Einstiegsseiten mit ?__server_only prüfen und das Äquivalent für Storefront Next bestätigen; URL-Logik über SCAPI getUrlMapping synchron halten.
• Der zu beseitigende Mythos: SEO ist auf SFCC möglich; fehlende Plattformkenntnis, nicht die Plattform selbst, ist die Begrenzung.

Offizielle Dokumentation

Primärdokumentation von Salesforce und Google.

Salesforce – B2C Commerce, Hilfe und Business Manager

• SEO & Discoverability for B2C Commerce – Zentrale SEO-Einstellungen für Canonical, Weiterleitungen, Sitemaps, Robots, Meta-Tags und URL-Syntax.
• SEO Best Practices for B2C Commerce.
• Configure SEO URLs for B2C Commerce – Mechanik der URL Rules.
• Create Canonical URL Tags for B2C Commerce – Empfehlung Variante → Master.
• Product Types and Variations in B2C Commerce – Master-/Variationsdatenmodell.
• Sitemaps in B2C Commerce – geplanter Sitemap-Auftrag.
• Generate a Robots.txt File with Business Manager.
• Hostname Aliases für B2C Commerce.

Salesforce – Entwicklerdokumentation zu PWA Kit und SCAPI

• PWA Kit Rendering (SSR & hydration) – SSR beim ersten Aufruf, Hydrationsgrenze und isomorpher Code.
• PWA Kit / Composable Storefront Best Practices Checklist – Crawlbarkeitstest ?__server_only und Migrationsplan für URLs und Weiterleitungen.
• Improve SEO with a Sitemap – Headless-Sitemap-Mechanismus und SCAPI-Upload-Endpunkt.
• URL Mapping / getUrlMapping – Headless-URL-Auflösung und Vorrang von Weiterleitungen.
• Storefront Next: Get Started und Migrate from PWA Kit to Storefront Next – neueres Headless-React-Framework; SEO-kritische Mechanismen dort separat bestätigen.

Salesforce – Trailhead-Lernmodule

• Explore SEO URLs.
• Configure SEO URLs — lowercase, whitespace separators, category/product patterns.
• Configure Hostname Aliases.

Google

• Consolidate duplicate URLs – Signalstärke, Kombination und Widerspruchsfreiheit.
• Product variant structured data – variesBy, hasVariant, isVariantOf und verschachtelte oder getrennte Muster.
• Localized versions of your pages – <link> gegenüber Sitemap, Gegenseitigkeit und x-default.
• Intro to structured data – JSON-LD als empfohlenes Format.

Zitate aus den Quellen

Öffentliche Aussagen aus der Entwicklerdokumentation von Salesforce und von Google, jeweils mit Sprunglink zur Passage. Inhalte aus Salesforces JavaScript-gerenderten Hilfe- und Business-Manager-Seiten werden in der fortgeschrittenen Perspektive paraphrasiert, weil sich der genaue Wortlaut nicht automatisiert verifizieren ließ. Prüfen Sie ihn im Live-Business-Manager oder in der gerenderten Dokumentation, bevor Sie ihn wörtlich nutzen.

Salesforce — PWA Kit Rendering (Entwicklerdokumentation)

• “For the critical first page load, we use server-side rendering because it offers a powerful tool for optimizing performance: caching.” Übersetzung: Für den kritischen ersten Seitenaufruf verwenden wir serverseitiges Rendering, weil Caching ein leistungsfähiges Werkzeug zur Performance-Optimierung bietet. Zum Zitat
• “Managed Runtime’s CDN cache can store a previously rendered version of a page and serve it to the user in an instant.” Übersetzung: Der CDN-Cache der Managed Runtime kann eine zuvor gerenderte Version einer Seite speichern und dem Nutzer sofort ausliefern. Zum Zitat
• “After the first page load, rendering duties are transferred from the server side to the client side through a process called hydration.” Übersetzung: Nach dem ersten Seitenaufruf werden die Rendering-Aufgaben durch einen Hydration genannten Prozess vom Server auf den Client übertragen. Zum Zitat
• “Some content, such as personalized or frequently changing content, must only be rendered on the client side to get the best possible performance.” Übersetzung: Manche Inhalte, etwa personalisierte oder häufig wechselnde, dürfen für bestmögliche Performance nur clientseitig gerendert werden. Zum Zitat

Salesforce – PWA-Kit-Checkliste für Best Practices

• Zur Crawlbarkeitsprüfung mit ?__server_only: “confirm that your server-rendered pages have enough data for crawlers and that the layout shift between server and client is small (ideally non-existent). This can help to improve your SEO ranking.” Übersetzung: Bestätigen Sie, dass serverseitig gerenderte Seiten genügend Daten für Crawler enthalten und der Layout-Shift zwischen Server und Client gering, idealerweise nicht vorhanden ist. Das kann das SEO-Ranking verbessern. Zum Zitat

Salesforce – SEO mit einer Sitemap verbessern

• “Sitemaps provide search crawlers with instructions on the pages to index and the site hierarchy, which can improve your SEO rankings.” Übersetzung: Sitemaps geben Such-Crawlern Anweisungen zu den zu indexierenden Seiten und zur Website-Hierarchie, was SEO-Rankings verbessern kann. Zum Zitat

Salesforce — URL Mapping / SCAPI (Entwicklerdokumentation)

• “If there’s a conflict between your URL redirects and your URL rules for SEO, the URL redirects take precedence.” Übersetzung: Bei einem Konflikt zwischen URL-Weiterleitungen und SEO-URL-Regeln haben die Weiterleitungen Vorrang. Zum Zitat

Google — Canonicalisierung

• “Don’t specify different URLs as canonical for the same page using different canonicalization techniques (for example, don’t specify one URL in a sitemap, but a different URL for that same page using rel=“canonical”).” Übersetzung: Geben Sie für dieselbe Seite mit verschiedenen Kanonisierungstechniken nicht unterschiedliche Canonical-URLs an, etwa eine URL in der Sitemap und eine andere über rel="canonical". Zum Zitat
• “When linking within your site, link to the canonical URL rather than a duplicate URL.” Übersetzung: Verlinken Sie intern auf die kanonische statt auf eine doppelte URL. Zum Zitat

Google – strukturierte Daten für Produktvarianten

• “use the ProductGroup class with associated properties variesBy, hasVariant, and productGroupID to group such variants together.” Übersetzung: Verwenden Sie die Klasse ProductGroup mit den Eigenschaften variesBy, hasVariant und productGroupID, um solche Varianten zu gruppieren. Zum Zitat

Salesforce Commerce Cloud (SFCC) SEO Checkliste

Nach Priorität und zuständiger Business-Manager-Ansicht geordnet. Die oberen Punkte haben den größten Einfluss.

Hohe Wirkung

• Canonical Variante → Master bestätigt: Jede Variations-PDP verweist auf ihr Masterprodukt; Sitemap und interne Links nennen dieselbe Master-URL.
• Facetten-/Refinement-URLs behandelt: Kombinationen erhalten Canonical und noindex gemäß Parametereinteilung; dies ist Eigenentwicklung.
• PWA-Kit-Crawlbarkeit geprüft: Startseite, PLP und PDP mit ?__server_only laden und Titel, Meta, Canonical, Hauptinhalt, Preis und JSON-LD in SSR bestätigen.
• Migrations-Weiterleitungsplan vollständig: auf Objekt-IDs statt fest codierter Pfade verweisen; bei Relaunches beansprucht dies 60 bis 70 % des SEO-Aufwands.

Business-Manager-Einrichtung (Merchant Tools → Website → SEO)

• URL Rules/Aliases: Kleinschreibung erzwingen, Bindestrich als Leerzeichentrenner, category oder category-path passend wählen, Produkte der Domain statt einem Kategoriepfad zuordnen und Alias-Datei mit Version 1 deklarieren.
• Pipelines Default-Start/Home-Show zugeordnet, damit keine doppelten Startseiten mit und ohne www entstehen.
• Sitemap-Auftrag geplant: verkehrsarme Zeit nach täglicher Replikation, getrennte Konfiguration je Instanztyp, korrektes lastmod; changefreq und priority nicht optimieren.
• Robots.txt minimal und bewusst: Business-Manager-Einstellung oder statische Cartridge-Datei unterscheiden, statischen Cache nach Cartridge-Änderung invalidieren und den domainweiten Geltungsbereich berücksichtigen.
• Meta Tag Rules mit hybrider Überschreibung ${IF Category.pageTitle THEN … ELSE …}; Verbindungswörter je Sprache/Land lokalisieren; H1-Vorlagen benötigen Entwicklung.
• Weiterleitungen: URL Redirects, Static oder Dynamic Mappings passend wählen; URL Redirects haben bei Konflikten Vorrang vor URL Rules.

Strukturierte Daten auf Entwickler-/Vorlagenebene

• JSON-LD für Product, ProductGroup und Breadcrumb in Vorlagen implementiert; im serverseitig gerenderten HTML vorhanden und nicht erst bei Hydration eingefügt.

International, nur Multi-Site/Multi-Locale

• hreflang umgesetzt über Include Alternate URLs in der Sitemap oder eigene <link>-Tags: gegenseitig, vollständig einschließlich Selbstverweis und x-default.
• B2B-Funktion Alternate Language Links nicht mit B2C verwechseln; B2C hat keine eigene hreflang-Ansicht.
• Für Bing gegebenenfalls ein Signal content-language berücksichtigen.
• Sitemap-Auftrag, robots.txt und Meta Tag Rules jeder Website synchron halten.

Die Denkmodelle

1. Native Grundlage oder Eigenentwicklung. Jede SFCC-SEO-Aufgabe ist entweder im Business Manager konfigurierbar – Robots, Sitemaps, URL Rules, Canonical-Varianten, Meta Tag Rules und automatische 301 – oder muss entwickelt werden, etwa hreflang, Facetten-URLs, Schema, H1-Vorlagen und Headless-Onpage-Tags. Diese Einordnung zeigt, ob eine Ansicht zu konfigurieren oder Entwicklung zu beauftragen ist.

2. Websites oder Locales bestimmen die Zahl der Konfigurationen. Jede Website ist eine getrennte vollständige SEO-Oberfläche mit eigenem Sitemap-Auftrag, robots.txt, Meta Tag Rules und URL Rules. Diese Entscheidung vervielfacht alle Bereiche.

3. Master/Variation entspricht ProductGroup. SFCCs Masterprodukt ist Googles ProductGroup; Variationsprodukte sind hasVariant-/isVariantOf-Mitglieder. Varianten auf den Master kanonisieren, als ProductGroup auszeichnen und überall dieselbe bevorzugte Master-URL verwenden.

4. robots.txt steuert Crawling, Canonical/noindex steuern Indexierung. Halten Sie robots.txt minimal. Es blockiert nur Crawling und gilt domainweit; für Indexierungsentscheidungen verwenden Sie Canonical und noindex.

5. In PWA Kit ist SSR notwendig, aber nicht hinreichend. Entscheidend ist, ob SEO-kritische Inhalte in der SSR-Ausgabe stehen oder als nur clientseitig markiert sind. Fehlen Titel, Canonical, Preis oder JSON-LD bei ?__server_only, sieht ein Crawler sie ebenfalls nicht.

Spickzettel für Salesforce-Commerce-Cloud-SEO

Wo Einstellungen im Business Manager liegen (Merchant Tools → Website → SEO → …)

URL Rules im Schnellüberblick

• Lower Case erzwingen; Bindestrich für Leerzeichen statt %20 oder Unterstrich.
• category für tiefe Bäume; category-path bei gleichnamigen Kategorien unter verschiedenen Eltern.
• Produkt-ID plus .html wird automatisch angehängt; Entfernung nur per Eigenentwicklung.
• Produkte der Domain statt einem Kategoriepfad zuordnen.
• sc.html, Seitentypkennzeichen und das Wort demandware in URLs vermeiden.

Syntax der Meta Tag Rules

• Basic: ${Category.Name} | Example Brand
• Hybrid override: ${IF Category.pageTitle THEN Category.pageTitle ELSE Category.Name}
• H1-Vorlagen werden von den Regeln nicht unterstützt; Eigenentwicklung ist nötig.

Redirects

• 301 dauerhaft, 308 über Eigenentwicklung, 307 vorübergehend.
• URL Redirects haben bei Konflikten Vorrang vor URL Rules.
• Auf Objekt-IDs statt fest codierter Pfade verweisen.

PWA Kit (headless)

• Einstiegsseiten mit ?__server_only auf crawler-sichtbare Inhalte prüfen.
• SEO-kritische Inhalte nicht ausschließlich clientseitig ausliefern.
• getUrlMapping nutzt URL Rules/Redirects des Business Managers; lange TTL, Standard zwölf Stunden.

Nicht tun

• Keine Zeit in changefreq/priority investieren; Google ignoriert sie.
• B2B Alternate Language Links nicht mit B2C-hreflang verwechseln.
• robots.txt weder zur Deindexierung noch für einzelne Locale-Unterordner einsetzen.
• PWA Kit nicht allein wegen SSR als SEO-sicher ansehen.
• Zuordnung von Default-Start/Home-Show nicht auslassen; sonst drohen doppelte Startseiten.

Zu vermeidende Fehler bei Salesforce-Commerce-Cloud-SEO

Sitemap-Felder optimieren, die Google ignoriert

Warum das falsch ist: changefreq und priority verbessern Googles Crawling nicht. Stattdessen: lastmod korrekt halten, Erzeugung nach der Replikation planen und prüfen, welche Canonical-URLs tatsächlich in der Sitemap erscheinen.

Die B2B-hreflang-Ansicht als B2C-Funktion behandeln

Warum das falsch ist: B2C Commerce besitzt die B2B-Funktion Alternate Language Links nicht. Stattdessen: In der B2C-Sitemap Include Alternate URLs verwenden oder gegenseitige <link rel="alternate">-Tags implementieren.

robots.txt als Deindexierungswerkzeug verwenden

Warum das falsch ist: Disallow steuert Crawling, nicht Indexierung, und verhindert das Lesen von Canonical oder noindex. Es kann bei gemeinsamer Domain keine einzelne Locale sauber ansprechen. Stattdessen: robots.txt minimal halten und Canonical oder noindex für den Indexierungszustand verwenden.

PWA Kit wegen SSR automatisch für crawlbar halten

Warum das falsch ist: Preis, Text, Metadaten oder JSON-LD können weiterhin nur clientseitig vorliegen. Stattdessen: Repräsentative Startseiten-, PLP- und PDP-URLs mit ?__server_only prüfen und alle crawlerkritischen Elemente bestätigen.

Belassen Default-Start und Home-Show nicht zugeordnet

Warum das falsch ist: Die Pipelines können unter Hostnamenvarianten doppelte Startseiten ausliefern. Stattdessen: Beide Pipelines ausdrücklich zuordnen und Hostnamenvarianten crawlen, um ihre Zusammenführung auf eine Startseite zu bestätigen.

Nachweisen, dass eine PWA-Kit-Rendering-Änderung funktioniert

Server-only-Antwort nach der Bereitstellung vergleichen

Test: Geänderte Startseiten-, PLP- und PDP-URLs mit ?__server_only öffnen und den Quelltext auf Titel, Meta-Beschreibung, Canonical, Haupttext, Preis beziehungsweise Verfügbarkeit und JSON-LD prüfen.

Erwartetes Ergebnis: Jedes von der Veröffentlichung betroffene SEO-kritische Element steht ohne Hydration in der Serverantwort.

Fehlerdeutung: Ein fehlendes Element wird weiterhin nur clientseitig abgerufen oder gerendert, oder seine serverseitige Datenabhängigkeit ist fehlgeschlagen.

Überwachungsfenster: Sofort nach der Bereitstellung; nach Aktualisierung des Managed- Runtime-Caches einmal wiederholen.

Rollback-Auslöser: Änderung zurückrollen, wenn Canonical, Hauptinhalt, Produktverfügbarkeit oder ein zuvor vorhandener Strukturdatensatz aus der Server-only- Antwort verschwindet.

Bestätigen, dass Google dieselben kritischen Inhalte erhält

Test: Dieselben repräsentativen URLs mit der URL-Prüfung der Google Search Console testen und das geprüfte HTML ansehen.

Erwartetes Ergebnis: Das geprüfte HTML enthält dieselben kritischen Inhalte und Tags wie die Antwort mit ?__server_only.

Fehlerdeutung: Google erhält eine zwischengespeicherte, blockierte oder anderweitig abweichende Antwort.

Überwachungsfenster: Sofort einen Live-Test ausführen und vor der Beurteilung des Indexierungsergebnisses die normale Recrawl-Zeit abwarten.

Rollback-Auslöser: Zurückrollen, wenn der Live-Test wiederholt zuvor vorhandene indexierbare Inhalte oder Canonical-Signale verliert.

Tools für Salesforce-Commerce-Cloud-SEO

• Business Manager: plattformeigene Administration; alle SEO-Hebel liegen unter Merchant Tools → Website → SEO.
• URL-Parameter ?__server_only: Salesforces eigener Headless-Crawlbarkeitstest. An eine PWA-Kit-Seite anhängen, um die Serverausgabe vor der Hydration zu sehen.
• Google Search Console: Sitemap-Einreichung, URL-Prüfung des gerenderten HTML, internationale Ausrichtung und Crawling-Statistiken; maßgeblich für Googles Verhalten.
• Bing Webmaster Tools: zweite Sitemap-Einreichung, Crawling-Kontrolle und Prüfung von content-language, da Bing hreflang historisch anders als Google behandelt hat.
• Screaming Frog / Ahrefs Site Audit: Store crawlen, um Refinement-URL-Explosionen, falsche Varianten-Canonicals, Weiterleitungsketten und doppelte Startseiten zu finden.
• URL-Prüfung in GSC: bei PWA Kit bestätigen, dass das gerenderte HTML Titel, Canonical, Preis und JSON-LD enthält – die Google-seitige Entsprechung zu ?__server_only.
• Rich Results Test / Schema Markup Validator: ProductGroup-/Varianten-JSON-LD prüfen, da Schema in SFCC entwickelt wird und keinen nativen Schalter besitzt.

Empfehlenswerte Ressourcen

Verwandte Inhalte auf dieser Website

• Facettennavigation – plattformunabhängige Details zu SFCCs wichtigstem Eigenentwicklungsproblem.
• Canonicalisierung – Mechanik hinter Variante → Master.
• Produktvarianten-SEO – Muster ProductGroup/hasVariant/isVariantOf.
• hreflang – internationale Mechanik für SFCCs nicht automatische Umsetzung.
• Headless-CMS-SEO – relevant zu SSR und Hydration in PWA Kit.

Salesforce, offiziell

• SEO & Discoverability for B2C Commerce – SEO-Zentrale im Business Manager.
• PWA Kit Rendering und PWA Kit Best Practices Checklist – SSR, Hydration und ?__server_only.
• Improve SEO with a Sitemap und URL Mapping / getUrlMapping.

Google official

• Product variant structured data und Consolidate duplicate URLs.
• Localized Versionen von Ihr Seiten (hreflang).

Meine verwandten Artikel

• A Website Migration Takes More Than a Checklist to Be Successful – relevant für SFRA-Relaunches und PWA-Kit-Migrationen.
• 11 Types of Redirects & Their SEO Impact und 301 vs. 302 Redirects for SEO – Leitfäden zu 301, 307 und 308.
• JavaScript SEO Issues & Best Practices – Rendering-Seite von PWA Kit.

Aus der Branche (SFCC-spezifische Fachbeiträge; gegen Live-Dokumentation prüfen)

• Resignal – SFCC SEO Masterclass Part 1 – URL Rules, Aliases, Startseitenfallen und Alias-Version 1.
• Resignal – SFCC SEO Masterclass Part 2 – Sitemap-Erzeugung und Weiterleitungswerkzeuge.
• Resignal – SFCC SEO Masterclass Part 3 – Meta Tag Rules, hybride Überschreibung und H1-Begrenzung.
• NOVOS – The Ultimate Guide to Salesforce Ecommerce SEO – Domain-Zuordnung und Weiterleitung auf Objekt-IDs.
• Eskimoz – Is SEO on Salesforce Commerce Cloud Even Possible? – Plattformkenntnis als Begrenzung.
• Acxiom – SFCC SEO: Important Considerations Before Your SFRA Launch – Weiterleitungsstrategie als 60 bis 70 % des Startaufwands.

Selbsttest: Salesforce-Commerce-Cloud-SEO

Fünf kurze Fragen dazu, wie SEO in Salesforce Commerce Cloud funktioniert. Wählen Sie jeweils eine Antwort und prüfen Sie anschließend das Ergebnis.

Änderungsprotokoll