Lutte anti Duplicate Content : l’Admin Sys est votre ami

L’administrateur système est votre allié pour optimiser votre SEO

Publié le 13/04/2010 à 18:11 par - Mis à jour le 20/09/2016 à 14:39

 

Le Duplicate Content, sans générer de pénalisation de la part des moteurs de recherche reste pénalisant pour un site Internet car il réduit la base de pages indexables et rend invisible et inopérant une partie du maillage interne de liens.

L’administrateur système est votre allié pour l’éradiquer de votre site web.

 

Qu’est ce que le Duplicate Content (ou DC)

On dit que l’on a du Duplicate Content sur un site lorsqu’on peut y trouver 2 pages ou plus rigoureusement identiques indexables par un moteur de recherche. Que ce soit volontaire ou pas, cela peut aboutir à la suppression pure et simple de l’index principal d’une des deux, voire des deux pages indexées. Les pages en duplicat seront alors placées dans l’index complémentaire du moteur, dans lequel elles ne génèreront aucun trafic et ne seront pas ou presque plus crawlées.

 

Pourquoi il est important de lutter contre le Duplicate Content

  – Augmenter la base de pages indexables

On le sait, plus un site comporte de pages et plus il a de chances de générer de trafic et de bénéficier de l’effet longue traîne. A moins que l’on ne soit un très très gros site (et même si…) chaque page additionnelle est bonne à prendre.

Or, dans les pages qui se retrouvent prises dans les filtres anti duplicate se trouvent des pages qui ne sont pas à proprement parler des contenus dupliqués, mais qui sont considérées comme telles par Google pour de multiples raisons, mais souvent pour cause title et/ou méta identiques.

Lutter contre le duplicate content c’est donc permettre au moteur de prendre en compte plus de pages.

  – Donner au maillage interne tout son potentiel

Le linking interne depuis des pages en duplicat a un pouvoir de vote quasi nul. C’est donc autant de jus de perdu. Dommage…

  – Empêcher la déperdition de jus de lien

Lorsqu’une page unique est accessible par plusieurs urls, c’est autant de chances que les liens externes qui sont faits vers elle se portent alternativement vers l’une ou l’autre des urls. Pour le linking interne c’est déjà par définition le cas (sinon il n’y aurait pas de pages en duplicate indexées par les moteurs…)

  – Faciliter la vie du moteur et améliorer la qualité de crawl

Le temps de crawl des moteurs est précieux. Leur objectif : indexer un maximum de contenus uniques en un minimum de temps et en définir facilement le degré d’importance ou de fraîcheur.

En ayant beaucoup de pages en duplicate content, clairement on leur complique la vie : il a plus de pages à crawler et ils doivent ensuite distinguer le bon grain de l’ivraie. Et parfois la surprise est mauvaise : l’url qui ressort n’est pas tout à fait celle que l’on souhaiterait.

Lorsque l’on sait qu’un crawl complet sur un site de taille moyenne n’est pas extrêmement fréquent, on se rend compte qu’on a tout à gagner à ne pas lui faire perdre du temps avec des contenus inutiles afin qu’il se concentre ce qui doit réellement être exploré : nouveaux contenus, contenus mis à jour, maillage.

 

En quoi votre Admin Sys peut vous y aider

  – Définition d’un domaine canonique / d’une page d’index canonique

Si le site est accessible via http://www.monsite.fr et http://monsite.fr (ce qui est plutôt une bonne chose pour l’internaute), il ne faut pas oublier d’ajouter une règle de réécriture renvoyant l’url sans le www vers l’url avec le www.

C’est une erreur assez commune mais elle est gênante, car le site dans son entier peut potentiellement être indexé dans sa totalité en duplicat…

De la même manière, on peut avoir du Duplicate Content si la page d’accueil, ou des homes de rubrique sont accessibles via deux urls ou plus. Malheureusement, on voit ça tout le temps sur le web : http://www.monsite.com/index.html, http://www.monsite.com/index.htm, http://www.monsite.com/index.php, http://www.monsite.com/accueil.php, etc.

On trouve aussi de nombreux cas de duplicate content à cause du Slash final ou pas dans l’url. En effet http://www.monsite.com/mon-repertoire et http://www.monsite.com/mon-repertoire/ sont bien deux urls différentes pour les moteurs…

Google recommande d’utiliser de manière systématique le slash final pour toutes les pages correspondant à des vues de répertoire, afin de faciliter la canonicalisation. Cela semble de toute façon une bonne pratique.

La solution : des redirections 301

Comment : identifier les types de pages qui posent problème et travailler avec l’Admin Sys au meilleur compromis « gain SEO/ Performance/Pérennité »

A noter : certains paramétrages sont réalisables via le Google Webmaster Tools

  – Neutralisation des codes de tracking

Pour de multiples raisons mais très souvent pour des raisons de tracking, on voit surgir des paramètres dans les urls. Par exemple »?xtor=xxx » chez ceux qui utilisent l’outil de stats Xiti et qui traquent leurs liens sponsorisés ou leurs flux RSS.

