Adobe Commerce et Magento

 Le référencement naturel (SEO) sur Magento consiste à rendre une boutique Magento ou Adobe Commerce explorable, indexable et suffisamment rapide pour que Google la récompense. La majeure partie de ce travail repose sur la configuration de la plateforme plutôt que sur le contenu. Magento génère des URL en double via sa navigation par couches, fournit des métadonnées par défaut qui ne s’adaptent pas à plus de quelques centaines de produits, et affiche souvent de mauvaises performances sur les Core Web Vitals sans mise en cache dédiée. C’est en considérant ces problèmes comme des problèmes de contenu que tant de boutiques stagnent après leur dixième article de blog.

Nous avons audité suffisamment de boutiques Adobe Commerce et Magento Open Source pour constater que le même schéma se répète. Un commerçant suit toutes les consignes relatives au contenu, publie des textes cohérents, et voit pourtant un concurrent utilisant une plateforme plus simple le devancer dans les classements. La différence réside rarement dans la qualité du contenu. Il s’agit généralement d’une navigation à plusieurs niveaux générant des milliers de pages dupliquées indexables, d’un fichier robots.txt bloquant les mauvaises ressources, ou d’un thème incapable de faire passer le « Largest Contentful Paint » sous la barre des 2,5 secondes.

Pourquoi le référencement naturel (SEO) sur Magento relève-t-il davantage d'un problème technique que d'un problème de contenu ?

La plupart des conseils en référencement partent du principe que la plateforme se comporte de manière prévisible : une URL par page, des métadonnées contrôlées par l'éditeur et une vitesse de chargement raisonnable par défaut. Magento nécessite une supervision technique plus poussée en matière de référencement. Selon sa configuration, il peut générer plusieurs URL pour un même contenu de catalogue, utiliser des métadonnées générées automatiquement et produire d'importants volumes de données de réécriture d'URL à mesure que les catalogues s'étoffent.

C'est important, car une stratégie de contenu ne peut pas résoudre un problème de budget d'exploration. Si Googlebot consacre son budget à explorer des combinaisons de catégories filtrées qui ne seront jamais référencées, il lui reste moins de budget pour les pages de produits et de catégories qui génèrent réellement du chiffre d'affaires. C'est pourquoi notre approche du référencement naturel (SEO) sur Magento commence toujours par une exploration, et non par un audit de contenu.

Comment la navigation par niveaux génère-t-elle des milliers d'URL en double ?

La navigation par niveaux correspond à la barre latérale de filtres présente sur les pages de catégories ; elle constitue une source majeure de contenu dupliqué sur une boutique Magento. Prenons une catégorie, « Chemises pour femmes », qui comporte 4 attributs filtrables : couleur, taille, matière et marque. Si la couleur propose 6 options, la taille 5, la matière 4 et la marque 8, cette seule catégorie peut générer près de 960 combinaisons de filtres uniques, chacune disposant de sa propre URL indexable, par exemple :

https://store.com/womens-shirts.html?color=blue&size=medium&material=cotton&brand=acme

Aucune de ces 960 pages n'apporte à un moteur de recherche quoi que ce soit que la page de catégorie de base ne fournisse pas déjà. Il s'agit des mêmes produits, simplement réorganisés. C'est exactement le schéma qui ressort d'une analyse SEO de Magento : une poignée de véritables pages de catégorie entourées de milliers d'URL de filtres quasi-dupliquées qui se disputent les mêmes classements.

Lorsque nous effectuons un audit SEO sur Magento, la navigation par niveaux est généralement le premier élément que nous vérifions, car c’est le moyen le plus rapide de déterminer si une boutique gaspille son budget d’exploration. La solution ne consiste pas à désactiver la navigation par niveaux, car les clients s’y fient. Elle consiste plutôt à utiliser des balises canoniques redirigeant chaque variante filtrée vers la page de catégorie de base, en combinaison avec des règles dans le fichier robots.txt qui empêchent complètement Googlebot d’explorer les paramètres de filtrage.

