Aller au contenu

Conditions du duplicat content


Kent

Sujets conseillés

Bonjour à tous,

J'ai un petit doute sur le duplicat content pourriez-vous m'indiquer laquelle des hypothèses suivante conduit à un duplicat content :

Hypothèse 1 :

www.monsite.com/index.php?param=1 => Contenu 1

www.autresite.com/index.php?param1 = > Contenu 1

Hypothèse 2 :

www.unsite.com/index.php?param=1 => Contenu 1

www.unsite.com/index.php => Contenu 1

Autrement dit , il ne peut y avoir duplicat que si 2 urls d'un même domaine pointent vers le même contenu.

Je pencherai pour la 2.

Si l'hypothèse 2 est vérifiée. Comment faites vous pour vos formulaire de recherche qui peuvent renvoyer les mêmes resultat avec des paramètres différents.

Exemple , il y a un tri ascendant par défaut sur les résultats, mais le paramètre ( tri=asc ) peut potientiellement être présent dans l'url.

Merci pour toute information.

Kent.

Lien vers le commentaire
Partager sur d’autres sites

Salut,

Les deux cas de figure conduisent au phénomène de duplicate content (littéralement duplication de contenu ; contenu 1 = contenu 1, non ?).

La meilleure solution consiste à canonicaliser l'URL grâce à la méthode du hash/dièse. On place tous les paramètres SEO useless après le dièse.


URL canonique : http://www.domaine.tld/page-1
URL à canonicaliser : http://www.domaine.tld/page-1?trackingcode=1
URL canonicalisée : http://www.domaine.tld/page-1#trackingcode=1

Lien vers le commentaire
Partager sur d’autres sites

Avec le dièse, tu es obligé de faire un traitement Javascript.

Lorsque le traitement est fait en PHP ou tout autre langage côté serveur, on ne peut pas s'en servir.

Dans ce cas, on peut utiliser une balise dans le header :

<link rel="canonical" href="http://www.site.com/recherche.php">

Lien vers le commentaire
Partager sur d’autres sites

Merci pour vos réponses,

Les deux cas de figure conduisent au phénomène de duplicate content (littéralement duplication de contenu ; contenu 1 = contenu 1, non ?).

Dans l'hypothèse 1, lequel des deux sites sera pénalisé ? le crawler pensera que la légitimité revient au premier site ou au deuxième sous quelles conditions ?

Parce que le premier site est bien mieux positionné (ancienneté, cohérence mot clé contenu, pagerank, etc) que le deuxième alors le contenu lui est légitime ?

Il peut arriver qu'un gros site en copie un petit... dans ce cas là il y a un hic

Captain, je ne conaissais pas cette balise méta, veut-elle dire "indexe cette page sous cette url uniquement" ?

Merci

Lien vers le commentaire
Partager sur d’autres sites

Pour ma part, je soutiens que le duplicate content entre 2 sites est beaucoup plus dangereux que le duplicate sur 1 même site.

Je ne suis pas d'ailleurs persuadé qu'on ai à faire au même phénomène.

Le premier cas peut conduire à une pénalité sur la totalité des positionnements, alors que je n'ai jamais pu observer cela pour du duplicate interne; uniquement des dés-indexations des doublons.

Lien vers le commentaire
Partager sur d’autres sites

Kent : exactement ! Plus d'infos en anglais à cette adresse : Specify your canonical.

En ce qui concerne le duplicate, l'âge des sites ne devrait être pris en compte que si la date d'indexation est similaire. Dans le cas où la page est indexée depuis longtemps sur un petit site et qu'elle est copiée plus tard par un gros, en toute logique cela devrait être le gros qui passerait en duplicate (Attention, je ne me base sur aucun texte précis pour le dire).

Lien vers le commentaire
Partager sur d’autres sites

J'opterai également pour l'interdiction d'indexation de résultats de recherche.

Par contre, je suis plus nuancé concernant le concept de "pénalité" pour contenu dupliqué. Il s'agirait plutôt de "non pondération" plutôt qu'une pénalité à proprement parler. En tout cas si on compare aux autres types de pénalités. Bien entendu, il réside le cas où le site est flaggé "spam" et là c'est bien plus qu'une pénalité algorithmique qui attend le coupable (blacklistage manuel).

