Le schema PrestaShop, aussi appelé données structurées, est une petite couche de code supplémentaire qui indique aux moteurs de recherche ce que représente chaque morceau de contenu sur votre page : un prix, un état de stock, un produit, une note, un fil d’Ariane ou une entrée FAQ. Les moteurs peuvent utiliser ces données pour des rich results éligibles comme les extraits de prix et stock produit, les étoiles d’avis quand elles sont prises en charge, les liens de fil d’Ariane, ou une présentation de type FAQ là où le moteur la supporte encore.

Les rich results ne font pas monter votre page dans le classement à eux seuls, mais ils peuvent rendre l’extrait plus utile et plus rassurant. Pour une boutique, les types de schema qui comptent généralement sont Product, Offer, AggregateRating/Review, BreadcrumbList, Organization, WebSite, CollectionPage, Article et, quand c’est pertinent, FAQPage.

Notre module Automatic SEO Schema Rich Snippets tente d’ajouter le balisage Product, Offer, rating/review, breadcrumb, Organization, WebSite, category et CMS-page sans modifier les templates. La même fonctionnalité schema fait aussi partie de Smart SEO Revolution Suite si vous voulez aussi les sitemaps, canonicals et l’automatisation des meta tags au même endroit.

Réserve importante dans le code actuel : le module sort du JSON-LD depuis hookDisplayHeader, mais clean_existing_jsonld est activé par défaut et le nettoyage de sortie finale ne conserve que les scripts JSON-LD contenant le marqueur <!-- mprschema -->. Le hook header émet actuellement du JSON-LD non marqué, donc avec le nettoyage JSON-LD actif, le HTML final peut supprimer le schema du module lui-même. Tant que le renderer ne marque pas ses scripts ou que la logique de nettoyage n’est pas désactivée/corrigée, vérifiez la source finale de la page avant de considérer le JSON-LD comme présent de façon fiable.

Sur les pages produit, le schema Product peut inclure le nom du produit, l’URL, la description, SKU, identifiants GTIN/UPC/ISBN/MPN, données de marque issues du fabricant/fournisseur/caractéristique, images, état de l’article, données d’offre, poids, catégorie et données d’avis quand la boutique les possède. Le générateur de marque utilise la source catalogue configurée, par exemple fabricant, fournisseur ou une caractéristique nommée comme Brand, avec un repli fabricant ; le champ override-brand déclaré n’est pas utilisé par le générateur actuel. Les données d’offre peuvent inclure prix, devise, disponibilité, vendeur, détails de livraison et politique de retour. Pour les produits avec déclinaisons, l’implémentation peut construire des données d’offre agrégées au lieu de prétendre que chaque variante a une offre identique.

Les pages catégorie sont traitées différemment : elles sont rendues comme données CollectionPage avec nom de catégorie, URL, description, image, nombre d’articles et un échantillon ItemList de produits. Les pages CMS sont rendues en schema Article avec headline, URL, description, corps d’article, nombre de mots, dates, auteur, publisher, logo, langue et URL main entity.

La règle pratique pour un marchand est de remplir les données sous-jacentes, pas seulement d’activer le schema. Si un produit n’a pas d’identifiant, de bonnes images, d’état de stock, d’avis ou de description, le schema ne peut décrire que ces données faibles. Les données structurées fonctionnent mieux quand vos données catalogue sont déjà propres, et dans le module actuel vous devez aussi vérifier que les paramètres de nettoyage ne suppriment pas le JSON-LD que vous pensez publier.

Quatre formulaires en front-office : contact, inscription, connexion et newsletter. Chacun s'active ou se désactive individuellement, vous protégez donc seulement les formulaires qui attirent réellement le spam et laissez les autres tels quels.

Vous choisissez un fournisseur pour tous, Google reCAPTCHA v2, reCAPTCHA v3 (avec un seuil de score que vous définissez, 0,5 par défaut) ou hCaptcha. La vraie protection se joue côté serveur : chaque envoi protégé est revérifié auprès du fournisseur avant d'aboutir, un bot ne peut donc pas contourner le widget en postant directement vers PrestaShop. La protection reste inactive tant que vous n'avez pas activé le module et saisi la clé de site et la clé secrète. Une erreur fréquente est de n'en renseigner qu'une et de s'étonner que rien ne soit bloqué.

La protection des formulaires fait partie de notre Store Launch Kit, l'essentiel à verrouiller avant d'ouvrir votre boutique.

Non. Les licences sont indépendantes : vous pouvez installer tout le Store Launch Kit en une après-midi, ou seulement ce dont le lancement a besoin d'abord et ajouter le reste ensuite. Chaque module garde son petit écran de réglages, et les versions de PrestaShop prises en charge varient selon le module ; vérifiez donc la fiche de chacun avant l'installation.

Oui. Lorsqu'il identifie dans votre thème un fil d'Ariane unique et sûr, ou que votre thème utilise le hook standard, il prend le relais proprement. Il reconnaît d'origine Hummingbird, Classic, Warehouse et les balisages plus anciens, et accepte un sélecteur personnalisé pour les thèmes sur mesure. Si la cible est absente ou ambiguë, il laisse le fil d'Ariane de votre thème en place plutôt que de risquer de casser la page.

Le Store Launch Kit est un pack de licences de modules indépendants achetées ensemble en une seule commande. Chaque module s'installe et se configure sur son propre écran, vous mettez donc en place d'abord ce dont votre lancement a besoin. Pour la liste exacte des modules inclus, consultez la page produit du pack.

Oui. Cookie Banner prend en charge les signaux Google Consent Mode v2 pour les tags Google. Le point important est que Consent Mode communique l’état du consentement à Google ; il n’empêche pas automatiquement chaque script tiers du site de se charger.

Avec la configuration plus sûre par défaut refusé, le module envoie un consentement refusé pour le stockage publicitaire et analytics jusqu’à ce que le visiteur accepte les cookies. Le stockage fonctionnel et de sécurité reste accordé dans l’appel Consent Mode par défaut. Lorsque le visiteur accepte, la bannière met à jour l’état de consentement Google à granted. Lorsque le visiteur refuse ou ferme la bannière, elle met à jour ces mêmes champs de consentement publicitaire et analytics à denied.

gtag('consent','default',{ad_storage:'denied',ad_user_data:'denied',ad_personalization:'denied',analytics_storage:'denied',functionality_storage:'granted',personalization_storage:'granted',security_storage:'granted'});
// Accept button: gtag('consent','update',{ad_storage:'granted',ad_user_data:'granted',ad_personalization:'granted',analytics_storage:'granted'});
// Deny or close: gtag('consent','update',{ad_storage:'denied',ad_user_data:'denied',ad_personalization:'denied',analytics_storage:'denied'});

Le module stocke le choix du visiteur dans son cookie de consentement first-party et déclenche un événement de consentement front-end. Après avoir activé GCM v2, vérifiez avec Google Tag Assistant que l’état par défaut se déclenche avant les tags Google et que l’événement de mise à jour se déclenche après Accept/Deny.

Les réglages derrière ce comportement sont GCM_ENABLED et DEFAULT_CONSENT. À l’installation, le module active GCM, définit DEFAULT_CONSENT à denied, active la bannière, définit une durée de consentement de 365 jours, utilise la position en bas à gauche, et stocke les textes multilingues de bannière, acceptation, refus et lien de politique. L’admin peut passer l’état par défaut à granted, mais le contrôle d’intégrité du module le marque comme modèle opt-out et avertit que les marchés GDPR exigent généralement l’opt-in.

L’appel Consent Mode par défaut est injecté depuis displayHeader, tandis que le HTML de bannière est rendu une seule fois depuis les hooks footer et que le JavaScript front est enregistré en bas. Cet ordre compte : l’état par défaut denied ou granted est disponible avant les tags Google ultérieurs, puis le script côté navigateur met à jour l’état après l’action du visiteur. Si le visiteur a déjà le cookie mprcookie_consent, la bannière n’est pas affichée et la valeur stockée est renvoyée à Google au chargement de la page.

La valeur de cookie stockée est seulement granted ou denied. Elle est écrite comme cookie first-party nommé mprcookie_consent avec path=/, SameSite=Lax, et Secure lorsque la boutique est servie en HTTPS. L’expiration vient de COOKIE_EXPIRY ; le contrôle d’intégrité traite les valeurs vides ou non positives comme une erreur et avertit au-dessus de 730 jours.

• Accept envoie granted pour ad_storage, ad_user_data, ad_personalization et analytics_storage.
• Deny, le bouton de fermeture, et un clic sur le backdrop de modale centrale envoient denied pour ces mêmes quatre champs.
• Le module ne met pas à jour functionality_storage, personalization_storage ou security_storage après l’appel par défaut initial ; ceux-ci sont accordés dans l’appel par défaut.
• L’événement personnalisé mprcookie:consent se déclenche lorsque le visiteur fait un nouveau choix, avec event.detail.consent contenant le nouvel état.

document.addEventListener('mprcookie:consent', function (event) {
  if (event.detail.consent === 'granted') {
    // load or unlock your optional non-Google script here
  }
});

Un point pratique : comme le module est volontairement léger, il ne scanne pas la page, ne catégorise pas les cookies, ne réécrit pas les balises script et ne bloque pas les scripts non Google par lui-même. Si un pixel Facebook, un widget chat ou un script analytics se charge avant de vérifier le consentement, Consent Mode n’arrêtera pas ce script. Reliez ces scripts à vos propres contrôles de consentement ou à l’événement mprcookie:consent, et gardez un seul module de consentement cookie actif car l’installation bloque l’exécution de ce module avec mprcookiesrevolution.

Pour tester, effacez mprcookie_consent, rechargez la page, confirmez que l’appel Consent Mode par défaut apparaît dans le head, puis cliquez sur Accept et Deny dans des tests séparés pour confirmer que l’appel de mise à jour change les quatre champs publicitaires et analytics. Rechargez une fois le cookie existant pour confirmer que la bannière reste masquée mais que l’état stocké est toujours poussé vers Google.

Oui. Avec Product Canonical Manager, vous définissez des règles par entité pour les produits, catégories, fabricants, fournisseurs et pages CMS, et le module écrit noindex et nofollow dans la balise meta robots de la page. Le même module régénère les balises hreflang depuis les langues actives de votre boutique et ajoute x-default pour votre langue par défaut, afin que chaque version linguistique pointe vers les bons alternates.

Cela garde les pages minces ou dupliquées (listings filtrés, recherche interne, pages compte) hors de l’index Google pendant que vos vrais produits restent indexables, et cela indique à Google quelle langue servir à quelle audience. Une erreur fréquente consiste à ajouter noindex et un canonical qui pointent dans des directions différentes sur la même URL ; décidez page par page si vous voulez l’indexer-mais-canonicaliser ou la mettre complètement en noindex, pas les deux en conflit.

Smart SEO Revolution Suite partage le même moteur canonical, hreflang et noindex, donc les mêmes règles par entité y sont aussi disponibles.

Les règles ont une priorité et un périmètre boutique. La recherche accepte l’ID exact de l’entité ou l’ID d’entité 0, et les règles exactes ou globales boutique peuvent être triées par priorité. Cela vous permet de créer une règle large pour tous les produits, puis de remplacer un produit, une catégorie ou une page CMS importante sans dupliquer chaque réglage.

La balise robots est construite uniquement à partir des directives que vous choisissez. Si vous cochez noindex, le module ajoute noindex ; si vous cochez nofollow, il ajoute nofollow ; si aucun des deux n’est sélectionné, il n’invente pas une balise robots juste pour être visible. Les balises robots existantes sont remplacées quand une règle s’applique, ce qui évite deux balises meta robots contradictoires dans le même head.

La génération hreflang n’a de sens que sur les boutiques multilingues. Le module vérifie les langues actives, génère des URL alternate pour chaque langue active et ajoute x-default pour la langue par défaut configurée. Il supprime aussi les balises hreflang existantes avant d’insérer les siennes, ce qui aide à éviter des clusters alternate dupliqués quand le thème et le module tentent tous deux de gérer le même signal.

Utilisez noindex avec prudence avec les sitemaps. Une URL noindex ne doit pas être promue comme URL indexable dans le sitemap, et les tables de politique de SEO Suite incluent des overrides séparés pour index, hreflang, sitemap et schema pour cette raison. Gardez les signaux alignés : les pages indexables reçoivent canonical et hreflang ; les pages volontairement masquées reçoivent noindex et doivent normalement rester hors du sitemap XML.

Des chemins dédiés existent pour les produits, les catégories, les pages CMS, les fabricants, les fournisseurs et la recherche. Si les modules MyPresta correspondants sont installés, il couvre aussi votre blog, votre FAQ, votre base de connaissances et votre documentation, et il relie les pages de compte et de commande que les thèmes laissent d'ordinaire sans fil d'Ariane. Vous choisissez les types de pages actifs depuis les réglages.

C'est précisément ce qu'il empêche. Sur les pages éligibles, il ne conserve qu'une seule BreadcrumbList : il réutilise celle qui existe déjà si elle correspond à ce que voient les visiteurs, sinon il émet la sienne. Il retire proprement les doublons lisibles de votre thème ou d'autres modules, tout en laissant intactes les données Product et Organization. Ce qu'il ne peut pas lire avec certitude est conservé tel quel, il n'abîme donc jamais des données inconnues.

