Après une migration d’URL, utilisez une seule table de correspondance entre anciennes et nouvelles URL pour mettre à jour les liens publics, les déclarations canoniques, les redirections et les entrées du plan de site. Ce processus sur Mac montre comment faire concorder ces modifications et vérifier le résultat publié.

La tâche consiste ici à déplacer un petit ensemble de documents HTML publics vers de nouveaux chemins sur le même site Web. Toutes les adresses et tous les noms de pages donnés en exemple sont fictifs. Pour effectuer l’ensemble du processus, vous devez avoir accès au système de publication, à ses paramètres de redirection et à la propriété correspondante dans Search Console.

Que doit-on faire concorder après la migration ?

Pour chaque document déplacé, choisissez une destination finale. Les liens que vous contrôlez doivent pointer directement vers celle-ci, la destination doit être déclarée comme URL canonique et le plan de site actuel doit répertorier cette adresse. L’ancienne adresse doit rediriger vers la nouvelle. Google décrit les redirections et les annotations canoniques comme des signaux forts de canonisation, tandis que l’inclusion dans le plan de site constitue un signal plus faible. Ces méthodes peuvent se renforcer mutuellement, mais Google choisit en dernier ressort l’URL canonique. Conseils de Google sur la canonisation.

Ces mécanismes ont des fonctions différentes. Une redirection traite une requête visant une ancienne adresse. Un lien public détermine où le lecteur se rend ensuite. Une déclaration canonique désigne l’URL privilégiée d’un document ; WHATWG définit ce sens pour le type de lien canonical. Un plan de site fournit une liste d’URL privilégiées pour faciliter leur découverte. Mettre à jour l’un de ces éléments ne modifie pas les autres. Norme HTML de WHATWG : type de lien canonique, Conseils de Google sur les plans de site.

Utilisez ce tableau de concordance comme contrôle pratique d’acceptation. Il s’agit d’un processus fondé sur la documentation, et non d’un système de notation de Google.

Élément Résultat attendu pour le document fictif Colors
Ancienne adresse https://example.com/notes/colors.html redirige de façon permanente vers la destination
Destination https://example.com/library/colors/ diffuse le document Colors
Navigation et liens dans les documents Pointent directement vers https://example.com/library/colors/
URL canonique de la destination Désigne https://example.com/library/colors/
Entrée dans le plan de site actuel Répertorie https://example.com/library/colors/

Établir une seule table de correspondance avant de modifier les paramètres

Sur votre Mac, ouvrez un tableur ou un éditeur de texte brut et notez chaque ancienne adresse à côté de la destination prévue. Google recommande de préparer une table de correspondance entre anciennes et nouvelles URL dans le cadre d’un déplacement. Conservez une copie de la liste d’origine afin que le remplacement des entrées du plan de site n’efface pas les adresses qui doivent encore faire l’objet de redirections. Conseils de Google sur le déplacement de sites.

Document Ancien chemin Chemin final
Colors /notes/colors.html /library/colors/
Palette /notes/palette.html /library/palette/
Shapes /notes/shapes.html /library/shapes/

Pour chaque ligne, indiquez les endroits où des modifications sont nécessaires : éditeur de pages, navigation partagée, paramètre canonique, paramètre de redirection et générateur de plan de site. Ajoutez des colonnes de vérification distinctes pour la réponse publique et l’inspection dans Search Console. Vous transformerez ainsi la vague consigne « mettre à jour les URL » en une liste limitée de modifications et de vérifications.

Vérifiez le contenu de destination avant de valider une correspondance. Si deux anciens documents ont été fusionnés en un document consolidé utile, les deux peuvent rediriger vers celui-ci. Évitez d’envoyer des documents sans rapport vers une page d’accueil générique ; Google avertit que des redirections non pertinentes peuvent être considérées comme des erreurs 404 logicielles. Recommandations de Google pour établir la table de redirection.

Mettre à jour les liens publics et vérifier les chemins relatifs

Dans votre éditeur de publication, utilisez la table de correspondance pour mettre à jour la navigation, les index de documents, les liens vers des documents connexes et les liens dans le texte des articles. Si le système génère la navigation à partir des fiches de pages, modifiez les fiches ou le modèle source plutôt que de corriger à répétition le résultat généré. Examinez chaque remplacement avant l’enregistrement, en particulier lorsque l’ancien chemin apparaît aussi dans des exemples explicatifs.

Un changement de chemin peut modifier la destination d’un lien relatif même si son texte reste identique. La norme URL de WHATWG définit la résolution des références relatives par rapport à une URL de base. Pour les cas illustratifs ci-dessous, supposons que le document ne comporte aucune surcharge explicite de l’URL de base. Norme URL de WHATWG.

