Retour d'expérience : bonnes pratiques à appliquer en cas de déréférencement Google (et autres) | bioinfo-fr.net

[Ldfa]

Avertissement : cet article déroge exceptionnellement à la ligne éditoriale que nous nous sommes imposées depuis le début de l'aventure. Nous n'allons pas parler de bioinformatique de près ou de loin dans cet article. Quoique les plus enthousiastes d'entre vous pourraient dire que cela peut arriver à une application web bioinfo 🙂

Mise en bouche

Nous avons malheureusement, et à notre grande surprise, vécu récemment un déréférencement inattendu de tous les plus gros moteurs de recherche connus et reconnus : Google, Duckduckgo, Yahoo, Bing, Lycos, ... Tous sans exception nous ont d'un coup d'un seul effacé du réseau. Net, propre, sans bavure. Nous n'existions plus pour eux. Calmez-vous, calmez-vous ! Reprenez votre respiration, nous ne sommes pas du genre à tout lâcher sous prétexte que notre tête ne revient plus à quelques robots d'indexation. D'ailleurs pas de panique (et spoiler), à l'heure où ces lignes sont écrites, le problème est résolu.
Mais les 5 ans de clics et de partages d'articles que vous aviez réalisés jusqu'alors semblent encore bien éloignés par rapport au score total, appelé aussi "ranking", que nos chers moteurs de recherche nous attribuent maintenant. Pour un rapport chiffré (nos amis statisticiens apprécieront), d'après Alexa, nous aurions perdu pas moins d'environ d'un million de places, rien que ça. Même pas mal.

Impression d'écran du site Alexa.com

La découverte du problème

Pour rappel, nous sommes actuellement 4 administrateurs à se relayer sur bioinfo-fr. Chaque semaine un administrateur est de garde et un autre est désigné pour le suppléer en cas de problème ou l'aider en cas de surcharge de travail soudain. Ce début d'année 2017 chargé pour nous 4 pourra sans doute expliquer le manque de réactivité de notre part par rapport au problème. Mi-janvier 2017 nous avions en effet entamé un fil de discussion entre-nous concernant une perte de place dans les recherches Google. Après plusieurs échanges, nous pensions que la nouvelle politique des géants du web en matière de full HTTPS pour tout le monde était la raison première de cette perte de score. Nous décidions donc d'entamer une migration d'HTTP à HTTPS pour l'ensemble du blog. Celle-ci a commencé en février 2017 et devait se dérouler en plusieurs étapes, étalées dans le temps suivant nos disponibilités.

Puis un jour, avant qu'on finisse notre migration, plus rien. Black-out. Nous n'étions plus trouvables... Qu'avions-nous fait ? Était-ce le fruit d'une mauvaise manip dans nos étapes de migration ? Notre certificat affichait un warning, peut-être que nous n'avions pas eu de chance et que les robots indexeurs étaient passés par là au mauvais moment... Que faire ? Nous n'avions jamais fais face à un problème de la sorte pour aucun d'entre-nous. L'enquête était ouverte.

Message de warning apparaissant lorsque le déréférencement est arrivé

L'enquête

Nous partions donc de zéro, il fallait tout envisager. Tout d'abord il fallait essayer de comprendre. Si nous réussissions à savoir quand cela avait commencé, peut-être que nous pourrions corréler une date à une action précise faite sur le blog (migration, nouveau plugin, nouveaux réglages, ...). Cela pouvait être tout et n'importe quoi. Un petit tour sur notre compte Google Analytics allait surement nous aider.