Lien vers le commentaire
Partager sur d’autres sites

Par contre, je suis plus nuancé concernant le concept de "pénalité" pour contenu dupliqué. Il s'agirait plutôt de "non pondération" plutôt qu'une pénalité à proprement parler.
Je suis tout à fait d'accord avec ce commentaire, mais pas avec les conclusions.

S'il y a "non pondération", cela signifie que le site n'est pas optimisé. Mettre des noindex ou interdire le crawl revient à accepter la "non pondération" donc à ne pas optimiser. L'optimisation peut être faite, soit en ne conservant qu'une seule URL, soit par des redirections 301, soit par la balise canonical. A mon sens, de ces manières, on ne se résigne pas à la "non pondération" et ont fait donc un travail de "search engine optimization".

Just, my 0,02€.

Jean-Luc

Lien vers le commentaire
Partager sur d’autres sites

Merci pour vos réponses,

Pourquoi ne pas simplement mettre les pages de resultats de recherche en Noindex, nofollow?

Le duplicat content sur le moteur de recherche (page recherche) n'était donné qu'à titre d'exemple.

Mais il est clair que c'est une solution radicale :). Pour les pages méritant d'être tout de même indexées j'opterais pour la balise canonical.

La réelle problématique se situe au niveau de l'indexation des sites multilingue. Je dois positionner un même site d'e-commerce sur deux langues différentes, anglais et français.

