E-commerce SEO

SEO Salesforce Commerce Cloud (SFCC) : URL, meta, redirections et sitemaps

Benoit DemonchauxCo-fondateur de Slashr, directeur SEO, conférencier SMX 2024.

Mis à jour le Publié le 18 min de lecture

Résumer avec
Le SEO d'un site SFCC se règle dans Business Manager (URL, meta, redirections, sitemaps) et dans le code du storefront (rendu serveur, balises dans le head)

Le SEOSearch Engine Optimization. Ensemble des techniques visant à améliorer le positionnement d'un site web dans les résultats naturels des moteurs de recherche. d'un site Salesforce Commerce Cloud (SFCC) se règle à deux endroits : les modules SEO de Business Manager (URL, balises meta, redirections, sitemaps, robots.txtFichier texte à la racine d'un site indiquant aux robots quelles pages explorer ou ignorer.) et le storefront, qui fixe le HTML que GooglebotRobot d'exploration de Google qui parcourt le web pour découvrir et indexer les pages. reçoit. Les outils sont natifs, le résultat dépend de leur réglage.

Pour qui : les équipes e-commerce et les développeurs qui lancent un site SFCC, y migrent ou reprennent un existant. Chaque section part d'un module : le réglage à choisir, la limite documentée par Salesforce, le piège.

Business Manager et storefront : où se règle le SEO sur SFCC

Sur SFCC, le marchandiseur règle le SEO dans Business Manager et les développeurs le rendent visible dans le storefront : un audit regarde les deux.

SFCC s'appelait Demandware. Salesforce a finalisé le rachat de Demandware le 11 juillet 2016, et la plateforme est devenue Salesforce Commerce Cloud ; la documentation actuelle parle de B2C Commerce. Le back-office, Business Manager, regroupe les réglages SEO dans Merchant Tools : règles d'URL, redirections, sitemaps, robots.txt et règles de balises meta.

Le storefront, lui, se choisit. Trois fronts cohabitent sur les sites SFCC :

  • SFRA (Storefront Reference Architecture) : HTML et JavaScript générés côté serveur, avec des templates ISML.
  • Storefront Next, l'option que Salesforce recommande aujourd'hui, un framework React complet (React Router 7, React 19) avec rendu côté serveur, hébergé sur Managed Runtime. Salesforce documente une migration progressive depuis SFRA, en mode hybride.
  • PWA Kit, aussi appelé Composable Storefront : une app React en headless, dont le même code tourne côté serveur et côté client. La page de choix de Salesforce ne le propose plus pour un nouveau projet, et Salesforce documente la migration de PWA Kit vers Storefront Next. Il reste le front de sites déjà en ligne.
Les trois storefronts de Salesforce B2C Commerce, leur mode de rendu et le contrôle SEO à faire pour chacun
Les trois storefronts de Salesforce B2C Commerce, leur mode de rendu et le contrôle SEO à faire pour chacun

La conséquence SEO tient en une phrase : les règles se créent dans Business Manager, leur sortie dans le <head> est du code. Deux équipes, donc deux contrôles. Le module Trailhead sur les balises meta précise que ses exemples d'intégration valent pour SFRA, et ne couvrent ni Storefront Next ni PWA Kit. En headless, vérifiez donc que title, meta description, robots, canonical et hreflang sortent bien dans le HTML servi.

Storefront Next pousse cette séparation plus loin. Business Manager reste la référence pour la forme des URL, mais le storefront la recopie dans sa configuration seoRoutes.

Chaque changement de règle d'URL dans Business Manager demande une mise à jour du code, un rebuild et un redéploiement, et la synchronisation automatique n'est qu'annoncée. Les balises passent par le composant SeoMeta, qui reçoit ses valeurs du code : pour que vos règles de balises s'appliquent, les développeurs doivent mapper les pageMetaTags de Business Manager vers ce composant.

Pour un site PWA Kit, la checklist de mise en ligne de Salesforce donne la méthode : ajouter le paramètre ?__server_only aux pages d'entrée (accueil, catégories, listes de produits, fiches produits) et confirmer que le rendu serveur contient assez de données pour les crawlers.

Le module Trailhead ajoute que beaucoup de crawlers d'IA, comme GPTBot, ClaudeBot ou PerplexityBot, n'exécutent pas JavaScript : nom, description et prix des produits doivent figurer dans le HTML rendu côté serveur. Le fonctionnement général est détaillé dans notre article sur le server-side rendering et le SEO.

Règles d'URL : catégories et fiches produits lisibles, sans conflit

Les URL se règlent dans Merchant Tools > SEO > URL Rules : des réglages de caractères communs, une règle par type de page, puis une validation des conflits.

Sans règle SEO, une catégorie SFCC ressemble à l'exemple de Salesforce : www.cloudkicks.com/on/demandware.store/Sites-cloudkicks-Site/default/Search-Show?cgid=mens-clothing-shorts. Avec les URL SEO activées, la même page devient www.cloudkicks.com/mens-clothing-shorts.

L'onglet Settings porte trois réglages à faire en premier :

  • Lower Case : toutes les URL en minuscules, pour qu'une marque écrite avec deux casses ne crée pas deux URL. Les identifiants produits ne changent pas.
  • Remplacement des espaces : %20 (encodage d'URL), ou au choix le plus, l'underscore, le tiret ou le point. Trailhead rappelle que les moteurs lisent le tiret comme un séparateur de mots, et prAlgorithme historique de Google évaluant l'importance d'une page selon ses backlinks. Toujours utilisé en interne.évient : s'il sert aussi de délimiteur dans les URL de facettes, un nom de produit ou de marque qui en contient crée des doublons.
  • Remplacements de caractères : l'exemple de Salesforce remplace « &ampAccelerated Mobile Pages. Framework Google pour créer des pages mobiles ultra-rapides (moins utilisé aujourd'hui).; » par un tiret, et /on-the-go-%26-gear/hiking/ devient /on-the-go-gear/hiking/.
Onglet Catalog URLs du module URL Rules de Business Manager : règle d'URL de catégorie, surcharge par l'attribut pageURL, slash final et URL de refinements

L'onglet Catalog URLsUniform Resource Locator. Adresse unique d'une page web. Une URL optimisée est courte, descriptive et contient le mot-clé. définit la forme des URL de catégorie et de produit. Une règle comme [ category-path, [ attribute, displayName ], - ] produit /mens-clothing/. Deux arbitrages, documentés par Salesforce : category-path quand le même nom de catégorie existe sous plusieurs parents (chaussures femme et chaussures homme), category seul quand l'arborescence dépasse deux ou trois niveaux, pour garder des URL courtes. L'identifiant produit s'ajoute toujours en fin d'URL de fiche, sans le mettre dans la règle. Pour une page précise, l'attribut pageURL remplace l'URL générée par la règle.

Reste les conflits. Quand deux catégories portent le même nom, SFCC ajoute un entier : shoes-1, shoes-2. L'URL reste unique, sans mot-clé qui distingue les deux pages. Mieux vaut corriger la règle ou poser un pageURL sur l'une des deux.

Le bouton Validate liste les conflits, Run Update Now relance la génération. Le job de génération tourne sur toutes les instances sauf la production : les URL se règlent sur staging, puis partent en production avec la réplication des catalogues et des bibliothèques. Ce circuit produit directement les URL d'un site SFRA ; sur Storefront Next, la configuration seoRoutes du storefront doit suivre. Pour le reste, une page catégorie SEO se travaille sur SFCC comme sur n'importe quel CMS.

Trois réglages du module URL Rules de SFCC et l'URL qu'ils produisent : règle de catégorie, remplacement de caractère, conflit numéroté
Trois réglages du module URL Rules de SFCC et l'URL qu'ils produisent : règle de catégorie, remplacement de caractère, conflit numéroté

Facettes : quelles URL de filtres laisser à Google

En SFRA, une combinaison de filtresSystème de filtres (taille, couleur, prix) générant de nombreuses URLs. Nécessite une gestion SEO. recherchée passe dans le chemin d'URL, les autres reçoivent un noindexDirective indiquant aux moteurs de ne pas indexer une page. par règle meta, puis un Disallow une fois sorties de l'index. Sur Storefront Next, le modèle garde tous les filtres dans le paramètre refine : le tri se fait dans le code.

SFCC appelle les filtres des « search refinements ». Par défaut, ils s'écrivent en paramètres, comme dans l'exemple de Salesforce : /new-arrivals/?prefn1=brand&prefv1=abrand&prefn2=refinementColor&prefv2=blau|grün. Côté Business Manager, l'option Enable Category Search Refinement URLs les fait passer dans le chemin, et la même page devient /new-arrivals/abrand/blau|grün.

Cette option a deux limites qui imposent de choisir : 30 refinements activables au maximum sur le site, et 5 par catégorie ou dossier. Il faut trier.

Le tri se fait sur la demande de recherche. Prenons une catégorie chaussures fictive : si les requêtesTerme ou expression que les utilisateurs saisissent dans un moteur de recherche. Base de toute stratégie SEO. du type « baskets nike blanches » ont du volume, marque et couleur prennent deux des cinq places. Un filtre de largeur sans recherche associée reste en paramètre. Salesforce signale aussi deux sources de conflits : la même valeur dans deux refinements (« red » en couleur et en marque) et les valeurs qui contiennent le délimiteur, tiret ou underscore.

Pour les combinaisons sans demande, les règles de balises meta savent poser un noindex conditionnel. L'exemple de la documentation Salesforce passe en noindex,nofollowAttribut indiquant aux moteurs de ne pas suivre un lien ou de ne pas transmettre de jus SEO. toute page filtrée par couleur ou issue d'une recherche interne :

${IF SearchRefinement.refinementColor OR SearchPhrase THEN Constant('noindex,nofollow') ELSE Constant('index,follow')}

Ne la copiez pas telle quelle. Dans l'exemple des baskets, la couleur est ouverte : la condition doit viser les filtres fermés, comme la largeur. refinementColor est l'identifiant de l'attribut couleur, le même qui apparaît dans le paramètre prefn2=refinementColor de l'URL : remplacez-le par l'identifiant du refinement à fermer.

Sur Storefront Next, le piège est ailleurs. Les filtres passent en paramètre refine, que le modèle garde dans la canonicalBalise indiquant la version principale d'une page en cas de contenu dupliqué ou similaire. des catégories, et la balise robots n'apparaît que si le code pose noIndex. Sans développement, chaque combinaison filtrée se déclare donc indexable : la liste des filtres fermés se transmet aux développeurs, qui posent le noIndex dans le storefront. Le modèle laisse aussi la recherche interne indexable par défaut.

Sur SFRA, le module Trailhead sur le robots.txt propose ensuite de bloquer les paramètres de refinement (prefn, prefv, pmin, pmax, srule). L'ordre compte : Google rappelle qu'une URL bloquée dans le robots.txt n'est plus explorée, et que son noindex n'est donc jamais lu. Sur un site déjà indexé, le noindex passe d'abord, crawlProcessus par lequel les robots des moteurs de recherche parcourent et analysent les pages web. ouvert, et le Disallow arrive une fois les URL sorties de l'index. Sur un site neuf, le Disallow suffit dès le lancement.

Sur Storefront Next, même ordre (noindex d'abord, Disallow ensuite), mais filtres ouverts et fermés partagent le même paramètre refine, avec une paire attribut=valeur par filtre dans le modèle officiel. Un Disallow sur refine couperait aussi les combinaisons à garder. La règle du robots.txt, servi par l'application, vise donc l'attribut fermé, par exemple Disallow: /*refine=c_largeur (identifiant fictif). Le robots.txt du modèle autorise tout par défaut.

Arbre de décision pour une combinaison de filtres sur SFCC, en SFRA et sur Storefront Next : URL ouverte, noindex, puis Disallow
Arbre de décision pour une combinaison de filtres sur SFCC, en SFRA et sur Storefront Next : URL ouverte, noindex, puis Disallow

La méthode complète pour choisir les facettes à ouvrir et celle pour désindexer une URL proprement s'appliquent telles quelles.

Title, meta description et JSON-LD : les Page Meta Tag Rules

Les title, meta descriptionBalise HTML décrivant le contenu d'une page. Affichée sous le titre dans les SERP, elle influence le CTR., balises robots et données structuréesCode ajouté au HTML pour aider les moteurs à comprendre le contenu et générer des rich snippets. JSON-LDFormat recommandé par Google pour implémenter les données structurées dans le code source. se génèrent par règles, par type de page, en cascade : une règle posée sur la catégorie racine couvre tout le catalogue.

Le module s'ouvre dans Merchant Tools > Site > SEO & Discoverability > Page Meta Tag Rules. Il connaît cinq scopes : page d'accueil, fiche produitPage dédiée à un produit, devant être optimisée avec description unique, images et données structurées. (PDP), liste de produits (PLP), page de contenu et liste de contenus.

Une règle mêle du texte fixe et des expressions dynamiques en ${...}, qui lisent les attributs du produit, de la catégorie, du dossier, du contenu ou du site. Sur le modèle de l'exemple Salesforce, une meta description de fiche produit peut s'écrire :

Découvrez ${Product.name} dans ${Category.displayName} | ${Site.displayName}

Un piège : une expression vide n'imprime rien, et le texte fixe autour reste. Si Category.displayName est vide, la règle ci-dessus donne « Découvrez Baskets X dans | Ma Boutique ». Les opérateurs IF, THEN et ELSE servent à prévoir ce cas, et Constant() imprime un texte fixe sous condition.

Fenêtre d'édition d'une règle de balise dans Business Manager : scope Product Listing Page, Meta Tag ID description et opérateurs disponibles

La cascade évite d'écrire une règle par produit. Pour une fiche, SFCC cherche dans cet ordre : le produit, ses groupes de variation, le produit principal, la catégorie principale, les catégories parentes jusqu'à la racine, puis la locale de repli. Une règle sur la racine sert de filet. Les catégories à fort enjeu reçoivent leur propre règle. Ce que la règle d'une fiche doit dire (le nom du modèle en tête du title, un argument de réassurance dans la meta) est détaillé dans le guide de la rédaction d'une fiche produit SEO.

Chaque règle tient en 4 000 caractères, et un changement met jusqu'à 30 minutes à s'appliquer, sans reconstruction d'index. L'onglet Page Meta Tag Rules d'un produit affiche l'aperçu avant mise en ligne.

Le même module crée des balises de type JSON-LD : la définition de balise est à créer avant la règle, puis elle se remplit comme une meta. Pour la rédaction, les principes de la balise titleBalise HTML définissant le titre d'une page, affiché dans les SERP et l'onglet du navigateur. Facteur de ranking important. et de la meta description restent ceux de n'importe quel site. Une règle bien écrite les applique à des milliers de pages d'un coup. Une règle bâclée aussi.

Deux règles de balises SFCC annotées : une meta description de fiche produit et une balise robots conditionnelle sur les refinements
Deux règles de balises SFCC annotées : une meta description de fiche produit et une balise robots conditionnelle sur les refinements

Redirections : le bon outil selon l'origine de l'URL

Sans fichier .htaccess, SFCC redirige avec quatre outils principaux : URL Redirects pour les URL du site, l'URL Archive en automatique, les mappings statiques et dynamiques pour les URL d'un ancien site. Les redirections de refinements et les alias d'hôte complètent la liste.

URL Redirects (Merchant Tools > SEO > URL Redirects) traite les URL qui existent déjà sur SFCC : une catégorie renommée, un produit retiré, un contenu déplacé.

Chaque redirection a une source (une catégorie dans l'exemple de Salesforce), une destination, le choix de copier ou non les paramètres, et un type de redirection, Permanent (301Redirection permanente transférant le jus SEO de l'ancienne URL vers la nouvelle.) pour un changement définitif. Un détail compte. Salesforce conseille de viser une destination par son identifiant (catégorie, produit) plutôt que par son URL : si la règle d'URL change, la redirection suit.

Formulaire New URL Redirect de Business Manager, ici avec une source et une destination en URL : copie des paramètres et type Permanent (301)

L'URL Archive travaille seule. Sur staging et en production, SFCC garde les anciens mappings de catégories et de dossiers quand ils changent, et les redirige vers les nouveaux. Les redirections de refinements jouent le même rôle pour les URL de facettes modifiées.

Les mappings statiques et dynamiques servent à la migration depuis une autre plateforme, avec des URL que SFCC ne connaît pas. Le statique gère une URL par ligne, pour les pages uniques.

Le dynamique utilise des motifs : * couvre tout jusqu'au prochain slash, ** traverse les slashes, et aucun des deux ne lit la query string. L'exemple de règle de Salesforce :

/index.asp?ID=576416&Cat=hockey.html    ie=iso-8859-1    /sports-equipment/576416,default,pd.html?cgid=Hockey

Le motif à gauche reconnaît l'ancienne URL, l'option au milieu est facultative, le modèle à droite construit l'URL SFCC. Une partie capturée par un joker se réutilise dans la cible avec {0}. Une redirection d'une URL SFCC vers une autre URL SFCC passe par URL Redirects : les mappings dynamiques la refusent.

Les quatre outils principaux de redirection de SFCC selon l'origine de l'URL, avec leur usage et leur limite par site
Les quatre outils principaux de redirection de SFCC selon l'origine de l'URL, avec leur usage et leur limite par site

Les quotas comptent dès le cadrage : 25 000 URL Redirects, et environ 18 000 mappings statiques et 18 000 dynamiques par site.

Prenons une migration fictive de 60 000 fiches produits : une ligne par URL ne tient pas, il faut des motifs dynamiques bâtis sur la structure des anciennes URL. Le plan de redirection SEO se construit donc avec ces chiffres en tête, et un accompagnement SEO de refonte et de migration sécurise le passage pour un gros catalogue.

Sitemaps et robots.txt : générés en production, bloqués ailleurs

Le sitemapFichier XML listant toutes les URLs d'un site pour faciliter leur découverte par les moteurs de recherche. se génère sur l'instance de production, avec les locales en liens alternates. En SFRA, le robots.txt se règle par type d'instance pour fermer staging et développement ; en headless, c'est l'application qui le sert.

Le module Merchant Tools > SEO > Sitemaps produit un index, sitemap_index.xml, et des fichiers numérotés. Chaque fichier contient de 0 à 50 000 liens, selon le réglage.

Pour un site multilingue, chaque entrée peut lister ses autres locales en liens alternates, l'équivalent des balises hreflangAttribut HTML indiquant la langue et la région ciblée d'une page pour le SEO international.. La version de 2023 de cet article disait le contraire : c'était faux. Google accepte cette méthode dans sa documentation sur les versions localisées. Pour un site multi-pays, l'architecture des locales se cadre avec un accompagnement SEO international avant la génération du premier sitemap.

Quatre points de réglage :

  • Instance : Trailhead demande de créer les sitemaps sur la production seulement, sinon, sans protection par mot de passe du storefront, les robots peuvent indexerProcessus par lequel Google ajoute une page à sa base de données pour qu'elle puisse apparaître dans les résultats. les URL de staging.
  • Contenu : par défaut, un produit doit être en ligne, disponible et recherchable pour entrer dans le sitemap. Un type de vue d'image ajoute l'URL, le titre et le texte alternatifAttribut HTML décrivant le contenu d'une image pour les moteurs de recherche et l'accessibilité. des images.
  • Priorité et fréquence : Business Manager propose priority et changefreq, mais Google ignore ces deux valeurs. Le temps passé à les régler est perdu pour Google.
  • Routes hors Business Manager : en headless, les pages dont les routes ne sont pas déclarées dans Business Manager passent par un sitemap personnalisé, envoyé avec l'endpoint uploadCustomSitemapAndTriggerSitemapGeneration. Les sitemaps personnalisés s'ajoutent à l'index sans écraser ceux du système.

Le job de génération se lance à la main ou se planifie, et Salesforce juge suffisante une mise à jour quotidienne ou tous les deux jours. L'URL de sitemap_index.xml va dans le robots.txt et dans la Search ConsoleOutil gratuit Google pour surveiller et optimiser la présence d'un site dans les résultats de recherche..

Points de contrôle des sitemaps et du robots.txt sur SFCC, de l'instance de production aux routes headless
Points de contrôle des sitemaps et du robots.txt sur SFCC, de l'instance de production aux routes headless

Le robots.txt se règle dans Merchant Tools > SEO > Robots, par type d'instance. Staging et développement passent en « All Spiders Disallowed to Access Any Static Resources ».

La production reçoit une définition personnalisée, l'option que recommande Salesforce, écrite sur staging puis répliquée avec les préférences de site. Après chaque modification, invalidez le cache de contenu statique (Administration > Sites > Manage Sites > Cache), sinon l'ancien fichier reste servi. Avant le lancement, la protection par mot de passe du storefront tient aussi les robots à l'écart. Les règles de syntaxe sont dans notre guide du robots.txt en SEO.

En headless complet, comme un site PWA Kit, le module Robots ne sert pas. La documentation Salesforce demande de mettre à jour le robots.txt du site headless avec l'URL de sitemap_index.xml, et de faire servir le sitemap à la racine du domaine par l'application. Le passage par le module Robots de Business Manager n'y est demandé qu'en plus, pour les sites hybrides SFRA et PWA Kit.

Lancement ou migration SFCC : l'ordre de mise en place

Sur un projet SFCC, l'ordre compte autant que les réglages : chaque étape s'appuie sur la précédente, et une redirection posée avant les règles d'URL finales pointe vers des URL qui vont changer.

Ordre de mise en place du SEO sur un projet SFCC en sept étapes, du storefront au sitemap en production
Ordre de mise en place du SEO sur un projet SFCC en sept étapes, du storefront au sitemap en production
  1. Storefront : contrôler le HTML servi des pages d'entrée (?__server_only sur PWA Kit), avec title, meta, canonical et contenu produit présents.
  2. Alias d'hôte et locales : Salesforce exige les alias d'hôte pour que les URL modifiées s'affichent sur le storefront. Sur un site multilingue, la locale se place dans le chemin, le nom d'hôte ou un paramètre ; le chemin (/fr/) reste le plus simple à mailler et à suivre.
  3. Règles d'URL : réglées et validées sur staging, conflits corrigés, puis réplication en production avec les catalogues et les bibliothèques.
  4. Refinements : jusqu'à 5 par catégorie en SFRA, choisis sur la demande de recherche, noindex pour les autres combinaisons (règle de balise en SFRA, noIndex dans le code sur Storefront Next).
  5. Règles de balises : une par scope sur la racine, des surcharges sur les catégories à fort enjeu, l'aperçu contrôlé sur quelques fiches.
  6. Redirections : export des URL de l'ancien site, motifs en mappings dynamiques, cas isolés en statiques, URL Redirects pour les URL SFCC renommées. L'URL Request Analyzer de Business Manager montre comment le storefront traite une URL donnée.
  7. Sitemap et robots.txt : sitemap généré en production, robots.txt personnalisé (dans Business Manager en SFRA, dans l'application en headless), index déclaré dans la Search Console.

Les règles du SEO restent celles de tout site e-commerce. Ce qui coûte du temps sur SFCC, c'est la mécanique propre à la plateforme : quotas, réplication entre instances, partage des rôles entre Business Manager et storefront. Une agence SEO Salesforce Commerce Cloud qui connaît ces modules évite d'apprendre ces limites pendant la migration. Slashr accompagne ces projets depuis Lille, avec l'équipe de notre agence SEO.

Questions fréquentes

Salesforce Commerce Cloud est-il bon pour le SEO ?

Oui pour les outils : URL réécrites, règles de balises par type de page, redirections, sitemaps avec locales alternates et robots.txt par instance sont natifs. La difficulté vient du réglage et du partage des rôles : un module mal réglé touche des milliers d'URL d'un coup, et le storefront doit sortir proprement ce que Business Manager génère.

Faut-il passer à Storefront Next ou au headless pour le SEO ?

Le SEO seul ne justifie pas le changement : SFRA rend déjà le HTML côté serveur, comme PWA Kit et Storefront Next. Le headless ajoute même des contrôles : l'insertion des balises dans le <head>, l'alignement des URL et des balises sur les règles de Business Manager, le sitemap des routes hors Business Manager. Salesforce présente Storefront Next comme son option recommandée. La décision se prend sur le front, puis le SEO se vérifie sur le HTML servi.

Combien de redirections SFCC accepte-t-il ?

Trois quotas distincts. Salesforce documente 25 000 URL Redirects et environ 18 000 mappings statiques et 18 000 dynamiques par site. Quand le volume d'URL à migrer approche ces quotas, les motifs dynamiques (* et **) remplacent la redirection ligne par ligne.

Faut-il une agence SEO spécialisée SFCC ?

Les principes du référencement restent les mêmes sur Salesforce que sur un autre CMS. Une agence ou un consultant SEO qui connaît SFCC fait gagner du temps sur Business Manager, les quotas de redirections, la réplication staging-production et le dialogue avec les développeurs du storefront. Le critère utile : la capacité à écrire des règles d'URL, de balises et de redirections directement exploitables par vos équipes.

Sources

  • Salesforce Completes Acquisition of Demandware : investor.salesforce.com/news/news-details/2016/Salesforce-Completes-Acquisition-of-Demandware/default.aspx
  • Choose Your B2C Commerce Storefront Type : developer.salesforce.com/docs/commerce/sfra/guide/which-product.html
  • Storefront Next Architecture : developer.salesforce.com/docs/commerce/sfnext/guide/sfnext-architecture.html
  • PWA Kit Overview : developer.salesforce.com/docs/commerce/pwa-kit-managed-runtime/guide/pwa-kit-overview.html
  • Automate and Validate Meta Tags for SFRA Storefronts, Salesforce Trailhead : trailhead.salesforce.com/content/learn/modules/b2c-seo-meta-tags/b2c-seo-meta-tag-integrate-check
  • Pre-Build and Go-Live Best Practices Checklist : developer.salesforce.com/docs/commerce/b2c-commerce/guide/pwa-best-practices.html
  • SEO URL Best Practices, Salesforce Trailhead : trailhead.salesforce.com/content/learn/modules/b2c-seo-urls/b2c-explore-seo-urls
  • SEO URL Configurations, Salesforce Trailhead : trailhead.salesforce.com/content/learn/modules/b2c-seo-urls/b2c-configure-seo-urls
  • Resolve SEO URL Conflicts, Salesforce Trailhead : trailhead.salesforce.com/content/learn/modules/b2c-seo-urls/b2c-seo-url-preview-resolve-conflicts
  • SEO Search Refinement Rules Configuration, Salesforce Trailhead : trailhead.salesforce.com/content/learn/modules/b2c-seo-urls/b2c-seo-url-search-refinements
  • Configure page meta tag rules for product pages, Salesforce Trailhead : trailhead.salesforce.com/content/learn/modules/b2c-seo-meta-tags/b2c-seo-meta-tag-configure-page-rules
  • Generate Robots.txt File, Salesforce Trailhead : trailhead.salesforce.com/content/learn/modules/b2c-xml-sitemaps/b2c-xml-sitemaps-generate-robots
  • Bloquer l'indexation dans la recherche avec "noindex", Google Search Central
  • Gérer l'exploration des URL de navigation à facettes, Google Search Central
  • SEO Meta Tag Rules for Storefronts and JSON-LD, Salesforce Trailhead : trailhead.salesforce.com/content/learn/modules/b2c-seo-meta-tags/b2c-seo-meta-tag-explore-rules
  • URL Redirect Configuration, Salesforce Trailhead : trailhead.salesforce.com/content/learn/modules/b2c-seo-urls/b2c-seo-url-configure-url-redirects
  • XML Sitemaps Best Practices, Salesforce Trailhead : trailhead.salesforce.com/content/learn/modules/b2c-xml-sitemaps/b2c-xml-explore-sitemaps
  • Versions localisées de vos pages, Google Search Central
  • Create Sitemap SEO Settings, Salesforce Trailhead : trailhead.salesforce.com/content/learn/modules/b2c-xml-sitemaps/b2c-xml-generate-sitemaps
  • Créer et envoyer un sitemap, Google Search Central
  • Improve SEO with a Sitemap : developer.salesforce.com/docs/commerce/b2c-commerce/guide/create-a-sitemap.html
  • Submit Sitemaps and Verify Site Ownership, Salesforce Trailhead : trailhead.salesforce.com/content/learn/modules/b2c-xml-sitemaps/b2c-xml-sitemaps-notify-search-engines
  • Migrate from PWA Kit to Storefront Next : developer.salesforce.com/docs/commerce/sfra/guide/sfnext-pwa-overview.html
  • SEO URL Rules Best Practices for Storefront Next : developer.salesforce.com/docs/commerce/sfnext/guide/sfnext-seo-url-rules-best-practices.html
  • developer.salesforce.com/docs/commerce/sfra/guide/sfnext-pwa-seo-metadata.html
  • developer.salesforce.com/docs/commerce/commerce-solutions/guide/sfnext-seo-metadata.html
  • storefront-next-template, src/components/category-refinements/index.tsx, Salesforce Commerce Cloud (GitHub)
  • storefront-next-template, public/robots.txt, Salesforce Commerce Cloud (GitHub)

Tags

  • E-commerce SEO

L’auteur

Benoit Demonchaux

Co-fondateur & SEO Director

Benoît Demonchaux est co-fondateur de Slashr, agence de référencement naturel basée à Lille et consultant SEO depuis 6 ans. Avant de créer Slashr, il a exercé en tant qu'éditeur de sites et chef de projets dans une grande agence SEO.

Voir tous ses articles

Articles recommandés

Tout le blog

Articles récents

Besoin d’aide ?

Accompagnement SEO spécialisé pour les sites Salesforce Commerce Cloud (SFCC).

Vous cherchez un partenaire de confiance pour développer votre trafic organique ? Faisons équipe, comme nous le faisons avec nos clients.

Agence SEO Salesforce Commerce Cloud