Un sitemap XML est un fichier lisible par machine écrit pour les moteurs de recherche. Il liste des URL avec des métadonnées (date de dernière modification, alternates hreflang, références d’images) et se soumet à Google Search Console ou Bing Webmaster Tools. Son rôle est la découverte : aider les crawlers à trouver et prioriser des pages qu’ils pourraient manquer.

Un sitemap HTML est une page ordinaire de votre boutique, faite pour les visiteurs humains. Elle liste des liens vers les catégories, produits, pages CMS et fabricants dans une structure lisible. Son rôle est la navigation et le maillage interne. Elle donne aux visiteurs un index de secours et aux crawlers un autre ensemble de liens vers les pages profondes.

Vous voulez généralement les deux : le sitemap XML est celui que les moteurs de recherche consomment réellement, tandis que le sitemap HTML est optionnel mais pratique sur les grands catalogues. Notre Advanced SEO Sitemap Builder génère des sitemaps XML avec alternates hreflang et entrées d’images, découpe automatiquement les grands catalogues à la limite moteur de 50 000 URL en index de sitemaps, et peut aussi publier une page sitemap HTML.

Le sitemap builder n’est pas un simple dump d’URL. Sa description de module et son pipeline sont construits autour de sitemaps XML vérifiés : les URL peuvent être crawlées et contrôlées pour statut HTTP, canonical et noindex avant écriture. Les lignes d’URL stockées incluent type d’entité, langue, boutique, statut, canonical et métadonnées image/hreflang, afin que le sitemap final puisse être basé sur des URL ayant passé la vérification plutôt que sur toutes les URL catalogue possibles.

Pour la sortie XML, le writer inclut le namespace sitemap standard et ajoute les namespaces image et XHTML lorsque la sortie image ou hreflang est activée. Chaque URL peut recevoir <loc>, <lastmod>, <changefreq>, <priority>, des entrées image et des liens de langues alternatives. Les grosses sorties sont découpées selon le nombre maximal d’URL et la taille de fichier configurés, et un index de sitemap pointe les crawlers vers les fichiers générés.

Le sitemap HTML est différent par conception. Il utilise les URL vérifiées pour la boutique et la langue courantes, les regroupe par type comme home, product, category, CMS, manufacturer, supplier, core, hook ou custom, et les rend comme une page normale. Dans le contrôleur front inspecté, la page sitemap HTML est marquée noindex, donc traitez-la surtout comme une page de navigation utilisateur et de maillage interne, pas comme une autre landing page censée se positionner.

Pour les marchands, la configuration pratique est : activez les types d’entités que vous voulez vraiment indexer, gardez la sortie image et hreflang active pour les catalogues multilingues ou riches en images, soumettez l’index XML dans Search Console, et liez le sitemap HTML uniquement là où il aide les visiteurs.

Soyons réalistes : un module SEO met en place les signaux techniques, données structurées, URL plus propres, balises canonical et maillage interne, mais le moment où ces changements apparaissent dans les résultats dépend de Google, pas du module. Google doit d'abord réexplorer et retraiter vos pages, et ce délai varie d'une boutique à l'autre : quelques jours pour certaines pages, bien plus pour d'autres, selon la fréquence à laquelle Google revisite votre boutique. Personne ne peut y mettre une date fixe.

Quelques actions accélèrent les premiers signaux : soumettre un sitemap XML à jour, corriger les 404 et rediriger les anciennes URL pour concentrer le budget de crawl sur les pages utiles. Ce sont précisément les leviers gérés par notre Smart SEO Revolution Suite. Ce qu'aucun module ne peut faire, c'est garantir un classement à une date fixe : qui promet des résultats immédiats vous trompe. Nous gérons aussi des boutiques, alors nous posons les attentes franchement : le SEO se joue sur la durée, et un bon module raccourcit la partie technique, pas l'horloge de Google.

Le module vise officiellement PrestaShop 1.7 à 9.x et il est conçu pour PHP 7.1 et supérieur. Il embarque en plus des chemins de code hérités pour la 1.6. Si vous êtes en 1.6 ou dans une configuration inhabituelle, commandez-le et nous ferons le nécessaire pour que votre installation fonctionne.

Il est économe, mais soyons honnêtes : construire un chemin et vérifier les données structurées de la page demande un peu de travail. Les recherches de catégories, de produits voisins et de page d'accueil sont mises en cache avec une invalidation ciblée, le résultat est donc calculé une fois puis réutilisé, et le code côté boutique ne pose ni cookie ni traceur. Nous ne publions pas de chiffre magique à zéro impact, parce que ce ne serait pas vrai.

Oui. Blog Revolution donne à chaque article une URL propre et lisible par mots-clés, ainsi que le balisage SEO technique attendu par les moteurs de recherche, pour que votre blog ne soit pas une impasse pour votre boutique.

Ce qu’il gère pour vous :

• Friendly URLs pour les articles, catégories et tags, des chemins lisibles, pas des query strings.
• Meta title, meta description et canonical par article, afin de contrôler l’apparence de chaque page et d’éviter les problèmes de contenu dupliqué.
• Open Graph et schema blog JSON-LD pour des aperçus sociaux propres et des données structurées (les deux peuvent être désactivés si un autre module les fournit déjà).
• hreflang sur les pages de blog indexables et rel=prev/next sur les listes paginées.
• RSS autodiscovery et inclusion automatique des articles publiés dans votre sitemap XML.

Erreur fréquente : laisser la meta description vide, Blog Revolution se rabat sur l’extrait, mais une description rédigée se lit mieux dans les résultats. Si votre boutique utilise aussi notre Smart SEO Revolution Suite, laissez un seul module gérer le schema blog pour éviter les doublons.

Le module enregistre des routes pour l’index du blog, les catégories, tags, auteurs, archives, recherche, RSS, liste d’auteurs et articles individuels. Les URL d’article sont construites depuis les slugs stockés plutôt que depuis des paramètres de requête bruts, et le contrôleur d’article redirige les mauvais slugs, URL de mauvaise langue ou variantes de chemin supplémentaires vers la forme canonical.

Chaque article stocke son propre link_rewrite, meta title, meta description, meta keywords et canonical optionnel. Si le canonical personnalisé est vide, le contrôleur utilise l’URL générée courante. Les pages d’aperçu sont marquées noindex, et les listes de blog paginées peuvent être marquées noindex à partir de la page deux tout en exposant des liens rel prev/next.

Pour la qualité du contenu, le contrôleur d’article peut traiter les shortcodes, normaliser les H1 accidentels en H2, calculer le temps de lecture et construire une table des matières à partir des titres H2/H3. Ce n’est pas seulement cosmétique : cela rend les articles plus cohérents avec un template de boutique produit où la page a déjà un H1 principal.

Pour les flux et la découverte, le module peut produire un RSS avec titre d’article, lien, GUID, contenu, date de publication, auteur, catégorie et image enclosure. Le hook sitemap ajoute la liste du blog et les pages détail des articles publiés, y compris les données d’image mise en avant quand elles existent. Les brouillons et articles non publiés ne sont pas poussés dans le sitemap.

La sortie schema a aussi un garde-fou : Blog Revolution vérifie si SEO Revolution est déjà configuré pour fournir le schema blog et ignore son propre JSON-LD BlogPosting natif si nécessaire. C’est le bon modèle pour les données structurées : un seul propriétaire propre par type de schema, pas deux modules qui émettent des blocs BlogPosting concurrents.

Les niveaux de catégorie peuvent afficher les catégories voisines, les sous-catégories ou les deux ; le niveau Accueil peut lister vos catégories de premier niveau ; et un niveau produit peut montrer d'autres produits actifs et visibles au catalogue dans sa catégorie. Les voisins de fabricant, de fournisseur et de section de contenu peuvent aussi apparaître. Tout respecte la boutique courante, la langue et les droits du groupe client.

Oui, c’est exactement son fonctionnement. Automatic SEO Images Alt Tags n’écrit pas de texte alt dans votre base de données au moment de l’installation. Il définit l’alt (legend) à la volée, chaque fois qu’une page produit, listing ou catégorie est rendue, en se branchant sur la couche presenter de PrestaShop. Ajoutez une nouvelle image produit et elle est couverte automatiquement, pas de relance, pas de tâche batch.

Les templates combinent des tokens comme {product_name}, {category}, {category_name}, {manufacturer}, {image_position} et des identifiants produit ({reference}, {ean13}, {isbn}, {upc}, {mpn}), avec un template séparé par langue de boutique afin que chaque front-office reçoive une balise alt localisée.

Une règle de sécurité : par défaut, le module n’écrase jamais le texte alt que vous avez saisi à la main, il remplit seulement les champs vides. Vous pouvez activer l’écrasement si vous voulez que chaque image soit pilotée par le template. La longueur maximale par défaut est de 125 caractères.

Le module enregistre des hooks presenter pour les pages produit, les listings produit et les pages catégorie. Sur une page produit, il met à jour l’image de couverture, l’image par défaut et les images de galerie. Sur les listings, il met à jour l’image cover/default du produit présenté et la liste d’images. Sur les pages catégorie, il met à jour la légende de l’image de catégorie. Comme cela se produit dans les données présentées, le fonctionnement reste compatible avec le cache et ne nécessite pas de scanner ou réécrire le HTML rendu.

Les templates par défaut sont simples et sûrs : les pages produit utilisent {product_name} - {manufacturer}, les listings utilisent {product_name} - {category}, et les pages catégorie utilisent {category_name}. Vous pouvez les modifier pour inclure des références ou des identifiants, mais gardez un résultat lisible. Les moteurs de recherche comme les lecteurs d’écran préfèrent un texte utile à une liste d’attributs bourrée de mots-clés.

Le builder nettoie le texte alt généré avant de le renvoyer : il remplace les variables, supprime le HTML, décode les entités, réduit les espaces répétés et retire les séparateurs laissés vides par les variables manquantes. Il tronque ensuite à la longueur maximale configurée, à une frontière de mot si possible. Cela signifie qu’un fabricant manquant ne doit pas laisser un template laid qui pend, et qu’un nom de produit très long ne doit pas produire un attribut alt démesuré.

Le workflow pratique consiste à définir une fois un template produit, un template listing et un template catégorie, à laisser l’écrasement désactivé sauf si vous voulez remplacer les légendes saisies à la main, puis à vérifier une page produit et une page listing dans la source du navigateur. Les futures images suivent automatiquement les mêmes règles, car le hook s’exécute chaque fois que la page est présentée.

Oui. Ils sont rendus comme de vrais liens côté serveur, les moteurs les explorent donc sans ouvrir le menu, ce qui ajoute un maillage interne réel entre pages voisines. En même temps, ils n'entrent jamais dans votre BreadcrumbList, qui reste un chemin linéaire et propre.

En bref : Yoast est un plugin WordPress et n'a pas d'équivalent sous PrestaShop. Il n'y a donc rien à intégrer de ce côté. Si vous parlez d'un autre module SEO PrestaShop, nos modules peuvent fonctionner à côté ; il faut seulement gérer le chevauchement.

Le risque avec deux outils SEO, c'est la sortie en double : deux balises canonical, deux jeux de balises Open Graph, deux blocs JSON-LD. Les moteurs n'aiment pas ça. Décidez, fonction par fonction, quel outil fait référence et désactivez le doublon dans l'autre.

Nos modules sont conçus pour coopérer, pas pour entrer en conflit. La Smart SEO Revolution Suite déduplique activement face au thème : quand elle génère ses propres balises hreflang ou Open Graph, elle retire du head les balises équivalentes du thème, et peut aussi nettoyer en option le JSON-LD étranger. Blog Revolution va plus loin et confie les données structurées du blog à SEO Revolution lorsque ce module doit les émettre, vous n'avez donc jamais deux schemas de blog.

Erreur fréquente : activer la même fonction dans deux modules en pensant « plus, c'est mieux ». Choisissez un seul responsable par fonction et la sortie restera propre et unique.

Il suit le motif de divulgation WAI-ARIA : un vrai bouton avec aria-expanded et aria-controls, des listes de liens ordinaires, des états de focus visibles et une prise en charge clavier (Entrée et Espace, flèches, Origine/Fin et Échap). La page courante utilise aria-current, le mouvement réduit est respecté, et le menu fonctionne au lecteur d'écran comme au toucher.

En partie, et cela dépend du motif indiqué par Google pour chaque URL. Soyons honnêtes : aucun module ne peut forcer Google à indexer une page. En revanche, nous corrigeons les causes techniques que Google signale souvent.

• Détectée/explorée, non indexée, ou sitemap manquant : l'Advanced SEO Sitemap Builder génère un sitemap XML vérifié et peut avertir Google et Bing à chaque changement, pour que les bonnes URL soient faciles à trouver.
• Doublon / page alternative avec canonical : géré par les règles canonical et noindex de la Smart SEO Revolution Suite, qui gère aussi les redirections 301/302 des URL déplacées.

Le reste relève du contenu et du serveur, que le module ne fait pas à votre place : pages pauvres, pages jugées de faible valeur par Google, ou erreurs serveur. Ouvrez le motif exact par URL dans la Search Console, corrigez la cause, puis renvoyez. Erreur fréquente : garder dans le sitemap des pages mises en noindex, le Sitemap Builder ignore les URL en noindex et non-200 pour ne pas envoyer de signaux contradictoires.

