curl -sS -D - -o /dev/null "$OLD_URL"

Suivre les redirections et afficher les en-têtes des réponses successives

curl -sS -L -D - -o /dev/null "$OLD_URL"

Afficher le statut final et l’adresse finale pour consigner les résultats

curl -sS -L -o /dev/null
-w 'statut=%{http_code} adresse_finale=%{url_effective}\n' "$OLD_URL"

Les résultats de validation doivent conserver à la fois la première réponse, l’adresse cible, la réponse finale et le contenu de la page. Le type de règle utilisé pour un déplacement permanent doit être confirmé par le responsable technique en fonction de l’environnement réel de déploiement. Constater dans le navigateur que « la redirection semble fonctionner » ne suffit pas.

Considérez les chaînes de redirections inutiles, les retours vers l’ancienne adresse, les redirections vers un domaine de test et les pages de destination inexistantes comme des motifs de blocage de la mise en ligne. Veillez tout particulièrement à ne pas vérifier uniquement les règles de la page d’accueil en oubliant les articles et les pages détaillées des produits.

## 5. Comment valider ensemble le contenu des pages et la balise canonical ?

Le fait qu’une adresse s’ouvre n’est que le minimum requis. Il est recommandé de sélectionner des pages représentatives de chaque modèle et de vérifier l’intégralité du titre, du titre principal, du corps du texte, des textes alternatifs des images, des liens internes et des boutons de contact, afin d’éviter de ne retrouver qu’une coquille de page après l’importation.

La balise canonical peut servir à vérifier l’adresse canonique, mais elle ne doit pas être considérée comme une solution de remplacement à tous les problèmes de migration. Lors de la validation, consignez l’adresse canonique déclarée par la page et assurez-vous qu’elle correspond à la page de production définie dans le projet. Recherchez en particulier les déclarations qui pointent encore vers l’ancien domaine, un domaine de prévisualisation ou une page sans rapport.

Pour les sites multilingues, vérifiez également la correspondance entre les versions linguistiques. Une page produit en chinois ne doit pas renvoyer vers la page d’accueil en anglais à la suite d’un remplacement en masse. Le sélecteur de langue, les liens du pied de page et les liens de recommandation dans le corps du texte doivent tous être testés par de véritables clics.

Comparez également les informations essentielles avant et après la migration. Les conditions tarifaires, le périmètre des services, les éléments étayant les cas clients et les coordonnées ne doivent pas disparaître involontairement lors du remplacement des modèles. Pour les pages utilisées par les commerciaux, il est recommandé d’associer le responsable métier à la validation, plutôt que de limiter le contrôle aux réponses techniques vérifiées par les développeurs.

## 6. Que vérifier dans le sitemap ? Le rapprocher d’abord de la liste des pages de production

Il est recommandé de commencer par dresser la « liste des pages de production destinées à être publiques et découvertes par les moteurs de recherche », puis de la comparer au sitemap généré. Ne considérez pas que le contrôle est terminé simplement parce qu’« un fichier XML a été généré ».

Vérifiez en priorité les points suivants :

- Les adresses du sitemap appartiennent-elles au domaine et à l’environnement de production ?
- Les nouveaux chemins issus de la migration y figurent-ils comme prévu ?
- Des adresses supprimées, encore redirigées ou pas encore prêtes à être publiques y ont-elles été incluses ?
- Les pages répertoriées dans le sitemap correspondent-elles aux adresses canoniques déclarées par les pages ?
- Des catégories entières ont-elles été omises, par exemple des répertoires linguistiques, des pages de pagination d’articles ou des catégories de produits ?
- La personne chargée de mettre à jour le sitemap et de le republier est-elle clairement identifiée ?

Si le nombre d’entrées du sitemap change, cherchez l’origine de cette variation : s’agit-il d’une fusion de contenus planifiée, d’un oubli lors de l’importation ou d’une erreur dans les critères de filtrage ? Il est recommandé de conserver des copies des fichiers avant et après la migration pour permettre une comparaison détaillée.

Le sitemap n’est qu’une partie de la validation de la migration. Après sa soumission, il faut encore vérifier l’accès aux pages, leur contenu et l’évolution de leur état. Cette soumission ne permet pas de promettre des résultats d’indexation, de positionnement ou de trafic.

## 7. Que vérifier dans Search Console avant et après la mise en ligne ?