Si ce problème n'est pas résolu, cela peut rapidement nuire aux performances SEO de Magento sur un catalogue par ailleurs en bon état, car Google continue de découvrir de nouvelles URL plus vite qu'il ne parvient à indexer celles qui comptent.

Pourquoi les métadonnées par défaut ne fonctionnent-elles plus à l'échelle du catalogue ?

Le modèle de métadonnées par défaut de Magento fonctionne bien pour un catalogue de 40 produits, mais ne tient plus la route à partir de 4 000. Le modèle prêt à l'emploi reproduit la même structure de titre sur toutes les pages, ce qui signifie que les moteurs de recherche voient des milliers de balises de titre qui ne diffèrent que par le nom du produit. Il ne s'agit pas de contenu dupliqué au sens strict du terme, mais cela ne donne guère à Google d'éléments pour différencier la pertinence d'une page par rapport à une autre.

La solution consiste en une approche par modèles, élaborée à partir des attributs des produits déjà présents dans le catalogue : marque, catégorie, matière et gamme de prix. Ainsi, les métadonnées varient de manière pertinente sans qu’un rédacteur ait à intervenir sur chaque page. Un titre tel que « Acheter [Nom du produit] de [Marque] | [Catégorie] | Livraison gratuite » utilise les données déjà stockées par Magento. Les pages de catégories doivent être traitées de la même manière, en s’appuyant sur l’ensemble d’attributs propre à chaque catégorie plutôt que sur un modèle global unique.

Bien maîtriser cet aspect est l'un des éléments les plus souvent négligés du référencement naturel (SEO) sur Magento, car même si cela ressemble à première vue à une tâche liée au contenu, il s'agit en réalité d'un exercice portant sur les données et les modèles.

Les Core Web Vitals sur Magento : quels sont les facteurs qui influencent réellement ces chiffres ?

On a tendance à considérer les « Core Web Vitals » comme l'ensemble du référencement technique, ce qui n'est pas le cas, mais c'est pourtant là que les boutiques Magento perdent le plus de terrain. Le thème Luma n'a jamais été conçu en accordant la priorité aux performances, et le temps de chargement du premier élément visible (Largest Contentful Paint) sur une installation Luma par défaut dépasse régulièrement quelques secondes sur les pages produits, principalement parce que RequireJS charge le JavaScript selon un modèle en cascade avant que la page ne puisse afficher quoi que ce soit d'utile.

Certaines interventions ont un impact sur les chiffres. D’autres sont constamment recommandées, mais n’ont pratiquement aucun effet. Ce qui fonctionne réellement :

1. Le passage de Luma à Hyvä, qui supprime complètement RequireJS au profit d'Alpine.js et de Tailwind, permet de réduire considérablement la taille du code JavaScript sur les boutiques fonctionnant sous Magento 2.4.7.
2. Varnish n'est pas une fonctionnalité du type « activez-la et n'y pensez plus ». Une configuration adéquate est essentielle pour tirer pleinement parti des gains de performances offerts par la mise en cache de pages entières. Adobe recommande vivement l'utilisation de Varnish en production, soulignant que la mise en cache de pages entières intégrée est nettement plus lente.
3. Proposer des formats d'image de nouvelle génération aux dimensions adaptées, plutôt que de compter sur le navigateur pour réduire les originaux en pleine résolution.
4. Migration de la recherche dans le catalogue vers Elasticsearch, ce qui réduit la charge pesant sur la base de données au niveau des pages de catégories et de recherche, et améliore le temps de réponse sur l'ensemble du site.

Ce qui n'améliore pratiquement pas les performances : une extension « de performance » qui ajoute son propre code JavaScript à un thème déjà surchargé, qui minifie le JavaScript et le CSS dans l'interface d'administration sans s'attaquer à la structure en cascade de RequireJS sous-jacente, et qui ajoute un CDN devant un site qui comporte toujours des ressources bloquant le rendu. Un CDN accélère la diffusion, pas le rendu.