Pour les pages produit de votre choix, vous rédigez vous-même le chemin exact des niveaux parents, par exemple pour placer un produit de campagne sous une route de catégorie précise. Une règle s'applique par produit, catégorie ou page de filtre SEO, puis remplace les niveaux parents ou insère vos propres étapes de catégorie, CMS, filtre ou lien libre. L'accueil et le produit courant restent toujours verrouillés, et une définition invalide retombe simplement sur le chemin normal.

Oui. Facebook Pixel vous permet de définir des événements Meta Pixel personnalisés côté navigateur depuis la configuration du module. Le module prend en charge des règles basées sur les clics, correspondances d’URL, contexte contrôleur/module PrestaShop, ou un événement DOM.

Utilisez un nom d’événement personnalisé uniquement pour quelque chose qui n’est pas déjà un événement Meta standard. Le module rejette les noms standard/réservés comme Purchase, AddToCart, Search, ViewContent et InitiateCheckout. Les noms personnalisés doivent commencer par une lettre et n’utiliser que des lettres, chiffres ou underscores, avec une limite de 50 caractères.

Exemple : envoyer un événement personnalisé quand un acheteur ouvre un guide des tailles sur une page produit.

[{"event":"SizeGuideOpen","trigger":"click","selector":"#size-guide-link, .js-size-guide","once":true,"params":{"placement":"product_page","source":"faq_example"}}]

Cette règle envoie fbq('trackCustom', 'SizeGuideOpen', ...) quand l’élément cliqué correspond au sélecteur, et inclut les paramètres du payload de règle. Testez l’événement dans Meta Pixel Helper ou Events Manager après enregistrement, car un sélecteur absent du thème actif ne se déclenchera jamais.

Le module valide les règles personnalisées avant enregistrement. Il accepte soit un tableau d’événements simple, soit un format d’objet enveloppé, ignore les règles désactivées, impose les champs requis selon le déclencheur et limite à 50 les noms d’événements personnalisés distincts. Les règles de clic ont besoin d’un sélecteur, les règles URL d’une valeur contains, les règles contrôleur d’un contexte contrôleur, et les règles événement DOM du nom de l’événement à écouter.

La gestion des paramètres est volontairement défensive. Les paramètres personnalisés sont nettoyés, les clés invalides sont ignorées, la profondeur d’imbrication et le nombre total de paramètres sont limités, et les champs sensibles ou réservés comme email, téléphone, IP et event ID ne sont pas acceptés depuis les params d’événement personnalisé. Cela garde les événements personnalisés utiles pour le suivi comportemental sans transformer la zone de configuration en fuite de données personnelles.

Les événements navigateur personnalisés ne s’exécutent que lorsque le tracking Pixel lui-même est actif. Le module vérifie que le tracking est activé, qu’un Pixel ID numérique existe, et que les règles d’exclusion employés et de consentement marketing autorisent le tracking. Le script header attend la porte de consentement quand elle est configurée, initialise Pixel une seule fois, envoie PageView et les événements standard propres à la page, puis attache les listeners AddToCart, wishlist et événements personnalisés.

N’utilisez pas des événements personnalisés pour dupliquer les événements ecommerce standard. Le module possède déjà des événements standard côté navigateur et une file CAPI purchase côté serveur séparée avec event IDs pour la déduplication. Utilisez les événements personnalisés pour des interactions propres au thème comme l’ouverture d’un guide des tailles, l’utilisation d’un simulateur de financement, les clics sur bouton de devis ou les étapes de configurateur que Meta ne modélise pas déjà comme événements standard.

Oui. Les libellés, les liens d'entité, les titres de groupe, les remplacements de chemin et les URL personnalisées tiennent tous compte de la langue, et la configuration, les groupes de menu, les Definable Trails et les caches sont cloisonnés par boutique.

Oui. Internal Linker peut insérer automatiquement des liens au rendu de la page, à partir de groupes de liens qui associent des mots-clés à une URL cible. Il n’exige pas que vous modifiiez manuellement chaque description produit, catégorie, CMS ou blog, et il ne réécrit pas le texte enregistré dans la base de données.

Un groupe de liens typique pourrait ressembler à ceci :

Group name: Shower screen SEO
Target URL: /en/shower-screens
Keywords: shower screen, walk-in screen, glass shower panel, shower enclosure|shower partition, shower*
Page types: product, category, cms
Content zones: product description, category description, CMS content
Max links from this group: 2
Link position: first

Les mots-clés peuvent être séparés par des virgules, spécifiques à une langue, et utiliser des variantes avec |. Les termes de style wildcard comme shower* sont pris en charge par la configuration de mots-clés du module.

Le module possède aussi des garde-fous pour garder une sortie naturelle : il peut ignorer l’URL courante, éviter les titres, éviter le texte déjà lié, empêcher les URL cibles dupliquées, et limiter le nombre total de liens par page ou par groupe. Cela le rend utile pour des schémas de maillage SEO, par exemple lier des termes produit répétés vers des catégories ou guides importants sans créer un excès de liens internes.

Le module s’exécute sur actionOutputHTMLBefore, donc il reçoit le HTML front-office final et modifie uniquement la réponse envoyée au visiteur. Il ignore les sorties non front-office, requêtes AJAX, réponses non HTML et contenus qui ne ressemblent pas à du HTML. L’injecteur partagé extrait ensuite le <body> et travaille dans les régions de contenu configurées, en laissant le <head>, les scripts et le JSON-LD tranquilles.

Les réglages par défaut sont prudents : max_links_per_page vaut 5, max_links_per_group vaut 3, les sélecteurs par défaut incluent descriptions produit, blocs de description, contenu de page et contenu d’article, et les tags autorisés par défaut sont p, div, span, blockquote, li et td. La classe par défaut des liens générés est mpr-autolink, les cibles de page courante sont ignorées, les titres sont exclus, et plusieurs autolinks dans le même élément sont empêchés.

Les zones de contenu simplifient la configuration par rapport à l’écriture manuelle de sélecteurs. Le resolver associe des libellés marchand comme description produit, description catégorie, contenu CMS, contenu blog, description fabricant et description fournisseur à des sélecteurs de thème courants, puis les filtre par type de page. Vous pouvez toujours remplacer les sélecteurs CSS et tags HTML par groupe si votre thème a un markup inhabituel.

L’injecteur compte les liens existants dans les régions de contenu ciblées et réduit le budget disponible d’un groupe quand la page pointe déjà vers la même URL cible. Il prend aussi en charge des stratégies de placement de lien : first, middle, last et spread. C’est utile lorsqu’un mot-clé apparaît plusieurs fois dans un long guide et que vous voulez un seul lien naturel plutôt que chaque occurrence devienne une ancre.

Pour les URL cibles, vous pouvez saisir une URL manuellement ou choisir une entité PrestaShop. Le formulaire admin prend en charge produits, catégories, pages CMS, fabricants et fournisseurs, et peut résoudre l’entité sélectionnée vers son URL front-office. Des overrides de mots-clés et d’URL cible par langue sont disponibles, afin qu’une boutique multilingue puisse utiliser un texte d’ancre local au lieu d’imposer les phrases d’une seule langue à chaque front-office.

Les balises hreflang corrigent très bien un problème précis : elles indiquent à Google quelle version linguistique ou pays d’une page afficher à chaque visiteur, afin que vos pages traduites cessent de se concurrencer comme contenu quasi dupliqué. Pour une boutique PrestaShop multilingue, elles ne sont pas optionnelles, mais elles ne sont qu’une partie du travail, pas la totalité.

Ce que hreflang ne fera pas : sauver des traductions minces ou de qualité machine, remplir des pages qui n’existent que dans une langue, ou corriger des structures d’URL incohérentes entre vos boutiques. Cela nécessite du vrai contenu et des URL propres sous les balises. Notre Smart SEO Revolution Suite génère automatiquement hreflang pour chaque langue active, ajoute un x-default correct, reste compatible multiboutique, et inclut aussi les mêmes références dans votre sitemap XML. Si ces signaux sont justes, Google peut associer la bonne version à chaque chercheur ; la qualité de traduction reste votre responsabilité.

Dans SEO Suite, la sortie hreflang fait partie du hook header. Quand HREFLANG_ENABLED est actif, le module appelle son gestionnaire Hreflang et rend des balises <link rel='alternate' hreflang='...'> pour les URL alternatives qu’il peut construire. S’il existe plus d’un alternate, il ajoute aussi une URL x-default. Si la décision robots courante contient noindex, la suite ne renvoie aucune sortie hreflang pour cette page, ce qui évite à des pages noindex d’envoyer des signaux mixtes.

<!-- MPR SEO Revolution - Hreflang Tags -->
<link rel="alternate" hreflang="en-US" href="https://example.com/en/product.html" data-mpr-seo="1" />
<link rel="alternate" hreflang="fr-FR" href="https://example.com/fr/produit.html" data-mpr-seo="1" />
<link rel="alternate" hreflang="x-default" href="https://example.com/en/product.html" data-mpr-seo="1" />

<url>
  <loc>https://example.com/en/product.html</loc>
  <xhtml:link rel="alternate" hreflang="fr-FR" href="https://example.com/fr/produit.html" />
</url>

Le côté sitemap est séparé mais aligné. Le writer de sitemap peut émettre des entrées xhtml:link rel='alternate' lorsqu’il trouve des URL correspondantes pour la même entité dans d’autres langues. La configuration sitemap possède un interrupteur INCLUDE_HREFLANG, donc les hreflang header et les hreflang de sitemap XML peuvent tous deux être contrôlés volontairement.

Il y a encore de vraies limites. Hreflang ne fonctionne que lorsqu’il existe une vraie URL alternative vers laquelle pointer. Si un produit existe en anglais mais que le produit français manque, est désactivé, noindex ou pauvrement traduit, la balise ne peut pas créer une bonne landing page française pour vous. De même, hreflang ne remplace pas les balises canonical ; chaque page de langue doit normalement se canonicaliser vers elle-même puis lister ses alternates.

Une bonne checklist SEO multilingue : gardez chaque URL de langue crawlable, utilisez des canonicals auto-référents, publiez des traductions complètes pour les produits et catégories importants, gardez les URL du sélecteur de langue cohérentes, incluez les alternates dans le sitemap XML, et évitez noindex sur les pages censées participer au cluster hreflang.

Non. Lorsque la page finale ou ses en-têtes indiquent noindex, ou qu'une page est marquée comme non éligible au schema, il n'émet aucune donnée structurée de fil d'Ariane et retire les siennes ainsi que les données natives reconnues, tout en préservant les données tierces inconnues. Le chemin visible pour les visiteurs reste en place.

Oui. La Smart SEO Revolution Suite est notre module SEO tout-en-un pour PrestaShop : elle réunit notre gamme SEO principale dans un seul tableau de bord du back-office, sous une licence unique et un même canal de mises à jour, pour ne plus jongler entre plusieurs modules ayant chacun sa page de réglages.

La Suite embarque ce que font ces modules autonomes, plus des extras :

• Advanced SEO Sitemap Builder, sitemaps XML/HTML, hreflang et images, avec découpage automatique à la limite de 50 000 URL.
• Automatic SEO Schema Rich Snippets, balisage Product, Offer, BreadcrumbList, Organization, Article, FAQ et Review.
• Product Canonical Manager, canonical, hreflang et contrôle noindex/nofollow.
• Automatic Internal SEO Linker, suggestions de maillage interne mot-clé vers URL sur tout votre contenu.

Elle ajoute aussi des modèles de balise title/description avec variables, un gestionnaire de redirections 301/302/410 avec journal des accès, le suivi des 404, des éditeurs robots.txt et llms.txt, les sorties Open Graph et Twitter Card, l'import Google Search Console, et la génération de balises en masse par IA via OpenAI, Claude ou Gemini.

La logique d'achat est simple : si vous n'avez besoin que d'une fonction isolée, par exemple seulement les canonical, le module autonome correspondant peut être le choix le plus léger. La Suite regroupe ces fonctions SEO dans un seul module et un seul tableau de bord ; comparez-la donc aux modules autonomes en fonction des fonctionnalités dont vous avez réellement besoin.

Oui. Il utilise des propriétés CSS logiques, inverse les séparateurs directionnels et les dégradés de bord, aligne les panneaux déroulants selon la direction calculée et défile correctement en RTL.

Non. Le module est activé par défaut, la balise x-default est activée et la langue x-default est réglée sur la langue par défaut de PrestaShop. Sur une boutique qui a déjà plus d une langue active, il commence à générer les balises hreflang immédiatement, sans rien à renseigner.

Il n y a que trois réglages : Active, Ajouter la balise x-default et Langue par défaut. Vous n y touchez que pour couper la sortie, désactiver le repli x-default ou pointer x-default vers une autre langue que celle par défaut de la boutique. Le reste est automatique.

Le fil d'Ariane côté boutique ne pose aucun cookie, n'utilise aucun stockage navigateur et aucun identifiant de suivi. Il lit seulement votre contexte client et groupe PrestaShop existant afin de ne pas afficher de liens inaccessibles au visiteur. Il n'ajoute donc aucune nouvelle obligation de consentement.

Le module construit les URL alternatives avec la classe Link de PrestaShop, il couvre donc les entités traduisibles standard : produits, catégories, pages CMS, fabricants et fournisseurs. Pour les autres contrôleurs du cœur, il tente getPageLink() et ajoute l alternative lorsque cela réussit.

