SEO multilingue PrestaShop : Ce que la boutique fait pour vous, et ses limites

Il existe une croyance répandue chez les marchands PrestaShop : l'ajout d'une langue serait une décision SEO. C'est faux. L'ajout d'une langue est une décision de contenu. La partie SEO se fait d'elle-même, mais uniquement si les traductions sont situées là où PrestaShop les attend.

Cette condition unique explique la majeure partie de la différence entre une boutique multilingue qui se positionne sur ses nouveaux marchés et une autre qui possède des pages traduites que personne ne trouve.

Ce que PrestaShop génère nativement

C'est la partie qui surprend ceux qui arrivent de WordPress, où chacun de ces éléments nécessite un plugin.

Une fois qu'une langue est activée et que votre contenu est traduit dans les tables de langue, PrestaShop produit lui-même les annotations hreflang, les balises canonical, les URLs spécifiques à la langue et les entrées du sitemap. Le sélecteur de langue du thème redirige vers la page équivalente plutôt que d'envoyer les visiteurs sur la page d'accueil. Les données structurées suivent la langue active.

La couche SEO multilingue n'est donc pas quelque chose que vous installez. C'est quelque chose que vous alimentez.

Cela signifie que le mode de défaillance n'est pas « mon plugin SEO est mal configuré », mais plutôt « les lignes sont vides, donc la boutique déclare correctement que cette page n'a pas de version allemande ».

La question des hreflang, résolue

Les balises hreflang indiquent aux moteurs de recherche que deux URLs sont la même page dans des langues différentes, afin que la bonne version soit servie au bon public au lieu que les deux se fassent concurrence.

PrestaShop les émet automatiquement pour chaque langue active, en utilisant l'URL de boutique configurée pour chacune. Trois facteurs peuvent les briser, tous liés à la configuration plutôt qu'à la traduction :

Des URLs de boutique qui ne correspondent pas à la réalité. Si vous servez la boutique en HTTPS mais que l'URL de boutique indique encore HTTP, ou si une langue est mappée sur un domaine que vous n'utilisez plus, les annotations pointent vers des adresses qui redirigent ou échouent. Vérifiez dans Préférences, puis SEO et URLs.

Des langues laissées actives mais vides. Une langue active sans contenu traduit est quand même déclarée. Les moteurs de recherche trouvent alors une page qui est principalement dans la langue source, décident qu'il s'agit d'un contenu dupliqué, et vos bonnes pages héritent du doute. Désactivez une langue que vous n'êtes pas prêt à servir.

Une page qui n'existe que dans une seule langue. C'est légitime, et PrestaShop le gère, mais cela signifie que le sélecteur de langue ne mènera nulle part d'utile pour cette page. Décidez délibérément quelles pages sont spécifiques à une langue plutôt que de le découvrir dans vos logs.

Vous n'avez pas besoin d'un plugin hreflang. Vous avez besoin que les URLs de boutique soient correctes et que les tables soient remplies.

URLs traduites, et le cas du vrai 404

PrestaShop stocke un link_rewrite par langue pour les produits, catégories et pages CMS, et un url_rewrite pour les pages meta statiques. Les traduire est bon pour le SEO : un acheteur français a plus confiance en /femmes/robes-ete qu'en /3-summer-dresses, et les mots présents dans l'URL restent un signal de classement sur la plupart des marchés.

Le risque n'est pas uniformément réparti, et il est utile de le savoir avant de toucher à quoi que ce soit sur une boutique en production.

Les routes PrestaShop par défaut incluent l'ID de l'objet : /3-clothes, /hommes/1-1-shirt.html, /content/1-delivery. Le front controller lit l'ID, remarque que la réécriture ne correspond plus et redirige vers l'adresse actuelle. Changer la réécriture d'un produit ou d'une catégorie ne casse donc pas l'ancien lien.

Les pages statiques sont l'exception. Leurs réécritures ne contiennent aucun ID, donc en traduire une transforme l'ancienne adresse en un vrai 404. Ce sont précisément les pages qui collectent les backlinks : livraison, retours, contact, conditions générales. Traduisez-les en ayant déjà mis en place des redirections, pas après.

Si vous avez migré depuis une autre configuration multilingue, c'est aussi là que les anciennes adresses disparaissent, et c'est la cause la plus fréquente de perte de trafic après une migration multilingue.