Dans ce cas le duplicate est particulièrement gênant : les flux RSS sont éditorialisés et beaucoup de jus de lien provient de ces urls en duplicat.

La solution : rediriger en 301 les pages comportant ces paramètres vers leur version canonique

Comment : analyser les infos de pages en duplicat dans le Google Webmaster Tools et établir une liste exhaustive des paramètres félons.

A noter : certains paramétrages sont réalisables via le Google Webmaster Tools, vous pouvez aussi utiliser la balise Canonical

  – Redirection des urls à variable de session

C’est un problème que l’on rencontre de mois en moins (l’évangélisation SEO gagne du terrain ?) mais certains sites passent encore les paramètres d’identification de session dans les urls. Les moteurs se retrouvent alors avec un volume exponentiel de Duplicate Content.

C’est définitivement un procédé à bannir. Mais il faut néanmoins traiter le problème lorsqu’on s’y retrouve confronté.

La solution : rediriger en 301 toutes les urls contenant le paramètre id vers leur version dans id.

Comment : faire quelques requêtes dans le moteur pour voir l’étendue des dégâts de manière à évaluer si le jeu en vaut la chandelle (gain versus charge serveur additionnelle) et si la réponse est oui, lister les paramètres correspondant à de la session utilisateur.

  – Refonte de site, déplacement de contenus

Dans ces situations, il est impératif de rediriger le maximum de contenus vers leur nouvelle adresse.

Un travail main dans la main avec votre Admin Sys vous permettra de passer ce moment crucial en toute sérénité, sans pour autant faire tomber le site sous le poids d’une liste de redirections longue comme le bras

 

Comment faire du SEO sans Admin Sys ?

Bah moi, je ne sais plus comment je faisais sans !

Google est très conscient de ces problématiques et veut lui aussi gagner du temps serveur (le temps serveur, c’est de l’argent…), c’est pourquoi il a mis à notre disposition des outils dans le Google Webmaster Tools et une balise spécifique.

De manière générale, je me méfie toujours de l’optimisation facile à réaliser mais qui reste une boite noire en terme de mesure a posteriori. Et puis, la balise sur mesure, Google nous a déjà fait le coup avec NoFollow…

Aucun patch ne remplace une véritable stratégie de lutte anti duplicate content. Il faut commencer par disposer d’une architecture de l’information logique et pensée puis ensuite enclencher un processus qualité et mesurer, mesurer, mesurer.

Et là encore, votre Admin Sys pourra vous être d’une aide précieuse, car il est le grand maître des logs…

C’est un travail de longue haleine qui met longtemps à porter ses fruits, mais le bénéfice sera au rendez-vous.

Partager sur les réseaux

 

6 Commentaire (s)

Nicolas Laustriat

sympa ta récap…

be tu parle pas de l’aide de l’admin sys sur le temps de chargement des pages…;-)

sinon j’ai jamais réussi à démontré si le fait d’avoir trop de rewrite impactait 1/ le temps de traitement chargement ; 2/ le positionnement des pages

    Virginie Clève

    @Nicolas_Laustriat L’article était centré sur la duplicate. J’en ferai peut être prochainment un autre sur d’autres sujets : 404, hotlinking, temps de chargement, tout ça 🙂
    Sur les rewrite, je laisse Charles Croix te répondre…

Karles

Mmm Je me rappel d’un souci pour passer de ?xtor=xxx à #xtor=xxx avec eZpublish. Nous avions bataillé pas mal mais je me souviens plus pourquoi cela était nécéssaire. J’avais débuté un article sur mon blog avec la solution de kathryl mais j’ai jamais terminé.

Karles

    Virginie Clève

    Et bien le fait de mettre une ancre, ça permet de ne plus générer de duplicate additionnel par la suite, puisque les moteurs ignorent ce qui se trouve derrière le #… Et comme toutes les anciennes pages sont redirigées en 301, c’est du concentré le jus qu’on a là 🙂
    Un grand moment de collaboration, oui, et la 1 ère place sur le mot « people » pour Voici à la clé ! D’ailleurs elle est pérenne : http://bit.ly/91BFsH

Karles

@Nicolas_Laustriat les rewrite rules outre leur maintenance et les effets de bord avec les nouvelles ajoutées au fil de l’eau ralentissent forcément le serveur. Imagine 50 règles appliquées une a une sur une requête http. Seule la 50è concorde et apporte une redirection. Multiplie cela par le nombre de requêtes. Disons 1ms par règle ? pour 5 millions de pages vue (Télé loisirs.fr) cela donne 8,3 minutes de temps cpu.

Tout ceci est relatif, c’est en fonction des règles, de leur qualités, de la fréquentation etc….

Le plus dangereux est que les règles interfèrent entre elles. Exemple : la règle 12 s’applique > redirection = nouvelle url, la règles 4 s’applique sur le nouvelle url etc…

Karles

Kathryl

Ma solution de ?xtor a #xtor était quand même crade de mon point de vue 🙂
J’avais déterré de vieux trigger de mod_rewrite pour trouver cette solution, mais niveau performance ça m’avait toujours inquiété.