Analyse des changements de liens liés à une migration

Construisez la carte de redirection avant le lancement

La carte de redirection est la partie d'une migration que les gens sous-estiment. Les destinations sont primordiales. Avant d'analyser les données de liens après une migration, les anciennes URL doivent avoir une destination claire, car ce sont les adresses vers lesquelles vos liens pointent déjà.

Le un-à-un bat le dump sur la page d'accueil

Envoyer des centaines d'anciennes URL non liées vers la page d'accueil indique très peu de chose aux moteurs de recherche et aux visiteurs. La pertinence est le test. Mappez chaque ancienne URL à forte valeur vers sa nouvelle page la plus proche, et envoyez le reste vers une section qui correspond encore à leur sujet.

Exportez d'abord les anciennes URL avec leurs codes de statut. Conservez ce fichier en sécurité. Ce fichier est la liste de contrôle, et il montre quelles pages ont gagné des liens.

Lorsqu'une page n'a pas de correspondance proche, indiquez-le dans la carte et envoyez-la vers la section la plus proche, avec une note. Les cellules vides cachent les choix. Une cellule vide dans le tableau est une décision que personne n'a prise.

Aplatissez les chaînes avant le lancement

Une redirection qui passe par deux règles antérieures avant d'atteindre la nouvelle page ajoute du délai et des risques. Les chaînes sont faciles à créer lorsqu'une deuxième migration se superpose à la première, donc examinez la carte avant chaque changement plutôt que de supposer qu'elle est encore propre. Chaque saut supplémentaire a un coût. Demandez chaque ancienne URL une fois après le changement et confirmez qu'elle répond avec un seul saut.

Corrigez-le tôt. Corrigez les chaînes dans la carte elle-même, et non une par une après le lancement, afin que la liste reste courte.

Conservez les chemins qui fonctionnent encore

Modifier la structure des URL dans une refonte est la perte la plus évitable. Chaque changement de chemin est aussi un changement pour chaque lien qui pointe vers lui, et ces liens sont hors de votre contrôle. Conservez ce qui fonctionne. Si un chemin fonctionne encore, gardez-le, et ne changez que ce que la migration vous force à changer.

Moins de redirections, moins d'erreurs. Chaque chemin que vous conservez est un lien qui n'a jamais eu besoin d'une redirection.

Un chemin conservé signifie que les anciennes lignes d'ancres continuent de pointer quelque chose d'utile, ce qui est une chose de moins à reconstruire dans le tableau. Moins de reconstruction plus tard.

Ce à quoi s'attendre après

Elles font le travail lourd, et une 301 de l'ancienne URL vers la nouvelle URL permet aux anciens liens de continuer à fonctionner. Conserver une redirection par ancienne URL, sans chaîne intermédiaire, est le moyen le plus simple de conserver la valeur de chaque lien intacte. Redirections. Les chaînes de trois ou quatre saits ralentissent les robots et doivent être aplatis.

Le texte d'ancre ne change pas quand une URL bouge, car le texte vit sur la page qui lie. Ce qui change, c'est le compte des destinations : votre tableau de pages principales montrera l'ancien hôte s'estomper et le nouveau monter sur quelques rafraîchissements mensuels. Les destinations changent lentement.

Une surprise courante est de supprimer trop tôt l'ancienne plateforme. Ne le faites pas. Squarespace, Wix et des hébergeurs similaires maintiennent souvent les règles de redirection, donc annuler l'abonnement peut les supprimer, et les liens pointent alors vers une impasse jusqu'à ce que vous reconstruisiez les règles ailleurs.

Hreflang et canoniques méritent aussi un regard. Les incohérences sont courantes. Après une migration de CRA vers Next.js, par exemple, les sites se retrouvent souvent avec des balises canoniques qui ne correspondent pas à leurs ensembles hreflang, et les liens se divisent entre deux versions d'une page.

Si les nombres ne correspondent pas après la migration, vérifiez le tableau de dépannage avant de supposer que des liens ont été perdus. Un seul rafraîchissement mensuel explique beaucoup d'écarts. Les écarts sont souvent une question de timing.

Attendez la première comparaison propre environ deux rafraîchissements mensuels après le lancement, et notez la date de chaque rafraîchissement dans votre tableau pour qu'un mois plat ne soit pas confondu avec un mois bloqué. Donnez-lui du temps. Ahrefs ou Semrush peuvent combler l'écart avec des crawls plus frais si vous avez besoin d'une lecture intermédiaire.

Surveillez ce qui bouge sans annonce de lancement

Le jour du lancement a une liste de contrôle, mais plusieurs problèmes arrivent plus tard et discrètement. Ils apparaissent dans les lignes et dans l'index, longtemps après que l'équipe ait passé à d'autres travaux. Ils sont faciles à manquer.

Noindex qui voyage avec une build de staging

