Le terme « migration de site » recouvre des projets très différents. Changer de serveur, changer de CMS ou changer de domaine sont toutes des migrations, mais du point de vue du SEO elles n’ont pratiquement rien en commun.
La vraie question est de savoir ce qui change du point de vue de Google.
Si les URL changent, il faut des redirections. Si le contenu ou la structure changent, Google doit réévaluer les pages concernées. Si seule la technologie sous-jacente change, Google ne devrait presque rien voir.
Cet article classe les migrations selon leur risque SEO. Plus vos URL, votre contenu, votre structure ou votre domaine changent, plus la migration demande de planification et de supervision Technical SEO.
Toutes les migrations ne présentent pas le même risque SEO :
| Type de migration | Risque SEO | Ce qui demande le plus d'attention |
|---|---|---|
| Migration d'hébergement | Faible | Interruptions de service et configuration serveur |
| Replatforming (changement de CMS) | Moyen | Templates, rendu et maillage interne |
| Migration HTTPS | Moyen | Redirections et URL canoniques |
| Changement de structure d'URL | Élevé | Mapping des URL et redirections |
| Migration de domaine | Élevé | Redirections et transfert d'autorité |
| Architecture de l'information | Élevé | Navigation et maillage interne |
| Migration internationale | Élevé | Ciblage linguistique et régional |
| Migration combinée | Très élevé | Planification, tests et déploiement par étapes |
Comprendre les principaux types de migration de site
Migration d'hébergement ou de serveur : le risque le plus faible
Une migration d’hébergement change l’infrastructure, pas le site lui-même. L’hébergeur, le serveur ou l’adresse IP changent, tandis que les URL, le contenu et les templates restent identiques. Du point de vue de Google, rien du site lui-même ne devrait changer.
Quand les positions chutent après une migration d’hébergement, la cause est généralement un changement de configuration plutôt que le déménagement en soi.
Erreurs de configuration à vérifier le jour de la bascule
Le robots.txt de préproduction se trouve à côté du reste du code et part facilement avec lui. Une seule règle Disallow suffit à empêcher Googlebot de crawler le site, alors que tout semble fonctionner normalement pour les visiteurs. Ouvrir le robots.txt en production juste après la bascule confirme que le bon fichier a été déployé.
Les problèmes de certificat SSL sont tout aussi faciles à passer à côté. Si le certificat couvre votredomaine.fr mais pas la version www, ou s’il a été mal installé, les navigateurs affichent un avertissement et Googlebot ne peut plus accéder au site. Testez les deux hostnames et les deux protocoles pour vérifier que chaque chemin de redirection fonctionne comme prévu.
Le temps de réponse est plus difficile à juger, car un serveur peut très bien se comporter lors d’un test manuel isolé et réagir tout autrement sous trafic réel. Mesurez le time to first byte sur plusieurs centaines d’URL une fois que le nouvel environnement traite du trafic réel, plutôt que de vous fier à une seule requête servie en cache.
L’hébergeur lui-même mérite aussi un contrôle, car un web application firewall ou une protection anti-bots peut classer Googlebot parmi les visiteurs indésirables et lui servir une page de blocage à la place du contenu. Une requête avec le user agent de Google confirme lequel des deux il reçoit.
Migration HTTP vers HTTPS
Pour la plupart des sites, la migration HTTPS appartient déjà au passé.
S’il s’agit de l’un des derniers sites encore en HTTP, chaque URL HTTP a besoin d’une redirection 301 vers son équivalent HTTPS, et les balises canonical doivent pointer vers les versions HTTPS. Ce qui subsiste généralement ensuite, c’est le mixed content : des pages HTTPS qui appellent encore des images, des scripts ou des feuilles de style en HTTP. Un crawl les identifie rapidement.
À partir d’ici, toutes les migrations impliquent un changement d’URL, et c’est là que le vrai travail commence.
Changement de domaine, rebranding, fusion : là où votre autorité se déplace
Quand le domaine change, Google doit comprendre que la nouvelle URL remplace l’ancienne. C’est la redirection 301 qui lui indique cette relation. Aucun réglage ne transfère les positions automatiquement.
Changer de domaine peut recouvrir trois projets différents, chacun avec son propre niveau de complexité.
Trois types de migration de domaine
- Changement de domaine simple. La marque reste la même, seul le domaine change, par exemple de votremarque.fr vers votremarque.com. Chaque ancienne URL doit renvoyer une 301 vers son équivalent exact sur le nouveau domaine, et le plan de redirection doit couvrir toutes les URL indexées.
- Rebranding. Le nom de marque et le domaine changent tous les deux. Les redirections transfèrent la compréhension que Google a des URL, mais elles n’expliquent pas le changement de nom en lui-même. Les moteurs de recherche apprennent la relation par les redirections, tandis que les LLM peuvent continuer un certain temps à associer l’ancienne et la nouvelle marque séparément, comme expliqué plus loin dans cet article.
- Fusion. Deux domaines ou plus n’en forment plus qu’un. Là où les deux sites traitent le même sujet, une URL doit devenir la destination canonique. Laisser plusieurs versions en ligne ne fait que créer une concurrence inutile.
Scinder un site en plusieurs est le même exercice à l’envers, traité plus loin sous la scission de sites.
Tout rediriger vers la page d'accueil ne fonctionne pas
Si une ancienne fiche produit redirige vers la page d’accueil au lieu de son remplacement, Google traitera souvent cette redirection comme une soft 404. La page d’origine sort de l’index et peu de valeur, voire aucune, n’est transférée.
Cela passe souvent inaperçu parce que la redirection semble fonctionner pour les utilisateurs. Le problème n’apparaît qu’après le recrawl des anciennes URL, quand la Search Console commence à remonter des Soft 404 et des Page avec redirection.
Chaque URL a donc besoin de sa propre destination : la page qui la remplace réellement. S’il n’existe pas de remplacement pertinent, la redirection est souvent la mauvaise réponse, ce qui nous amène à la section suivante.
Utiliser l'outil de changement d'adresse pour un déménagement complet
Pour une migration de domaine complète, la Google Search Console propose un outil de changement d’adresse, à n’utiliser qu’une fois vos redirections 301 en ligne et vérifiées. Il indique à Google que le déménagement est volontaire, mais il ne crée pas de redirections et ne transfère pas les positions de lui-même.
Google a resserré ses exigences sur ce point. Lors d’un déménagement vers un nouveau domaine, le changement doit être déclaré pour chaque variante de sous-domaine de l’ancien domaine, y compris www et non-www, et chacune de ces variantes doit être validée au préalable dans la Search Console, même si vous ne les utilisez pas activement.
Conservez l’ancienne propriété Search Console après la mise en ligne. Elle permet de suivre le recrawl des anciennes URL, de repérer les codes de statut inattendus et d’observer la migration pendant que Google traite les redirections. Une certaine fluctuation des positions pendant cette période est normale.
L’outil ne concerne que les changements au niveau du domaine. Il ne s’applique ni aux migrations HTTP vers HTTPS, ni au passage entre www et non-www sur le même domaine, ni aux changements de structure d’URL sur un même domaine, ni aux migrations d’hébergement. Ces cas reposent sur des redirections correctes, des signaux canoniques quand c’est pertinent, des sitemaps à jour et le crawl habituel de Google.
Changement de structure d'URL : là où les migrations échouent
Le domaine reste le même, mais les URL changent. Du point de vue SEO, l’exercice est le même que pour une migration de domaine : chaque URL modifiée a besoin d’une destination planifiée et de la bonne réponse HTTP après la mise en ligne.
Couche de planification et implémentation technique
Mapping des URL
Définit ce qui doit advenir de chaque URL importante pendant la migration.
Réponse réelle du serveur
La configuration des redirections transforme ces décisions en réponses HTTP réelles.
Read Our Latest Articles
Lorem ipsum purus eu id enim sit rhoncus ut eu dapibus neque eu ipsum mauris rhoncus lorem iaculis varius non arcu lectus potenti felis ac arcu ac porttitor feugiat sed velit felis sed tortor faucibus semper quis leo in dictumst malesuada lacinia urna nulla vitae ornare scelerisque
Types de migration de site web : Quels changements mettent réellement vos positions en péril ?
Chaque URL a besoin d'une réponse HTTP définie
Chaque URL existante doit faire l’objet d’une décision avant le début des développements. Soit elle reste, soit elle bascule vers une page de remplacement, soit elle est supprimée volontairement. Ces décisions constituent le mapping des URL que les développeurs implémentent ensuite pendant la migration.
Après la mise en ligne, chaque URL doit renvoyer la réponse qui correspond à sa décision :
- 200 : la page reste inchangée.
- 301 : le contenu a été déplacé de façon permanente.
- 410 : le contenu a été supprimé volontairement.
- 404 : la page est introuvable, sans indiquer explicitement une suppression définitive.
La majorité des URL renverront une 301. Ce sont les exceptions qui demandent de vraies décisions. Un produit arrêté sans remplacement, une campagne expirée ou une page supprimée volontairement doivent normalement renvoyer une 410. Rediriger ces pages vers une catégorie vaguement apparentée produit souvent une soft 404 à la place, ce qui consomme du budget de crawl sans préserver la moindre pertinence.
Les URL qui posent problème sont généralement celles que personne n’a prévues. Elles renvoient des 404 inattendues après la mise en ligne et passent souvent inaperçues jusqu’à ce que Google les remonte dans la Search Console, des semaines plus tard.
Quatre schémas courants de changement d'URL
- Restructuration planifiée. Nouveaux permaliens, nouveaux répertoires, ou un blog qui passe de blog.votresite.com à votresite.com/blog. Tant que chaque ancienne URL a une destination définie avant la mise en ligne, la migration reste sans surprise.
- Supprimer puis recréer. Une page est retirée, puis republiée sous une nouvelle URL sans 301. Google traite la nouvelle URL comme une page entièrement nouvelle alors que le contenu est identique, et les signaux de positionnement attachés à l’ancienne URL sont perdus.
- Changements au fil de l’eau. Quelqu’un modifie une URL sans mettre à jour le mapping des redirections, et quelques mois plus tard personne ne sait plus quelle URL a remplacé quelle page. Faites-en une règle d’équipe : toute modification d’URL exige une redirection et une ligne dans le mapping avant la mise en production.
- URL parallèles. L’ancienne URL reste en ligne, si bien que /services et /solutions renvoient toutes deux un 200 avec le même contenu. Google peut indexer les deux et positionner l’une ou l’autre. Une redirection 301 tranche la question. La balise canonical n’est qu’une indication, et convient au cas où les deux URL doivent réellement rester accessibles.
Vérifier les chaînes de redirection et les redirections temporaires
Si /boutique/produit-a redirige vers /produits/produit-a, qui redirige à son tour vers /p/produit-a, Googlebot doit effectuer trois requêtes avant d’atteindre la page finale.
Google a confirmé que le PageRank n’est plus perdu lors des redirections 3xx, ce qui rend caduc l’ancien argument du link equity, mais cela ne rend pas les chaînes inoffensives pour autant. Elles ralentissent le crawl, consomment du budget de crawl pour rien et créent des points de défaillance supplémentaires à mesure que les règles de redirection évoluent.
Profitez-en pour vérifier les codes de statut. Une 302 indique à Google que le déplacement est temporaire, si bien que l’ancienne URL peut rester indexée au lieu d’être consolidée avec la nouvelle. Beaucoup de CMS, de plugins et de frameworks créent des 302 par défaut : vérifiez donc toujours qu’un changement d’URL définitif renvoie bien une 301.
Changement de plateforme ou de CMS (replatforming) : rien ne fonctionne sans mapping complet
Un replatforming combine plusieurs types de migration à la fois : nouveaux formats d’URL, templates différents, modification du maillage interne. Dans certains cas le rendu change également, et un contenu auparavant livré directement dans le HTML est désormais rendu en JavaScript.
Sonder quelques pages ne suffit pas. Chaque URL existante doit être prise en compte avant la migration.
Exporter l'inventaire des URL avant le début des développements
Constituez l’inventaire des URL pendant que l’ancien site est encore en ligne. Une fois qu’il a été remplacé, récupérer l’ensemble complet des URL devient difficile et généralement incomplet.
Aucune source ne contient à elle seule toutes les URL, il faut donc croiser plusieurs jeux de données :
- Un crawl du site en production capte tout ce qui est lié en interne.
- Les sitemaps XML, y compris ceux que le CMS génère automatiquement, contiennent souvent des URL que le crawler n’atteint jamais.
- Le rapport Pages de la Search Console ajoute les URL qui reçoivent encore des impressions ou des clics.
- Les logs serveur révèlent ce que les utilisateurs et les moteurs continuent d’appeler, ce qui signifie généralement que des liens externes pointent toujours là.
Après dédoublonnage, chaque URL de l’inventaire doit avoir une issue définie : rester en ligne, rediriger vers un remplacement, ou renvoyer le code de statut approprié.
Tester les redirections avant la bascule DNS
Les redirections doivent être testées avant le changement DNS. Une fois le nouveau site en ligne, chaque redirection incorrecte affecte immédiatement les utilisateurs et les crawlers.
Pointez un crawler vers l’environnement de préproduction et utilisez l’inventaire des anciennes URL comme liste de départ. Cela met en évidence les URL qui renvoient une 404, les redirections qui aboutissent sur la page d’accueil, les chaînes de redirection et les 302 qui auraient dû être des 301.
Le second contrôle compare les deux sites plutôt que des URL isolées : balises title, titres H1, nombre de mots, balises canonical et nombre de liens internes par URL, ancien crawl contre nouveau. Les pages qui arrivent en ligne avec sensiblement moins de contenu ou moins de liens internes ont perdu les éléments avec lesquels elles se positionnaient, et cela se corrige bien plus facilement avant la mise en ligne qu’après.
Conservez l’ancien sitemap XML et soumettez-le une fois le nouveau site en ligne. Il donne à Googlebot la liste exacte des URL à recrawler, ce qui accélère la découverte de vos redirections 301.
URL produits, catégories et filtres en e-commerce
En e-commerce, les URL de produits, de catégories et de filtres sont concernées en très grand nombre. Les URL à paramètres comme /chaussures?couleur=noir&taille=42 se transposent rarement une pour une sur la gestion de paramètres du nouveau système.
Les produits arrêtés représentent l’essentiel du volume. Chacun demande une décision, mais pas une décision individuelle : redirection vers le produit successeur quand il existe, redirection vers la catégorie parente quand la gamme subsiste, et 410 pour le reste. Formulés comme des règles exécutées sur la base produits, ces trois cas couvrent l’ensemble du catalogue. Traités manuellement, ils deviennent un tableur avec une ligne par produit arrêté.
Refonte graphique : le « purement visuel » est un mythe
Une refonte semble ne changer que la présentation. En pratique elle change le HTML, et c’est le HTML que Google lit. La différence se voit dans la façon dont les pages sont liées, dont elles sont structurées et dans la quantité de texte qu’elles portent.
Les menus de navigation, les sidebars et les blocs de contenus associés sont souvent reconstruits ou supprimés pendant une refonte. Des pages qui recevaient auparavant des dizaines de liens internes peuvent n’en conserver qu’une poignée. La hiérarchie des titres change également, typiquement quand le titre de page devient un div stylé et que les anciens H2 s’aplatissent sur un seul niveau.
Reste le contenu rédactionnel. Les longues sections explicatives entrent rarement dans une mise en page plus serrée, elles sont donc raccourcies pendant la phase de design et la page perd les termes sur lesquels elle se positionnait. Cette décision se prend en revue de design, pas au développement.
La comparaison de crawls utilisée pour un replatforming s’applique ici aussi. En comparant le nombre de mots et le nombre de liens internes par URL, ancien contre nouveau, on identifie les pages qui arrivent en ligne avec moins qu’avant.
Migration de contenu et de structure : agir directement sur la pertinence
C’est ici que vous modifiez volontairement ce que disent les pages et la façon dont elles se relient entre elles.
- Trois pages de prestations peu fournies n’en font plus qu’une, avec des redirections 301 depuis les deux pages supprimées.
- Des guides qui se recouvraient sont fusionnés pour ne plus se disputer les mêmes requêtes.
- Les pages qui n’ont jamais généré de trafic significatif sont supprimées, chacune renvoyant soit une 301, soit une 410.
- La navigation est réorganisée, ce qui modifie les liens internes qui aident Google à comprendre quelles pages sont les plus importantes.
Bien planifiée, c’est l’un des rares types de migration capable d’améliorer les positions au lieu de simplement les préserver. Sans cette planification, des pages qui généraient du trafic disparaissent et emportent leurs positions avec elles.
Ces décisions doivent s’appuyer sur des données de recherche plutôt que sur des suppositions. Une page qui paraît pauvre dans le CMS peut très bien capter du trafic de longue traîne intéressant. La Search Console le montre, le CMS non.
Fusion et scission de sites : plusieurs migrations dans un seul projet
Lors d’acquisitions ou de restructurations, plusieurs sites sont fusionnés en un seul, ou un site unique est scindé en plusieurs. Cela combine une migration de domaine, une migration d’URL et une migration de contenu dans le même projet, avec en plus la décision de savoir quelle page doit faire référence chaque fois que deux sites traitent le même sujet.
La principale difficulté n’est généralement pas technique. Elle consiste à se mettre d’accord sur la page qui doit survivre quand plusieurs équipes estiment que c’est la leur.
Internationalisation : ajouter des langues et des pays
Les sites internationaux imposent deux décisions distinctes : comment structurer chaque marché, et comment relier les versions linguistiques et régionales entre elles.
Répertoire, sous-domaine ou domaine national ?
- Les répertoires, par exemple votresite.com/fr-be/, gardent tout sur un seul domaine, ce qui permet de consolider l’autorité.
- Les sous-domaines, par exemple be.votresite.com, séparent les marchés tout en restant rattachés au même site.
- Les domaines nationaux, par exemple votresite.be, envoient le signal géographique le plus clair, mais chaque domaine doit construire sa propre autorité.
La structure compte moins que la cohérence. Choisissez celle qui correspond à l’organisation réelle de l’entreprise, puis appliquez-la partout.
Valider le hreflang
Le hreflang indique à Google quelle version linguistique ou régionale d’une page doit être servie aux utilisateurs. Chaque version doit référencer toutes les autres, y compris elle-même.
Quand le hreflang est incorrect, rien ne casse visiblement. Les pages restent indexées, mais Google peut servir la mauvaise version linguistique ou régionale dans les résultats. Ces problèmes n’apparaissent souvent que lorsque la Search Console ou l’analytics ne correspondent plus à la structure pays et langues que vous aviez prévue.
Comme ces erreurs sont difficiles à repérer manuellement, validez le hreflang avec un crawler qui contrôle la réciprocité des annotations sur l’ensemble du site. Une seule référence retour manquante suffit à rompre la relation.
La migration la plus risquée : tout changer en même temps
Un nouveau domaine, un nouveau CMS, un nouveau design et une nouvelle structure d’URL lancés simultanément cumulent les risques de tous les types de migration.
Le risque en lui-même n’est pas le pire. Si le trafic chute ensuite, vous ne pouvez pas déterminer quel changement en est la cause, puisque tout a changé le même jour.
Dans la mesure du possible, découpez les changements majeurs en phases. Migrez d’abord vers la nouvelle plateforme, puis introduisez la refonte une fois les positions stabilisées. Cela demande un second déploiement et une seconde campagne de tests, mais cela rend bien plus simple l’identification et la correction des variations de positions.
Pourquoi cette distinction compte
La plupart des pertes de positions après une migration ne viennent pas d’une pénalité Google. Elles surviennent parce que les mesures de sécurité d’un type de migration ont été appliquées à un autre.
- Une migration d’hébergement demande une checklist de déploiement : robots.txt, certificats SSL, temps de réponse et règles de firewall.
- Une migration de domaine demande un mapping d’URL complet, implémenté avec des redirections 301.
- Une migration de structure d’URL demande à la fois un mapping d’URL et un mapping de contenu.
Utiliser la bonne checklist pour la mauvaise migration laisse les vrais risques à découvert.
C’est aussi pour cela que le point de référence vient en premier, quel que soit le type de migration prévu. Exportez les données de performance de la Search Console, sauvegardez un crawl du site existant et relevez vos principales landing pages dans l’analytics. Sans ce point de comparaison, vous constaterez après la mise en ligne que le trafic a évolué, sans pouvoir dire quelles URL ni quelles requêtes sont concernées.
Les migrations de site vues sous l'angle de l'AI search
Les moteurs de recherche ne sont plus les seuls systèmes qui doivent comprendre une migration. ChatGPT, Perplexity et les AI Overviews de Google pèsent de plus en plus sur la façon dont les gens découvrent les marques, et ils ne réagissent pas tous de la même manière à une migration.
Recherche en direct et données d'entraînement
Les grands modèles de langage produisent leurs réponses de deux façons différentes, et une migration les atteint à des vitesses différentes.
Parfois le modèle lance une recherche pendant qu’il génère sa réponse. Les AI Overviews s’appuient sur l’index de Google, tandis que ChatGPT Search utilise principalement Bing, complété par les systèmes de retrieval d’OpenAI. Dans ce cas, les migrations se comportent à peu près comme dans la recherche classique : dès que les redirections 301 sont en ligne et que les nouvelles URL ont été crawlées, les systèmes de retrieval commencent à utiliser les nouvelles adresses.
Dans de nombreux cas, cependant, aucune recherche n’a lieu. Le modèle répond à partir de ce qu’il a appris pendant son entraînement, bien avant que la question soit posée. Une étude de données de navigation de Semrush suggère qu’une large part des réponses des IA sont générées de cette façon, sans déclencher la moindre recherche en direct.
Une redirection 301 ne met pas à jour les données d'entraînement
Une redirection 301 change l’endroit où les crawlers sont envoyés. Elle ne change pas l’information déjà stockée dans un modèle.
C’est pourquoi une migration de domaine parfaitement exécutée peut malgré tout donner lieu, des mois plus tard, à des réponses de ChatGPT qui citent l’ancien domaine, alors même que Google a intégralement traité les redirections. L’ancien domaine ne disparaît qu’au fil de l’entraînement de nouveaux modèles sur un web qui référence de façon cohérente la nouvelle marque et le nouveau domaine.
La seule façon de le suivre consiste à interroger régulièrement les systèmes d’IA sur votre marque et ses sujets clés, sur plusieurs mois. La Search Console ne peut pas montrer comment les modèles d’IA identifient votre entreprise.
Une étude de l’Université de Toronto a établi que 16 pour cent en moyenne des entités citées dans les réponses générées n’apparaissaient dans aucun document récupéré, et que modifier les sources récupérées ne changeait quasiment rien au résultat.
Un rebranding ne se règle pas avec des redirections
Pour les systèmes d’IA, le signal important n’est pas l’URL mais le nom de marque.
Une redirection 301 indique à un crawler qu’une page en a remplacé une autre. Elle n’indique pas à un modèle de langage qu’un nom d’entreprise en a remplacé un autre.
Un modèle ne reconstruit cette association qu’à mesure que le nouveau nom apparaît de façon cohérente sur les sites, les annuaires, les plateformes d’avis, les organisations professionnelles et dans la presse. Une étude d’Ahrefs portant sur 75 000 marques montre que les mentions de marque sur le web corrèlent avec la visibilité dans les AI Overviews à 0,664, contre 0,218 pour les backlinks, et une étude de suivi retrouve le même schéma sur ChatGPT et Google AI Mode. Ahrefs souligne d’ailleurs qu’il s’agit d’une corrélation et non d’une preuve de causalité.
En pratique, la mise à jour des mentions sur les sites tiers fait partie intégrante du projet de migration, et non de ce qu’on traite après coup.
Citations des IA et positions Google sont deux signaux distincts
Être bien positionné dans Google ne signifie pas automatiquement être cité par les systèmes d’IA.
La même étude de l’Université de Toronto relève un recoupement très faible entre les pages les mieux positionnées dans Google et les sources citées par les systèmes d’IA. Pour GPT-4o, le recoupement médian était nul, ce qui signifie que sur plus de la moitié des requêtes testées, il ne citait rien du top 10 de Google.
Traitez la visibilité search et la visibilité IA comme deux mesures distinctes.
Ce à quoi ressemble aujourd'hui une migration réussie
Une migration réussie produit désormais deux résultats.
Le premier est technique. Google reçoit les bonnes redirections, les bons codes de statut et les bons signaux internes, ce qui permet aux positions de se transférer comme prévu.
Le second relève de la reconnaissance de marque. Les systèmes d’IA apprennent progressivement le nouveau domaine et, le cas échéant, le nouveau nom d’entreprise, à mesure que les références sur le web sont mises à jour et que les futurs entraînements de modèles les intègrent.
Conserver ses positions n’est plus l’objectif tout entier. Quelques mois après la mise en ligne, votre nouvelle marque et votre nouveau domaine doivent être reconnus de façon cohérente aussi bien par les moteurs de recherche que par les systèmes d’IA. Les redirections assurent le premier résultat. Seule la planification assure le second.
Vos fondations Tech SEO sont-elles prêtes pour une migration ?
Vous préparez une migration ? Nous établissons votre bilan de visibilité de départ pour protéger votre trafic et mesurer vos gains.