Les métadonnées que personne ne traduit jusqu'à ce que cela fasse mal

Vos descriptions de produits reçoivent de l'attention car elles sont visibles. Les champs qui décident si quelqu'un verra la page, eux, sont souvent ignorés.

Meta titres et meta descriptions par langue. Une page produit allemande avec un meta titre français sera réécrite par Google, rarement en votre faveur.

Descriptions de catégories. Sur la plupart des boutiques, ce sont ces pages qui se positionnent sur les requêtes commerciales larges, et elles sont le plus souvent laissées dans la langue source parce que personne ne scrolle aussi bas dans le back office.

Attribut alt des images. Il a du poids dans la recherche d'images, qui est un véritable canal d'acquisition pour les produits physiques, et c'est le champ que les projets de traduction ignorent le plus systématiquement.

Valeurs de la recherche à facettes, si vous l'utilisez. Les combinaisons de filtres génèrent des pages indexables, et une page de filtre française listant des valeurs d'attribut allemandes ne sera pas lue comme une page française.

Le sitemap n'est pas le problème que l'on croit

Le sitemap d'une boutique traduite doit lister chaque version linguistique de chaque page. PrestaShop et les modules de sitemap habituels le font correctement une fois que les traductions existent.

Le problème vient du timing. Le sitemap est généré à la demande ou selon un planning, donc une boutique traduite le mardi peut encore annoncer son sitemap monolingue le vendredi. Régénérez-le après une session de traduction, et vérifiez que les versions linguistiques y figurent réellement au lieu de le supposer.

Le second échec est le cache en amont de la boutique. Si vous utilisez un cache pleine page ou un CDN, un vieux sitemap ou un ancien jeu de balises hreflang peut survivre bien après la modification. Lorsque quelque chose semble incorrect, demandez la page avec une chaîne de requête pour contourner le cache avant de conclure que la boutique est en tort. C'est le moyen le plus rapide de distinguer un vrai bug d'une copie obsolète.

Ce qui améliore réellement le positionnement sur un nouveau marché

Une fois que la mécanique est en place, le reste du travail est éditorial, et c'est là que la traduction automatique fait ses preuves ou échoue.

Les requêtes de recherche ne sont pas des traductions les unes des autres. Un acheteur allemand ne recherche pas la traduction littérale de ce qu'un acheteur français recherche. Les titres traduits sont un point de départ, pas une stratégie de mots-clés : vérifiez les termes que vos concurrents sur ce marché utilisent réellement, et ajustez la poignée de pages qui comptent.

Le contenu de confiance compte encore plus à l'étranger. Délais de livraison, politique de retour, méthodes de paiement locales, gestion de la TVA. Ces pages convertissent et gagnent aussi des liens, c'est pourquoi les laisser dans la langue source coûte doublement cher.

Et la cohérence du vocabulaire. Un catalogue où la même famille de produits est nommée de trois façons différentes à travers les catégories dilue chaque page qui la mentionne. Il s'agit d'un problème de glossaire plutôt que d'un problème de traduction.

Un court audit que vous pouvez effectuer aujourd'hui

1. Ouvrez une page produit dans chaque langue et affichez la source. Confirmez qu'il y a une ligne hreflang par langue active, plus x-default, pointant toutes vers des URLs accessibles.
2. Désactivez toute langue dont le catalogue est encore vide.
3. Listez vos pages statiques et vérifiez si leurs URLs ont changé. Chaque changement nécessite une redirection depuis l'ancienne adresse.
4. Triez vos catégories par trafic et vérifiez le top dix pour le meta titre, la meta description et la description traduite.
5. Régénérez le sitemap et ouvrez-le. Comptez les langues.
6. Recherchez l'un de vos noms de produits dans un moteur de recherche du marché cible, dans une fenêtre privée. Les résultats vous en diront plus que n'importe quel outil d'audit.

La mécanique est le travail de PrestaShop, et il le fait bien. Remplir les tables et choisir quoi dire sur chaque marché est le vôtre. Le module TrueLang existe pour la première partie de cette phrase : il écrit le catalogue, les pages CMS, les champs meta et les réécritures d'URL dans les propres tables de la boutique, afin que la couche SEO que PrestaShop sait déjà construire ait de quoi travailler.