Le projet en un coup d’œil
Produits, catégories, marques, vendeurs et Etictos devaient former des pages utiles sans laisser la navigation à facettes fabriquer un nombre incontrôlé de variantes.
Origami porte les objets transactionnels, Algolia la recherche et les facettes, tandis qu’un CMS local gouverne slugs, contenus et correspondances SEO avant restitution par Symfony.
Le chantier SEO s’étend d’avril 2022 à août 2023 : modèles de slugs, back-office, combinaisons de pages, pagination, index Algolia, génération atomique et images WebP.
Sur Shopetic, le SEO ne pouvait pas être réduit à une liste de recommandations posée à côté de la marketplace. Le catalogue écoresponsable devait relier des produits à des catégories, des marques, des vendeurs et des « Etictos », les labels propres à Shopetic. Chacune de ces dimensions pouvait devenir une porte d’entrée publique ; leurs combinaisons pouvaient aussi multiplier les URLs. Le travail réel a donc consisté à construire une architecture de découverte dans le produit.
La première brique de recherche Algolia apparaît le 11 avril 2022. Les contrôleurs SEO arrivent le 14 avril, les entités de slugs et de types le 19, puis les cas d’usage, tests et écrans de gestion se structurent jusqu’à la fin du mois. En mai, les routes de marques, catégories, vendeurs et Etictos reçoivent leur logique SEO. La suite traite les images, les sitemaps, les redirections, la pagination, les canoniques et la cohérence entre les facettes.
Une seconde séquence, entre octobre 2022 et août 2023, transforme ce socle en système plus durable. Le catalogue Algolia se synchronise par fenêtres, les produits désactivés ou supprimés sont purgés, la canonical rejoint le layout, la génération du sitemap passe par un dossier temporaire, les pages combinées sont ajoutées au plan d’URLs et les visuels passent progressivement au WebP. Le dernier jalon SEO clairement identifié, le 25 août 2023, concerne l’image WebP destinée à Google Shopping.
Le SEO technique marketplace constitue un volet précis de l’application Shopetic. Le frontend Shopetic Origami porte l’expérience transactionnelle complète ; ce projet montre comment catalogue, contenu et URLs ont été rendus gouvernables en amont de l’achat.
1. Une marketplace où la taxonomie fait partie de la promesse
Faire découvrir des produits responsables par catégories, marques, vendeurs et Etictos
Shopetic présente un catalogue organisé autour de critères commerciaux et écoresponsables. Une catégorie décrit le besoin ; une marque porte une identité ; un vendeur représente l’offre ; un Eticto qualifie un engagement. Le moteur de découverte doit permettre de croiser ces dimensions tout en conservant des pages compréhensibles pour le lecteur et pour les moteurs.
Le produit repose sur trois responsabilités techniques. Origami demeure la source transactionnelle des produits, offres, stocks, paniers et commandes. Algolia reçoit une projection destinée à la recherche et aux facettes. Un CMS local conserve les slugs, les textes et les correspondances entre les identifiants distants et les pages publiques. Symfony orchestre ces sources puis rend l’interface.
Cette répartition évite de demander au moteur marketplace de porter seul l’éditorial ou au moteur de recherche de devenir la source du commerce. Elle impose en revanche une synchronisation précise : un produit supprimé dans Origami ne doit pas rester visible dans Algolia ; une catégorie sans mapping ne doit pas produire une page incohérente ; un changement de slug doit conserver une trajectoire pour l’ancienne URL.
La preuve SEO se situe exactement dans cette coordination. Elle couvre la génération des slugs, les métadonnées, les canoniques, la pagination, les liens de facettes, les redirections et les sitemaps. Elle ne revendique ni l’ensemble de la stratégie de marque ni la performance commerciale de Shopetic, qui ne sont pas documentées dans les mêmes sources.
2. De la recherche au plan d’URLs sur 502 jours calendaires
Une évolution du 11 avril 2022 au 25 août 2023, sans en faire un délai contractuel
Avril 2022 établit le vocabulaire du système. Algolia est branché sur la recherche produit, puis les contrôleurs de découverte apparaissent. Le CMS reçoit les entités de slug et de type, leurs cas d’usage, leurs tests et un début de back-office. À la fin du mois, les pages peuvent collecter une configuration SEO au lieu de fabriquer tous leurs textes directement dans le contrôleur.
Mai étend cette logique aux différentes portes d’entrée. Marques, catégories, vendeurs et Etictos disposent de contrôleurs et de vues. La pagination, les facettes et les images évoluent avec la recherche. En juin et juillet, l’effort relie les produits à leurs slugs, automatise les images, construit le sitemap, ajoute les pages d’erreur et transforme plusieurs traitements en messages asynchrones.
L’automne 2022 traite l’exploitation. Les produits qui attendent, disparaissent ou sont désactivés sont retirés de l’index ; une mise à jour de score peut déclencher la projection Algolia ; les commandes SEO sont reprises ; la canonical devient une responsabilité du layout. Le produit ne se contente plus de créer des pages : il entretient leurs sources et leur état.
L’été 2023 reprend enfin les angles les plus exposés : cache des listes paginées, génération temporaire du sitemap, WebP, alternatives d’images, titres et descriptions des combinaisons, règles de pagination, canonical produit, ajout des vendeurs et des combinaisons au sitemap. Les 502 jours calendaires décrivent cette fenêtre d’évolution, pas une charge continue ni une promesse de planning.
3. Traiter le SEO comme une fonction de la marketplace
Les pages indexables naissent des données et des parcours, pas d’un rapport séparé
Le travail ne part pas d’un crawl conservé dans le projet, mais de l’application elle-même. Les contrôleurs, cas d’usage, entités et templates construisent les pages qui seront indexées. Le SEO intervient au moment où une marque, une catégorie, un vendeur, un Eticto ou un produit reçoit une adresse, un contenu et une place dans la navigation.
Cette position change la méthode. Il ne s’agit pas de corriger manuellement cent pages, mais de définir une règle qui s’applique à chaque famille : comment trouver son mapping, quel H1 produire, quelles métadonnées utiliser, comment gérer la pagination, quelle canonical annoncer et si la route doit apparaître dans un sitemap.
Le projet contient un domaine CMS consacré aux slugs, aux types de pages, aux mappings et aux contenus. Il dispose aussi d’écrans de back-office pour rechercher et modifier plusieurs objets éditoriaux. Le référencement devient ainsi une donnée administrable et un comportement exécutable, pas seulement une consigne écrite hors du produit.
Le périmètre reste distinct de la construction générale du frontend. Paniers, paiements et comptes clients relèvent du parcours Shopetic Origami ; la valeur présentée ici réside dans le système d’adresses et de découverte qui rend le catalogue accessible en amont de la transaction.
4. Donner une responsabilité différente à Origami, Algolia et au CMS
Ne pas confondre vérité commerciale, moteur de découverte et couche éditoriale
Origami porte les objets transactionnels : produits, variantes, offres, vendeurs, stocks, panier, livraison et commandes. Une page produit doit donc revenir à cette source lorsqu’elle a besoin d’une donnée qui engage l’achat. Algolia n’est pas utilisé comme registre du commerce ; il sert une projection optimisée pour trouver et filtrer.
L’index Algolia rassemble les données nécessaires à la découverte, dont catégories, marques, Etictos, vendeurs et attributs produits. Les contrôleurs transforment les choix de l’utilisateur en filtres puis reçoivent produits, facettes et pagination. Cette couche rend les listes réactives, mais doit rester synchronisée avec les suppressions et désactivations de la source.
Le CMS local résout une autre difficulté : les identifiants techniques d’Origami ou d’Algolia ne font pas de bonnes URLs éditoriales. Il conserve les correspondances, les slugs et les contenus propres aux pages. Les contrôleurs peuvent alors partir d’un slug public, retrouver le mapping attendu et reconstruire la bonne recherche.
Le frontend Symfony assemble ces trois responsabilités sans exposer les réponses brutes dans toutes les vues. Des contrats, mappers, cas d’usage et présentateurs isolent une partie des transformations. Ce découpage ne garantit pas à lui seul l’absence d’erreur, mais il localise mieux une divergence entre commerce, index et contenu.
Produits, offres, vendeurs, stock et objets transactionnels.
Recherche, pagination et facettes adaptées à la découverte.
Slugs, contenus et correspondances avec les identifiants externes.
Contrôleurs, règles de routes, canoniques et restitution Twig.
Une URL compréhensible avec produits, contexte et navigation.
5. Faire de la taxonomie écoresponsable un axe de découverte
Catégories, marques, vendeurs et Etictos ne racontent pas la même chose
La catégorie aide le lecteur à partir d’un usage ou d’une famille de produits. La marque l’oriente vers une identité commerciale. Le vendeur permet de parcourir une offre. L’Eticto exprime un engagement propre à Shopetic. Ces axes sont complémentaires et le produit les modélise séparément dans ses mappings, ses routes et ses facettes.
Cette distinction est essentielle pour la marketplace écoresponsable. Un Eticto ne doit pas devenir une catégorie générique ni une marque ; son libellé, son contenu, ses visuels et les raisons qui le justifient appartiennent à un parcours propre. Des vues et contrôleurs dédiés rendent cette singularité visible.
Le CMS permet d’enrichir les objets avec des titres, descriptions, images ou contenus. Les pages ne se résument donc pas nécessairement à un filtre Algolia. Une marque ou un Eticto peut expliquer son contexte avant de présenter les produits correspondants, ce qui crée une entrée éditoriale plus utile.
La difficulté apparaît lorsque ces axes sont combinés. Une marque dans une catégorie, un Eticto chez un vendeur ou trois dimensions réunies peuvent être pertinents, mais tous les croisements possibles ne méritent pas automatiquement une page indexable. Le projet construit plusieurs routes ciblées ; la gouvernance future doit décider lesquelles disposent d’une demande, d’un contenu et d’un catalogue suffisants.
6. Organiser vingt-neuf routes de découverte sans perdre leur contexte
Neuf parcours de marque, huit d’Eticto, six de vendeur et six de catégorie
La version finale du frontend compte vingt-neuf routes dans les familles de découverte : neuf liées aux marques, huit aux Etictos, six aux vendeurs et six aux catégories. Ce nombre inclut des routes simples, des recherches et des combinaisons. Il décrit la surface construite, pas le nombre d’URLs réellement indexées.
Chaque contrôleur prépare le contexte nécessaire à sa vue. Une combinaison marque-catégorie doit résoudre les deux mappings, ajouter les bons filtres à la recherche Algolia et conserver les objets pour produire le titre, le fil d’Ariane, les facettes et la canonical. La logique est plus dense qu’une simple page de filtre.
Les routes combinées donnent des entrées naturelles lorsqu’elles correspondent au vocabulaire du catalogue : les produits d’une marque dans une catégorie, ceux d’un vendeur portant un Eticto, ou une catégorie filtrée sur un engagement. Elles permettent aussi au maillage de quitter une suite de paramètres pour utiliser des chemins lisibles.
Le volume de routes ne doit toutefois pas être confondu avec une victoire SEO. Une page combinée faible, vide ou presque identique à une autre peut diluer l’index. La valeur vient de la sélection des combinaisons, de leurs contenus, de la stabilité des mappings et des règles de canonical qui empêchent une recherche libre de créer un doublon.
7. Décorréler l’adresse publique des identifiants techniques
Un domaine CMS gère slugs, types et correspondances par ressource
Le travail sur les slugs commence en avril 2022 avec les entités, la couche d’accès aux données et les cas d’usage SEO. La solution distingue le slug public de la ressource qu’il désigne. Une page peut ainsi recevoir une adresse lisible sans demander à Origami de changer ses identifiants internes.
Les mappings couvrent notamment produits, catégories, marques, vendeurs et Etictos. Les contrôleurs partent du chemin demandé, recherchent la correspondance dans le CMS puis utilisent l’identifiant externe pour interroger la bonne source. Cette chaîne donne au contenu public une identité stable tout en gardant le raccordement au catalogue.
Une ancienne route produit basée sur l’identifiant reçoit une redirection temporaire vers le slug en juillet 2022. Le mécanisme évite de laisser deux adresses actives pour la même fiche, même si un code 301 aurait été plus adapté à une migration définitivement assumée. Les évolutions suivantes reprennent la canonical de la fiche produit autour du slug.
La gestion des slugs ne garantit pas encore un historique complet. Pour sécuriser une refonte, chaque modification devrait conserver l’ancienne adresse, la nouvelle, la date et le motif, puis générer une redirection permanente testée. Sans cette mémoire, le CMS sait nommer le présent mais pas nécessairement préserver toutes les URLs passées.
8. Composer les métadonnées à partir du contexte réel de la page
Les gabarits simples et combinés ne peuvent pas partager un titre générique
Les pages de marque, catégorie, vendeur, Eticto et produit disposent de blocs pour le titre et la description. Lorsqu’un contenu CMS existe, il peut enrichir l’objet. Des règles de repli composent aussi des formulations à partir du nom de la ressource et du contexte de navigation.
Les combinaisons demandent davantage de précision. Une page marque-catégorie ne porte pas la même intention qu’une marque seule ; une page Eticto-vendeur-catégorie doit conserver les trois dimensions sans produire un titre illisible. Les changements de juin et juillet 2023 reprennent précisément les titres, descriptions et H1 de plusieurs parcours combinés.
Le produit prévoit également un raccourci de gestion : un super-administrateur connecté peut accéder à l’édition SEO depuis certaines pages publiques. Ce lien raccourcit la distance entre constat et correction sans exposer le back-office à un visiteur anonyme. Il ne constitue pas une validation automatique de la qualité du texte.
Aucun export ne permet de mesurer le CTR obtenu par ces métadonnées. La bonne preuve reste leur administrabilité et leur contextualisation. La prochaine boucle doit confronter les titres aux requêtes réelles, aux impressions et aux pages dominantes, puis éviter que plusieurs combinaisons ciblent la même intention.
9. Faire suivre la canonical lorsque la pagination et les combinaisons évoluent
Une règle par famille plutôt qu’une URL courante reprise aveuglément
La canonical devient un bloc du layout en octobre 2022. Quinze templates de l’espace public déclarent ou spécialisent ensuite ce bloc, dont produit, marque, catégorie, vendeur, Eticto et plusieurs combinaisons. La fiche produit pointe vers son slug principal, indépendamment de la variante sélectionnée.
Les pages paginées construisent leur canonical avec le numéro de page lorsqu’il est présent, puis reviennent à l’URL simple sur la première page. Cette décision conserve chaque page de catalogue comme document distinct tout en retirant le paramètre inutile de la page initiale. Les changements de juillet 2023 reprennent ces règles sur plusieurs gabarits.
Le layout plus récent possède aussi une canonical fondée sur l’URI courante, après retrait des paramètres ajoutés par PageSpeed. Cette solution protège un cas technique précis, mais reste moins sûre qu’une route construite avec des paramètres autorisés : une URI courante peut conserver une facette ou une campagne qui ne devrait pas définir l’adresse de référence.
La meilleure prochaine étape est une matrice de canonical par type de page : paramètres conservés, paramètres supprimés, page un, pages suivantes, recherche interne, tri, variante produit et combinaisons. Des tests de rendu peuvent alors vérifier chaque règle et empêcher une modification de contrôleur de changer silencieusement l’URL de référence.
10. Transformer certaines facettes en chemins et contenir la recherche libre
Le maillage suit la taxonomie tandis que <code>mainSearch</code> reste un contexte de recherche
Les composants de facettes ne se contentent pas d’empiler des paramètres. Selon le contexte présent, ils construisent une route de catégorie, marque, vendeur, Eticto ou une combinaison reconnue. Un clic peut ainsi conduire à une page métier dotée de son propre mapping et de sa propre canonical.
Le paramètre mainSearch est propagé lorsque l’utilisateur effectue une recherche textuelle. Les vues adaptent alors leur titre et leur marquage analytique au contexte de résultats. Un changement de juin 2023 limite les liens SEO suivis lorsque cette recherche est active afin que le texte libre ne transforme pas chaque facette en nouvelle porte d’entrée.
Algolia renvoie les produits, la pagination et les facettes. Les filtres couvrent les catégories, marques, Etictos, vendeurs et plusieurs attributs produit. Le frontend conserve les mappings CMS nécessaires pour afficher des noms et construire des URLs, au lieu d’exposer directement toutes les valeurs techniques de l’index.
Cette articulation entre facette et route est le cœur du SEO marketplace. Elle permet de mailler les pages utiles sans indexer chaque état de l’interface. Sa limite est l’absence d’une matrice publique des combinaisons autorisées, de seuils de produits ou de règle automatique noindex pour une page pauvre.
11. Entretenir l’index de découverte à plusieurs horizons
Rattrapage long, synchronisation récente et purge des états devenus invalides
Le cron de production final conserve trois fenêtres de projection vers Algolia. Une exécution quotidienne reprend soixante jours, une exécution toutes les six heures reprend deux jours et une exécution toutes les trente minutes couvre quatre heures. Ces horizons superposés cherchent à concilier fraîcheur récente et rattrapage plus large.
Trois tâches d’entretien complètent cette projection. Toutes les trente minutes, les produits désactivés dans le référentiel interne et ceux en attente sont retirés ou traités ; toutes les quatre heures, une commande recherche les produits supprimés dans Origami. La découverte doit ainsi oublier ce que la source transactionnelle ne propose plus.
Une mise à jour du score produit peut également préparer ou déclencher une projection. Le produit contient un monitoring ciblé pour les opérations Algolia et des réponses domaine capables de conserver des erreurs. Ces mécanismes rendent les incidents plus localisables, sans prouver un taux de succès ou un délai maximum de synchronisation.
Les fréquences déclarées ne valent pas SLA. Elles ne garantissent ni que les processus s’exécutent, ni que chaque article est visible trente minutes après une modification. Pour le vérifier, il faut mesurer l’âge du document dans Algolia, comparer les volumes entre sources et alerter lorsque les files ou purges ne progressent plus.
12. Passer d’un sitemap général à treize familles de pages
Décrire les ressources simples et les combinaisons réellement prises en charge
Le premier générateur assemble les pages fixes, catégories, marques, Etictos et produits. Il traite les produits par lectures de cent mappings actifs et limite chaque fragment à mille URLs. En juin 2023, sa production passe par un dossier temporaire avant de remplacer les fichiers publics, ce qui réduit la fenêtre où un incident laisserait un sitemap incomplet.
Une version étendue construit treize familles : pages, catégories, produits, marques, Etictos, vendeurs, Etictos-catégories, marques-catégories, marques-Etictos, marques-Etictos-catégories, vendeurs-catégories, Etictos-vendeurs et Etictos-vendeurs-catégories. Le plan d’URLs reflète ainsi la taxonomie combinatoire du frontend.
Le générateur s’appuie sur les mappings CMS et, pour plusieurs combinaisons, sur les résultats disponibles dans Algolia. La page produit est exclue lorsqu’elle est désactivée dans le mapping du premier générateur. Les commandes publient des priorités et dates, mais leur qualité dépend toujours des données de mise à jour fournies par les objets.
La génération de sitemap dispose de deux commandes dédiées. Une cadence supervisée peut sélectionner le générateur de référence, contrôler ses treize familles et publier le dernier résultat valide.
13. Faire évoluer les médias du catalogue vers le WebP
Miniatures, fiches, réassurance et flux Shopping sont repris par étapes
Les images apparaissent tôt comme un sujet du produit : téléchargement, redimensionnement, stockage local et messages dédiés. En juin 2022, les vues utilisent des tailles adaptées à la recherche et à la fiche. En juin 2023, plusieurs ressources de thème et du catalogue passent au WebP.
Les produits disposent notamment de variantes locales autour de deux cents, trois cents et cinq cents pixels selon les usages observés dans les gabarits. La fiche et les cartes peuvent ainsi demander une ressource plus proche de leur surface d’affichage au lieu de reprendre systématiquement le média original.
Le travail s’étend au flux Google Shopping avec une image WebP en août 2023. D’autres évolutions ajoutent des alternatives et attributs de lien sur les pages Etictos, puis ajustent les liens suivis autour des sliders produit. Les médias sont donc traités à la fois comme charge front, contenu et surface de maillage.
Aucun rapport de poids ou de Core Web Vitals n’est conservé pour comparer les versions. Le format, la taille et les attributs constituent des améliorations vérifiables ; leur effet sur LCP, trafic Shopping ou conversion ne peut pas être chiffré. Une version mesurée devrait journaliser dimensions, poids, taux de cache et erreurs de génération.
14. Relier SEO, cache, commandes planifiées et tests
Une architecture solide dont les garanties ne sont pas uniformes
Les caches principaux de marque, catégorie, produit et listes utilisent sept jours dans la configuration finale ; certaines pages combinées utilisent un jour. Ces durées réduisent les lectures répétées mais créent un enjeu de fraîcheur, traité en partie par les commandes de mapping et d’indexation.
Les mappings SEO sont rafraîchis par famille : les produits tous les deux jours et d’autres familles quotidiennement dans le cron final. Les tâches Algolia possèdent leurs propres fréquences. Le run ne forme donc pas une seule commande, mais un ensemble de cadences dont les dépendances doivent rester cohérentes. Le hub opérateur Shopetic raconte séparément les synchronisations destinées aux équipes et aux vendeurs.
Les contrôles automatiques réunissent 244 méthodes actives réparties entre tests unitaires, d’intégration et applicatifs. Ils protègent des domaines variés. Les canonicals, les combinaisons de facettes et les fichiers sitemap peuvent encore gagner des scénarios dédiés pour transformer les règles SEO en garanties de non-régression.
Les accès techniques gagnent à être injectés par environnement depuis un gestionnaire protégé, avec une politique de rotation. Cette discipline de sécurité accompagne l’architecture SEO et la chaîne de livraison.
15. Identifier les gains que l’application permet réellement d’observer
Une gouvernance de catalogue, des parcours lisibles et un entretien automatisable
Pour l’équipe catalogue, les identifiants distants peuvent recevoir un slug et un contenu public sans modifier Origami. Une correction éditoriale reste dans le CMS et les projections Algolia peuvent être entretenues selon plusieurs horizons. Les trois systèmes conservent leur responsabilité.
Pour le visiteur, les catégories, marques, vendeurs et Etictos deviennent des chemins de découverte nommés. Les combinaisons utiles évitent de tout concentrer dans une recherche générique. La pagination, les H1 et les canoniques donnent à chaque vue un contexte plus explicite.
Pour les moteurs, la marketplace peut exposer des familles d’URLs structurées, supprimer les produits invalides de son index de recherche, générer des sitemaps dédiés et servir des médias WebP. Ces fonctions rendent la surface technique contrôlable, même si leur état réel demande des mesures externes.
Pour le delivery, les règles appartiennent aux contrôleurs, templates, cas d’usage et commandes. Une nouvelle catégorie ou un changement de mapping suit le système au lieu de demander une correction page par page. Aucun chiffre de trafic, conversion, revenu ou vitesse ne vient compléter ces gains faute de baseline disponible.
16. Distinguer les capacités construites des garanties encore absentes
La complexité combinatoire demande un contrôle plus explicite
Treize familles de sitemap et vingt-neuf routes ne prouvent pas que chaque URL mérite l’indexation. Le projet ne conserve pas une matrice exhaustive liant type de page, volume minimum de produits, contenu unique, demande de recherche, canonical, robots et présence sitemap.
Les deux générateurs de sitemap coexistent et leurs tâches finales sont commentées. La canonical varie entre des blocs spécialisés et une URI courante nettoyée. Une ancienne route produit emploie une redirection 302. Ces choix montrent une évolution réelle, mais aussi plusieurs standards à unifier.
Les cadences Algolia ne fournissent pas de rapport de fraîcheur ni de comparaison automatique avec Origami. Les caches d’un ou sept jours peuvent masquer une correction tant que leur invalidation n’est pas observée. Les secrets historiques représentent enfin un risque distinct et prioritaire.
La visibilité, les clics, les ventes et les Core Web Vitals peuvent être suivis dans un même tableau de bord daté. Cette mesure relie les optimisations techniques aux parcours réellement utilisés et fournit une base claire aux arbitrages suivants.
17. Transformer l’architecture en système SEO piloté
Décider, tester, mesurer et corriger chaque famille de page
Le premier palier est une matrice d’indexabilité. Pour chaque route simple ou combinée, elle doit indiquer l’intention, les données requises, le seuil de produits, le contenu attendu, la canonical, le statut robots, le sitemap et la règle lorsque la page devient vide. Cette matrice borne la surface avant toute extension.
Le deuxième est l’automatisation. Des fixtures de catégories, marques, vendeurs, Etictos, produits, pages deux, recherches et anciens slugs doivent alimenter des tests de rendu. La CI peut alors contrôler H1, title, description, canonical, robots, pagination, données structurées, redirection et présence dans le bon sitemap.
Le troisième est le run. Un seul générateur de sitemap doit devenir la référence, être exécuté sur une cadence active et publier volumes, erreurs et âge des fichiers. Algolia doit comparer son inventaire aux produits actifs d’Origami. Une démarche de monitoring et QA de non-régression doit surveiller ces invariants. Les secrets doivent être renouvelés puis retirés des sources versionnées.
Le dernier est la mesure. Search Console doit suivre couverture, pages dominantes, requêtes et CTR par famille ; l’analytique doit séparer recherche libre, facette, page SEO et conversion ; les Core Web Vitals doivent être lus sur le terrain. Ce dispositif permettrait de prioriser les routes qui créent une vraie valeur au lieu de juger le projet au seul nombre de pages.
18. Le SEO marketplace devient fiable quand il appartient au produit
Gouverner les données, les routes et les combinaisons plutôt que corriger les pages une à une
Shopetic montre qu’une architecture SEO marketplace se construit aux frontières des systèmes. Origami doit fournir un produit exploitable ; Algolia doit exposer une projection fraîche ; le CMS doit relier les identifiants à des slugs et des contenus ; Symfony doit appliquer la bonne route, la bonne canonical et les bons filtres. Une seule balise ne peut pas compenser une rupture dans cette chaîne.
Les gains démontrables sont fonctionnels : vingt-neuf routes de découverte, des facettes qui construisent des chemins métier, une gestion de slugs, des canoniques paginées, des images WebP, des tâches d’entretien Algolia et treize familles de sitemap dans la version étendue. Aucun historique de trafic ou de conversion n’autorise à transformer ces mécanismes en résultat commercial chiffré.
Le prochain niveau demande moins de nouvelles URLs que de meilleures garanties : matrice d’indexabilité, tests automatiques des combinaisons, métriques d’index, canonical contrôlée, sitemaps réellement planifiés, mapping de redirections et suivi Search Console. Dawap réunit pour cela le SEO technique marketplace, le frontend opérateur et l’intégration API marketplace.