Il est volontairement prudent : si une route ne peut pas être construite en toute sécurité (certaines routes de modules PS 9 lèvent une erreur), il ignore simplement cette alternative au lieu de casser la page. Les balises ne sont générées que lorsque la boutique courante a plus d une langue active, les boutiques monolingues restent donc intactes.

Le plus souvent, cela se résume à quelques points corrigeables, et le plus courant est un texte alt manquant ou vide. Google s’appuie fortement sur l’attribut alt et le contexte autour pour comprendre ce qu’une image montre, donc les images sans alt descriptif ressortent rarement dans Google Images. Parcourez cette liste :

• Texte alt vide ou générique, le facteur principal ; corrigez cela en premier.
• robots.txt bloque le dossier d’images. Google ne peut pas indexer ce qu’il ne peut pas récupérer.
• Images chargées seulement par JavaScript de lazy-loading que le crawler n’exécute pas (moins fréquent aujourd’hui avec le lazy loading natif).
• Aucune entrée image dans votre sitemap, donc la découverte est plus lente.
• Images très petites ou de faible qualité que Google peut choisir de ne pas indexer.

Commencez par le texte alt. Automatic SEO Images Alt Tags le génère depuis vos données catalogue, nom produit, fabricant, catégorie, référence et plus, et peut remplir seulement les légendes vides ou remplacer les existantes. Notez qu’il donne à Google un texte alt propre à lire ; il ne garantit pas l’indexation ni le classement.

Dans le module, le template produit par défaut est {product_name} - {manufacturer}, les pages listing utilisent {product_name} - {category}, les catégories utilisent {category_name}, et la longueur maximale par défaut est de 125 caractères. Vous pouvez ajouter des placeholders comme {reference}, {ean13}, {mpn} et {image_position} pour rendre les images de galerie plus distinctes. Le builder supprime les séparateurs vides et coupe les textes longs à une frontière de mot, donc un template comme {product_name} - {manufacturer} - {reference} reste lisible même quand un champ manque.

Le module remplit la valeur legend/alt de l’image au moment de la présentation pour les images de couverture produit, images de galerie produit, images de listing et images de catégorie prises en charge. Par défaut, il remplit les valeurs vides sans écraser les légendes écrites à la main ; activez le remplacement seulement après avoir vérifié que votre texte alt manuel n’est pas meilleur. Après modification des templates, videz le cache et inspectez les attributs img alt rendus sur une page produit et une page catégorie. Ce n’est pas un générateur de sitemap image et il ne peut pas forcer Google à indexer une image, mais il retire l’un des principaux blocages côté catalogue.

Oui. À chaque requête, il lit les langues actives de la boutique courante, pas une liste globale, de sorte que chaque boutique d un groupe multiboutique ne génère des alternatives que pour les langues qu elle sert réellement.

Le repli x-default suit la même logique et pointe vers votre langue par défaut configurée. Comme les URL proviennent de la classe Link de PrestaShop, le domaine et le préfixe de langue de chaque boutique sont résolus correctement, ce qui garde le cluster hreflang cohérent dans une configuration multiboutique.

Oui, depuis un seul écran : choisissez un style d'affichage (Minimal, Boxed, Pill ou Underline), le séparateur (chevron, barre oblique, flèche, point, barre verticale, tiret ou aucun) et l'indicateur du menu, décidez si la page courante est affichée, tronquée ou masquée, et réglez le conteneur d'alignement pour votre thème. Aucune modification de template n'est nécessaire.

Passez une de vos URL produit dans le Rich Results Test de Google - il montre quelles données structurées Google trouve sur la page et signale erreurs ou avertissements. Vous pouvez aussi suivre la couverture dans le temps dans Google Search Console, dans les rapports Enhancements. Après l’installation de notre module Schema & Rich Snippets, testez quelques pages produit, catégorie et CMS avant de vous fier à la sortie front-office.

Dans le back-office du module, l’écran d’aperçu vous permet de choisir un type de page et de générer le JSON-LD avant de vous reposer sur la page live. Les schemas Product, Organization, WebSite, Breadcrumb, Category et CMS sont activés par défaut, tandis que le balisage FAQ est désactivé par défaut, car le contenu FAQ doit correspondre au contenu visible de la page. Le schema Product utilise des données catalogue comme fabricant/marque, identifiants de type SKU, état, avis, variantes et jusqu’à cinq images sauf si vous modifiez la limite d’images.

Réserve importante du code actuel : le schema live du front-office doit être vérifié avec le nettoyage JSON-LD existant désactivé, ou après avoir marqué la sortie du module pour que le cleaner la conserve. Le module sort des scripts JSON-LD dans displayHeader, mais l’étape de nettoyage s’exécute sur le HTML final et supprime les blocs application/ld+json sauf s’ils contiennent le commentaire marqueur du module. La sortie header actuelle ne contient pas ce marqueur, donc le nettoyage par défaut peut supprimer le schema que le module vient de rendre.

Cela signifie que vous devez valider à la fois la sortie d’aperçu et la vraie URL publique après exécution du cache, des hooks du thème et des autres modules SEO. Si le nettoyage est activé, vérifiez la source réelle de la page pour confirmer que le JSON-LD est toujours présent. Les avertissements pour champs optionnels ne bloquent pas toujours l’éligibilité, mais les erreurs dans les champs Product obligatoires doivent être corrigées avant d’attendre des rich results. Même un schema valide ne garantit pas que Google affichera des rich results ; il rend seulement la page éligible.

Le fil visible et le JSON-LD proviennent d'une même source ordonnée, ils correspondent donc toujours. Le schéma utilise une URL absolue sans fragment et des positions séquentielles pour chaque étape, est encodé avec des indicateurs HTML sûrs et ne contient que le fil linéaire, jamais les liens du menu déroulant des catégories sœurs. S'il reste moins de deux étapes, ou si la page n'est pas éligible, aucun schéma n'est émis.

Oui. Le module TikTok Pixel & Events API pour PrestaShop fonctionne sur PrestaShop 9 et les autres versions actuelles, sans override ni modification du thème.

Il suit les événements commerce standard de TikTok utilisés pour l'optimisation des publicités et la création d'audiences : ViewContent, AddToCart, InitiateCheckout, mappage Purchase/CompletePayment, CompleteRegistration, Search, Subscribe et AddToWishlist. Chaque événement a son propre interrupteur dans le back-office, vous n'envoyez donc que ce dont vous avez besoin.

Les achats finalisés sont également envoyés côté serveur via l'Events API de TikTok avec le même event_id que le pixel navigateur, pour que TikTok déduplique les deux signaux Purchase au lieu de double-compter. C'est ce qui garde vos rapports d'achat fiables quand iOS, un bloqueur de publicités ou une connexion faible perdent le pixel navigateur. L'exclusion des employés peut empêcher les visites du personnel connecté, et le garde-fou de consentement bloque tous les déclenchements jusqu'à ce que le consentement marketing soit accordé, de sorte qu'un contrôle d'intégrité intégré confirme que les hooks sont enregistrés et que le pixel se déclenche bien.

Pour démarrer : collez votre code Pixel et le jeton d'accès, vérifiez les événements dans l'outil Test Events du TikTok Ads Manager, et c'est en place.

La valeur hreflang x-default indique aux moteurs de recherche quelle page montrer aux visiteurs dont la langue n est pas explicitement ciblee. Lorsqu elle est activee, le module l ajoute en pointant vers votre langue par defaut, et uniquement quand la page a plus d une alternative disponible.

Pour la plupart des boutiques internationales, mieux vaut la laisser active : elle donne a Google un repli sensé au lieu de le laisser deviner. Vous pouvez la desactiver depuis la configuration, ou regler la langue x-default sur une autre que la langue par defaut de PrestaShop si votre audience principale differe de votre langue de catalogue par defaut.

Oui. Le module enregistre les anciennes URL lorsque les URL produit/catégorie/CMS/fabricant/fournisseur changent et sert des redirections depuis la table d’historique. C’est exactement fait pour protéger les URL Google indexées après des changements de slug ou de motif. Utilisez des redirections 301 pour les déplacements permanents, gardez l’historique de redirection activé, et évitez de changer les motifs d’URL à répétition sauf si vous êtes prêt à gérer la chaîne de redirections.

La table d’historique stocke l’ancienne URL, la nouvelle URL, le type de redirection, le type d’entité, l’ID d’entité, l’ID boutique, l’indicateur actif, le nombre de hits, la date du dernier hit et le motif du changement. Le gestionnaire de cycle de vie capture les anciennes URL avant les mises à jour d’entités, les compare après mise à jour, et enregistre les changements d’URL pour produits, catégories, pages CMS, fabricants et fournisseurs. Il possède aussi un comportement de suppression et désactivation qui peut rediriger vers un parent, la page d’accueil, 410 Gone ou rien, selon la configuration.

Au moment de la requête, le routeur vérifie les overrides et entrées d’historique, puis renvoie l’URL de redirection et le type de redirection configurés lorsqu’une ancienne URL correspond. Pour les migrations SEO, gardez les anciennes lignes d’historique activées assez longtemps pour que les moteurs de recherche et liens externes se stabilisent, préférez 301 pour les changements de slug permanents, et testez les URL indexées importantes avec une requête HTTP directe pour confirmer qu’elles renvoient une seule redirection propre vers la destination finale.

Autant que votre boutique en a besoin. Advanced SEO Sitemap Builder n'utilise pas un nombre fixe de fichiers sitemap et ne nomme pas les fichiers enfants par type d'entité. Il collecte les sources d'URL activées, les vérifie, écrit des fichiers XML découpés en lots, puis écrit un index de sitemap pour la boutique.

Par défaut, le module inclut les produits, catégories, pages CMS, pages cœur, images produits et alternatives hreflang. Les fabricants et fournisseurs sont aussi des sources d'URL disponibles, mais ils sont désactivés par défaut dans les paramètres du module. Le writer découpe la sortie lorsque la limite d'URL configurée est atteinte, avec 50,000 URL par fichier par défaut, et protège aussi la limite de taille de fichier de 50 MB du protocole sitemap.

Example generated files for shop ID 1:
modules/mprsitemapbuilder/sitemaps/sitemap_index_1.xml
modules/mprsitemapbuilder/sitemaps/sitemap_1_1.xml
modules/mprsitemapbuilder/sitemaps/sitemap_1_2.xml
modules/mprsitemapbuilder/sitemaps/sitemap_1_3.xml

<sitemapindex xmlns='http://www.sitemaps.org/schemas/sitemap/0.9'>
  <sitemap>
    <loc>https://www.example.com/modules/mprsitemapbuilder/sitemaps/sitemap_1_1.xml</loc>
    <lastmod>2026-06-17T10:00:00+00:00</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://www.example.com/modules/mprsitemapbuilder/sitemaps/sitemap_1_2.xml</loc>
    <lastmod>2026-06-17T10:00:00+00:00</lastmod>
  </sitemap>
</sitemapindex>

Soumettez uniquement l'URL de l'index dans Google Search Console. Google lit les fichiers enfants depuis l'index, vous n'avez donc pas à gérer chaque fichier XML généré à la main. Sur les installations multiboutiques, chaque boutique reçoit son propre index et ses fichiers enfants basés sur l'ID boutique.

Un avertissement de balisage manquant signifie que l’outil n’a pas trouvé le type de schema ou le champ requis sur cette URL. Dans Schema Revolution, vérifiez d’abord que le type de schema est activé pour ce type de page, puis comparez l’aperçu du module avec la source finale de la page après vidage du cache, et enfin testez l’URL live dans le Rich Results Test de Google ou le validateur Schema.org.

Le module construit le JSON-LD selon le type de page détecté. Selon la configuration, il peut sortir Organization et WebSite sur la page d’accueil, BreadcrumbList sur les pages internes, Product schema sur les pages produit, CollectionPage pour les catégories, et Article pour les pages CMS. Le schema Product peut inclure nom, URL, description, SKU, GTIN, MPN, marque issue de la source catalogue configurée, images, état, offres, disponibilité, détails de livraison, politique de retour, notes, avis, poids et données de catégorie quand la boutique possède ces données.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Example product",
  "url": "https://example.com/product.html",
  "description": "Short product description",
  "sku": "REF-123",
  "gtin13": "1234567890123",
  "offers": {
    "@type": "Offer",
    "price": "29.99",
    "priceCurrency": "EUR",
    "availability": "https://schema.org/InStock"
  }
}

Si Google signale des champs manquants, comparez trois choses : l’aperçu du module, la source HTML finale après vidage des caches PrestaShop et externes, et l’URL live récupérée par l’outil de test. Un champ peut être absent parce que le type de schema est désactivé, que le détecteur de page n’identifie pas la page comme attendu, que le produit manque de données source comme marque ou GTIN, que du HTML en cache est encore servi, ou qu’un autre thème/module modifie la sortie finale.

Soyez prudent avec les options de nettoyage. Elles sont destinées à supprimer l’ancien microdata et les JSON-LD dupliqués, mais le nettoyage JSON-LD actuel ne conserve que les scripts marqués avec <!-- mprschema -->, tandis que la sortie header du module n’est pas marquée. Avec clean_existing_jsonld activé, y compris dans son état par défaut, le nettoyage peut supprimer le schema du module lui-même dans le HTML final. Si des outils indiquent un schema manquant, désactivez/corrigez le nettoyage JSON-LD ou ajoutez le marqueur attendu avant de supposer qu’un autre module est en cause.

