Mes formules vont de 900 € pour un cadrage sur un petit catalogue ou une bascule déjà préparée, à 2 500 € pour une migration complète avec correspondance exhaustive, recette et suivi, et 4 500 € pour une migration avancée avec analyse de logs, multilingue, multiboutique ou changement de CMS. Le budget dépend de trois facteurs : l'écart entre votre version de départ et votre cible, le volume d'adresses à cartographier, et la durée du suivi après la bascule. Le devis est établi après un échange de cadrage.

Trois éléments suffisent : votre version actuelle de PrestaShop et votre cible, qu'il s'agisse d'une nouvelle version majeure ou d'un autre CMS ; la taille réelle de votre catalogue en produits, déclinaisons, catégories, pages CMS et articles ; et l'état d'avancement du projet, de la simple réflexion à la bascule déjà effectuée. Ajoutez si possible les accès à la Search Console et à votre outil d'analyse d'audience, la liste de vos modules principaux et l'historique des refontes précédentes, qui explique souvent les chaînes de redirection déjà en place.

Oui, dans la grande majorité des montées de version majeures. Par défaut, PrestaShop construit ses adresses de produits et de catégories à partir d'un identifiant numérique interne. Quand le catalogue est réimporté dans une base neuve, ces identifiants sont réattribués dans l'ordre de l'import, ce qui réécrit l'adresse même si le nom, la description et le texte réécrit sont strictement identiques. C'est la cause numéro un des migrations qui perdent leur trafic alors que « rien n'avait changé ».

C'est l'option la plus sûre : une adresse qui ne change pas n'a rien à transférer. Nettoyer les adresses n'est pas un objectif de référencement le jour d'une montée de version, c'est un chantier de confort qui multiplie le risque. Si le schéma doit malgré tout évoluer, par exemple pour sortir les identifiants des routes, la décision se prend une fois, avant le développement, avec une table de correspondance exhaustive et des redirections permanentes prêtes avant la bascule. Elle ne s'improvise jamais pendant la recette.

Parce que Google ne l'interprète pas comme un transfert. Une redirection vers une destination sans rapport avec la page d'origine est traitée comme une page introuvable, et l'historique de la page est perdu. Chaque ancienne adresse doit pointer vers son équivalent exact, ou à défaut vers son successeur ou sa catégorie mère. Les pages sans aucun équivalent assument un retrait propre, ce qui est toujours préférable à une redirection trompeuse.

Oui, mais seulement si elles répondaient à la même intention de recherche. Regrouper trois anciennes catégories qui se positionnaient sur trois requêtes différentes vers une seule page revient à demander à cette page de porter trois sujets à la fois : elle en perd généralement au moins deux. Chaque regroupement est donc justifié explicitement dans la table de correspondance, et les cas douteux gardent leur propre destination.

Non, et c'est une erreur fréquente. Si le robot n'a plus le droit d'explorer l'ancienne adresse, il ne peut pas lire la redirection qui s'y trouve, donc il ne transfère rien. Les anciennes adresses doivent rester explorables aussi longtemps que le transfert n'est pas constaté dans l'index. Le blocage se réserve à ce que vous ne voulez pas voir explorer sur le nouveau site, comme les combinaisons de filtres hors liste blanche.

Au minimum un an, et de préférence indéfiniment. Le trafic revenu ne signifie pas que les redirections sont devenues inutiles : les liens externes acquis au fil des années continuent de pointer vers les anciennes adresses, et ce sont eux qui transportent la popularité. Retirer les règles trop tôt revient à couper cette popularité une seconde fois, longtemps après que plus personne ne surveille.

Oui, si elles sont placées au mauvais endroit. La régénération des règles de réécriture depuis le back-office réécrit intégralement le bloc délimité par les commentaires de PrestaShop dans le fichier de configuration du serveur. Ce qui se trouve à l'intérieur disparaît, ce qui se trouve à l'extérieur survit. Les redirections de migration sont donc posées hors de ce bloc, dans un fichier inclus, dans la configuration du serveur ou via un module dédié.

Oui, même si aucune adresse ne bouge. Le thème porte la hiérarchie des titres, une partie des données structurées, des contenus affichés en dur, le maillage interne et le poids des pages. Un nouveau thème peut faire disparaître un H1, en introduire trois, dupliquer les données structurées produit ou charger les prix en JavaScript sans que personne ne s'en aperçoive à l'œil nu. La recette est la même que pour une migration complète : un crawl comparatif de l'ancien et du nouveau rendu, gabarit par gabarit.

Dès que le projet est décidé, et idéalement avant que le premier gabarit ne soit développé. L'inventaire de l'ancien site, la période de référence de trafic et les spécifications SEO doivent exister avant le développement, pas après la recette : ce qui n'a pas été demandé au départ se paie en corrections à la fin, quand le calendrier ne le permet plus. Une migration cadrée tardivement reste utile tant que la bascule n'a pas eu lieu, mais chaque semaine gagnée en amont est une semaine de rattrapage évitée.