Une copie de staging qui a été exclue des recherches peut transporter ses paramètres dans le site live. Vérifiez les balises meta robots et tout en-tête noindex lors du premier crawl, et échantillonnez des pages de chaque section plutôt que seulement la page d'accueil. Échantillonnez chaque section.

Les modèles cassent en premier. Si une section entière disparaît de l'index après le lancement, regardez son modèle avant de regarder son contenu.

Les captures d'écran aident aussi. Conservez une copie des paramètres robots de la build de staging aussi. Quand quelque chose disparaît de l'index, comparer les deux ensembles de paramètres prend quelques minutes plutôt qu'un après-midi.

Liens fragmentés qui sont indexés

Les liens d'ancrage comme un sommaire peuvent apparaître comme des URL séparées dans les résultats de recherche. Les moteurs de recherche plient généralement ces liens dans la page principale, mais quand ils ne le font pas, le même contenu peut apparaître sous plusieurs adresses. Ils divisent les signaux de la page principale, et ils peuvent ressembler à des pages dupliquées dans un rapport de couverture. Les URL avec hachure se multiplient discrètement.

Une version, une adresse. Une balise canonique qui pointe vers une adresse alors que le sitemap en liste une autre envoie des signaux mixtes, et le rapport montrera l'incohérence. Définissez une version canonique pour chaque page et confirmez que le sitemap liste la même version.

Vérifiez le rapport de couverture après le lancement pour les URL avec un hachure, car ce sont celles qui se multiplient discrètement. Les hachures sont les coupables.

Un sous-domaine qui devient le domaine principal

Déplacer un site d'un sous-domaine de staging vers le domaine principal apporte ses propres doublons, car les deux versions peuvent rester accessibles pendant un certain temps. Décidez quel hôte est canonique avant le lancement. Choisissez l'hôte tôt.

Un hôte, partout. Quand un hôte change à un endroit et pas à un autre, la version plus ancienne peut continuer à collecter des liens pendant des mois sans que personne ne le remarque. Ensuite, gardez le sitemap, les balises canoniques et tout ensemble hreflang pointant vers cet hôte unique.

Liens do-follow qui semblent disparaître

Après une refonte, les lignes do-follow dans un outil peuvent chuter brusquement, et la première supposition est que les liens sont partis. Comparez les anciennes pages principales avec les nouvelles avant d'accepter cette supposition, puis vérifiez si chaque ancienne adresse redirige maintenant correctement. Vérifiez avant de paniquer.

Corrigez celui-là en premier. Un lien qui existe encore sur la page qui lie mais qui pointe vers une adresse morte est le cas à corriger en premier.

Définissez la date tôt. Donnez à l'équipe une date fixe pour la comparaison, afin que personne ne relance la collecte tous les jours et ne lise du bruit comme de l'actualité.

Travailler avec un développeur pendant la migration

La plupart du travail de redirection incombe à un développeur, et la surveillance incombe à celui qui lit le tableau. Écrire la répartition sous forme de court tableau, avec un nom dans chaque cellule, est souvent suffisant pour empêcher deux personnes de supposer la même tâche. Séparez ces rôles sur papier avant le lancement, afin que personne ne suppose que l'autre surveille. Les rôles ont besoin de noms.

Donnez au développeur une carte, pas une liste de tâches

Une liste de tâches dit à un développeur quoi faire, tandis qu'une carte montre quelle ancienne adresse va où. Envoyez le tableau un-à-un avec les codes de statut et la raison pour chaque ligne, afin que les cas limites reçoivent une décision plutôt qu'une supposition. Les décisions battent les suppositions.

Les plans de test viennent en premier. Demandez un court plan de test qui commence avec les anciennes adresses du fichier de pages principales.

Entendez-vous sur qui lit le fichier mensuel

La première comparaison propre vient environ deux rafraîchissements après le lancement, et le fichier aura besoin d'un lecteur. La première lecture après le lancement est généralement bruyante, et un lecteur qui le sait évitera de réagir à un mois inhabituel. Nommez cette personne, le jour où elle l'ouvre, et le tableau où le résultat va. Quelqu'un doit en être propriétaire.

Les dates règlent la question. Écrire la date de rafraîchissement à côté de chaque fichier transforme une inquiétude concernant un index bloqué en un fait simple sur le calendrier. Un mois plat est facile à mal lire comme un mois bloqué à moins que quelqu'un n'écrive les dates de rafraîchissement.

Demandez à cette personne d'écrire une ligne par rafraîchissement, même quand rien n'a changé, afin que le fichier garde un enregistrement continu. Une ligne à chaque fois.

Planifiez le retour arrière avant le lancement

Si le nouvel hôte casse un chemin critique, l'équipe a besoin d'un moyen de retour qui a été testé à l'avance. Écrivez les étapes, y compris qui peut actionner l'interrupteur et comment se comportent les redirections pendant qu'il est annulé. Répétez-le avant le lancement.

Écrivez le retour arrière. Un retour arrière qui n'existe que dans la tête d'une personne n'est pas un plan.