URL du document Valeur du lien Destination résolue
https://example.com/notes/colors.html palette.html https://example.com/notes/palette.html
https://example.com/library/colors/ palette.html https://example.com/library/colors/palette.html
https://example.com/library/colors/ /library/palette/ https://example.com/library/palette/

Ces résolutions fictives ont été vérifiées avec l’API JavaScript URL. La valeur palette.html, restée inchangée, pointe maintenant vers un emplacement du répertoire Colors ; une vérification des remplacements de texte ailleurs ne permettrait pas de détecter le problème. Pour ce petit ensemble de documents, utiliser le chemin relatif à la racine prévu rend la destination explicite. En cas de migration vers un autre hôte, utilisez la bonne adresse absolue ou vérifiez que chaque lien relatif à la racine reste sur l’hôte prévu.

Ouvrez le document Colors publié dans le navigateur de votre Mac et suivez son lien vers Palette. Vérifiez à la fois le document affiché et l’adresse finale. Faites de même pour la navigation partagée et les liens de section. Si un lien utilise #swatches, vérifiez que la destination contient toujours l’identifiant de section correspondant ; la table des chemins ne permet pas de le déterminer à elle seule.

Définir les URL canoniques et les redirections permanentes à leur source

Pour chaque nouveau document HTML, définissez l’URL canonique comme l’URL absolue finale. Google recommande les URL canoniques absolues et accepte l’élément canonique HTML dans le head du document. Si votre système de publication comporte un champ canonique, saisissez-y l’adresse et examinez le code généré. Instructions de Google pour la mise en œuvre des URL canoniques.

Pour la page Colors, l’extrait suivant est à placer dans l’en-tête existant du document ; il ne s’agit pas d’une page HTML complète :

<link rel="canonical" href="https://example.com/library/colors/">

Vérifiez si l’hôte envoie aussi une URL canonique dans un en-tête de réponse HTTP Link. Google prend en charge les deux méthodes, mais recommande d’en choisir une, car leur gestion simultanée peut entraîner des destinations contradictoires. Corrigez le modèle ou le paramètre qui génère la valeur afin que la prochaine publication ne rétablisse pas une ancienne adresse. Méthodes de canonisation de Google.

Configurez l’ancienne adresse pour qu’elle renvoie une redirection permanente côté serveur vers la destination. La RFC 9110 définit 301 et 308 comme des redirections permanentes et décrit la destination dans l’en-tête Location. La différence concerne notamment le traitement de la méthode de requête : 308 la conserve, tandis que 301 autorise le comportement historique POST vers GET. Pour la récupération ordinaire de documents, Google considère les deux comme des signaux de redirection permanente. RFC 9110 : sémantique HTTP, Documentation de Google sur les redirections.

La configuration exacte dépend de votre hébergeur ou de votre système de publication. La modification dans un navigateur ne suffit pas à créer une règle de réponse HTTP. Si votre plateforme ne permet pas de configurer des redirections côté serveur, utilisez la configuration d’hébergement documentée ou demandez à l’opérateur d’hébergement de mettre en œuvre la table. Google documente la redirection instantanée par meta refresh comme solution de repli lorsque les redirections côté serveur ne sont pas disponibles ; il recommande les redirections JavaScript uniquement si les autres méthodes sont inutilisables. Une déclaration canonique ne redirige pas à elle seule le visiteur vers la nouvelle adresse. Méthodes de redirection prises en charge par Google.

Régénérer le plan de site à partir des mêmes destinations

Mettez à jour la source du plan de site, puis régénérez-le. Une correction manuelle d’un fichier généré risque d’être perdue lors de la prochaine compilation. Pour cette migration, le plan de site actuel doit contenir les URL finales de Colors, Palette et Shapes plutôt que leurs anciens chemins.

Google exige des URL absolues complètes et un encodage UTF-8 pour les plans de site. Si vous devez simplement répertorier des pages Web, un plan de site texte est accepté : une URL par ligne, sans titre ni commentaire. Voici l’exemple fictif complet de trois pages :

https://example.com/library/colors/
https://example.com/library/palette/
https://example.com/library/shapes/

Formats et exigences de Google pour les plans de site.

Si le site génère déjà un plan de site XML, conservez ce format pris en charge et mettez à jour les entrées d’URL. Utilisez des dates de modification exactes lorsque vous indiquez lastmod ; Google précise que cette valeur doit refléter les mises à jour importantes de la page. Ne remplacez pas automatiquement toutes les dates dans le seul but de donner au plan de site un air récent. Conseils de Google sur les plans de site XML.

