A quand le déploiement de l\'index Google Mobile-First ?

Dans un article précédent intitulé “Google index mobile-first : le changement, ce n’est pas pour maintenant”, j’avais indiqué certaines raisons qui pouvaient justifier ce retard à l’allumage.

Google Index Mobile-First ne sera pas déployé avant 2018 !

Il nous revient à nouveau en écho que ce fameux index mobile-first, qui doit donner la priorité au contenu mobile pour le classement dudit contenu tant sur mobile que sur desktop, ne va plus voir le jour avant 2018.

C’est en tout cas Gary Illyes, porte-parole chez , qui vient de le confirmer dans un Tweet révélé par Barry Schwartz. Et ce, après des échanges entre pros sur ce sujet.

Un premier Tweet indiquait ce qui suit :

Le mobile-first sera déployé à la fin de cette année (2017, ndlr).

Cette première interprétation est alors contestée par un autre Tweet :

Pas du tout. J’ai écouté attentivement. Les ingénieurs disent espérer le déployer avant la fin de l’année, mais il (Gary Illyes, ndlr) pense maintenant que ce n’est plus probable.

Pour finir, c’est Gary Illyes lui-même qui vient clarifier ses propos pour dire :

Oui, cette phrase avait une deuxième partie où j’ai dit que je ne pense pas en fait qu’il sera lancé cette année.

Pour conclure, il n’y aura pas de mobile-first avant l’année 2018 ! CQFD.

Google Index Mobile First : Le changement, ce n\'est pas pour maintenant !

Depuis que a annoncé l’arrivée imminente de son Index Mobile-First, ce qui pourrait considérablement bouleverser les résultats de recherche, certains indices laissaient à penser que la date de son déploiement se situerait entre le 1er et le 31 Janvier 2017. 

Google Index Mobile First : Le changement, ce n\'est pas pour maintenant !

Et nous sommes déjà à la mi-Février… Google ayant lui-même dit que ce sera fait dès le début de l’année 2017.

Pour rappel, l’arrivée du Mobile First verrait Google indexer et classer les sites selon la qualité et les performances de la version mobile du site. Un changement qui intervient donc pour refléter le fait que plus de 50% (et ce n’est pas fini) de toutes les recherches sur Google sont faites via un appareil mobile.

Et avec certains propriétaires de sites qui tronquent le contenu ou présentent une version alternative de la page (lisez l’article “Ce que Google veut voir sur votre site mobile first”), il peut être frustrant, pour les mobinautes qui cherchent, de trouver un contenu qu’ils recherchaient mais ne correspond pas à la même version complète de ce contenu sur ordinateur.

Le changement est donc très logique puisqu’il influence autant la perception du mobinaute que la qualité des résultats de recherche de Google qui ne veut pas fournir des contenus tronqués.

Bref, comme nous nous approchons allègrement vers la fin du mois de Février, de plus en plus de interpellent Google sur la date du déploiement du Mobile-First.

C’est ainsi que, Gary Illyes, Webmaster Trends Analyst chez Google et porte-parole SEO de Google, a évoqué le sujet lors la récente Friends of Search conference :

Gary Illyes :

Nous continuons toujours à travailler sur un index complètement mobile first, nous nous approchons du lancement.

Mais, comme vous pouvez l’imaginer, l’assistance a insisté et demandé à savoir quand le mobile-first sera effectif. Réponse de Gary Illyes :

En d’autres termes :

L\’Index Mobile First peut encore prendre quelques mois…

Avant d’ajouter ce qui suit :

Google n’a pas encore de date exacte pour le Mobile-First.

Nous savons depuis un certain temps que Google effectue actuellement une expérimentation de son Index Mobile-First. Mais, s’il tarde à le déployer, c’est qu’il subsiste de petits problèmes qui pourraient s’avérer embêtants sur le long terme.

Notamment en ce qui concerne les backlinks ou liens entrants dont on connaît la position et l\’importance parmi les 3 premiers facteurs de référencement sur Google.