Dans la configuration du module, ouvrez Schema Revolution > Configuration > Schema Types. Activez le type manquant à cet endroit : Product Schema, Organization Schema, WebSite Schema, Breadcrumb Schema, Category Schema ou CMS Article Schema, selon l'URL testée.

Si le schema existe dans l'aperçu mais disparaît du HTML final, désactivez Remove Existing JSON-LD dans le même onglet Schema Types pendant les tests. Cette option supprime les scripts application/ld+json non marqués de la page avant la sortie ; c'est donc le premier réglage à vérifier lorsque les validateurs indiquent que tout le JSON-LD est absent.

Qu'est-ce que le robots.txt et pourquoi il est important pour PrestaShop

Le fichier robots.txt se trouve à la racine de votre installation PrestaShop et constitue le premier point de communication entre votre boutique et les robots d'exploration des moteurs de recherche. Il indique aux bots comme Googlebot, Bingbot et d'autres quelles parties de votre site ils peuvent explorer et lesquelles ils doivent ignorer. Bien qu'il ne soit pas un mécanisme de sécurité (il n'empêche pas l'accès, il ne fait que conseiller les robots), c'est l'un des outils les plus importants pour gérer votre budget de crawl, le nombre de pages qu'un moteur de recherche explorera sur votre site dans un laps de temps donné.

Pour les boutiques PrestaShop, cela est extrêmement important. Une installation PrestaShop typique peut générer des milliers de variations d'URL à travers les filtres, les options de tri, la pagination, le changement de devise et les requêtes de recherche. Si rien n'est fait, les robots des moteurs de recherche gaspilleront leur budget de crawl sur ces pages à faible valeur au lieu de découvrir et d'indexer vos véritables pages de produits et de catégories.

Comment PrestaShop génère son robots.txt

PrestaShop inclut un générateur de robots.txt intégré, accessible depuis le Back Office. Naviguez vers Paramètres de la boutique > Trafic & SEO et faites défiler vers le bas où vous trouverez la section "Génération du fichier robots". Cliquer sur le bouton de génération crée un fichier robots.txt dans le répertoire racine de votre boutique.

Le fichier généré par défaut inclut généralement des règles comme celles-ci -

User-agent: *
Disallow: /classes/
Disallow: /config/
Disallow: /download/
Disallow: /mails/
Disallow: /modules/
Disallow: /translations/
Disallow: /tools/
Disallow: /*?orderby=
Disallow: /*?orderway=
Disallow: /*?tag=
Disallow: /*?id_currency=
Disallow: /*?search_query=
Disallow: /*?back=
Disallow: /*?n=
Sitemap: https://votreboutique.com/sitemap.xml

Bien que ce soit un point de départ raisonnable, c'est loin d'être complet. De nombreux modèles d'URL critiques qui gaspillent le budget de crawl ne sont pas inclus.

Ce que vous devez bloquer dans PrestaShop

1. Pages panier, commande et compte

Ces pages sont spécifiques à l'utilisateur et n'apportent aucune valeur SEO. Elles doivent toujours être bloquées -

Disallow: /*?controller=cart
Disallow: /*?controller=order
Disallow: /*?controller=authentication
Disallow: /*?controller=my-account
Disallow: /*?controller=identity
Disallow: /*?controller=addresses
Disallow: /*?controller=address
Disallow: /*?controller=history
Disallow: /*?controller=order-detail
Disallow: /*?controller=password
Disallow: /*?controller=discount
Disallow: /*?controller=order-return
Disallow: /*?controller=order-follow
Disallow: /*?controller=guest-tracking
Disallow: /cart
Disallow: /order
Disallow: /login
Disallow: /my-account
Disallow: /password-recovery

2. Navigation à facettes et filtres par couches

La navigation à facettes est le plus grand tueur de budget de crawl pour les boutiques e-commerce. Lorsqu'un client utilise des filtres comme la couleur, la taille ou la fourchette de prix, PrestaShop génère des URL uniques pour chaque combinaison. Une catégorie avec 5 couleurs, 4 tailles et 3 fourchettes de prix peut produire des centaines de combinaisons d'URL, dont aucune ne devrait se trouver dans l'index de Google.

# Bloquer les paramètres de filtres de navigation par couches
Disallow: /*?q=
Disallow: /*&q=
Disallow: /*?selected_filters=
Disallow: /*&selected_filters=
Disallow: /module/ambjolisearch/jolisearch

# Bloquer les combinaisons de filtres de prix
Disallow: /*?price=
Disallow: /*&price=

# Bloquer les filtres d'attributs et de caractéristiques
Disallow: /*?id_attribute_group=
Disallow: /*&id_attribute_group=
Disallow: /*?id_feature=
Disallow: /*&id_feature=

3. Résultats de recherche internes

Les pages de résultats de recherche internes sont du contenu mince et ne devraient jamais être indexées. Elles créent fréquemment des pages quasi-dupliquées et sont une source connue de problèmes de qualité -

Disallow: /*?controller=search
Disallow: /*?s=
Disallow: /*&s=
Disallow: /search
Disallow: /*?search_query=
Disallow: /*&search_query=

4. Paramètres de pagination

Bien que les pages de catégories elles-mêmes doivent être explorables, les paramètres de pagination qui génèrent des variantes de tri/page doivent être contrôlés -

Disallow: /*?page=
Disallow: /*&page=
Disallow: /*?p=
Disallow: /*&p=

Note importante - Soyez prudent avec la pagination. Si vous bloquez /*?page= entièrement, vous pouvez empêcher les robots d'atteindre les produits qui n'apparaissent que sur les pages plus profondes. Une meilleure approche consiste à implémenter des balises rel="canonical" pointant les pages paginées vers la première page, ou à utiliser les signaux de pagination rel="next" et rel="prev".

5. Pages de comparaison et listes de souhaits

Disallow: /*?controller=comparison
Disallow: /comparison
Disallow: /*?controller=wishlist
Disallow: /module/blockwishlist/

6. Répertoires admin et système

Disallow: /admin*/
Disallow: /app/
Disallow: /bin/
Disallow: /cache/
Disallow: /classes/
Disallow: /config/
Disallow: /controllers/
Disallow: /docs/
Disallow: /download/
Disallow: /img/tmp/
Disallow: /localization/
Disallow: /mails/
Disallow: /override/
Disallow: /pdf/
Disallow: /src/
Disallow: /tools/
Disallow: /translations/
Disallow: /upload/
Disallow: /var/
Disallow: /vendor/
Disallow: /webservice/

7. Paramètres de suivi d'URL

Les paramètres de campagnes marketing créent du contenu dupliqué lorsque les bots explorent les URL taguées -

Disallow: /*?utm_source=
Disallow: /*?utm_medium=
Disallow: /*?utm_campaign=
Disallow: /*&utm_source=
Disallow: /*&utm_medium=
Disallow: /*&utm_campaign=
Disallow: /*?fbclid=
Disallow: /*?gclid=
Disallow: /*?ref=

Ce que vous devez autoriser dans PrestaShop

1. Pages produits et catégories

Ce sont le cœur de votre boutique et doivent toujours rester explorables. Ne bloquez pas vos répertoires de contenu principal.

2. Fichiers CSS, JavaScript et images

Google a besoin de rendre vos pages pour évaluer la qualité du contenu. Bloquer les fichiers CSS ou JS empêche le rendu et peut nuire à vos classements -

Allow: /themes/*/assets/
Allow: /themes/*/css/
Allow: /themes/*/js/
Allow: /js/
Allow: /img/
Allow: /modules/*/views/css/
Allow: /modules/*/views/js/

3. Pages CMS

Vos pages légales, pages à propos et pages de marketing de contenu doivent être entièrement explorables. Assurez-vous qu'elles ne sont pas accidentellement capturées par des règles Disallow trop larges.

4. Pages fabricants et fournisseurs (si utilisées)

Si vous maintenez des pages fabricants ou fournisseurs riches avec du contenu unique, gardez-les explorables. S'il s'agit de pages minces auto-générées, envisagez de les bloquer.

Gestion des robots d'IA

L'essor des services d'IA a introduit une nouvelle catégorie de robots qui extraient du contenu à des fins d'entraînement. Si vous souhaitez empêcher que vos descriptions de produits, images et autres contenus soient utilisés par des modèles d'IA, vous pouvez ajouter des règles spécifiques -

# Bloquer les robots d'entraînement IA
User-agent: GPTBot
Disallow: /

User-agent: ChatGPT-User
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: anthropic-ai
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: FacebookBot
Disallow: /

User-agent: Bytespider
Disallow: /

Notez que le blocage de Google-Extended empêche Google d'utiliser votre contenu pour l'entraînement de l'IA (Gemini) tout en permettant toujours au Googlebot normal d'explorer et d'indexer vos pages normalement.

Fichier robots.txt complet recommandé pour PrestaShop

Voici un fichier robots.txt complet que vous pouvez adapter pour votre boutique PrestaShop -

# Robots principaux des moteurs de recherche
User-agent: *

