Liste de contrôle de migration de site : de J-4 semaines au jour 45

Un 301 qui se termine par un 404 ne conserve rien

Certaines équipes envoient toutes les anciennes URL vers la nouvelle page d'accueil et laissent les pages de destination expirer plus tard. La redirection elle-même fonctionne. C'est pourquoi cette habitude est risquée, car chaque saut semble propre dans un journal tandis que la page à l'extrémité répond par une erreur 404.

Imaginez que vous déplacez une boutique vers un nouveau domaine et que vous ne conservez que les produits qui se vendent encore. Les pages de catégorie qui concentraient la plupart des liens externes rebondissent maintenant vers rien d'utile. Comptez les URL liées de l'extérieur avant de mettre quoi que ce soit hors ligne. Faites-en la première étape. Une page avec des domaines référents a besoin d'une cible active sur le même sujet, pas d'un haussement d'épaules.

Gardez la règle courte : un saut, puis un 200 final. Tout le reste est une fuite que vous avez choisie.

Ce qu'une redirection 301 en un seul saut vers une page active protège

La valeur d'un lien réside sur l'URL vers laquelle il pointe. Une redirection transporte cette valeur uniquement si l'adresse d'arrivée répond et correspond toujours au sujet. Un produit déplacé vers le même produit dans le nouveau catalogue passe ce test, tandis qu'un produit envoyé vers la page d'accueil ne le passe généralement pas, même si c'était la page vers laquelle tout le monde faisait un lien.

Revérifiez le statut final après chaque modification de modèle. Une redirection qui fonctionnait au lancement peut se terminer par un 404 après une version ultérieure, lorsque quelqu'un supprime une catégorie lors d'un nettoyage de menu.

Quand un 410 est la réponse honnête

Certaines anciennes URL n'avaient ni liens, ni visites, ni remplacement réel. Pour celles-ci, un 404 clair ou un 410 est plus honnête qu'une redirection vers une page qui ne répond pas à la question que l'ancienne posait. Une redirection vers une page non liée est souvent traitée comme un soft 404, donc elle ne sauve rien.

Notez la décision pour chaque groupe d'URL, avec la raison à côté. Un dossier de tutoriels retirés reçoit une réponse différente d'un dossier de pages avec quatre-vingts domaines référents, et vous voudrez expliquer cette différence à un collègue dans six mois.

Vérifier le dernier saut, et pas seulement le premier

La plupart des tests de redirection s'arrêtent à la première réponse, ce qui est le mauvais endroit pour s'arrêter. Suivez la chaîne jusqu'à sa fin, puis enregistrez le nombre de sauts et le statut final à côté de l'ancienne URL. Une chaîne de deux sauts n'est pas cassée, mais elle ajoute du délai et un endroit supplémentaire où une règle peut échouer.

Si un script est hors de portée, une feuille de calcul et quelques appels curl feront l'affaire. La page des scripts API propose une version que vous pouvez planifier.

Sitemaps et demandes manuelles après le lancement

Conservez l'ancien sitemap accessible pendant quelques semaines après le déplacement. Les robots qui revisiteront l'ancien hébergeur pourront toujours trouver ces adresses dans une seule liste, ce qui accélère leur premier passage à travers les redirections.

Les demandes manuelles sont un outil différent. Utilisez-les pour les quelques pages qui comptent le plus, pas pour des centaines d'URL soumises une par une. Une page demandée sans liens internes et au contenu léger a tendance à être retirée à nouveau, donc la demande n'est bonne que si la page derrière elle l'est aussi.

Attendre est un plan valide. Donnez du temps au crawl, puis jugez-le sur les données.

Conserver l'ancien sitemap listé pendant un certain temps

Laissez l'ancien sitemap dans Search Console jusqu'à ce que les anciennes URL cessent d'apparaître dans les statistiques de crawl. Ensuite, supprimez-le intentionnellement et notez la date dans le journal de migration.

Ne le supprimez pas le jour du lancement juste pour rendre la propriété plus propre. Une suppression précoce masque la seule liste qui nomme chaque ancienne URL que vous devez encore suivre.

Demander l'indexation pour les pages qui portent des liens

