Refonte surprise : ce qu’il faut vérifier en urgence

5 Commentaires

Il n’y a pas de pire situation que de découvrir une refonte de site par soi-même pour laquelle on n’a pas été consulté au préalable. On peut l’apprendre par mail quand le client nous demande une vérification du nouveau site en ligne ou par des alertes dues à une chute de positionnement, de trafic ou via son outil de monitoring de modification on-site (perso, j’utilise Visual Ping ou l’extension AlertBox).

ambulance et police au secours dune perte de trafic suite à une refonte

Dans ce cas on tire la sonnette d’alarme et on va traquer les points récurrents qui peuvent poser problème lors d’une refonte.

A la recherche de signaux défaillants des URLs de l’ancienne version

Cette étape est surement la plus importante. En général, les pages positionnées sur Google sont accessibles en suivant des liens depuis la page d’accueil (Il y a quelques exceptions avec des pages orphelines détectables avec l’analyse de log mais on est censé les avoir déjà réintégrées au maillage du site).

Je relance donc un crawl avec Screaming frog de la liste d’URLs de l’ancienne version du site que j’ai sauvegardé (je fais toujours une sauvegarde des données du crawl de chaque audit de site).

Pour faciliter la manipulation je vais exporter toutes les données sur Excel puis filtrer les URLs :

  • en 404
  • en noindex
  • en 200 avec une canonical vers une URL différente
  • en 302 (redirection temporaire)

Ce tableau va me permettre d’avoir une première vue sur la quantité et les formats d’URLs concernés par chaque cas de figure.

Les URLs en 404 et noindex sont à vérifier en priorité car ce sont potentiellement des landing pages qui généraient du trafic sur la précédente version du site. Je vais regarder si elles sont nombreuses et si ce sont des pages importantes.
J’ouvre également le TOP 10 des pages générant du trafic sur Google Analytics le mois précédent la refonte pour voir si elles sont en 404 ou noindex, puis j’ouvre 1 ou 2 pages de chaque formats en me basant sur la catégorisation d’URLs (faite lors de l’audit de l’ancien site, heureusement que je ne l’avais pas fait en une heure ;-)). Les pages importantes sont en général les pages catégorie, sous-catégorie, produit, article de blog, guide, etc.

Je note tous les formats d’URL en 404 ou noindex à traiter en urgence. Certaines fois cela pourra être justifié si ce sont des pages qui n’étaient pas importantes et que l’on ne souhaite plus faire apparaître sur le site, ce qui est rarement le cas après une refonte surprise…

Ensuite viennent les pages en 302 et les pages en 200 avec des canonicals vers des URLs différentes qu’il faudra en général remplacer par des redirections 301 qui sont plus fiables et efficaces.

Les pages interdites de crawl

Il arrive que des erreurs s’insèrent dans le fichier robots.txt lors d’une refonte, on va donc juste vérifier que des pages importantes ne sont pas bloquées par un disallow. On peut également comparer le fichier robots.txt actuel avec l’ancien via la Wayback Machine. Le nouvel outil de test du fichier robots.txt dans Google Webmaster Tools est aussi très pratique pour vérifier si une URL est bloquée par le robots.txt surtout lorsque celui ci est très long ou utilise des wildcards.

Outil de vérification robots.txt sur google Webmaster Tools

Repérer les formats de contenu dupliqué

On va maintenant chercher s’il y a du contenu dupliqué. D’abord je lance un crawl global du nouveau site à partir de la page d’accueil. J’exporte sur Excel toutes les informations du crawl, je fusionne avec la liste d’URLs de la précédente version re-crawlée (1er paragraphe), je supprime les doublons et ne garde que les URL renvoyant un code http 200 et sans canonical vers une URL différente ou en noindex. J’essaye de repérer s’il y a de la duplication en comparant les hash, title et h1 récupérés via Screaming frog.

Pour compléter la vérification sur la duplication, j’ouvre la page d’accueil du site en utilisant toujours la WayBack Machine (en espérant qu’elle ait crawlé récemment la précédente version du site) et ouvre une page de chaque format important (ex : catégorie, sous-catégorie, produit, actualité…) en suivant les liens de navigation de la WayBack Machine. Je supprime le préfixe « https://web.archive.org/web/XXXXXXXX/ » dans l’URL pour voir a quoi la page ressemble maintenant.

Parallèlement j’ouvre la page d’accueil de la nouvelle version du site en ligne et ouvre les mêmes pages en suivant les liens de navigation.

Je compare les pages accessibles depuis l’ancienne version (via Wayback Machine) avec la version actuelle :

  • Le cas le plus simple : les URLs sont les mêmes, il n’y pas de problème
  • Le pire des cas : les URLs sont différentes (co-existence de pages orphelines de l’ancienne version dupliquant les pages remplaçante). En général, il faudra préconiser d’utiliser une redirection 301

Fireman extinguishing a brazier royalty free stock photograph 2014-08-22 15-34-25

Conclusion

Les refontes sont planifiées par les propriétaires de sites pour différentes raisons : une envie d’améliorer l’UX et le taux de conversion avec un meilleur design et ergonomie, une envie de changer de CMS car celui-ci n’est plus adapté ou tout simplement une envie de changement comparable à un achat compulsif pendant les soldes !

Lors d’une refonte imprévue, je me penche en priorité sur les anciennes pages indexées qui doivent être accessibles et indéxables ou redirigées convenablement pour ne pas perdre le trafic acquis.

Evidemment, je suis majoritairement consulté en amont du projet de refonte mais j’ai eu quelques fois de petites surprises de ce genre et malheureusement on ne peut jouer qu’au pompier pour limiter les pertes…

Et vous comment gérez-vous les refontes surprise ?

Abonnez-vous à notre Newsletter !

Les champs avec une * sont obligatoires
5 Commentaires
  1. Répondre

    @LB : Quand on fait une refonte on prend toujours le risque de subir des baisses. Après lorsque tout est bien fait (surtout au niveau des redirections) en amont avant la mise en ligne de la nouvelle version et donc avant le nouveau crawl de Google, les baisses peuvent être faibles ou inexistantes (certaines pages vont perdre un peu et d’autres vont gagner quelques positions) car on ne donnera pas le choix à Google et donc des problème d’interprétation du contenu dupliqué créé lors d’une mauvaise refonte de site.

    @Florian : on va dire que ça met un peu de piment dans notre journée lorsque ça arrive 😉 mais si on pouvait éviter…

  2. Répondre

    Ca fait longtemps que ça ne m’est pas arrivé, mais c’est vrai qu’on adore ce moment où l’on réalise qu’il va falloir tout refaire (cf nouvelle quotation en pj :p)

    • LB
    • 4 septembre 2014
    Répondre

    Je dois avouer pour ma part, que tous ces risques liés à la refont d’un site me freine un peu..
    Est-il possible d’avoir une refonte d’un site internet sans baisser en référencement naturel?

  3. Répondre

    @Patrice : On sera toujours confronté de temps en temps à ce cas de figure même en ayant averti le client du process à suivre lorsque l’idée d’une refonte est envisageable.
    Il faut que l’on soit organisé pour repérer ça rapidement et remettre tout en ordre le plus rapidement possible pour limiter la casse.

  4. Répondre

    Je vois que c’est partout pareil, on y a tous eu droit au moins une fois ( dans mon cas plus de 5 fois… ) , et la, c’est l’histoire du référenceur qui fond comme du chocolat au soleil devant son écran, et le client au téléphone qui vous dis, « je ne comprends pas on a disparu de google, il faut faire quelque chose »….

 

Ajouter un commentaire