Les paramètres SEO de Magento 2 que la plupart des boutiques en ligne ne configurent jamais

Tous les paramètres SEO de Magento 2 qui comptent le plus sont enfouis à trois niveaux de menu dans l'interface d'administration, sous Boutiques > Configuration > Catalogue > Optimisation pour les moteurs de recherche, et la plupart des commerçants n'ouvrent jamais cet écran après la configuration initiale. Quelques boutons d'activation/désactivation suffisent à déterminer si, par défaut, la plateforme favorise ou nuit aux performances en référencement naturel.

Voici les 6 paramètres que nous vérifions en premier lieu pour chaque boutique :

1. Utilisez la fonction « Réécriture du serveur Web », accessible sous Boutiques > Configuration > Général > Web, qui permet de déterminer si les URL sont lisibles ou non.
2. Utilisez l'option « Chemin d'accès aux catégories » pour les URL des produits, qui détermine si l'URL d'un produit reflète la structure de ses catégories.
3. Créer une redirection permanente pour les URL en cas de modification de la clé d'URL, ce qui évite les liens rompus chaque fois que le nom d'un produit change.
4. Utilisez la balise méta « Canonical Link » pour les catégories ; elle est désactivée par défaut et est directement à l'origine du problème de contenu dupliqué évoqué plus haut.
5. Utilisez la balise meta « canonical » pour les produits, qui correspond à ce paramètre pour les pages produit.
6. Le modèle par défaut du fichier robots.txt, qui reflète souvent encore des règles écrites pour une ancienne version de la plateforme et qui est rarement revu après une mise à jour.

La plupart des paramètres SEO de Magento 2 ne prennent que quelques minutes à modifier une fois qu’on sait où les trouver. Le plus difficile est de savoir lesquels sont importants, car Magento ne les met pas en évidence dans le tableau de bord d’administration.

Si votre boutique n'a pas été mise à jour depuis plusieurs versions majeures, certains de ces paramètres peuvent ne pas encore exister dans votre version. Il s'agit là d'un sujet que nous abordons généralement dans le cadre de notre service de mise à jour Magento, plutôt que comme une intervention ponctuelle. Rien de tout cela n'a de particulier. Cela s'apparente davantage à une maintenance de routine, mais cette tâche est souvent négligée car, au sein de l'équipe d'un commerçant, il est rare qu'une personne soit clairement désignée comme responsable du référencement Magento.

Données structurées pour les pages de produits et de catégories Magento

Magento Open Source fournit d'emblée des données structurées de base, mais les pages de produits peuvent nécessiter une mise en œuvre supplémentaire pour prendre pleinement en charge les propriétés permettant de les rendre éligibles aux résultats enrichis dans les recherches. Une page de produit doit inclure le balisage Schema.org « Product » avec les propriétés pertinentes telles que le nom, la référence (SKU), la marque, l'image, ainsi qu'un objet « offering » couvrant le prix, la devise et la disponibilité. Un balisage « aggregateRating » valide peut également rendre un produit éligible aux extraits d'avis affichant des notes sous forme d'étoiles dans la recherche Google.

Les pages de catégories tirent parti du balisage « ItemList » ou « BreadcrumbList », qui aide les moteurs de recherche et les moteurs de réponse basés sur l'IA à comprendre comment une page s'intègre dans la structure du site. Cela revêt autant d'importance pour la manière dont les « aperçus IA » résument une page que pour les classements organiques classiques, car ces deux systèmes s'appuient sur des signaux explicites plutôt que de déduire le contexte à partir du texte.

Dans chaque projet de référencement Magento, nous considérons les données structurées comme un élément incontournable de notre liste de contrôle, et non comme une amélioration à envisager ultérieurement, car il s'agit de l'une des mesures les moins coûteuses de toute cette liste par rapport à la visibilité qu'elle apporte.

Référencement naturel (SEO) Magento pour les boutiques multi-sites et internationales