Sélectionnez les vingt nouvelles URL avec le plus de liens externes, en utilisant la même jointure que vous avez créée pour la carte de redirection, et demandez-les à la main. L'effort suit alors le risque au lieu de la taille du site.

Si une page demandée est toujours manquante après quelques semaines, examinez la page avant de demander à nouveau. Vérifiez ses liens internes, son canonical et son contenu. Une cinquième demande ne changera rien.

Combien de temps avant que le déplacement puisse être jugé

Jugez le déplacement à partir de la deuxième extraction de liens, et non de la première. Notre index s'actualise environ une fois par mois, donc une extraction au jour trois montre surtout l'image du mois dernier. Exécutez la deuxième extraction après l'actualisation, et utilisez-la pour trouver tous les backlinks vers un site web sur le nouvel hébergeur.

Le rapport Pages et les données de liens répondent à des questions différentes. Lisez-les côte à côte, et non comme des verdicts concurrents sur le même déplacement.

Surveiller le site après le lancement, et pas seulement avant

Un audit pré-lancement enregistre ce qui était vrai le jour où il a été exécuté. La plupart des dommages du lancement apparaissent plus tard, après une mise à jour de plugin, un changement de règle CDN ou un modèle qui touche à un paramètre que personne n'a examiné.

Traitez la surveillance post-lancement comme un ensemble de petites différences par rapport à une sauvegarde de référence. Aucun tableau de bord n'est nécessaire. Un calendrier et un dossier de fichiers datés suffiront.

Ce qu'une surveillance hebdomadaire devrait comparer

Sélectionnez les vérifications qui auraient le plus mal si elles changeaient, et exécutez-les le même jour chaque semaine.

• Code de statut et URL finale pour les 50 anciennes URL les plus liées
• Robots.txt et la balise meta robots sur les modèles principaux
• Nombre d'URL 200 actives contre le nombre dans le nouveau sitemap
• Balises canonical sur la page d'accueil, une catégorie et un article

Pourquoi un audit ponctuel rate la dérive lente

Les paramètres dérivent après le lancement. Un indicateur de test laissé activé, un plugin qui réécrit les permaliens, ou une redirection ajoutée pour corriger une page peuvent chacun annuler une partie du plan. Un audit pris le jour du lancement ne peut rien voir d'eux.

Une différence planifiée, si. Conservez les fichiers de référence dans le contrôle de version et comparez la sortie de chaque semaine avec eux, afin qu'un changement inattendu soit visible le jour où il se produit.

Sous-domaines, suppressions et changements de domaine à l'échelle du site

Certaines équipes déplacent une section vers un sous-domaine et n'indexent que ses pages populaires. Cela peut fonctionner. Le coût est que les liens destinés aux pages moins populaires atterrissent maintenant sur un hébergeur avec moins d'historique, donc comptez-les avant de supprimer quoi que ce soit.

Les demandes de suppression sont plus étroites qu'elles n'y paraissent. Search Console applique une suppression à la propriété où vous la déposez, donc une demande faite sur un sous-domaine n'agit pas sur le domaine principal. Vérifiez d'abord la propriété. Ensuite, soumettez, et conservez les deux vérifiées.

Indexer uniquement les pages populaires sur un sous-domaine

Commencez par les liens par URL dans cette section. Les pages qui portent des liens externes mais peu de trafic sont les premières qu'une règle uniquement pages populaires cachera. Conservez-les crawlables, ou redirigez chacune vers sa page populaire la plus proche et notez la raison à côté de la règle.

La façon dont le site principal lie au sous-domaine décide de la facilité avec laquelle ses pages sont trouvées. Listez ces liens avant de choisir quelles pages resteront cachées, car une page que le site principal ne lie jamais est difficile à atteindre de toute façon.

Un changement de domaine à l'échelle du site, page par page

Une règle à l'échelle de l'hébergeur gère la racine, mais un changement de domaine nécessite également une carte au niveau du chemin. Lorsque la première partie de l'URL change et que le slug reste le même, un échange d'hébergeur couvre la plupart des pages, et les exceptions nécessitent leurs propres lignes.

Construisez la liste à partir des pages liées en premier, puis associez chaque ancien chemin à son nouveau. La recette de la carte de redirection montre comment classer cette liste par liens.