Une des stratégies pourrait être de prendre deux noms de domaine (respectivement .com pour l'anglais et .fr pour le français).

Même si les mêmes noms de domaines pointent au final vers le même système de fichier, la langue des pages est modifiée en fonction de plusieurs critères :

- Le premier critère est l'existence d'un paramètre langue dans l'url auquel cas il est prioritaire et l'on dessert le site dans la langue correspondante. Si le domaine est en incohérence avec la langue demandée (ex .fr et la valeur du paramètre langue est "en") alors je fais une redirection permanente ( R=301) vers la même url mais en .com en prenant soins de remettre le paramètre langue qui cette fois sera bon. Ce raisonnement est le même pour la combinaison .com et langue "fr".

Première question ;

Cette première méthode vous parait-elle bonne ?

- Deuxième méthode, lorsque aucun paramètre langue n'est fourni je me base sur le header HTTP Accept-Language, ainsi la langue sera la langue préférée de l'utilisateur ( celle envoyée par le navigateur, autrement dit celle du navigateur tout compte fait...). En fonction de ce header, je redirige à nouveau en 301 vers la même url en ajoutant le paramètre langue en prenant soin de vérifier la cohérence extension du nom de domaine et langue envoyée. Par exemple le header envoi du "fr" mais l'utilisateur demande une url en .com je renvoie vers le .fr avec le paramètre langue à "fr".

Quel est le lien avec le duplicat content ?

Je souhaite m'assurer que chacune des pages soit accessible via une url unique dans une langue unique. Pour cela je m'efforce de faire en sorte que le paramètre langue soit toujours présent et qu'il soit cohérent avec le nom de domaine demandé. J'ai initié cette démarche car je me suis aperçu que google m'indexé le .fr avec en paramètre langue "en" du coup le contenu du site en .fr était en anglais ce qui a causé sa chute dans son positionnement sur google.fr et site francophone, le comportement inverse est tout aussi vrai, c-a-d le .com mal positionné sur google.com et "pages web" car son contenu était en français.

Dernières questions :

- Toutes ces corrections d'urls je souhaite les réaliser en masse, combien de temps pensez-vous que durera le flottement dans le positionnement ? Pensez-vous que ce référencement multilingue se stabilisera dans une période inférieur à 1 mois ? Avez-vous d'autres techniques de référencement testées avec succès sur des site d'e-commerce multilingue à me suggérer ?

Merci pour votre aide.

Kent.

PS : Modérateurs, dois-je transformer cette réponse en un nouveau topic [ technique de référencement multilingue ] ?

Lien vers le commentaire
Partager sur d’autres sites

A mon sens, de ces manières, on ne se résigne pas à la "non pondération" et ont fait donc un travail de "search engine optimization".

D'une manière ou d'une autre, je pense que nous sommes du même avis qui est contraire à celui de Google, souhaitant le moteur laisser se débrouiller dans un premier temps afin de dénicher quel est le bon contenu à valoriser.

Il est franchement préférable de prendre ses précautions en amont afin de faire remonter la bonne URL.

Une des stratégies pourrait être de prendre deux noms de domaine (respectivement .com pour l'anglais et .fr pour le français).

Nom de domaine ou sous-domaine sont les choix de prédilection. Il faut séparer au maximum les différentes langues. Même si un répertoire peut s'en servir, c'est tout de même plus clair sur un domaine séparé.

Première question ;

Cette première méthode vous parait-elle bonne ?

Ça ne fera rien au niveau des moteurs. Pour le user agent, il faudrait aussi traiter les différents robots d'indexation.

Le charset se révèle beaucoup plus efficace (voir brevet Google sur le character mapping)

Même la meta langage est inefficace. Il faut vraiment donner tous les signaux relatifs à une seule langue au sein de la page Web. Bien sûr les URLs, Doctype, etc. mais je vais même jusqu'aux éventuelles balises commentaire et toute trace du code source qui puisse émettre un signal flou.

Petit outil Google pour tester la détection et montrer la difficulté d'identifier certains mots qui sont multilangue.
/>http://www.google.com/uds/samples/language/detect.html

Pour cela je m'efforce de faire en sorte que le paramètre langue soit toujours présent et qu'il soit cohérent avec le nom de domaine demandé.`

Encore une fois, ce n'est pas prépondérant (paramètre en ou fr dans l'URL). Je n'aurais pas fait des redirections à tout va pour si peu.

combien de temps pensez-vous que durera le flottement dans le positionnement ?

Ca dépend de la popularité des pages. Il faut que le robot passe sur la page et décide de la valoriser et cela dépend grandement de sa popularité. Ben oui le PageRank peut servir à quelque chose finalement (pfiou pourvu qu'Arlette ne me lise pas).

Avez-vous d'autres techniques de référencement testées avec succès sur des site d'e-commerce multilingue à me suggérer ?

Je crois qu'on a fait le tour, mais je répète que tu fais fausse route avec ton paramètre dans l'URL. Ce n'est pas inutile, mais par rapport à l'instabilité du site suite au redirections, il réside des moyens moins brutaux pour identifier clairement une page.

Lien vers le commentaire
Partager sur d’autres sites

Thick,

Merci pour tes réponses. En les lisant je me rends compte que je me suis peut être mal exprimé sur certains points.

Je suis d'accord que le domaine.com et le domaine.fr suffiraient à eux mêmes accompagné des bons métas et de contenu dans la bonne langue à identifier la langue de la page, cependant le but du paramètre langue n'est pas seulement d'indiquer aux scripts quelle est la langue mais de bel et bien de la forcée.

Je m'explique,

Prenons le cas où je déciderais de supprimer tout simplement le paramètre langue ainsi que la détection via le header Accept-Language, ainsi si on demande .fr on aura du français et .com de l'anglais un point c'est tout.

Imaginons que pour un client tu communiques pour une certaine période sur le .com. Au moment de cette campagne de communication le site n'était pas multilingue le contenu du .com était donc du français. Aujourd'hui ce même client souhaite toujours communiquer sur son .com pour des raisons X ou Y (par cartes de visites sorties en centaines d'exemplaire avec le domaine en .com dessus au lieu de .fr) ou tout simplement par habitude ou encore la clientèle ne connais que le .com.

Que se passera-t-il si je suis en france et que je souhaite visiter ce site ? Comme l'adresse que je connais est en .com je vais me retrouver sur le site en anglais.

- Je suis un habitué je vais donc rechercher malgré tout le lien pour changer de langue et je serais rediriger vers le .fr, si je ne mets pas à jour mon marque page ou si je garde un certains temps le réflexe d'aller sur le .com . Je vais vite finir par passer à un autre site.

- Je suis nouveau et je me retrouve sur un site en anglais, après quelques secondes ( peut être pas plus de 10 ) je ne trouverais pas le lien pour cliquer sur le drapeau français ou je n'aurai peut être pas envie.

Conséquence, le taux de rebond sera monstrueux pour les nouvelles visites et les habitués seront à la longue agacés de toujours cliquer sur le drapeau.

Première solution :

Ok pour le paramètre langue mais il faudrait tout de même garder le header Accept-Language envoyé par le navigateur du client.

Que se passera-t-il si je suis aux US et que je souhaite voir le site en français ? il y a de forte chance que la langue préféré de mon navigateur soit l'anglais, je vais donc systématiquement me retrouver sur le site en anglais

Je dois donc changer la langue du navigateur, ce qui oblige les visiteurs à changer de langue à chaque fois. C'est assez pénible surtout s'il ne savent pas le faire.

Le raisonnement est aussi vrai pour un client Anglais dans cybercafé français par exemple...

Résumons :

l'extension à elle seule ne suffit pas pour choisir la langue judicieusement (cf ; campagne de com sur le .com en france... )

le header accept-language ne suffit pas pour choisir la langue judicieusement (visiteurs francophones utilisant un navigateur en anglais...)

Comment régler le scénario du français en voyage à New York.

Le visiteur demande le .fr mais ne donne pas de langue, si l'on se fiait au accept-language il se retrouverais sur le .com avec le paramètre langue à "en". Ce pendant j'ai créé un système de rewriting qui complète les urls pour s'assurer que le paramètre langue est toujours présent. Il le rajoute systématiquement aux urls dont il est absent.

Le visiteur demande donc domaine.fr

1ere règle :

Transformer domaine.fr en domaine.fr/index.php?langue=fr

pourquoi ?

Le paramètre langue est absent, il faut le déterminer .

Comment ?

Il doit être cohérent avec l'extension demandée (ici .fr)

2ème règle :

Si le paramètre langue est présent alors desservir le site dans la langue demandée et corriger les incohérences.

À la fin de la première règle on se retrouve avec une url du type :

domaine.fr/index.php?langue=fr

Le paramètre langue est présent et il est cohérent avec l'extension du domaine

On affiche la page.

Pour chaque règle on s'assure que le site sera référencé directement avec la bonne url par les bots ( R = 301 )

ainsi domaine.fr devra toujours être référencé sous domaine.fr/index.php?langue=fr

J'espère avoir éclairci ma problématique.

Cdlt

Lien vers le commentaire
Partager sur d’autres sites

Bonjour Kent,

Tout cela me semble bien compliqué alors que cela ne concerne qu'un petit nombre de cas.

Quoi qu'il en soit, je ne vois pas en quoi une redirection automatique vers domaine.com/index.php?langue=fr serait préférable à une redirection automatique vers domaine.fr, pour un visiteur français égaré sur l'adresse anglaise du site.

Jean-Luc

Lien vers le commentaire
Partager sur d’autres sites

Bonjour Kent,

Tout cela me semble bien compliqué alors que cela ne concerne qu'un petit nombre de cas.

Quoi qu'il en soit, je ne vois pas en quoi une redirection automatique vers domaine.com/index.php?langue=fr serait préférable à une redirection automatique vers domaine.fr, pour un visiteur français égaré sur l'adresse anglaise du site.

Jean-Luc

Tu voulais surement dire domaine.fr/index.php?langue=fr vers domaine.fr

Pour éviter les boucles. Si le paramètre langue est absent je me fis à la langue du navigateur (ici fr) je redirigerais donc vers domaine.fr/index.php?langue=fr. Si je redirige vers domaine.fr uniquement alors le paramètre langue sera absent et la redirection va boucler.

Le paramètre langue est indispensable pour la consultation du site dans une langue différente de celle de son navigateur ( Cf raisonnement dans le précédent poste ).

Lien vers le commentaire
Partager sur d’autres sites

Franchement, je comprends de moins en moins.

Sachant que la simplicité est la solution de 99% des problèmes Web, ça me laisse perplexe de ne pas piger exactement de quoi il en retourne.

Encore une fois, le paramètre langue n'est pas du tout indispensable pour qualifier la langue d'un site (heureusement d'ailleurs).

Comme je t'ai suggéré, tu peux traiter différemment les visiteurs humains et les robots, mais là aussi tu dévies de la simplicité.

Laisse donc les 0,0001% de visiteurs qui voudront une langue différente cliquer sur le drapeau qu'ils veulent à la place de la langue affichée par défaut et reste le plus simple possible dans ta structure.

Lien vers le commentaire
Partager sur d’autres sites

Kent,

je suis du meme avis que Jean Luc et thick, Tu te complique beaucoup la vie pour pas grand chose.

A partir du moment ou tu as 2 domaines il te suffit de bien specialiser chacun d'entre eux dans une langue et de laisser le cours des choses se faire.

J'ai bosser sur de nombreux cas de SEO international et je peux dire que c'est peut etre la premiere fos que je vois quelqu'un se poser des questions pareilles.

tiens je te mets un petit lien vers un article a moi - en anglais - sur le SEO international. Tu verras c'est pas tres complique et ca marche du tonerre.

Lien vers le commentaire
Partager sur d’autres sites

Salut,

Merci pour vos réponses. Contrairement à ce que l'on pourrait croire, mon but est aussi de lutter contre la complexité. Seulement parfois on est face à des situations que l'on ne peut pas changer ou simplifier parce que cela nous arrange.

La majorité du trafic sur le site vient des accès direct et non du moteur de recherche, la communication en France a été faite très longtemps sur le .com. Ma seule préoccupation c'est que ces 85% de visiteurs, ne se retrouve pas sur un site en anglais lorsqu'il vont sur leur site favori.

Il est plus difficile de gagner un client que de garder ceux qu'on a déjà. Je souhaite éviter les désagrément coté visiteur au maximum et les taux de rebonds des nouvelles visites au maximum.

Il ne s'agit pas de positionner un nouveau site fraichement créé, mais d'optimiser le SEO internationale pour des sites avec quelques dizaines d'années d'ancienneté, dont le gagne pain sont les accès direct et la fidélisation de la clientèle.

Voilà pourquoi je dois faire en sorte que les français ayant pour habitude de venir sur le .com ne soit pas perdus (il seront donc redirigé vers le .Fr grâce à la langue de leur navigateur).

Le juge,

A partir du moment ou tu as 2 domaines il te suffit de bien spécialiser chacun d'entre eux dans une langue et de laisser le cours des choses se faire.

Toute l'astuce consiste à spécialiser chaque site dans une langue sans perdre le trafic francophone sur le .com

tiens je te mets un petit lien vers un article a moi - en anglais - sur le SEO international. Tu verras c'est pas très complique et ca marche du tonnerre.

Merci bien je vais le décortiquer.

Je pense que je vais adopter une stratégie qui permettra de ne pas trop pénaliser mes anciens visiteurs, mais j'axe tout de même vers l'avenir et le gain en trafic potentiel sur le .fr et le .com (respectivement sur google.fr et google.com)

Que pensez-vous de l'acquisition d'une ip US ou UK pour le .com ? Quelqu'un a noter des changements significatifs ?

Bien cordialement,

Kent

Lien vers le commentaire
Partager sur d’autres sites

Tu peux te contenter de géolocaliser avec GWT pour l'audience anglaise. J'ai toutefois souvent entendu dire dans le monde du SEO pro que pour cibler le marché anglais il était préférable de prendre le ccTLD qui va bien (.co.uk) plutôt qu'un gTLD géolocalisé. Si tu tiens absolument à exploiter un nom de domaine en gTLD pour l'audience anglophone, tâches de voir quel marché tu souhaites cibler en priorité (UK ou US ?).

Lien vers le commentaire
Partager sur d’autres sites

Juste une précision : Google ne se sert pas de balises (content-language ou autre) pour déterminer la langue du contenu d'une page

Merci pour la precision - reste que comme la balise keywords, je la demande souvent, quand on fait un puzzle on met toute les pieces.

Kent, depuis le debut de ce post, tu parles d'une clientelle anglophone - OK mais c'est du US, du UK, de l'australien???? Si tu pars de ce principe la tu vas droit dans le mur. Il fat penser en termes de Marché - sachant qu'il y a anglophone et americanophone (et la difference et pas si petite que ca croyez moi) qu'il y a dollar, livre sterling, euro (irlande) et australian dollar.

Les francais sont habitues au .com ... tres bien,

pour du UK --> garde le .com en francais, tu prends un .co.uk pour tes clients outre-manche

Pour du US --> la ca se complique parce que les ricains ils aiment pas bien ne pas avoir du .com --> la soluce changer de NDD. tu prends "monsiteweb.com" pour le site francais et "mywebsite.com" pour le site americain (tu assures le.fr aussi pour la version francaise).

Dans l'eventualite ou tu dois basculer le .com en anglais moi perso je jouerais la carte du re-branding a savoir un grosse com' sur le basculement en .fr, la mise en place d'URL bien specifique pour le site anglophone (en reecrit et en anglais par exemple) et la redirection page a page de toutes les URLs du.com version francophone en 301 vers le .fr ....

bref tout ca pour dire que honnettement la situation ne passe pas pas la gestion des langages et l'impact sur le referencement. c'est a la fois plus simple et plus complique sleon tes choix strategiques. Mais ca implique surtout des choix plus drastiques dans la strategie AMHA

Lien vers le commentaire
Partager sur d’autres sites

En ce qui concerne le duplicate, l'âge des sites ne devrait être pris en compte que si la date d'indexation est similaire. Dans le cas où la page est indexée depuis longtemps sur un petit site et qu'elle est copiée plus tard par un gros, en toute logique cela devrait être le gros qui passerait en duplicate (Attention, je ne me base sur aucun texte précis pour le dire).

Je vis actuellement l'expérience inverse : contenu indéxé depuis longtemps sur un petit site, repris ensuite par un gros, et c'est le petit qui est parti enduplicate content.

Concernant la problématique du référencement multilingue, si tel est bien l'objectif du site, j'en suis arrivé à la conclusion personnelle (qui n'engage donc que moi), qu'il faut 1 URL par pays cible, hébergée sur 1 IP localisée dans pays concerné. 1 base de données centralisée suffit pour gérer l'ensemble.

Ainsi, chaque contenu est différent, sur une URL différente, et sur une IP différente. CQFD !

Sylvain

Lien vers le commentaire
Partager sur d’autres sites

Effectivement, les dates de publication ou d'indexation ne sont pas des facteurs déterminants ; PageRank, TrustRank, LocalRank, etc. semblent en revanche l'être.

Lien vers le commentaire
Partager sur d’autres sites

Bonjour à tous,

Le-juge,

Kent, depuis le debut de ce post, tu parles d'une clientelle anglophone - OK mais c'est du US, du UK, de l'australien????

À vrai dire, c'est du "google.com", une première étape c'est une position générale correcte sur google.com ensuite je pourrais localiser les nom de domaines. Et c'est là que ce que tu dis est interessant.

Tu suggère une extension spécifique par pays. Ça peut être intéressant, je n'avais pas penser au .co.uk par exemple !

Mais pour l'instant je ne propose pas les variantes de traduction us. Le site peut être FR ou EN, il n'y a pas de "En/UK , en/US"

Donc le domaine pour les us va pointer sur la traduction anglaise du site, la chose qui pourrait jouer sur le positionnement, ce serait la localisation IP du domaine us par rapport au domaine uk.

Dans l'éventualité ou tu dois basculer le .com en anglais moi perso je jouerais la carte du re-branding a savoir un grosse com' sur le basculement en .fr

Ouch cela va être difficile de justifier le budget com chez certains de nos clients.

[...]et la redirection page a page de toutes les URLs du.com version francophone en 301 vers le .fr ....

Ça c'est fait, its ok.

Sinon pour le coup du monsiteweb.com et mywebsite.com, cela peut être une idée sauf que le nom de domaine est le nom de la marque donc d'un point de vue marketing et identité difficile à traduire, c'est comme si tu traduisais... je ne sais pas... webmaster-hub en maitreduweb-salon :).

Katmars,

[...]qu'il faut 1 URL par pays cible, hébergée sur 1 IP localisée dans pays concerné. 1 base de données centralisée suffit pour gérer l'ensemble.

Je suis d'accord avec ça, j'espère réussir cette architecture à terme.

Pour le coup les remarque du "Juge" me font réaliser que tout ça s'annonce beaucoup plus stratégique que technique. Et là, je n'ai pas les cartes en main je vais voir avec les services concernés pour chacune des marques.

Il faut que je bûche de ce coté là...

Modifié par Kent
Lien vers le commentaire
Partager sur d’autres sites

Veuillez vous connecter pour commenter

Vous pourrez laisser un commentaire après vous êtes connecté.



Connectez-vous maintenant
×
×
  • Créer...