Puisque les liens impactent sur le classement sur Google, sans doute que Google veut s’assurer que les versions destinées au mobile (du type m.domaine.com ou mobile.domaine.com) vont continuer à bénéficier des backlinks reçus par les versions desktop.

Pour la simple raison que les sites Web et les blogs ne pointent des liens que sur les versions desktop des sites.

Ce qui serait plus facile avec un site en responsive design qu’avec un site qui a une version desktop et une autre version différente dédiée au mobile.

Google déteste le bouton Lire la suite pour lire le reste d\'un article

On a connu, il y a encore peu de temps, le phénomène des interstitiels lorsqu’on visite des contenus sur mobile. Et pour dissuader les webmasters et les éloigner de cette pratique, a finalement décidé de déclasser les pages mobiles qui en affichent.

Et comme toujours, ce sont les abus qui finissent par inciter Google à créer des pour freiner les ardeurs des uns et des autres. Aujourd’hui, les projecteurs se braquent sur un phénomène qui commencent à prendre de l’ampleur sur mobile : le clic sur le bouton “Lire la suite”.

on vous présente un bouton labellisé “Lire la suite”.

Vous comprenez alors qu’on vous demande de cliquer sur ce bouton pour déplier la page complète et poursuivre votre lecture de ce même article sur cette même page. C’est abusé, non ?

Sauf que, ce bouton “Lire la suite” n’est jamais placé là de façon anodine. C’est une stratégie pour s’assurer une plus grande visibilité d’une publicité (quelle qu’elle soit) placée juste en dessous du bouton “Lire la suite”.

Selon l’information relayée par Seroundtable, les principaux portes-paroles de Google, que sont Gary Illyes et John Mueller, ont manifesté leur grande désapprobation de cette nouvelle pratique sur mobile.

Non seulement cela constitue une perte de temps pour l’utilisateur, mais c’est aussi une mauvaise expérience utilisateur qui peut être pénalisante.

Toujours est-il, pour répondre à une question sur ce sujet, John Mueller a répondu ce qui suit dans son Tweet :

En d’autres termes :

Ce n’est pas un interstitiel, mais oh combien je déteste ceux-là. Pourquoi pourquoi pourquoi un site veut-il masquer son contenu ?

Et Gary Yllies de rajouter :

Je n’ai jamais compris sa raison d’être. Ça génère plus d’argent ? Ou pourquoi les gens le font-ils ?

Bref, c’est comme cela que ça avait commencé avec les interstitiels. Aujourd’hui, on connaît la suite…

Alors, attention au retour de bâton.

Google supprime l\'opérateur link:votredomaine.com

Google demande aux webmasters et autres référenceurs internet d’arrêter d’utiliser l’opérateur de recherche “link” qui est désormais officiellement “mort”.

Google supprime officiellement l\'opérateur link:votredomaine.com

C’est ce que déclare Searchengineland.com qui aurait reçu officiellement confirmation de la part de , et la suite de cet article vous le démontre aussi.

Continuer à utiliser la commande \ »link:www.VotreNomdeDomaine.com\ » vous affichera au fil du temps () des résultats non pertinents ou approximatifs, pour ne pas dire des résultats erronés.

Mais, en termes de référencement, la commande \ »link:VotreNomdeDomaine.com\ »