Ok... Donc pour résumer voilà ce que cela nous a appris : depuis début janvier 2017 nous sommes passés de pics de fréquentation à 750/800 visites par jour lors d'une publication d'article à "seulement" 100/150. Nous étions donc dans le juste, il y avait bien quelque chose de louche. (note au lecteur qui se dit à cet instant "mais il leur à fallu 3 mois pour avoir l'idée de vérifier leurs stats ?!", eh bien... on vous l'a dit : on était assez occupés, première faille identifiée et mauvais point pour nous, on vous le concède).

Nous avions donc une fourchette de dates, autour du 9 janvier.
Avec le temps, nous avons appris à nous organiser et à noter TOUTES les actions que nous entreprenons sur le blog lors de nos semaines d'admin de garde. Ce fichier de log épluché, aucune action ne fut recensée dans cette plage de dates. Dommage, ç'eût été trop simple.

Nous avancions quand même : on pouvait dire que ce n'était pas une action imputable à l'administration du blog, ni au début de la migration en HTTPS (qui avait commencé quelques semaines plus tard).

Nous voilà repartis dans les méandres des mystères de l'indexation, du ranking, des algorithmes des moteurs de recherches, ...

Nos recherches nous ont alors amenées à un éventuel candidat pouvant nous apporter une explication à nos soucis : sitemap.xml (je passe sous silence ici une modification minime du robots.txt, mais ça aurait pu aussi être de sa faute).

Notre ami le fichier sitemap.xml

Les bilingues l'auront compris, il s'agit d'un fichier chargé de décrire le plan du site. Ce fichier est l'une des premières choses qu'un robot indexeur va chercher en arrivant sur une page. Chez nous, c'était bien simple il n'y en avait pas. Du coup, on se documente, on regarde comment c'est structuré (il y a une convention à respecter, comme pour un bon vieux SBML) et on voit qu'il est possible de le générer facilement via plusieurs plugins qui proposent en plus de cela tout une ribambelle d'options censées aider à l'indexation d'un site. Super, ça nous fera gagner du temps et de la visibilité. On se met d'accord sur celui qu'on sent le mieux, on l'installe et on lance la génération du sitemap.xml tout beau, tout propre, tout comme il faut.

Pour info, voici notre bô sitemap.xml :

<?xml version="1.0" encoding="UTF-8"?><?xml-stylesheet type="text/xsl" href="//bioinfo-fr.net/main-sitemap.xsl"?> <sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"> <sitemap> <loc>https://bioinfo-fr.net/post-sitemap.xml</loc> <lastmod>2017-03-31T22:47:55+02:00</lastmod> </sitemap> <sitemap> <loc>https://bioinfo-fr.net/page-sitemap.xml</loc> <lastmod>2015-05-06T21:46:32+02:00</lastmod> </sitemap> <sitemap> <loc>https://bioinfo-fr.net/attachment-sitemap.xml</loc> <lastmod>2017-03-31T22:47:26+02:00</lastmod> </sitemap> <sitemap> <loc>https://bioinfo-fr.net/category-sitemap.xml</loc> <lastmod>2017-03-31T22:47:55+02:00</lastmod> </sitemap> <sitemap> <loc>https://bioinfo-fr.net/post_tag-sitemap.xml</loc> <lastmod>2017-03-31T22:47:55+02:00</lastmod> </sitemap> <sitemap> <loc>https://bioinfo-fr.net/post_format-sitemap.xml</loc> <lastmod>2016-10-18T10:04:00+02:00</lastmod> </sitemap> </sitemapindex>

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

<?xml version="1.0" encoding="UTF-8"?><?xml-stylesheet type="text/xsl" href="//bioinfo-fr.net/main-sitemap.xsl"?> <sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">     <sitemap>         <loc>https://bioinfo-fr.net/post-sitemap.xml</loc>         <lastmod>2017-03-31T22:47:55+02:00</lastmod>     </sitemap>     <sitemap>         <loc>https://bioinfo-fr.net/page-sitemap.xml</loc>         <lastmod>2015-05-06T21:46:32+02:00</lastmod>     </sitemap>     <sitemap>         <loc>https://bioinfo-fr.net/attachment-sitemap.xml</loc>         <lastmod>2017-03-31T22:47:26+02:00</lastmod>     </sitemap>     <sitemap>         <loc>https://bioinfo-fr.net/category-sitemap.xml</loc>         <lastmod>2017-03-31T22:47:55+02:00</lastmod>     </sitemap>     <sitemap>         <loc>https://bioinfo-fr.net/post_tag-sitemap.xml</loc>         <lastmod>2017-03-31T22:47:55+02:00</lastmod>     </sitemap>     <sitemap>         <loc>https://bioinfo-fr.net/post_format-sitemap.xml</loc>         <lastmod>2016-10-18T10:04:00+02:00</lastmod>     </sitemap> </sitemapindex>

Ni plus, ni moins que des informations sur des chemins menant à d'autres fichiers XML. Ceux-ci permettront d'aller plus loin dans l'arborescence et la description du site. En prime, des horodatages correspondants aux derniers changements recensés sur ces pages.

Du coup, maintenant qu'on montre patte blanche aux robots c'est gagné ?! Vous êtes sûrs ? Comment savoir sans avoir à attendre une semaine, voire un mois et constater que nos articles reviennent "dans le game"...ou pas ?

Google Search Console

C'est à ce stade qu'on a découvert THE outil, et c'est Google (notre bourreau du moment) qui le met à notre disposition, "weird" comme diraient nos copains anglais ou ironie du sort comme on dit chez nous.

Google Search Console c'est un peu LA boite à outil du webmaster pour tester l'indexation de son site (et son bon fonctionnement). Pour en profiter, il nous faut juste un compte Google (ça tombe bien on avait ça depuis le début pour l'analytics et le Google Plus).

On déclare ensuite quel site on administre, puis on peut commencer à faire joujou ! Nous n'allons pas faire l'inventaire de tout ce que vous trouverez comme fonctionnalités, mais en voici quand même un aperçu avec cette impression d'écran du menu de navigation :

"Explorer comme Google", voilà ce qui nous a aidé à tout comprendre. Cette fonctionnalité vous permet de déclarer l'URL d'une page de votre site et de voir comment le robot de Google la perçoit.
Nous venions tout juste de créer un magnifique sitemap.xml, ça aurait été bête de ne pas demander comment il été perçu !

Ni une, ni deux, Google, mon bon Google, dit nous qui a le sitemap.xml le plus beau !

Qu...oi... ? Bon, cela a assez duré ! Que celui ou celle qui nous a jeté un mauvais sort se désigne et nous dise ce qu'il/elle veut de nous !

Blague à part, à ce stade-là nous ne faisions pas les malins, mais nous nous rapprochions indubitablement du problème et on avait maintenant un atout de taille : la vue.

La traque du coupable

L'erreur générée nous référençait une destination particulière : notre répertoire à plugins.
Avant d'aller plus loin, et de nous jeter des cailloux, il faut savoir qu'une de nos règles en matière de gestion du blog est d'installer le moins de plugins possibles. Car qui dit plugin, dit potentiellement faille de sécurité et mises à jour régulières à faire. Cet interlude faite, vos petites pierres rangées dans vos poches, continuons notre enquête dans un climat serein.
On cherche donc un  plugin répondant au doux nom de "xslt". Très bien, sauf que depuis l'interface admin de gestion des extensions rien ne porte ce nom là... Et xslt étant employé pour un format informatique, les recherches rapides ne nous donnèrent rien de mieux comme information. Forcément, c'est comme dans les films, si c'était trop simple on aurait pas pu en faire un article 🙂

Continuons. On a récupéré la vue, profitons en ! Nous avons donc désactivé la dizaine de plugins installés, puis sommes retournés faire un test dans la console search.

Ça passe !

Enfin, victoire ! Pour ceux qu'on aurait perdu : nous avions trouvé l'origine du blackout : un vilain plugin !
Mais nous ne l'avions pas encore identifié, pour cela il a fallu rallumer tous les plugins un à un et tester à chaque étape via l'outil de Google pour voir si Nono le robot arrivait à passer. Et comme on est plutôt chanceux jusque-là, on est allé jusqu'à l'avant dernier plugin à tester...

On vous passe le suspens, qui n'a que trop duré dans cet article, le coupable était "Better RSS Feeds" (actif sur le blog depuis nos débuts pour la petite histoire).
Après vérification sur le site de cet saleté (que nous ne linkerons pas pour éviter de lui faire de la pub) il s'avère qu'il est toujours disponible au téléchargement, qu'il a été choisit au moins par 2000 WordPress, mais petite consolation tout de même : ses avis récents le dézinguent. Vous êtes maintenant prévenu, n'y touchez surtout pas si vous gérez un WordPress.

Hum...ça donne envie d'essayer...

Alors ça y est ? On est clean maintenant ?

Petit récapitulatif pour ceux qui sont encore là, qu'a-t-on a réellement fait à ce stade ?

• Nous avons trouvé l'origine principale du déréférencement et l'envoyer paître dans /dev/null
• Puis passer toutes nos pages en HTTPS forcé
• Et enfin tous nos média sont maintenant en HTTPS (nous nous efforçons d'essayer de ne pas avoir de hotlinking dans nos articles, mais il y avait eu parfois quelques ratés - une vingtaine d'articles sur 250 pour les amateurs de chiffres)
• Tous nos média passent maintenant par un CDN
• On a un certificat de sécurité valide sur toutes nos pages (si vous en trouvez une ou ce n'est pas le cas, merci de nous la signaler)
• On a fait le ménage dans nos plugins et mis en place quelque chose exclusivement pour nous aider dans le référencement de nos articles

Allez, on prend un de nos articles (le plus vu au hasard) et on regarde si notre nouvel indic' s'entend avec lui.

FUUUUUUUUUUUUUUUUUUUUUUU !!!

On ne vous cache pas qu'à cette étape, des noms d'oiseaux ont fusé de toute part. Du coup on s'est dit qu'on avait continué de pas avoir de chance et on a essayé un autre article...et encore un autre... Tous pareil.
Après être sorti pour crier un grand coup avoir repris nos esprits, nous avons regardé de plus près les URL bloquées. L'une d'entre elle mentionnait clairement un appel vers sharethis.com. Pour ne rien vous cacher, on aimait bien ce plugin, il nous permettait de voir le nombre approximatif de partages des articles et du coup d'essayer de voir les sujets qui vous intéressaient plus que les autres. Mais depuis le début de notre migration en HTTPS ces compteurs avaient été remis à zéro (nouvelles adresses en HTTPS). Du coup, ça a été le dysfonctionnement de trop pour Sharethis, hop direction /dev/null également ! Des volontaires pour le suivre ? Autant vous dire qu'à cet instant chez les plugins ça ne mouftait plus trop 🙂

Pas de panique pour autant, ce qu'on a mis en place pour le référencement proposait en option d'afficher des boutons d'aide au partage sur les réseaux sociaux. De plus, ils sont assez sympas niveau design. Adoptés !

Après cela, c'est le moment du grand test. Là où la défaite n'est plus permise. Une invocation aux dieux du ranking est faite, un script Python 3.6 est sacrifié (c'est ce qu'on avait de plus propre sous la main) et l'appel de Nono le robot est relancé !

VICTOIRE ! Enfin ! Nous sommes clean, propres, lavés de nos saletés, débarassés de notre crasse, etc.

La phase de convalescence

Alors ça y est, nous voilà guéris ! Mais le mal a été fait et il a malheureusement eu le temps de s'ancrer en profondeur.
Nous espérons que grâce à nos actions, nos articles vont petit à petit être re-référencés. Mais l'inconnue majeure reste le temps que cela prendra.
Il n'y a pas de secret, le nombre de visites, de partages, de référencement sur d'autres sites ne pourra que jouer en notre faveur et seul le temps nous dira quand nous retrouverons notre vitesse de croisière.

Dorénavant, nous allons porter une attention toute particulière à notre nouvel ami qu'est la search console et qui dispose d'un bon nombre de petits outils dont nous n'avons pu pas parlé dans l'article. Un exemple parmi tant d'autre qui permet un suivi quotidien du site, les erreurs enregistrées au niveau des URLs :

Ici quand une erreur est détectée, l'URL fautive apparaît et il ne reste plus qu'à corriger le problème (souvent minime) et déclarer l'URL comme de nouveau fiable.
Pas de panique pour l'onglet qui affiche les 14 erreurs, il s'agit d'anciens liens vers les anciennes fiches auteurs qui ont changé d'URL au fil du temps. Il faudra qu'on se fasse une campagne de correction de nos très vieux articles pour mettre un terme à cela.

Conclusion et pourquoi fait-on tout cela

En conclusion, il faut maintenant vous avouer que tout cela a été fait sur notre temps libre, le soir ou/et le week-end. Cette précision afin de vous expliquer les éventuels manque de discernement envers les erreurs générées. A la relecture, je me rends compte qu'à tête reposée je n'aurais peut-être pas mis autant de temps à percuter et que j'aurais privilégié certaines pistes plutôt que d'autres. Dans tout les cas, et pour ce qui me concerne, cela m'a permis d'apprendre ÉNORMÉMENT sur tout ce qui touche le référencement (et son contraire du coup...).

De plus, on pourrait se demander pourquoi on a fait tout ça. La réponse est simple et il n'y en a qu'une : pour vous et surtout pour nos auteurs. Ils nous ont donné du temps et font ce qu'est ce blog aujourd'hui : les articles d'entre-aide et de partage de savoir. C'était juste impossible de laisser tomber tout cela maintenant, pas après plus de 5 ans d’existence, pas après plus de 250 articles publiés (et plus d'une trentaine en écriture à l'heure où sont écrites ces lignes).

Enfin, j'aimerai conclure cet article, qui j'espère aidera d'autres personnes se retrouvant malheureusement dans le même cas que nous, en remerciant mon super copain admin Yohan (alias nahoy) pour le (gros) coup de main dans l'urgence, les craintes et les instants plus plaisants partagés via nos échanges fou par messages et pour les heures de loisirs sacrifiées. Tu gères la fougère 😉 Je n'oublie pas également de remercier nos deux autres copines admins Isabelle et Gwenaëlle qui mettent énormément d'énergie dans le blog 🙂

Merci également à mes relecteurs Kumquatum, Hedjour et nahoy pour le coup de main sur ce gros pavé ! N'hésitez surtout pas à enrichir l'article en réagissant par le biais des commentaires.

Partager :

Sur le même thème

• À propos de Yoann M.

• Je suis issu d'une licence de Biologie des Organismes et du Master de Bioinformatique de Bordeaux (Promo 2011).

  J'ai été bioinformaticien à l'Ecole Polytechnique Fédérale de Lausanne (EPFL) pendant 4 ans. Tout d'abord dans le laboratoire Trono puis dans le laboratoire Duboule, je fus ensuite rattaché à la plateforme de bioinformatique et de biostatistiques de l’EPFL (BBCF) où j'ai développé BioRepo, un LIMS (Laboratory Information Management System) pour les données issues de HTS.

  Depuis début 2015, je suis en poste en tant que Bioinformaticien/Software developer au sein de l’Institut de Recherche Technologique BIOASTER à Lyon.

  Enfin, j'ai l'honneur et la fierté d'être un des fondateurs/administrateurs de bioinfo-fr.net et grand supporter des Girondins de Bordeaux.

Afficher l’article complet