Le référencement naturel (SEO) d'Adobe Commerce dans le cadre d'une configuration multi-boutiques soulève un problème qui n'existe pas dans le cas d'une installation mono-boutique : la concurrence entre les vues de boutique. Un commerçant qui gère des vues de boutique distinctes pour le Canada et les États-Unis, toutes deux en anglais, risque de voir Google classer la page du mauvais pays pour un internaute donné, ou que les deux vues de boutique se cannibalisent mutuellement en termes de classement.

C'est là que le référencement naturel (SEO) d'Adobe Commerce devient véritablement complexe, car l'architecture multi-boutiques de Magento ne génère pas automatiquement de balises hreflang entre les différentes vues de boutique. Chaque vue de boutique doit comporter des éléments de lien hreflang renvoyant vers toutes les autres versions de cette page, ce qui doit être validé à l'aide d'un outil d'exploration tel que Screaming Frog.

Que doit inclure un audit SEO Magento ?

Un audit SEO Magento digne de ce nom va bien au-delà d'une simple analyse par plugin ou d'une liste de contrôle générique conçue pour un autre CMS. Il nécessite une simulation complète de l'exploration du site à l'aide d'un outil tel que Screaming Frog, croisée avec les données de Google Search Console concernant la couverture, l'indexation et les Core Web Vitals.

Voici les 7 domaines couverts par chaque audit SEO Magento que nous réalisons :

1. Simulation d'exploration et taux d'indexation : comparaison entre les pages générées et celles effectivement indexées
2. Mise en œuvre des balises « canonical » pour les catégories, les produits et les URL paginées
3. Précision du fichier robots.txt et du plan du site XML
4. Configuration de la navigation par niveaux et gestion des paramètres de filtrage
5. Validation des données structurées pour les modèles de produits et de catégories
6. Référence des Core Web Vitals par modèle de page, et non une moyenne unique à l'échelle du site
7. Configuration multi-boutiques et hreflang, le cas échéant

Par où commencer si votre boutique n'a jamais fait l'objet d'un audit technique de référencement naturel

Certains problèmes de référencement sur Magento sont moins coûteux à résoudre qu’à contourner, tandis que d’autres relèvent du cas contraire. Si une boutique fonctionnant sous une ancienne version de Magento Open Source compte moins de quelques milliers de références et que les principaux problèmes concernent la navigation par couches et les métadonnées, un projet technique ciblé permet généralement de les résoudre plus rapidement qu’un changement de plateforme.

Si le site utilise une base de code fortement personnalisée, datant de plusieurs années, présentant des problèmes de performances inhérents à ses modules personnalisés, et que l'entreprise envisage déjà de changer de plateforme, il est souvent plus économique de résoudre ce problème en changeant de plateforme plutôt qu'en appliquant des correctifs à une infrastructure qui n'a jamais été conçue pour supporter son trafic actuel. C'est l'audit lui-même qui permet de déterminer quelle situation s'applique. Il vous indique s'il s'agit d'un simple travail de configuration ou d'une refonte structurelle avant que vous n'engagiez un budget dans l'une ou l'autre de ces solutions.

Pour les équipes qui ont déjà compris cela et qui ont simplement besoin de mettre ces mesures en œuvre, c'est là que les services de référencement Magento prennent tout leur sens. Les corrections mentionnées ci-dessus nécessitent une expérience en développement Magento, et non une expérience générale en référencement.

Une agence de référencement générique vous dira que la navigation par niveaux pose problème. Mettre en œuvre la solution sans perturber le processus de paiement ni la recherche dans le catalogue relève d'un autre type de compétences, qui se rapproche davantage de ce que nos services de référencement Magento couvrent au quotidien.

Si vous souhaitez avoir une vision plus claire de la situation de votre boutique, la prochaine étape logique consiste à effectuer un audit technique et une analyse via Search Console, et non pas à procéder à une nouvelle série de modifications de contenu. Nous proposons cette prestation sous forme de mission autonome aux boutiques qui souhaitent disposer des résultats avant de décider de la suite à donner.

Assistance