Et certains webmasters ont pris l’habitude de se servir de cette commande pour comparer le nombre de backlinks entre 2 ou plusieurs sites ou pages. Car, comme pour toutes les recherches sur Google, le nombre total de résultats (et donc de backlinks potentiels

Déjà au mois de Février 2016, des doutes subsistaient quant à la continuité de cet opérateur \ »link:www.VotreNomdeDomaine.com\ ». Mais, Google avait confirmé que l’opérateur link restait toujours valable sur Google Search.

Mais voilà, John Mueller de chez Google vient de répondre à un webmaster en lui recommandant de ne plus utiliser l’opérateur de recherche link.

Voici ce qu\’affichait auparavant la page d\’aide de Google sur les opérateurs de recherche :

Et voici ce qu\’on trouve aujourd\’hui sur cette même page d\’aide :

Copie d\’écran via Google

Vous constatez sur la deuxième copie d\’écran que l\’opérateur \ »Link\ » a disparu de la liste des opérateurs supportés par Google Search. La commande link n’est donc plus officiellement une option de recherche sur Google Search.

Il va donc falloir se tourner, si ce n\’est fait depuis longtemps, vers des outils SEO tiers ou aller dans votre espace Google Search Console pour avoir une idée sur vos backlinks.

36 Conseils pour passer sans faute de HTTP à HTTPS ?

Depuis que a annoncé qu’il allait commencer à utiliser le HTTPS comme un signal de référencement, de nombreux sites Web ont commencé à migrer vers HTTPS.

Checklist pour migrer HTTPS

Et ce, non seulement pour des raisons de sécurité, mais aussi pour bénéficier du boost supplémentaire dans le classement dans les pages de résultats de Google.

Néanmoins, même si Google a publié les meilleures pratiques pour passer de HTTP à HTTPS, la réalité est que, dans de nombreux cas, elles ne sont pas suivies.

Ou encore certaines étapes sont manquées puisqu’il y a tant de différents domaines impliqués, ainsi que des vérifications et validations à faire avant, pendant et après le passage au .

Par exemple, Gary Illyes, Webmaster Trends Analyst chez Google, a publié un Tweet pour quelques rappels utiles appelant à vérifier et modifier le suivi et les scripts des annonces pour éviter tout blocage :

La vraie question lors d’un passage du HTTP au HTTPS n’est vraiment pas une absence totale de connaissance des webmasters, car, même si les gens connaissent certaines bonnes pratiques à prendre en considération, le problème est souvent plus dû à un manque de ressources complètes avec toutes les validations, spécifiant quand les mettre en œuvre.

Ce qui pourrait être facilement partagé et suivi par toutes les parties impliquées dans la migration, et qui sauraient dès le début quand faire quoi, afin de planifier les bonnes ressources au moment opportun.

Voici donc une checklist HTTPS qui vous indique les tâches à accomplir avant, pendant et après la migration.

 

Comment démarrer le passage de HTTP au HTTPS ?

 

  1. Certificat SSL : Achetez, configurez et testez le certificat sécurisé SSL/TLS à l’aide de SHA-2 pour SSL sur le serveur.
  2. Enregistrez et validez à la fois le en http et https dans Console, et dans les versions avec www et sans www. Si vous avez également enregistré des sous-domaines ou des sous-répertoires dans la Search Console, répliquez ces enregistrements et ces configurations avec leur version https.
  3. Installez et commencez le suivi des classements en parallèle avec le HTTPS du nom de domaine dans vos outils SEO ou logiciels de tracking.
  4. Identifiez les meilleures pages du site dans la Search Console et dans Google Analytics, ainsi que les requêtes connexes, qui vous assurent la visibilité organique et le trafic. Vous en ferez une priorité lors de la validation et du suivi référencement et des performances du site.
  5. Analysez la version HTTP du site afin d’identifier et corriger tous les liens internes brisés, ainsi que la structure actuelle avant migration.
  6. Configurez la nouvelle version du site Web afin de la modifier, tester et mettre à jour les liens dans un environnement de préparation, pour les pointer vers des URLs (pages et ressources telles que les images, js, pdfs, etc.) avec HTTPS.
  7. Mettez à jour les balises canoniques (rel=”canonical”) pour inclure des URLs absolues utilisant le protocole https.
  8. Vérifiez que toutes les réécritures et redirections déjà existantes (avec ou sans www, avec ou sans slash (barre oblique), etc.) sont également implémentées dans la version HTTPS comme elles ont l’habitude de fonctionner sur le http.
  9. Préparez et testez les règles de réécriture des redirections 301 de toutes les URL existantes identifiées (pages, images, js, etc) sur le nom de domaine http vers le https, sur le serveur.
  10. Générez un nouveau fichier Sitemap au format XML avec les URLs pour HTTPS afin de le télécharger dans la version HTTPS du nom de domaine dans la Search Console, une fois que le site aura été déplacé en HTTPS.
  11. Préparez le fichier robots.txt qui sera téléchargé sur la version HTTPS du nom de domaine lorsque le site sera déployé en répliquant les directives actuelles de la version HTTP, mais en pointant vers les URLs HTTPS si nécessaire.
  12. Préparez les modifications sur toutes les campagnes publicitaires, d’emailing ou d’affiliation pour commencer à les pointer vers les versions HTTPS des URLs dès que la migration sera faite.
  13. Vérifiez si des demandes de désaveu de liens ont été soumises par le passé afin de les soumettre à nouveau pour les versions HTTPS des URLs via la propriété du nom de domaine en HTTPS dans .
  14. Si vous migrez un gTLD (nom de domaine de premier niveau) que vous ciblez géographiquement via la Search Console (autant que ses sous-domaines ou sous-répertoires, au cas où vous les ciblez géographiquement de façon individuelle), assurez-vous de les ciblez à nouveau géographiquement avec la version HTTPS du nom de domaine.
  15. Si les paramètres des URLs sont gérées via Google Search Console, la configuration existante doit être répliquée dans le profil ou propriété HTTPS du site.
  16. Si un CDN (Content Delivery Network) est utilisé, vérifiez qu’il sera en mesure de bien servir la version du nom de de domaine du site en HTTPS et gérer le SSL lorsque la migration sera effective.
  17. Vérifiez que tous les codes des annonces publicitaires servies, les extensions tierces et les plugins sociaux utilisés sur le site fonctionneront correctement lorsqu’ils seront déplacés dans le HTTPS.
  18. Assurez-vous que la configuration existante de Web Analytics surveillera également le trafic du domaine HTTPS.

Comment vérifier pendant la migration vers HTTPS ?

 

  1. Publiez la version HTTPS du site en ligne (en mode production).
  2. Vérifiez que la structure des URLs sur la version HTTPS du site est la même que celle de la version HTTP.
  3. Vérifiez que les liens du site pointent effectivement vers les bonnes URLs HTTPS.
  4. Vérifiez que la balise canonicale (rel=”canonical”) dans le header des pages pointent également vers les bonnes URLs HTTPS.
  5. Vérifiez que la nouvelle version HTTPS canonique implémente les réécritures et redirections des versions avec ou sans www, avec ou sans slash à la fin, etc, dans la nouvelle version HTTPS.
  6. Mettez en place les redirections 301 de chaque URL du site depuis HTTP vers sa version HTTPS.
  7. Annotez la date de la migration dans votre plateforme de Web Analytics et vérifiez que la configuration a été bien définie pour suivre les performances de la version HTTPS.
  8. Vérifiez que la configuration SSL de votre serveur Web est correcte. Vous pouvez utiliser un service tel que SSLLabs pour la tester.
  9. Actualisez les paramètres du fichier robots.txt dans le nom de domaine en HTTPS avec les modifications pertinentes.

Les vérifications après passage au HTTPS

 

  1. Analysez le site pour vérifier que les URLs HTTPS sont celles qui devraient être accessibles, liées et servies sans erreurs, sans noindex erronées ni redirections ni balises canoniques erronées.
  2. Vérifiez que les règles de redirection de http et https, avec www et sans www, avec slash et sans slash sont correctement mises en œuvre.
  3. Téléchargez et vérifiez le fichier sitemap XML généré avec les versions d’URL HTTPS dans la propriété HTTPS (du nom de domaine) de Google Search Console.
  4. Mettez à jour, tant que peut se faire, les liens externes (backlinks) pointant vers le site avant de bien vérifier qu’ils sont redirigés vers la version HTTPS.
  5. Vérifiez que les plugins, ainsi que les boutons sociaux, annonces et extensions tierces fonctionnent correctement dans les versions HTTPS des URLs. Vous pouvez scanner votre site pour vérifier s’il existe encore du contenu non-sécurisé avec JitBit.
  6. Mettez en place les modifications pertinentes des campagnes publicitaires, d’emailing et d’affiliation pour qu’elles soient correctement redirigées vers la version Web HTTPS du site.
  7. Surveillez l’exploration, l’indexation, la visibilité et les erreurs des deux versions HTTP et HTTPS du site. Car, vous ne devez en aucun cas supprimer la version HTTP.
  8. Surveillez le trafic des versions HTTP et HTTPS du site, ainsi que leurs classements.
  9. Vérifiez les paramètres du fichier robots.txt dans le nom de domaine en https pour vous assurer que la configuration a été correctement mise à jour.

En principe, avec toutes ces consignes d’implémentation et de migration vers un hébergement sécurisé via HTTPS, vous devriez faire un sans faute.

Mais, il est également important de mentionner qu’une fois que vous déplacez votre site vers votre serveur HTTPS, vous pourriez considérer servir les pages via HTTP/2.

En effet, HTTP/2 (nommé initialement HTTP/2.0) est une version majeure du protocole réseau HTTP utilisé sur le World Wide Web. Il est issu du protocole expérimental SPDY (à prononcer comme le mot anglais speedy) développé par Google.

Pour la petite histoire, sachez que HTTP/2 ne demande pas de modification des applications web existantes, un effort ayant été apporté sur la rétro-compatibilité avec HTTP 1.1. Mais les applications webs existantes ou futures peuvent être développées pour bénéficier des nouveautés proposées notamment pour les gains de vitesse de transmission.

HTTP/2 conserve la majorité de la syntaxe de HTTP 1.1, comme les méthodes, les codes, les URI ou les headers. Un élément a été modifié : la manière dont la donnée est segmentée et transportée entre le client et les serveurs. Ce qui n’a pas d’impact sur les applications existantes.

RankBrain a-t-il une influence sur l\'ordre des résultats de Google ?

Ce fut une surprise le jour où avait annoncé que son système RankBrain, doté de l’intelligence artificielle, était désormais son troisième plus important signal de référencement.

Google RankBrain

Par rapport à ce que l’on sait aujourd’hui de RankBrain, c’est qu’il permet à Google d’ajuster effectivement les facteurs de classement déjà existants.

Mais, quelle est réellement son influence sur le classement des résultats de recherche de Google ?

C’est selon Thesempost qui rapporte l’information, ce à quoi a récemment répondu Gary Illyes, Webmaster Trends Analyst chez Google, lors d’un chat . Il a déclaré ce qui suit :

Dans la plupart des cas, RankBrain ne modifie pas l’ordre d’affichage des résultats de recherche de Google que d’autres algorithmes de classement ont déjà déterminé.

Certes, c’est le troisième facteur plus important de classement, mais dans des tonnes de cas, il n’est pas à même de changer l’ordre des résultats.

En d’autres termes, autant RankBrain touche (dans le sens de vérifier par rapport à la requête) aux résultats de recherche, autant il n’influence pas actuellement l’ordre des résultats de recherche dans la très grande majorité des cas.

Par contre, ce que ne dit pas Gary Illyes ni Google lui-même, c’est le pourcentage des résultats que RankBrain change. En dehors du fait qu’il a une forte influence sur 15% des requêtes de recherche que Google n’avait jamais vues auparavant.

Toutefois, selon Thesempost, Gary Illyes aurait précisé par la suite que RankBrain n’est pas là pour remplacer le classement, mais pour aider à mieux comprendre les requêtes des internautes.

Que compte à nouveau faire Google avec l\'authorship pour demander ça ?

Vous avez sans doute oublié l’authorship lancé par pour revendiquer la paternité de vos contenus sur le Web en associant votre profil Google+ avec votre site internet.

Google Authorship

En effet, en Août 2014, en plein été, Google a officiellement mis fin à l’AuthorshipGoogle+ pour bénéficier d’un éventuel avantage de l’authorship dans les résultats de recherche de Google se sont sentis abusés.

Mais, depuis quelques mois, des signaux sont envoyés ici et là par les porte-paroles de Google, notamment par Gary Illyes, comme si l’authorship allait renaître de ses cendres et faire bientôt son come-back.

C’est Gary Illyes qui, en Octobre 2015, a recommandé aux propriétaires de sites de laisser le tag de l’authorship sur leurs sites. Ce fut une vraie surprise.

Et, voilà que ce même Gary Illyes, selon une information rapportée par Barry Schwartz, aurait à nouveau déclaré lors de la dernière SMX West : “Si vous avez encore l’authorship sur votre site, je vous recommande de le laisser tel quel”.

Gary Illyes serait au courant qu’une équipe de Google cherche des façons de l’utiliser à nouveau.

Faut-il vraiment croire à un éventuel retour de l’authorship ou est-ce une carotte pour inciter les webmasters à revenir massivement vers Google+ ? L’avenir nous le dira.

Affaire à suivre…

Google Penguin : Vous n\'entendrez plus bientôt parler de lui aussi !

Gary Illyes a laissé entendre que Google Penguin ne sera finalement pas mis à jour à la période précédemment indiquée dans de nombreux Tweets.

Google Penguin

Toujours est-il que dans un autre Tweet, Gary Illyes, Webmaster Trends Analyst chez , nous livre une information très importante concernant . En même temps, on pouvait s’y attendre.

A la question de savoir si Penguin “en temps réel” signifie aussi qu’il va être introduit au coeur de l’algorithme de Google, Gary Illyes répond ce qui suit :

Gary Illyes a donc confirmé que Google Penguin sera bel et bien en temps réel, mais il a aussi ajouté qu’il fera bientôt partie du coeur de l’algo de Google.

Et il ajoute : “Ce qui signifie que nous arrêterons d’en parler (ou plutôt que je n’en parlerai plus)”.

Tout comme pour Google Panda qui est maintenant au coeur de l’algo, Google continuera de nous parler de l’évolution de son algorithme de ranking, sans plus jamais faire allusion à Panda ni Penguin qui n’existeraient donc plus de facto en tant que filtres anti-spam de Google.

Google : Que reste-t-il de l\'autorité des liens lors de la migration du site vers le HTTPS ?

encourage depuis un certain temps les propriétaires de sites web à migrer vers l’hébergement sécurisé avec un certificat SSL valide.

Google : Les liens peuvent-ils perdre leur autorité lors d’une migration vers le HTTPS ?

Ainsi, après avoir officiellement déclaré l’hébergement HTTPS comme un critère de référencement, mais avec un tout petit “boost”, Google a créé un label https pour indiquer dans ses pages de résultats quels sites web sont sécurisés.

Et tout récemment, toujours pour rassurer les webmasters et leur donner plus de gages en cas de migration du HTTP vers le HTTPS, Google a annoncé des critères d’indexation du HTTPS par défaut.

Il s’agit ici d’une mesure qui va consister à prioriser l’indexation des pages sécurisées HTTPS par rapport aux pages HTTP normales.

L’une des inquiétudes manifestées par certains webmasters qui l’ont exprimée en commentaires dans un post de John Mueller, Webmaster Trends Analyst chez Google, était d’en savoir plus de ce qu’il advenait des backlinks reçus par un ayant migré du HTTP vers le l’hébergement sécurisé HTTPS.

En d’autres termes, est-ce que les liens précédemment obtenus avant la migration HTTPS ne perdaient pas de leur autorité (et donc leur jus et leur trafic) du fait que les pages en question sont désormais en HTTPS ?

Comme le montre la capture d’écran ci-dessous, John Mueller va confirmer qu’il n’y aura aucune perte d’autorité des backlinks lors de la migration du HTTP vers le HTTPS. Plus précisément, voici ce qu’il dit :

C\’est comme avec l’URL avec www et sans-www, vous ne perdez pas les liens qui pointent vers la version alternative, même si vous ne définissez pas de redirection.”

Ainsi, ce n’est pas parce que les pages HTTP ne comptent plus que les liens qu’elles ont reçus sont pour autant perdus et que votre trafic web pourra en être affecté. Ils sont transférés avec tous leurs signaux vers la nouvelle version HTTPS du site.

C’est ce qu’a d’ailleurs à nouveau confirmé Gary Illyes de chez Google dans le Tweet ci-dessous :

Selon Gary Illyes, Google prendra en compte les signaux collectifs des liens entrants à la fois vers la version HTTP et la version tHTTPS d’une même page. En outre, cela se fera automatiquement, donc il n\’y a aucun besoin de s\’inquiéter du défaut de redirections.

C\'est quoi le contenu dupliqué pour Google ?

Le contenu dupliqué ou contenu en double est aussi l’un des sujets récurrents du référencement Web abordés par les .

Qu\'est-ce que Google entend par contenu dupliqué ou en double ?

Et ce, en raison du fait qu’il existe différentes sortes de contenus en double dont certains peuvent être pénalisés par et d’autres pas.

Le dernier Hangout de John Mueller sur le “duplicate content”

Par définition, et selon Google

Alors, voici quelques précisions de John Mueller :

  • Le contenu dupliqué touche à peu près tous les sites web, quelle que soit leur taille.
  • Selon John Mueller, le contenu en double, c’est un même contenu sur un même site. C’est aussi un même contenu avec un même chemin d’accès dans des URLs avec et sans WWW.
  • N’est pas un contenu dupliqué un contenu traduit ou adapté à partir d’une autre langue (ce n’est pas une raison pour ne pas citer la source). Il en est de même avec différentes pages ayant un même titre et/ou une même description, ainsi que le contenu dans les applications.
  • John Mueller confirme ce qu’avait déjà dit Gary Illyes en Mars 2015, à savoir que le contenu dupliqué n’est pas en soi une cause de pénalité.
  • Les contenus dupliqués sont une perte de temps de stockage et de ressources serveurs.
  • Si une page est dupliquée, Google ne conserve qu’une seule copie.
  • Un contenu dupliqué pour 2 localisations dans deux pays différents n’est pas une cause de pénalité.

La pénalité de contenu dupliqué est donc un mythe.

Comment gérer les contenus dupliqués

Selon Google, les mesures suivantes vous permettent de résoudre les problèmes de contenu en double de manière proactive et de vous assurer que les visiteurs accèdent au contenu que vous souhaitez leur présenter.

  • Utilisez les redirections 301 : si vous avez restructuré votre site, utilisez des redirections 301 (\ »RedirectPermanent\ »
  • Soyez cohérent :http://www.example.com/page/, http://www.example.com/page ni http://www.example.com/page/index.htm.
  • Utilisez des domaines de premier niveau :

    Google peut supposer que le site ”http://www.example.de”“http://www.example.com/de” ou http://de.example.com.

  • Soyez prudent en diffusant votre contenu :Guest blogging), Google affichera systématiquement la version jugée la plus appropriée pour les internautes pour chaque recherche donnée, qui pourra correspondre ou non à celle que vous préférez.

    notamment en guest blogging) inclut un lien renvoyant vers votre article original.

  • Utilisez Search Console pour indiquer à Google comment indexer votre site : vous pouvez indiquer à Google votre domaine favori (par exemple, http://www.example.com ou http://example.com).
  • Limitez les répétitions :l\’outil de gestion des paramètres
  • Évitez la publication de pages incomplètes :Meta noindex pour bloquer leur indexation.
  • Apprenez à maîtriser votre système de gestion de contenu :
  • Limitez les contenus similaires :
  • rel=\ »canonical\ » ou des redirections 301.

Si votre site a été retiré des résultats de recherche, après avoir apporté les modifications nécessaires et vous être assuré que votre site respectait ses consignes SEO, envoyez une demande de réexamen à Google.