![7. Que vérifier dans Search Console avant et après la mise en ligne ?](https://we0-frontend.oss-cn-beijing.aliyuncs.com/growth-covers/3ae5ab5b-404e-4812-9473-4305e47b4bb6.png)

Avant la mise en ligne, assurez-vous que l’équipe peut accéder aux propriétés concernées et que les droits des responsables ne disparaîtront pas avec le départ de l’ancien prestataire. Relevez les principales pages de destination, les requêtes, les clics et les impressions avant la migration, et conservez la date d’observation pour disposer d’un point de départ aux comparaisons ultérieures.

Après la mise en ligne, il est recommandé de vérifier et de consigner les éléments suivants dans cet ordre :

1. **Propriétés et autorisations** : la propriété consultée correspond-elle au site concerné par la migration, et le responsable dispose-t-il toujours des droits d’accès ?
2. **URL représentatives** : vérifiez l’exploration, l’état d’indexation et les informations d’adresse canonique des pages clés, en distinguant les données historiques des évolutions ultérieures.
3. **Sitemaps** : vérifiez le sitemap soumis, son état de traitement et les messages associés ; en cas d’anomalie, revenez au fichier réel pour enquêter.
4. **Problèmes de pages** : classez les anomalies par répertoire et par modèle, sans vous focaliser uniquement sur leur nombre total.
5. **Performances** : comparez les requêtes, les clics et les impressions en rapprochant les anciennes pages de leurs nouvelles pages correspondantes, plutôt qu’en comparant seulement la page d’accueil.

Si le domaine change également, vérifiez séparément si la procédure de changement d’adresse s’applique à votre situation. Ne confondez pas un changement d’outil de création de sites sur un même domaine avec une migration vers un autre domaine.

Lorsqu’un problème est détecté, regroupez dans un même ticket l’adresse de la page, le message observé, la date et l’heure de l’observation ainsi que le résultat du nouveau test. Ne supprimez pas de pages et ne modifiez pas les règles à répétition sur la seule base d’une capture d’écran isolée.

## 8. Comment organiser la validation et le retour arrière le jour de la mise en ligne ?

Il est recommandé de diviser la mise en ligne en phases de préparation, de bascule, de nouveaux tests et d’observation. Pendant la préparation, gelez les modifications importantes de contenu, sauvegardez les données des pages et les configurations, et confirmez qu’il reste possible de conserver les accès nécessaires à l’ancien site.

Après la bascule, testez d’abord les parcours métier essentiels : arrivée par un ancien point d’entrée, lecture de la présentation du produit, envoi du formulaire, réception de la notification et suivi commercial. Les contrôles SEO et ceux de la collecte de prospects doivent être menés en parallèle pour éviter qu’une page soit accessible alors que personne ne reçoit les demandes de contact.

Les conditions bloquant la mise en ligne doivent être convenues à l’avance : par exemple, des pages produits clés inaccessibles, un grand nombre d’anciens points d’entrée sans la destination prévue, des pages de production encore soumises aux restrictions de l’environnement de test ou un parcours de contact défaillant. Dans ces situations, le responsable décide de corriger ou de revenir en arrière, au lieu de débattre des critères pendant la mise en ligne.

Le retour arrière doit lui aussi disposer d’un mode opératoire : qui peut l’exécuter, quelles configurations doivent être restaurées et comment confirmer que la restauration a réussi. N’attendez pas le jour de la migration pour découvrir que l’ancien site a déjà été supprimé ou que les droits d’accès au compte de l’ancien prestataire ont expiré.

## 9. Comment analyser méthodiquement les variations de performances après la migration ?

Il est recommandé de rechercher d’abord les problèmes techniques et de contenu reproductibles, avant d’aborder plus largement les performances dans les moteurs de recherche. Vous pouvez procéder dans cet ordre : les pages sont-elles accessibles ? Les anciens points d’entrée mènent-ils aux bonnes destinations ? Le contenu est-il complet ? Les liens internes ont-ils été mis à jour ? Le sitemap et les adresses déclarées par les pages sont-ils cohérents ?

Lors de la comparaison des données, examinez ensemble l’ancienne et la nouvelle adresse d’une même page métier. Si vous ne consultez que l’historique de la nouvelle adresse, vous risquez de négliger les données antérieures à la migration. Si vous ne regardez que les totaux de l’ensemble du site, vous risquez au contraire de masquer les pertes d’un répertoire important.

Consignez également les changements publicitaires, les modifications ou suppressions de contenu, les campagnes saisonnières et les ajustements de configuration du suivi statistique survenus pendant la même période, afin de ne pas attribuer toutes les variations au changement de plateforme. Il est recommandé de ne corriger qu’un groupe de problèmes clairement identifiés à chaque cycle et de consigner les résultats des nouveaux tests, pour éviter que l’accumulation de modifications rende les causes impossibles à déterminer.

Il n’existe pas de délai de rétablissement universel applicable à tous les sites. Vous pouvez définir un rythme interne de revérification pour la validation de la migration, mais il ne faut pas présenter ce rythme comme un engagement de traitement des moteurs de recherche.

## 10. Quelles questions poser sur les capacités de migration lors du choix d’une plateforme de création de sites par IA ?

La génération de pages et la reprise de l’ancien site sont deux travaux de validation distincts. Le [site officiel de we0](https://we0.ai/zh) présente la formulation des besoins en langage naturel, la création de sites par plusieurs agents, les ajustements visuels et le processus de déploiement sur un domaine. Les entreprises peuvent s’appuyer sur ces éléments pour évaluer la méthode de création du site, mais elles doivent demander séparément une démonstration de la conservation des anciens chemins, de la configuration des redirections et des méthodes de test après migration. Il ne faut pas présumer que ces tâches seront automatiquement réalisées.

À titre de référence pour un autre type de produit, le [site officiel de Readdy](https://readdy.ai/zh) présente l’export du code, l’hébergement de domaines ainsi que des outils liés au SEO et au GEO. Lors de l’achat, posez des questions supplémentaires : après l’export, qui maintient la configuration de déploiement ? Qui gère les règles de chemins ? Qui recherche les causes des anomalies ? Les noms de fonctionnalités ne remplacent pas un document formalisant les responsabilités du projet.

L’[article de présentation de Wan Xiaozhi publié dans la communauté des développeurs Alibaba Cloud](https://developer.aliyun.com/article/1773673) aborde la création de sites par conversation et le processus de déploiement, mais la page précise que son contenu est une contribution d’utilisateur. Il peut aider l’équipe à comprendre les cas d’usage de la création de sites, mais ne doit pas être considéré comme un engagement du fournisseur sur le périmètre des prestations de migration de ce projet.

Il est recommandé de demander à la plateforme ou au prestataire envisagé de réaliser une démonstration sur un petit ensemble de véritables pages de l’ancien site avant de décider de l’achat et du calendrier de mise en ligne. La démonstration doit couvrir différents modèles et situations d’erreur, et pas seulement la génération d’une nouvelle page d’accueil.

## Questions fréquentes

### Faut-il une liste de contrôle de migration si l’on change uniquement de plateforme de création de sites, sans changer de domaine ?

Oui. Il est recommandé de vérifier que les chemins, le corps du texte, les déclarations des pages, les liens internes et le parcours de contact restent cohérents. Le maintien du domaine ne signifie pas que tous les résultats du déploiement seront automatiquement conformes au plan initial.

### Peut-on rediriger toutes les anciennes pages vers la page d’accueil ?

Ce n’est pas recommandé comme solution par défaut. Déterminez d’abord si chaque ancienne page dispose d’une nouvelle page pertinente pour la remplacer. Lorsqu’aucun contenu de remplacement n’existe, consignez également clairement le traitement choisi, au lieu de masquer cette absence avec la page d’accueil.

### La migration est-elle terminée une fois le sitemap soumis ?

Non. Il faut également tester les anciens points d’entrée, vérifier les pages clés et valider les parcours métier, tout en continuant de consigner les évolutions des états dans Search Console. La soumission ne remplace pas les tests d’accès réels.

## Outils associés

- **Tableau de correspondance des URL** : gérer les anciens chemins, les nouveaux chemins, les traitements prévus et les responsables.
- **curl** : consulter les en-têtes de réponse, la chaîne de redirections et l’adresse finale.
- **Google Search Console** : organiser les relevés de contrôle des états du site et de ses performances dans les moteurs de recherche.
- **Outils de développement du navigateur** : retester le chargement des pages, les liens et les requêtes des formulaires.

## Liens associés

- [we0 : création de sites, ajustement des pages et processus de déploiement](https://we0.ai/zh)
- [Readdy : présentation de la création de sites, de l’export du code et des outils de gestion](https://readdy.ai/zh)
- [Communauté des développeurs Alibaba Cloud : présentation des cas d’usage de la création de sites par IA avec Wan Xiaozhi](https://developer.aliyun.com/article/1773673)

## Synthèse

Lors d’un changement de plateforme de création de sites, la validation ne porte pas uniquement sur le nouveau site, mais sur le parcours complet allant des anciens points d’entrée aux nouveaux contenus, puis à la prise de contact. Établissez d’abord un tableau de correspondance des URL, puis testez les redirections, le contenu des pages, les sitemaps et les parcours métier. Poursuivez ensuite les vérifications à l’aide de Search Console. Les capacités de la plateforme doivent être confirmées par des démonstrations sur des pages réelles, tandis que les responsabilités de migration et les conditions de retour arrière doivent être formalisées avant la mise en ligne.