design+code
L'essentiel du trafic perdu lors d'un changement de plateforme n'est pas perdu à cause de Shopify. Il est perdu à cause d'URL qui ont changé sans que personne ne note où elles sont parties. Voici la méthode que nous suivons quand nous migrons une boutique depuis WooCommerce, Squarespace ou PrestaShop, et les étapes où l'on se trompe facilement.
On nous demande régulièrement si Shopify se positionne moins bien que WooCommerce. Ce n'est pas le cas. Les moteurs de recherche indexent des pages, pas des interfaces d'administration. Ce qui se passe réellement lors d'une migration ratée est plus simple et plus banal : quelques centaines d'URL cessent d'exister, rien n'indique à Google où elles sont parties, et l'autorité que ces pages avaient accumulée au fil des années disparaît avec elles.
C'est tout le risque, et c'est un problème de gestion de projet avant d'être un problème technique. Si vous pouvez produire la liste complète de vos URL actuelles et une destination défendable pour chacune, une migration est en grande partie sans danger. Si vous ne le pouvez pas, aucune correction après le lancement ne permettra de tout récupérer.
Avant que quiconque ouvre Figma, nous crawlons le site existant et exportons toutes les URL qui renvoient un code 200. Ensuite, nous récupérons les douze derniers mois de Search Console et d'Analytics, et nous croisons les données. Le crawl vous dit ce qui existe. Search Console vous dit ce qui compte.
C'est cette seconde liste qui guide les décisions. Une boutique de 400 produits a souvent 30 ou 40 URL qui font l'essentiel du travail organique, et ce sont rarement les pages que le propriétaire imagine. Des fiches produit positionnées sur une requête de longue traîne, un vieil article de blog qui a récupéré des liens, une page catégorie positionnée sur un terme générique. Ce sont ces URL qu'il faut protéger à tout prix.
À ce stade, nous exportons aussi les balises title, les meta descriptions, les H1 et les textes alternatifs des images. C'est du contenu, quelqu'un l'a écrit, et le réécrire de zéro sur le nouveau site est du travail perdu.
C'est la plus grande différence avec WordPress, et ce qui surprend le plus ceux qui viennent de WooCommerce. Shopify impose ses propres préfixes de chemin : les produits sont sous /products/, les catégories sous /collections/, les pages statiques sous /pages/, et les articles sous /blogs/<blog-handle>/<article-handle>.
Une boutique WooCommerce avec /product/leather-tote/ et /product-category/bags/ ne peut donc pas garder ces chemins. Une boutique PrestaShop avec des identifiants numériques dans l'URL non plus, pas plus qu'une boutique Squarespace avec sa propre structure de pages boutique. Chaque URL de produit et de catégorie change. Ce n'est pas une erreur de migration, c'est la migration.
Ce que vous pouvez contrôler, c'est le handle, le dernier segment. Gardez-le identique à l'ancien slug partout où l'ancien slug était pertinent. Le plan de redirection reste lisible, et vous conservez la pertinence que l'URL apportait sur les mots-clés.
Un plan de redirection est un fichier à deux colonnes : ancienne URL, nouvelle URL. Pour l'essentiel du catalogue, vous pouvez le générer automatiquement à partir de l'export produits, en faisant correspondre les slugs. Pour les pages qui figurent dans la liste Search Console, faites-le à la main et vérifiez-les une par une.
Trois règles que nous ne transgressons pas. Chaque redirection est une 301, pas une 302. Chaque redirection pointe vers la page équivalente la plus proche, jamais vers la page d'accueil, car une redirection massive vers la page d'accueil est traitée comme une soft 404 et toute la valeur est perdue. Et aucune redirection ne pointe vers une URL elle-même redirigée, car les chaînes diluent la valeur et ralentissent tout.
Quand un produit n'existe vraiment plus, redirigez-le vers la collection à laquelle il appartenait. Quand une catégorie entière disparaît, redirigez-la vers son parent le plus proche. Quand il n'existe vraiment aucun équivalent, renvoyez une 410 plutôt qu'une 301 vers une page sans rapport.
Shopify accepte l'import groupé de redirections par fichier CSV : le plan peut donc être chargé en une seule opération le jour du lancement. Un piège à connaître à l'avance : l'outil de redirection de Shopify ne s'applique qu'aux chemins qui ne correspondent pas à une page existante de la boutique. Si un chemin est actif, la redirection qui le vise sera ignorée.
Les descriptions produit survivent généralement à une migration, parce qu'elles font partie de l'export produits. Les balises title et les meta descriptions, souvent non, car sur WooCommerce elles sont stockées dans des champs Yoast ou RankMath qu'aucun export standard ne récupère.
Exportez-les délibérément, puis reportez-les dans les champs SEO de Shopify pendant l'import. Si vous comptez les réécrire de toute façon, très bien, mais faites-le volontairement plutôt que de découvrir trois semaines après le lancement que 300 produits utilisent tous le modèle de titre par défaut du thème.
Il en va de même pour les textes alternatifs des images, qui sont un vrai facteur de positionnement dans la recherche d'images pour une boutique de mode ou centrée sur le produit, et qui disparaissent presque toujours lors d'un import CSV.
Shopify génère et tient à jour automatiquement le sitemap.xml, et place des balises canoniques sur les fiches produit pour que /collections/bags/products/leather-tote pointe vers /products/leather-tote. Cela règle un problème de contenu dupliqué avec lequel les sites WooCommerce se débattent souvent. Vous pouvez aussi désormais modifier le robots.txt via robots.txt.liquid, ce qui n'a pas été possible pendant des années.
Ce qui n'est pas géré pour vous, ce sont les données structurées. La plupart des thèmes incluent un balisage Product, dont la qualité va de correcte à cassée. Avant le lancement, passez les principaux modèles de page dans un validateur et vérifiez que le prix, la disponibilité, la marque et les avis sont bien balisés, et correctement. Les résultats enrichis sur les fiches produit valent plus que l'essentiel du travail on-page sur lequel on passe du temps.
La navigation à facettes est l'autre sujet qui demande une décision. Les URL de collections filtrées peuvent générer un grand nombre de pages pauvres et quasi dupliquées. Décidez quelles combinaisons de filtres méritent d'être indexables, et bloquez les autres.
Nous lançons, puis nous vérifions immédiatement une courte liste de points : le fichier de redirections est actif et un échantillon de dix anciennes URL mène bien à la bonne destination, le robots.txt ne bloque pas la boutique, le sitemap est soumis dans Search Console, les balises d'analyse se déclenchent, et aucun modèle ne garde un noindex hérité de l'environnement de préproduction. Ce dernier point a piégé plus de sites que n'importe quelle autre erreur.
Ensuite, il faut attendre et observer. Attendez-vous à une baisse. Les positions bougent généralement pendant deux à quatre semaines, le temps que Google recrawle et réévalue les nouvelles URL, et une baisse temporaire ne prouve pas que quelque chose est cassé. Pendant cette période, ce que vous surveillez, c'est le rapport de couverture et le journal des 404, pas la courbe de trafic. Un nombre de 404 qui augmente signale un trou dans le plan de redirection, et cela se corrige en un après-midi. Un trafic qui n'est pas revenu au bout de six à huit semaines, avec un journal des 404 propre, signale un problème structurel à investiguer.
Nous conservons l'export du crawl de l'ancien site pendant au moins trois mois, parce que le moyen le plus rapide de diagnostiquer une page manquante est de vérifier ce qui s'y trouvait avant.
Sur un catalogue de quelques centaines de produits, le travail SEO d'une migration représente environ un à deux jours : le crawl et l'export, le plan de redirection, la reprise des métadonnées, les vérifications avant lancement. Ce n'est pas la partie coûteuse du projet. C'est simplement la partie invisible quand elle est bien faite, et très visible quand elle est oubliée.
Si vous envisagez de passer à Shopify et voulez un second avis sur la structure d'URL avant de vous lancer, écrivez-nous à bonjour@dellamattia.com.