Vérifier le résultat public depuis votre Mac

Vérifiez le résultat déployé, car un aperçu dans l’éditeur ne permet pas d’établir la réponse HTTP à l’adresse publique. Ouvrez Terminal sur votre Mac. Les commandes de diagnostic suivantes utilisent des adresses fictives : avant de les exécuter, remplacez-les par les URL publiques correspondantes de votre table. Ces exemples ne présupposent aucun résultat de migration en ligne.

old_url='https://example.com/notes/colors.html'
new_url='https://example.com/library/colors/'

curl --silent --show-error --connect-timeout 10 --max-time 30 \
  --dump-header - --output /dev/null "$old_url"

curl --silent --show-error --connect-timeout 10 --max-time 30 \
  --location --max-redirs 5 --output /dev/null \
  --write-out 'status=%{http_code}\nfinal=%{url_effective}\nredirects=%{num_redirects}\n' \
  "$old_url"

curl --silent --show-error --connect-timeout 10 --max-time 30 \
  "$new_url"

La première commande affiche les en-têtes de la réponse initiale sans suivre la redirection. La deuxième suit les redirections et indique le statut final, l’adresse et le nombre de redirections. La troisième récupère le balisage de destination pour inspection. Ces options sont décrites dans le manuel de curl.

Pour une page ordinaire de la table, attendez-vous à recevoir d’abord une réponse 301 ou 308 avec le Location prévu, puis à ce que l’adresse finale diffuse correctement le document. Examinez le balisage renvoyé pour vérifier l’URL canonique. Lisez aussi le document dans votre navigateur : une réponse HTTP réussie ne prouve pas à elle seule que le bon contenu a été transmis. Google recommande de rediriger directement vers la destination finale plutôt que de créer des chaînes de redirections. RFC 9110 : codes d’état, Conseils de Google sur le déplacement de sites.

En cas d’échec, suivez l’ordre de diagnostic ci-dessous. Il permet de relier les corrections aux résultats observables.

Observation Action suivante
L’ancienne URL redirige vers une page inattendue Corrigez la correspondance ou la règle de redirection
La redirection aboutit à une autre redirection Faites pointer directement l’ancienne adresse vers la destination finale
La page correcte comporte une ancienne URL canonique Corrigez la source des métadonnées et republiez
La navigation mène toujours à un ancien chemin Mettez à jour le lien source ou le modèle partagé
Le plan de site répertorie toujours les anciens chemins Corrigez les données d’entrée du générateur et régénérez le plan de site
Terminal signale un délai d’attente dépassé Répétez la vérification après avoir résolu le problème de connexion ; indiquez que le test est incomplet

Envoyer le plan de site et distinguer les vérifications en direct de l’indexation

Dans Search Console, sélectionnez la propriété couvrant les nouvelles URL et utilisez le rapport Sitemaps pour envoyer l’adresse publique du plan de site. Google présente ce rapport comme une méthode d’envoi qui révèle aussi les erreurs de traitement. L’envoi facilite la découverte, mais ne garantit pas l’indexation. Instructions de Google pour envoyer un plan de site.

Pour inspecter un nouveau document, saisissez son URL complète dans la barre d’inspection de Search Console. Utilisez le test en direct pour vérifier l’accessibilité actuelle et la possibilité d’indexation. Pour connaître l’URL canonique choisie par Google, consultez le résultat indexé et son champ Google-selected canonical. Le test en direct ne permet pas de prévoir le choix de l’URL canonique. Outil d’inspection d’URL de Search Console.

Cet exemple concerne des changements de chemin sur un même hôte ; l’outil Change of Address ne s’applique donc pas. Google demande aux éditeurs qui déplacent des pages d’appliquer des redirections et de mettre à jour les plans de site. Cet outil est destiné aux migrations de domaine ou de sous-domaine, une fois le site déplacé et les redirections configurées. Outil de changement d’adresse de Search Console.

Conservez la table de correspondance comme registre de maintenance. Ne marquez une ligne comme terminée qu’une fois la redirection publique, le contenu de destination, les liens, l’URL canonique et le plan de site concordants ; consignez séparément les observations ultérieures sur l’indexation par Google. Conservez les redirections aussi longtemps que possible — les conseils généraux de Google sur les migrations recommandent au moins un an — et continuez à utiliser les adresses finales lors de futures modifications de documents. Conseils de Google sur les migrations.

Sources