Migration Sylius 2 et SEO : garder ses positions

Non, la migration vers Sylius 2 ne fait pas perdre le référencement à elle seule : les adresses publiques des fiches produits et des catégories sont les mêmes en 1.14 et en 2.x, et les slugs restent en base. Les pertes viennent de ce que le chantier casse au passage : balises et données structurées logées dans des gabarits réécrits, plugins SEO non portés, redirections oubliées, pages plus lentes. Un relevé complet avant la bascule et une comparaison méthodique après, dans la Search Console, suffisent à garder vos positions.

Qu'est-ce qui change vraiment pour Google quand on passe à Sylius 2 ?

Commençons par la bonne nouvelle. Dans le cœur de Sylius 2, la fiche produit répond toujours sur /products/{slug} et la liste d'une catégorie sur /taxons/{slug}, comme en 1.14. Vous pouvez le vérifier dans le fichier de routage de la boutique. Le préfixe de langue /{_locale} reste lui aussi un choix de configuration de votre projet.

Les dizaines de routes supprimées listées dans le guide officiel UPGRADE-2.0 sont des routes d'administration, des appels Ajax et des routes « partielles » de la boutique, remplacées par des composants Twig. Google ne les indexe pas en temps normal. Vérifiez quand même qu'aucune n'apparaît dans vos rapports d'indexation : certaines boutiques en exposaient une par erreur, dans un lien ou un sitemap.

Les slugs sont stockés dans les traductions des produits et des catégories. Une montée de version ne les touche pas. Le danger apparaît quand on profite du chantier pour réimporter le catalogue ou régénérer les slugs : la gestion des accents, des doublons et des suffixes peut produire des adresses différentes, et chaque adresse différente est une page que Google doit redécouvrir.

Pourquoi les balises et les données structurées disparaissent-elles ?

Parce qu'elles vivent presque toujours dans votre code, pas dans celui de Sylius. En 1.14, le bloc metatags du gabarit principal de la boutique est vide par défaut. La meta description, la balise canonical, les hreflang et le JSON-LD Product ont été ajoutés par votre prestataire, dans des gabarits surchargés ou via les template events.

Or Sylius 2 supprime les template events et Sonata Block, et réécrit toute la boutique sur Twig Hooks. Un gabarit surchargé pour la 1.x n'est plus appelé. Un bloc branché sur un ancien événement ne s'affiche plus. Et rien ne plante : la page s'affiche, elle a simplement perdu sa description et ses données structurées. C'est l'erreur SEO la plus fréquente sur ce type de chantier, parce qu'aucun test fonctionnel ne la détecte.

Les champs existent toujours : la traduction d'un produit garde sa meta description en Sylius 2. Il faut donc reporter l'affichage dans le hook #metatags du nouveau gabarit, puis repasser chaque type de page (accueil, catégorie, produit, contenu) dans le test des résultats enrichis de Google. Le fonctionnement des hooks est détaillé dans mon guide pratique des Twig Hooks.

Les plugins SEO, sitemap et redirections

Beaucoup de boutiques 1.x confient leur sitemap, leurs balises ou leurs redirections à un plugin. Si ce plugin n'a pas de version compatible Sylius 2, il faut le remplacer avant la bascule, pas après. Le cas le plus dangereux est le plugin de redirections : s'il disparaît, toutes les 301 accumulées depuis des années disparaissent avec lui, et les liens externes vers vos anciennes pages tombent en 404. Sylius Upgrade Analyzer vérifie chaque plugin installé contre le Sylius Store et Packagist, ce qui donne cette liste en quelques minutes.

Quelles redirections prévoir, et quand sont-elles inutiles ?

Si vos URL ne changent pas, il ne faut aucune nouvelle redirection. En ajouter « par sécurité » crée des chaînes et des boucles, pas de la sécurité. Les redirections deviennent nécessaires dans quatre cas précis : vous changez la stratégie de préfixe de langue, vous régénérez des slugs, vous restructurez l'arbre des catégories, ou vous changez de domaine en même temps. Mon conseil est de ne pas cumuler : une montée de version d'un côté, une refonte de l'arborescence de l'autre, à quelques semaines d'écart.

Dans tous les cas, exportez la table de vos redirections existantes, qu'elles soient en base, dans un plugin ou dans la configuration du serveur, et rejouez-la sur la préproduction. Google recommande des redirections permanentes côté serveur et déconseille les chaînes : une ancienne URL doit pointer directement vers sa destination finale.

Le passage à Bootstrap rend-il la boutique plus rapide ?

Pas automatiquement. Sylius 2 remplace Semantic UI et jQuery par Bootstrap 5 et Symfony UX. Sur le papier, le socle est plus moderne. En pratique, tout dépend de ce que vous faites du thème. Si vous reconstruisez un front propre sur le nouveau socle, les gains sont possibles. Si vous recopiez l'ancien design avec une couche de CSS supplémentaire, ou si vous chargez encore des scripts hérités, vous pouvez finir plus lourd qu'avant.

Les Core Web Vitals (LCP pour l'affichage, INP pour la réactivité, CLS pour la stabilité visuelle) font partie des signaux d'expérience de page. Deux pièges reviennent souvent sur un front réécrit : des images sans dimensions déclarées, qui font sauter la mise en page, et des composants dynamiques comme le panier qui ajoutent des requêtes au chargement. Mesurez les pages clés en préproduction, sur mobile, avant la bascule. Le détail technique du nouveau front est dans mon article sur la migration Bootstrap et Stimulus.

Comment contrôler avant et après dans la Search Console ?

La méthode tient en trois temps, et le premier est le plus important : on ne peut comparer que ce qu'on a relevé.

Le contrôle du jour J évite le classique : une préproduction en noindex dont la configuration part en production. Ensuite, lisez les chiffres par type de page. Une légère fluctuation globale dans les premiers jours est normale. Une baisse concentrée sur les fiches produits, elle, désigne presque toujours un gabarit : balise manquante, données structurées cassées ou canonical erroné. Le rapport Core Web Vitals s'appuie sur des données terrain collectées sur plusieurs semaines, ne concluez donc pas sur la vitesse dès le lendemain.

Ce que mon outil vérifie, et ce qu'il ne vérifie pas

Sylius Upgrade Analyzer lit votre code. Il repère les template events et les gabarits surchargés à réécrire, les routes supprimées encore appelées et les plugins sans version 2. Autrement dit, il désigne les endroits où vos balises risquent de disparaître. Il ne crawle pas votre site et ne connaît pas vos positions : le contrôle SEO reste un crawl comparé et une lecture de la Search Console. Les deux se complètent.

J'ai déjà mené des montées de version Sylius 1.x vers 2.x de boutiques en production pour mes clients, et ce relevé avant et après fait partie de chaque chantier, au même titre que la bascule sans coupure. Sylius 1.14 ne reçoit plus de correctifs de sécurité après le 31 décembre 2026 : mieux vaut préparer ce relevé maintenant que dans l'urgence. Si vous voulez savoir où se trouvent les risques SEO de votre propre boutique, demandez le diagnostic offert de migration Sylius 2 : je passe votre projet à l'analyseur et je vous dis précisément quels gabarits, plugins et redirections demandent de l'attention.