Une séquence écrite à l'avance et horodatée : mise en production et vérification du certificat sécurisé, retrait des protections de la préproduction et de toute balise noindex de recette, déploiement du fichier robots.txt de production, activation du plan de redirections, génération et soumission du nouveau sitemap, mise à jour du flux produit et des campagnes payantes, puis premiers contrôles sur un échantillon d'anciennes et de nouvelles adresses. Un scénario de retour arrière est prêt, avec sa condition de déclenchement définie avant le jour J.

Oui, et c'est même le meilleur moment pour certains chantiers : repartir sur une liste blanche de facettes au lieu de réimporter l'indexation sauvage de l'ancien site, solder la fin de vie du catalogue, refondre le maillage interne dans le nouveau thème, corriger une performance mobile dégradée. Une règle tient cependant : on change l'adresse d'une page ou son contenu, rarement les deux en même temps. On améliore ce qui est faible, on conserve intact ce qui porte déjà le trafic.

La migration est le bon moment pour trancher. Une rupture temporaire justifie de conserver la page et son adresse avec une disponibilité correctement signalée. Un produit remplacé appelle une redirection permanente vers son successeur, jamais vers l'accueil. Un arrêt définitif sans équivalent appelle un retrait propre, signalé comme tel plutôt que laissé en simple page introuvable. PrestaShop propose ces options dans l'onglet Référencement de la fiche produit : la politique se décide avant la bascule, puis s'applique uniformément au catalogue.

Rarement telles quelles. Le module de navigation à facettes est généralement réinstallé lors d'une montée de version majeure, et il revient avec l'ensemble des groupes d'attributs ouverts à l'indexation. Sans report explicite de votre liste blanche, la migration rouvre au crawl des dizaines de milliers de combinaisons de filtres le premier jour. Les adresses de facettes qui se positionnaient réellement sont, elles, traitées comme n'importe quelle autre page : équivalent identifié et redirection permanente.

Non. Une page peut répondre parfaitement, s'afficher normalement, et avoir perdu sa balise titre d'origine, son texte de catégorie, sa canonique ou les liens internes qui la nourrissaient. Le code de réponse ne dit rien du contenu. C'est pourquoi la recette compare l'ancien et le nouveau site champ par champ, gabarit par gabarit, au lieu de se contenter de vérifier que le site est en ligne.

Pour la partie technique, oui : la pose des redirections au niveau du serveur, les règles de réécriture, l'import du catalogue, les corrections du thème et des données structurées relèvent d'un développeur, le vôtre ou celui de votre agence. La reprise des contenus, les réglages natifs de la boutique et une partie des contrôles se font depuis le back-office. Cette séparation est volontaire : celui qui recette n'est pas celui qui produit, et chaque ligne des livrables précise qui met en œuvre.

Uniquement si vous changez de nom de domaine. L'outil de changement d'adresse ne couvre que ce cas, et il vient en complément des redirections permanentes, jamais à leur place. Sur une montée de version ou une refonte à domaine constant, il n'y a rien à déclarer : tout se joue dans le plan de redirections, le sitemap soumis et les contrôles d'indexation.

Les premières réexplorations des anciennes adresses interviennent dès les jours qui suivent la bascule, à un rythme qui dépend de la fréquence de passage habituelle sur votre boutique. La sortie des anciennes adresses de l'index et la reprise complète des nouvelles se jouent ensuite sur plusieurs semaines, davantage sur un gros catalogue. Aucun délai fixe ne peut être annoncé, et c'est précisément l'objet des contrôles à un jour, une semaine et un mois : mesurer la reprise au lieu de l'attendre.

Dans la plupart des cas oui, à condition d'intervenir vite. Le diagnostic reconstitue ce qui a été perdu à partir du crawl de l'ancien site quand il est encore disponible, des données de la Search Console et des liens entrants : adresses sans redirection, redirections en chaîne, balisage disparu avec l'ancien thème, contenus non réimportés, canoniques incohérentes, indexation bloquée par un fichier robots.txt ou une balise oubliée. Les correctifs sont ensuite priorisés sur les pages qui portaient réellement le trafic, et leurs effets contrôlés semaine après semaine.

Non. Je garantis un travail cadré, documenté et vérifiable selon le périmètre convenu : chaque adresse a une destination, chaque réglage est contrôlé, chaque écart après la bascule est détecté et corrigé dans des délais courts. Le trafic dépend ensuite de facteurs internes, dont la qualité de l'exécution technique et la rapidité des corrections, et de facteurs externes sur lesquels personne n'a de prise.

J'accompagne en priorité les e-commerçants de Paris et d'Île-de-France, avec recette et ateliers en présentiel et une disponibilité réelle le jour de la bascule. J'interviens également partout en France à distance, avec exactement les mêmes livrables.