# Autoriser les ressources statiques
Allow: /themes/*/assets/
Allow: /themes/*/css/
Allow: /themes/*/js/
Allow: /js/
Allow: /img/
Allow: /modules/*/views/css/
Allow: /modules/*/views/js/

# Bloquer les répertoires système
Disallow: /app/
Disallow: /bin/
Disallow: /cache/
Disallow: /classes/
Disallow: /config/
Disallow: /controllers/
Disallow: /docs/
Disallow: /download/
Disallow: /img/tmp/
Disallow: /localization/
Disallow: /mails/
Disallow: /override/
Disallow: /pdf/
Disallow: /src/
Disallow: /tools/
Disallow: /translations/
Disallow: /upload/
Disallow: /var/
Disallow: /vendor/
Disallow: /webservice/

# Bloquer panier, commande, compte
Disallow: /cart
Disallow: /order
Disallow: /login
Disallow: /my-account
Disallow: /password-recovery
Disallow: /*?controller=cart
Disallow: /*?controller=order
Disallow: /*?controller=authentication
Disallow: /*?controller=my-account

# Bloquer filtres et tri
Disallow: /*?orderby=
Disallow: /*?orderway=
Disallow: /*?n=
Disallow: /*?q=
Disallow: /*?selected_filters=
Disallow: /*?id_currency=
Disallow: /*?tag=
Disallow: /*?back=

# Bloquer recherche
Disallow: /*?controller=search
Disallow: /*?search_query=
Disallow: /*?s=
Disallow: /search

# Bloquer paramètres de suivi
Disallow: /*?utm_source=
Disallow: /*?utm_medium=
Disallow: /*?utm_campaign=
Disallow: /*?fbclid=
Disallow: /*?gclid=

# Bloquer comparaison et liste de souhaits
Disallow: /*?controller=comparison
Disallow: /comparison

# Sitemap
Sitemap: https://votreboutique.com/1_index_sitemap.xml

# Bloquer robots d'entraînement IA
User-agent: GPTBot
Disallow: /

User-agent: ChatGPT-User
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: Google-Extended
Disallow: /

Erreurs courantes à éviter

Bloquer entièrement le répertoire modules

Le robots.txt par défaut de PrestaShop bloque /modules/. Bien que vous ne vouliez pas que les fichiers PHP des modules soient explorés, de nombreux modules servent des CSS et JavaScript critiques depuis ce répertoire. Le blocage général peut empêcher Google de rendre correctement vos pages. Au lieu de cela, bloquez /modules/ mais autorisez explicitement les sous-répertoires CSS et JS comme montré ci-dessus.

Utiliser robots.txt au lieu de noindex

Un malentendu critique - robots.txt indique aux bots de ne pas explorer une URL, mais il n'empêche pas l'indexation. Si un autre site lie vers une page que vous avez bloquée dans robots.txt, Google peut quand même l'indexer (affichant "Aucune description n'est disponible pour ce résultat en raison du fichier robots.txt de ce site"). Pour les pages que vous souhaitez complètement retirer des résultats de recherche, utilisez plutôt la balise meta noindex ou l'en-tête HTTP X-Robots-Tag.

Oublier la référence au sitemap

Incluez toujours l'URL de votre sitemap en bas du robots.txt. Cela aide les robots à trouver votre sitemap immédiatement. Si vous utilisez un module qui génère plusieurs sitemaps, référencez le fichier index du sitemap.

Utiliser des règles trop larges

Une règle comme Disallow: /*? bloquerait chaque URL avec un paramètre de requête quelconque, ce qui serait catastrophique. Soyez précis avec vos règles et testez-les avec l'outil de test robots.txt de Google Search Console avant de les déployer.

Tester votre configuration robots.txt

1. Google Search Console - Utilisez l'outil de test robots.txt (trouvé sous les outils hérités) pour vérifier des URL spécifiques par rapport à vos règles
2. Test manuel - Visitez votreboutique.com/robots.txt directement dans votre navigateur pour vérifier que le fichier est accessible et correctement formaté
3. Rapport de couverture - Après le déploiement des modifications, surveillez le rapport de couverture dans Google Search Console pour détecter toute augmentation inattendue des pages "Exclues"
4. Analyse des fichiers de log - Vérifiez vos journaux serveur pour confirmer que les bots respectent bien vos règles et ne gaspillent pas le budget de crawl sur les URL bloquées

Considérations multiboutique

Si vous gérez une configuration multiboutique PrestaShop, chaque boutique (domaine) a besoin de son propre fichier robots.txt à sa racine. Le générateur PrestaShop crée des règles pour toutes les boutiques dans un seul fichier, mais si vos boutiques sont sur différents domaines, vous devez les séparer en conséquence. Le robots.txt de chaque boutique doit référencer son propre sitemap et avoir des règles appropriées à sa structure d'URL.

Quand régénérer votre robots.txt

Vous devriez régénérer ou mettre à jour votre robots.txt chaque fois que vous -

• Ajoutez de nouveaux modules qui créent des URL publiques (modules de recherche, modules de filtres)
• Changez votre structure d'URL ou activez/désactivez les URL conviviales
• Changez de thème (différents thèmes peuvent servir des ressources depuis différents chemins)
• Ajoutez ou supprimez des langues (ce qui modifie les préfixes d'URL)
• Activez ou désactivez la fonctionnalité multiboutique
• Remarquez des modèles de crawl inhabituels dans vos journaux serveur ou Google Search Console

Rappel - faites toujours une sauvegarde de votre robots.txt fonctionnel avant de le régénérer. Le générateur PrestaShop écrase complètement le fichier, et toutes les règles personnalisées que vous avez ajoutées manuellement seront perdues à moins de les rajouter après la génération.

Si vous préférez ne pas modifier les règles à la main à chaque changement de catalogue, Advanced SEO Sitemap Builder garde votre sitemap synchronisé et donne aux robots une carte propre des URL que vous voulez indexer.

"Crawled. Currently not indexed" signifie que Google a récupéré la page et a choisi de ne pas l’indexer, c’est presque toujours un jugement de qualité ou de priorité, pas une erreur technique. Sur les boutiques PrestaShop, les déclencheurs habituels sont :

• Contenu mince ou dupliqué, pages produit avec seulement le texte du fabricant, ou pages de variantes quasi identiques. C’est la cause principale ; donnez à chaque page un texte unique et utile.
• Maillage interne faible, les pages enterrées profondément avec peu de liens semblent peu importantes. Croisez les liens entre produits liés et depuis le contenu CMS/blog.
• Budget de crawl gaspillé sur URL de filtre, recherche et paramètres de session, laissant peu d’attention pour vos vraies pages.
• Produits longtemps hors stock, gardez la page live avec schema OutOfStock, ou redirigez en 301 les articles arrêtés vers l’alternative la plus proche.
• Problèmes canonical / réponse, mauvais canonicals, chaînes de redirection ou soft 404. Vérifiez avec l’outil URL Inspection.

Corrigez d’abord le contenu et le maillage, puis demandez une réindexation pour vos URL prioritaires. Des outils comme notre Smart SEO Revolution Suite aident avec les canonicals, données structurées et sitemaps afin que Google voie des signaux propres.

La vérification de sitemap de SEO Revolution suit la même idée avant que les URL atteignent le XML. Elle ignore les URL qui renvoient une réponse non-200, redirigent vers une URL finale différente, contiennent noindex dans les en-têtes ou balises meta, ou déclarent un canonical qui ne correspond pas à l’URL demandée. Les erreurs serveur restent pending pour réessai au lieu d’être publiées comme URL saines.

C’est important, car forcer de mauvaises URL dans le sitemap peut aggraver ce statut Search Console. Si la page est un doublon filtré, une page de recherche interne mince ou un doublon canonicalisé, la bonne correction consiste généralement à la garder hors du sitemap et à renforcer la cible canonical plutôt que de demander sans cesse l’indexation.

Pour les landing pages de résultats de recherche, Search Revolution est conservateur par défaut : les pages de recherche ordinaires sortent noindex, follow, et les pages SEO search générées commencent inactives et non indexables. Seules les pages de recherche éditorialisées avec contenu unique et vrai objectif merchandising doivent être rendues indexables et incluses dans les sitemaps.

Good candidate: curated /search/walk-in-shower-trays with unique copy, products and internal links.
Poor candidate: raw ?s=shower query page with duplicate listings and no unique content.

Vendre dans la langue de vos clients aide vraiment, mais traduire une boutique PrestaShop avec une sortie machine brute coûte généralement plus que ça ne fait économiser. Les dégâts sont discrets : des tournures maladroites qui inspirent la méfiance, des fiches techniques mal traduites qui génèrent des retours, et des pages minces et quasi dupliquées que les moteurs ne classent pas.

La traduction automatique convient en premier jet pour des textes sans enjeu. En e-commerce, elle échoue précisément là où se gagne l'argent : noms et attributs produit, tailles et matières, pages légales et de livraison, et tout ce qui porte la voix de marque. Un mot erroné sur une fiche n'est pas une coquille, c'est un retour, un litige ou une vente perdue.

Une approche viable est hybride : traduire automatiquement le gros, puis faire relire et réécrire par un locuteur natif les pages qui convertissent (produits phares, catégories, tunnel de commande, textes légaux). PrestaShop offre déjà des champs par langue et un outil de traduction intégré : vous gardez la main sur chaque langue, au lieu de dépendre d'une couche d'auto-traduction qui produit du contenu non indexable.

Si vous ajoutez des langues pour vous développer à l'international, parcourez nos modules PrestaShop dédiés au SEO et au contenu, et prévoyez une relecture humaine là où elle compte.

Lighthouse, intégré aux Chrome DevTools, note une page de 0 à 100 dans quatre catégories, Performance, Accessibilité, Bonnes pratiques et SEO. Voyez ces chiffres comme une liste de tâches, pas comme une note : chacun se décompose en vérifications précises à corriger.

Ce que dit chaque score

• Performance est le plus difficile pour PrestaShop, car les thèmes et modules chargent beaucoup de CSS et de JavaScript. Il dépend des Core Web Vitals : Largest Contentful Paint (souvent votre image produit), Cumulative Layout Shift (images et bannières sans espace réservé) et Interaction to Next Paint (scripts lourds sur les filtres et déclinaisons).
• Accessibilité signale les textes alternatifs manquants, le contraste trop faible et les champs sans étiquette.
• Bonnes pratiques détecte les erreurs console, le contenu mixte HTTP et les en-têtes de sécurité absents.
• SEO est le plus simple, titre et meta description valides, balise viewport, liens descriptifs et pages indexables.

Données labo vs terrain

Le score des DevTools provient d'une simulation bridée (labo). Google s'appuie sur les données terrain (vrais visiteurs) dans le rapport Core Web Vitals de la Search Console. Les deux divergent souvent : corrigez d'abord ce qui ressort en terrain, et servez-vous du labo pour déboguer.

Gains rapides sur PrestaShop

Activez CCC (Combiner, Compresser, Cacher) sous Performance, définissez largeur et hauteur sur les images du thème, différez le JavaScript non critique et retirez les modules inutilisés.

Un frein fréquent est le suivi en double. Si l'analyse passe par plusieurs endroits, regroupez-la, nos modules Google Analytics GA4 et Google Tag Manager chargent leurs balises proprement, pour que la mesure ne soit pas ce qui alourdit vos scripts.

Un flux de produits est un fichier structuré (XML, CSV ou JSON) listant les données de chaque produit, que des plateformes comme Google Shopping et Meta (Facebook/Instagram) lisent pour afficher vos articles. Bien configurer le flux Google Shopping de PrestaShop, c'est ce qui maintient vos produits approuvés plutôt que refusés.

Ce qu'attendent les plateformes

Les attributs essentiels exigés par Google et Meta : id, title, description, link, image_link, price (avec devise), availability, brand et les identifiants produit, gtin (EAN-13/UPC) ou mpn quand un GTIN existe. Pour Google, vous associez chaque catégorie PrestaShop à une google_product_category.

<item>
  <g:id>123-45</g:id>
  <g:item_group_id>123</g:item_group_id>
  <g:title>Example Product - Blue / M</g:title>
  <g:link>https://example.com/product.html</g:link>
  <g:image_link>https://example.com/img/p/1/2/3/123-large_default.jpg</g:image_link>
  <g:availability>in_stock</g:availability>
  <g:price>29.99 EUR</g:price>
  <g:brand>Example Brand</g:brand>
  <g:gtin>1234567890123</g:gtin>
  <g:mpn>REF-123-BLU-M</g:mpn>
</item>

Configurer le flux Google Shopping dans PrestaShop

1. Créez un compte Google Merchant Center et vérifiez/revendiquez le domaine de la boutique. Un compte Google Ads n'est requis que pour les campagnes Shopping payantes, pas pour les fiches gratuites.
2. Générez le flux. Le module officiel PrestaShop "Google & YouTube" se connecte au Merchant Center via OAuth et mappe vos attributs. Les modules de flux tiers ajoutent le mapping personnalisé, le filtrage par catégorie/stock et la régénération planifiée (cron). Pour un contrôle total, vous pouvez aussi produire un flux XML personnalisé et le rafraîchir via cron.
3. Mappez les attributs et choisissez les produits (exclure par catégorie, stock ou prix), puis définissez un planning de régénération.

Catalogue Facebook / Instagram

Dans le Meta Commerce Manager, créez un catalogue e-commerce, choisissez « Flux de données » et pointez une URL de flux planifié vers votre flux PrestaShop. Les champs obligatoires de Meta reprennent ceux de Google. Pour les publicités dynamiques, il faut aussi le Meta Pixel envoyant ViewContent, AddToCart et Purchase.

Éviter les refus courants

• Identifiants manquants, renseignez l'EAN-13 et le fabricant sur chaque produit ; sans GTIN réel, mettez identifier_exists à false.
• Écart de prix, le prix du flux (HT/TTC, mauvaise devise ou périmé après une promo) doit correspondre à la fiche produit ; régénérez assez souvent.
• Rejet d'image, pas de filigrane ni texte promotionnel, le produit remplit l'image, résolution correcte.

Variantes

Soumettez chaque combinaison PrestaShop comme son propre élément avec un id unique, regroupé sous un item_group_id commun, plus la color/size spécifique et le prix de cette variante.

Voir notre Smart Google Merchant Feed Manager.

La Smart SEO Revolution Suite est un seul module qui prend en charge ensemble les principales tâches de SEO technique, au lieu d'enchaîner plusieurs modules à usage unique. Vous le configurez d'un seul endroit et les éléments partagent un même jeu de règles.

Ce que regroupe ce module unique :

• Modèles de meta title et description pour produits, catégories, pages CMS et plus.
• Sitemap XML, éditeur robots.txt et gestion des canonical.
• Données structurées Schema.org, Open Graph et Twitter Cards et hreflang pour les boutiques multilingues.
• Redirections 301/302 et surveillance des 404.
• SEO des images, maillage interne et score SEO.

Les modules séparés ont du sens quand vous n'avez vraiment besoin que d'une tâche précise, texte alt des images, ou juste un sitemap. L'avantage de la suite : les fonctions se connaissent. Comme un seul module génère le head, il peut retirer les balises en double du thème et conserver un seul jeu propre de canonical, hreflang et schema. Avec plusieurs modules indépendants, c'est à vous de coordonner, et les conflits de doublons sont le résultat habituel.

Erreur fréquente : acheter la suite et un module séparé qui se chevauche, puis activer la même fonction dans les deux. Laissez un seul module responsable de chaque tâche. Voir la Smart SEO Revolution Suite.

Le SEO Technical Pack est le pack de modules SEO PrestaShop dédié aux signaux techniques que Google utilise pour explorer, comprendre et consolider votre boutique. Il réunit quatre de nos modules : Advanced SEO Sitemap Builder pour les sitemaps XML/HTML, Automatic SEO Schema Rich Snippets pour les données structurées Schema.org, Product Canonical Manager pour le contrôle des canonical et du noindex, et Hreflang Tags Manager pour le ciblage multilingue.

Il se distingue de la Smart SEO Revolution Suite complète car il s'en tient à l'infrastructure, pas à tous les flux SEO. Choisissez ce pack quand votre priorité est la découverte des pages, les données structurées, le contrôle du contenu dupliqué et le bon ciblage des langues, sans acheter chaque module technique séparément.

Le SEO Content Pack est le pack de modules SEO PrestaShop qui renforce les signaux de contenu on-page dans votre catalogue, plutôt que la plomberie technique. Il réunit nos modules de contenu : textes alt automatiques pour les images, lazy loading des images, Automatic Internal SEO Linker pour le maillage interne mot-clé vers URL, sous-titres SEO produit et un second bloc de description de catégorie.

Il est conçu pour les boutiques qui ont déjà des produits et des catégories en ligne mais veulent tirer plus de leur contenu existant : meilleur SEO image, liens internes qui font circuler l'autorité entre les pages, textes de catégorie plus riches et contexte supplémentaire sur les fiches produit. Si vous avez aussi besoin de sitemaps, de schema ou de canonical, ils se trouvent dans le SEO Technical Pack ou, tous ensemble, dans la Smart SEO Revolution Suite.

Automatic SEO Schema Rich Snippets génère du JSON-LD par type de page, en utilisant les données que PrestaShop détient réellement, et chaque type possède son propre interrupteur on/off afin que vous décidiez ce que chaque page émet :

• Product sur les pages produit - nom, image, SKU/référence, marque, GTIN, plus une Offer avec prix, devise et disponibilité, et rating/review lorsque ces données existent.
• Organization et WebSite sur la page d’accueil.
• BreadcrumbList sur les pages internes.
• Category sur les pages catégorie et balisage CMS sur les pages CMS.

Le schema Product est la partie la plus profonde : il peut inclure la référence comme SKU, les identifiants EAN/UPC/ISBN, la référence fournisseur comme MPN, les images produit jusqu’à la limite configurée, la marque issue du fabricant/fournisseur/caractéristique, l’état de l’article, et la disponibilité de l’offre comme InStock, BackOrder ou OutOfStock. Quand les déclinaisons sont activées, les variantes produit peuvent être représentées comme offres, et les champs livraison/politique de retour sont ajoutés lorsque ces réglages sont activés.

La sortie homepage est volontairement limitée aux schemas Organization et WebSite, y compris la search action WebSite. Les pages catégorie sont émises comme page de style collection avec description, image de catégorie, nombre de produits et courte liste d’items. Les pages CMS sont émises comme contenu de style article avec headline, description/contenu, nombre de mots, dates, organisation auteur/publisher et langue.

Le nettoyage fait partie du travail du module. Avec les réglages de nettoyage par défaut activés, il supprime le microdata du thème ou du cœur et le JSON-LD existant avant d’injecter son propre JSON-LD, afin que les outils de test voient une source cohérente plutôt que des balisages produit ou breadcrumb dupliqués. Les scripts générés sont ajoutés dans le head de page comme application/ld+json.

Limite pratique : il existe une clé de configuration stockée enable_faq, mais le code renderer actuel ne sort pas de schema FAQ. Considérez le jeu de sortie actif comme product, organization, website, breadcrumb, category et CMS/article schema sauf si le code du module est étendu.

Un écran d’aperçu vous permet d’inspecter le JSON-LD exact avant que Google recrawle, et une étape de nettoyage retire les microdata ou JSON-LD dupliqués laissés par votre thème afin que les outils voient une copie propre. Un balisage correct rend les pages éligibles aux rich results ; Google décide toujours s’il les affiche. Voir Automatic SEO Schema Rich Snippets.

Advanced SEO Sitemap Builder ne liste pas simplement votre catalogue - il vérifie chaque URL avant de décider qu’elle est prête pour le sitemap. Pendant la génération, il envoie une requête à chaque URL candidate et lit trois éléments : le statut HTTP, tout signal noindex (robots meta ou en-tête X-Robots-Tag), et la cible canonical de la page. Les URL qui renvoient autre chose que 200 (redirections, 404), portent noindex, ou pointent leur canonical vers une autre adresse sont ignorées au lieu d’être soumises.

Le flux de vérification est plus prudent qu’un simple crawl. Il utilise d’abord HEAD, ignore les URL qui échouent déjà là, puis GET les réponses 200 restantes afin de parser le head de page pour canonical et robots meta. Les redirections sont suivies jusqu’à la limite configurée, le timeout de requête a un plancher de sécurité minimal, et la concurrence est plafonnée à trois requêtes pour que la génération ne martèle pas la boutique.

Chaque exclusion est écrite dans un log avec son motif et son code HTTP, afin que vous voyiez pourquoi une URL a été laissée de côté. Les grands catalogues sont découpés en plusieurs fichiers avec un index de sitemap (jusqu’à 50 000 URL par fichier), et vous pouvez activer les entrées image et alternates hreflang quand votre boutique en a besoin.

Le module stocke l’état des URL candidates dans sa propre table URL : pending, verified, skipped ou error, avec des champs pour motif de skip, code HTTP, URL canonical, indicateur noindex, URL d’images et date de vérification. Si la vérification d’URL est désactivée, les URL pending peuvent être marquées verified directement ; si elle est activée, seules les URL qui passent les contrôles sont écrites dans le sitemap. Les changements de produit, catégorie et CMS remarquent les URL correspondantes comme pending, donc les pages modifiées sont revérifiées à la génération suivante.

Le writer évite aussi une erreur opérationnelle fréquente : il écrit d’abord dans des fichiers temporaires, puis remplace les fichiers sitemap live. Si aucune URL vérifiée n’est disponible, il n’écrase pas un sitemap existant fonctionnel par un sitemap vide. Les fichiers sitemap sont découpés par nombre d’URL et taille, et le fichier index est utilisé lorsqu’il existe plusieurs fichiers par langue ou par découpage.

Pourquoi c’est important : un sitemap propre signifie que vous pointez Google seulement vers les pages que vous voulez vraiment indexer, et vous attrapez les problèmes d’URL ici au lieu d’attendre des semaines que Search Console les remonte. L’erreur fréquente évitée est de publier un sitemap plein d’URL redirigées ou noindex qui gaspillent discrètement le budget de crawl.

Automatic SEO Schema Rich Snippets ne demande aucune modification de thème ni de fichiers .tpl. Il se branche sur le hook standard d'en-tête de page de PrestaShop et écrit ses données structurées automatiquement en application/ld+json dans le head de la page. Il fonctionne donc avec tout thème, y compris personnalisé, sans que vous touchiez le moindre template.

Avant d'ajouter son propre balisage, le module peut nettoyer les données structurées en conflit : avec le nettoyage activé par défaut, il supprime les microdata et blocs ld+json existants laissés par votre thème ou le cœur, afin que Google et les outils de test voient une seule copie de référence au lieu d'un balisage Product ou Breadcrumb dupliqué. Vous contrôlez tout depuis la configuration du module - quels types de pages émettent du schema, les limites d'images et si le nettoyage s'exécute - et rien n'est codé en dur dans votre thème, si bien que retirer ou mettre à jour le module ne laisse jamais de balisage orphelin. Voir Automatic SEO Schema Rich Snippets.

Oui. Le texte alt est basé sur des modèles ; vous décidez donc de la formulation des légendes d’image générées. Automatic SEO Images Alt Tags propose des modèles distincts pour les pages détail produit, les listes de produits comme les blocs catégorie/recherche/page d’accueil, et les images de couverture des catégories.

Le module construit ces valeurs au niveau du presenter PrestaShop, sans analyser le HTML rendu et sans réécrire les légendes d’image dans la base de données à chaque chargement de page. Il renseigne le champ legend de l’image présentée lorsque vos réglages l’autorisent. Vous pouvez choisir de ne remplir que les légendes vides ou de remplacer celles qui existent déjà.

Les variables produit disponibles sont {product_name}, {manufacturer}, {category}, {reference}, {ean13}, {isbn}, {upc}, {mpn} et {image_position}. Les modèles d’image de catégorie peuvent utiliser {category_name} et {category_description}. La longueur maximale par défaut est de 125 caractères, et le générateur coupe si possible à une limite de mot.

Product page template:
{product_name} - {manufacturer} | {category}

Product listing template:
{product_name} in {category} - {reference}

Category cover template:
{category_name} - online collection

Utilisez des champs catalogue réellement renseignés. Si un produit n’a pas de fabricant ni de référence, le générateur supprime les espaces réservés vides et nettoie les séparateurs, mais le meilleur résultat SEO vient toujours de données produit complètes et d’un modèle qui décrit précisément l’image.

Voir Automatic SEO Images Alt Tags.

Oui. Product Canonical Manager retire les paramètres de tracking de vos balises canonical PrestaShop, afin que les moteurs de recherche voient une seule adresse propre au lieu de dizaines de variantes de la même page avec tags de campagne.

La liste de suppression par défaut est utm_source, utm_medium, utm_campaign, utm_term, utm_content, fbclid, gclid et msclkid - les paramètres publicitaires habituels Google, Meta et Microsoft. La liste est un simple champ séparé par des virgules, donc vous pouvez ajouter ou retirer des paramètres pour correspondre à vos propres campagnes.

Un détail d’implémentation compte : le hook de sortie front-office actuel applique la liste séparée par virgules à la balise canonical. Le module possède une valeur de configuration strip_pagination, mais dans le chemin de code inspecté ici, la pagination n’est pas supprimée par une branche de hook séparée. Si vous voulez retirer p ou page aujourd’hui, ajoutez ces noms à la liste des paramètres à supprimer.

Une chose doit être claire : le nettoyage réécrit la balise <link rel="canonical"> dans le head de page, pas l’URL sur laquelle se trouve le visiteur. L’acheteur arrive toujours sur le lien tagué et vos analytics enregistrent encore la campagne - seul le canonical que vous donnez à Google est nettoyé. C’est exactement ce que vous voulez : le tracking continue de fonctionner, tandis que les signaux d’URL dupliquées sont consolidés sur une seule adresse canonical.

Le même passage de sortie peut aussi forcer les chemins en minuscules, ajouter ou remplacer les balises meta robots, appliquer des canonicals personnalisés par règles, et régénérer les balises hreflang pour les langues actives avec un x-default pointant vers la langue par défaut configurée. La normalisation en minuscules s’applique au chemin, pas à chaque valeur de requête.

Vous le configurez dans le back-office, mais il s’exécute pendant la sortie front-office de page, sans modification de thème ni template. Si vous avez aussi besoin de contrôle hreflang et noindex/nofollow sur produits, catégories, CMS, marques et fournisseurs, cela vit dans le même module.

Les groupes de liens sont la façon dont le module SEO PrestaShop Automatic Internal SEO Linker crée automatiquement votre maillage interne. Un groupe de liens associe plusieurs variantes d'ancre à une seule URL de destination : le module parcourt vos contenus, repère ces ancres et les transforme en liens vers la cible, sur tout le site, sans toucher aux descriptions une par une.

Chaque groupe permet de configurer :

• Variantes d'ancre, plusieurs expressions clés pointant toutes vers la même cible.
• Destination, produit, catégorie, page CMS ou URL externe.
• Zones de contenu. Où les correspondances sont autorisées : descriptions produit et courtes, descriptions de catégorie, contenus CMS, et les types de pages choisis.
• Limites de sur-liaison, un maximum par page et un plafond global facultatif, pour qu'un mot-clé ne vire pas au bourrage.
• Politique de position, première correspondance seulement ou toutes.
• Sensibilité à la casse, attributs du lien (target, rel, classe CSS) et un interrupteur actif pour les tests.
• Priorité, départage deux groupes qui pourraient toucher le même texte.

Ce qui marche en pratique : des groupes ciblés pour les catégories, guides et landing pages importants, avec des limites prudentes. Lier chaque mot répété crée du bruit ; quelques liens intentionnels par page gardent une structure propre. Internal SEO Linker fait aussi partie de la Smart SEO Revolution Suite.

Le Tracking & Analytics Pack est un ensemble de licences pour des modules de tracking et d'analyse, vendu ensemble pour moins cher que l'achat séparé des mêmes modules. Chaque module est un module dédié avec son propre écran de réglages, installé et configuré indépendamment, avec ses propres identifiants et son propre comportement de consentement.

Pour la liste à jour des modules inclus, et la version de PrestaShop prise en charge par chacun, consultez la page produit du Tracking & Analytics Pack.

Subtitles Manager affiche une courte ligne de support juste après le H1 principal, et pas seulement sur les fiches produit. Le même moteur couvre les pages produit, catégorie, CMS, fabricant et fournisseur : une catégorie ou une marque peut donc avoir son propre sous-titre.

L'affichage passe par le hook displayMprSubtitle, que le module place juste après le H1 en insérant l'appel du hook dans vos templates de thème lors d'un scan. Si vous préférez gérer la position vous-même, appelez le hook où vous voulez dans le thème ; il existe aussi un alias displayProductSubtitle pour les thèmes qui utilisent ce nom. Dans les listes produit, vous pouvez passer un ID de produit explicite pour que chaque carte ait son sous-titre.

La balise qui l'entoure est libre : H2 par défaut, ou H3, H6, <p>, <span> ou <div> si votre thème utilise déjà les titres plus bas. Le module valide la balise par rapport à cette liste fixe et revient à H2 si autre chose est fourni, et il nettoie la classe CSS. Une faute de frappe dans le template ne peut donc pas injecter de balisage arbitraire.

Le ciblage est piloté par règles : définissez un sous-titre sur un produit, une catégorie, une page CMS, un fabricant ou un fournisseur, ou appliquez-le à tous les produits d'une catégorie choisie, la priorité tranchant quand plusieurs règles correspondent. Chaque langue a son champ, et les marqueurs permettent à une seule formulation de couvrir de nombreux produits, les jetons remplissant les détails. À utiliser pour un contexte longue traîne concis, type de produit, compatibilité, taille, usage, pas pour répéter le nom du produit.

Oui. Smart SEO Friendly URL Manager retire les IDs numériques par défaut des URL produit, catégorie, CMS, fabricant et fournisseur, et route les anciens chemins via des redirections 301, afin que les liens entrants et favoris existants continuent de répondre.

La sécurité vient de quatre mécanismes intégrés. La gestion des collisions empêche deux entités d’aboutir à la même URL finale en ajoutant un suffixe si nécessaire, au lieu de laisser un doublon écraser le cache. Une table d’historique URL enregistre chaque ancienne URL avec un compteur de hits, afin que vous voyiez quels chemins legacy reçoivent encore du trafic avant de les retirer. Un override manuel permet de fixer une URL précise hors du motif - pratique pour les pages importantes que vous ne voulez pas régénérer automatiquement. Et le code de redirection est configurable (301, 302, 307 ou 410 Gone) afin d’envoyer le bon signal par migration.

Le système de motifs URL est configurable par entité. Les URL produit peuvent utiliser des placeholders comme {name}, {category}, {categories}, {brand}, {reference}, {ean13}, {supplier} et {rewrite}. Les URL catégorie, CMS, fabricant et fournisseur ont leurs propres jeux de placeholders. Le motif par défaut est conservateur : {rewrite}, minuscules activées, suppression des accents activée, nettoyage des caractères spéciaux activé et aucun suffixe.

Quand une URL générée entre en collision avec une autre URL en cache ou un override manuel, le module peut ajouter un suffixe basé sur l’ID d’entité, la référence/SKU, l’EAN13 ou un nombre incrémental. C’est plus sûr que bloquer une sauvegarde produit, car le produit peut encore être routé pendant que le doublon reste visible dans le workflow de régénération.

L’historique de redirection est créé lorsque les link rewrites changent, et les actions de suppression ou désactivation peuvent rediriger vers un parent, la page d’accueil ou renvoyer 410 Gone, selon le réglage par entité. Le routeur gère aussi les correspondances exactes de cache, overrides manuels, redirections d’historique, correspondances de motif et redirections legacy par préfixe ID, tout en préservant les query strings sur les redirections.

Lancez la régénération en masse avec son aperçu d’abord, examinez les changements proposés, et revérifiez vos URL principales dans Search Console avant d’appliquer. Si mprseorevolution est installé et activé, ce module est conçu pour lui céder la place par défaut afin que deux routeurs SEO URL ne se battent pas sur la même requête.

Oui. Filter Revolution rend les pages catégorie filtrées avec des URL propres et lisibles comme /category/color:blue/size:l au lieu de paramètres query-string bruts, afin que les combinaisons de filtres sélectionnées puissent être exposées comme landing pages crawlables et indexables. Lorsque le mode URL compacte est activé et qu’un slug de valeur est globalement unique, le module peut encore raccourcir le chemin en omettant le slug de groupe.

Il sépare navigation rapide et SEO indexable. Les acheteurs obtiennent une navigation à facettes AJAX qui met à jour les résultats sans recharger la page - sliders de prix, swatches de couleur, chips de taille, multi-sélection marque et arbres de catégories hiérarchiques. Pour les combinaisons qui méritent l’indexation, vous épinglez un jeu précis de facettes, lui donnez un slug d’URL propre, et rédigez son titre, sa meta description et son H1, afin que seules les pages à forte valeur entrent dans l’index.

La table de pages SEO stocke le contrôleur, l’ID catégorie, le chemin de facettes encodé, un hash de facettes normalisé, indicateurs active/indexable, meta title, meta description, segment d’URL, H1, descriptions hautes et basses, et une URL d’image optionnelle. La correspondance est indépendante de l’ordre, car les parties de facettes sont normalisées avant comparaison du hash, donc size:l/color:blue et color:blue/size:l se résolvent vers la même cible SEO.

Pour les pages filtrées ordinaires qui n’ont pas de page SEO personnalisée, les paramètres SEO décident si elles sont noindexées et si le canonical pointe vers le listing non filtré. Les liens de facettes profonds peuvent être marqués nofollow, et le blocage de chemins robots.txt est disponible mais désactivé par défaut afin que les moteurs de recherche puissent toujours crawler une URL filtrée et voir le signal noindex/canonical.

Les combinaisons de facettes à zéro produit peuvent être masquées ou grisées, gardant les pages minces et vides hors du crawl. Un index de facettes précalculé maintient les temps de réponse stables sur les grands catalogues, avec des tables produit, catégorie, attribut, caractéristique et agrégat utilisées pour un filtrage rapide. Le module plafonne aussi les valeurs products-per-page et prend en charge les contrôleurs de listing category, search, manufacturer, supplier, best-sales, new-products et prices-drop. Le module tourne sur PrestaShop 1.7.6 et versions actuelles.

Oui. Le module Facebook Pixel retient le tracking jusqu’à ce qu’un visiteur accorde son consentement marketing, afin que vous puissiez utiliser le Pixel sans le déclencher avant l’accord.

Activez le réglage Respect cookie consent et le module vérifie votre bannière de consentement avant le déclenchement de tout événement. Il lit le consentement depuis nos propres modules Cookies Revolution ou Cookie Banner - le pixel navigateur comme les événements page-load restent supprimés jusqu’à l’octroi de la catégorie marketing, puis ils se déclenchent normalement.

Le script navigateur utilise une porte de consentement côté client lorsqu’un module de consentement pris en charge est actif. Il vérifie window.MPRCR.isGranted('marketing') si disponible, se rabat sur le cookie mprcr_consent pour Cookies Revolution, puis sur mprcookie_consent pour la bannière légère. Il écoute aussi mprcr:consent et mprcookie:consent, donc un visiteur qui accepte les cookies marketing peut démarrer le tracking sans rechargement complet de page.

Une limite honnête à connaître : cette porte fonctionne avec un module de consentement pris en charge. Si vous n’avez pas accordé (ou refusé) le consentement via Cookies Revolution ou Cookie Banner, le module se rabat sur l’état de consentement par défaut de la bannière ; et si aucun module de consentement pris en charge n’est actif, le Pixel tracke normalement - il n’invente pas une couche de consentement par lui-même. Associez-le donc à une bannière si votre boutique a besoin d’une porte de consentement GDPR.

Le même contrôle de consentement couvre l’événement Conversions API Purchase côté serveur, donc un visiteur retenu n’est pas suivi par la porte de derrière non plus. CAPI ne met en file que lorsque le Pixel ID, le token d’accès et le tracking purchase sont configurés, et il utilise le même event ID généré que le purchase navigateur afin que Meta puisse dédupliquer les événements navigateur et serveur.

Le module possède aussi des garde-fous pratiques : le Pixel ID doit être numérique, les employés peuvent être exclus du tracking front-office, les événements standard peuvent être activés individuellement, et les événements navigateur personnalisés sont limités et validés afin de ne pas dupliquer les noms d’événements réservés de Meta.

Oui. Le module GA4 suit les événements ecommerce standard, dont les vues produit, ajout au panier, retrait du panier, vue panier, début de checkout et achat. Il prend aussi en charge des événements non ecommerce plus simples comme recherche, connexion et inscription, ainsi que des événements navigateur personnalisés configurés par règles.

Un événement purchase envoyé à GA4 utilise le modèle standard de payload ecommerce :

window.dataLayer.push({ 'ecommerce': null });
gtag('event', 'purchase', {
  transaction_id: 'PS-100012',
  value: 129.90,
  currency: 'EUR',
  items: [{
    item_id: '42-5',
    item_name: 'Shower tray 120x90',
    item_category: 'Shower trays',
    price: 64.95,
    quantity: 2
  }]
});

Le module construit le payload ecommerce côté serveur, l’assigne au template de hook, vide l’ancien objet ecommerce dans la couche de données, puis déclenche l’événement GA4. Pour les confirmations de commande, il peut aussi mettre en file un fallback purchase Measurement Protocol lorsque le Measurement ID et l’API Secret sont configurés, ce qui aide à préserver le tracking d’achat quand l’événement navigateur est bloqué ou interrompu.

Les hooks exacts sont séparés par étape de parcours : les pages produit émettent view_item, les pages panier émettent view_cart, les changements de quantité panier peuvent émettre add_to_cart ou remove_from_cart, les étapes transporteur/checkout émettent begin_checkout, et la confirmation de commande émet purchase. Connexion et inscription sont stockées comme événements navigateur pending one-time, puis consommées au chargement de page suivant.

Le tracking ne tourne que lorsque le module est activé et qu’un GA4 Measurement ID valide comme G-XXXXXXXXXX est présent. Il ignore les requêtes non front-office, bots connus, visiteurs avec le cookie mpr_notrack=1, et employés connectés lorsque l’exclusion employé est activée. Le suivi user ID optionnel hash l’ID client PrestaShop avec un salt par boutique avant de l’envoyer à GA4.

La gestion du consentement est aussi volontaire. Si Cookies Revolution est installé, le module positionne son hook header après le CMP afin que les valeurs par défaut de Consent Mode existent avant gtag('config'). Si aucun CMP n’est présent, il émet un bloc de fallback Consent Mode par défaut avec analytics et ad storage denied, afin que la page ait quand même une base claire.

Pour le meilleur reporting, assurez-vous que votre thème rend toujours les hooks produit, panier, checkout et confirmation de commande pertinents, puis testez les événements avec GA4 DebugView ou Tag Assistant après installation. Si vous activez les purchases Measurement Protocol, ajoutez un API Secret valide et gardez le worker cron partagé en cours d’exécution afin que les événements en file puissent être réessayés.

Le module Google Tag Manager pour PrestaShop pousse des événements ecommerce au format GA4 dans dataLayer, afin que les tags de votre conteneur GTM puissent lire des données boutique structurées sans modifier les templates du thème.

Le module émet côté navigateur des événements ecommerce incluant view_item, add_to_cart, remove_from_cart, view_cart, begin_checkout et purchase. Il prend aussi en charge des événements non ecommerce simples comme recherche, connexion et inscription, plus des règles dataLayer personnalisées configurables. Avant chaque événement ecommerce, il pousse {ecommerce: null}, qui est le schéma de réinitialisation sûr pour GA4.

window.dataLayer = window.dataLayer || [];
window.dataLayer.push({'ecommerce': null});
window.dataLayer.push({
  'event': 'purchase',
  'ecommerce': {
    'transaction_id': 'ABCDXYZ',
    'affiliation': 'Example Shop',
    'value': 129.90,
    'tax': 21.65,
    'shipping': 4.90,
    'currency': 'EUR',
    'coupon': 'WELCOME10',
    'items': [{
      'item_id': '42',
      'item_name': 'Premium Shower Tray',
      'item_brand': 'Example Brand',
      'item_category': 'Bathroom',
      'item_variant': '90x90',
      'price': 125.00,
      'quantity': 1
    }]
  }
});

Le script du conteneur GTM est injecté dans le header de la page, et l'iframe noscript est injectée après la balise body ouvrante lorsque le thème expose ce hook. La gestion Consent Mode est conçue pour fonctionner avec mprcookiesrevolution : lorsque cette CMP est installée, le module déplace son hook header après la CMP ; lorsqu'aucune CMP n'est présente, il peut émettre un fallback Consent Mode v2 refusé par défaut avant le chargement de GTM.

Le tracking est ignoré pour les requêtes non front, les bots connus, les employés connectés lorsque cette option est activée, et les visiteurs avec le cookie d'opt-out mpr_notrack=1. Le fallback serveur optionnel Measurement Protocol envoie les données d'achat sur actionValidateOrder lorsqu'un GA4 Measurement ID et un API Secret valides sont configurés ; GA4 déduplique via transaction_id.

Oui. TikTok Pixel propose le suivi navigateur (ttq.load + ttq.page) et l'envoi serveur via l'Events API dans une seule configuration, avec un event_id partagé pour que TikTok déduplique au lieu de compter deux fois. Les événements suivis incluent ViewContent, AddToCart, InitiateCheckout, PlaceAnOrder, CompletePayment, Search et Subscribe, avec un garde de consentement, l'exclusion automatique des employés connectés et un filtrage des IP de bureau par CIDR.

La même conception navigateur-plus-serveur équipe notre module Facebook Pixel pour PrestaShop : le pixel navigateur (fbq) et la Conversions API côté serveur se déclenchent avec un event_id partagé, de sorte que Meta déduplique les deux et que les conversions restent remontées même si un envoi navigateur est bloqué.

Le module Facebook Pixel suit ViewContent, AddToCart, AddToWishlist, InitiateCheckout, Purchase, Search, Lead et CompleteRegistration avec les champs content_ids, content_type, value et currency attendus par Meta. Un garde de consentement bloque le déclenchement jusqu'à ce que votre CMP signale le consentement marketing, les employés et les plages d'IP internes sont exclus, et un panneau d'intégrité vérifie l'enregistrement des hooks pour qu'un hook manquant ne casse pas l'attribution en silence.

Utilisez Hreflang Tags Manager dès que votre boutique PrestaShop a plus d’une langue, afin que les moteurs de recherche associent la bonne page à la bonne audience et cessent de servir l’anglais à des acheteurs français (ou l’inverse).

Pour chaque page, le module ajoute une balise <link rel="alternate" hreflang="..."> pour chaque langue active de cette page, avec un fallback x-default optionnel pour les visiteurs dont vous ne ciblez pas la langue. Il couvre produits, catégories, pages CMS, fabricants et page d’accueil, et reste discret sur les boutiques monolingues - si une seule langue est active, aucune balise n’est ajoutée.

La configuration par défaut est activée, x-default activé, et la langue x-default définie sur la langue par défaut de PrestaShop. La valeur de balise vient du language_code de chaque langue, et l’URL est générée via la classe Link de PrestaShop pour l’entité courante : produit, catégorie, CMS, fabricant ou fournisseur. Pour les autres pages cœur, le module tente getPageLink() et ignore l’alternate si PrestaShop ne peut pas construire cette route en sécurité.

Cela signifie que le module convient surtout aux entités PrestaShop traduites normales où chaque version linguistique existe déjà. Il ne vérifie pas si le nom produit traduit ou le contenu CMS est complet, et ne crée pas les traductions manquantes. Il émet seulement les liens alternate pour les langues actives de la boutique en utilisant le générateur d’URL propre à PrestaShop.

Une chose doit être claire : le module ne traduit pas votre contenu. Il indique seulement aux moteurs de recherche quelle version traduite d’une page existe déjà, en utilisant les langues configurées dans PrestaShop. Si votre catalogue est déjà multilingue mais que Google continue d’afficher la mauvaise langue dans les résultats, c’est la pièce qui corrige cela.