Ensemble SEO technique

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.

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.

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.

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": "1234567890128",
  "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 (types de données structurées). Activez le type manquant à cet endroit : Product Schema (produit), Organization Schema (organisation), WebSite Schema (site web), Breadcrumb Schema (fil d’Ariane), Category Schema (catégorie) ou CMS Article Schema (article CMS), 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 (supprimer le JSON-LD existant) dans le même onglet Schema Types (types de données structurées) 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.

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 peu étoffées 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 internaute ; 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 plusieurs liens vers des versions alternatives, 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 générateur 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 versions alternatives.

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 liens vers les versions alternatives dans le sitemap XML, et évitez noindex sur les pages censées participer au cluster hreflang.

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.

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.

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 les directives noindex et/ou nofollow sélectionnées 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 versions linguistiques correspondantes.

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 la laisser indexable tout en indiquant une URL canonique 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 groupes de liens vers les versions linguistiques en double 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.

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. 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.

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.

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.

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.

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.