Un site accessible en HTTP et en HTTPS est-il un site dupliqué? La réponse est oui. Vous trouverez de nombreux posts autour de ce sujet sur tous les forums SEO de la planète.
L’URL est différente, la configuration de l’un et de l’autre pouvant présenter du contenu différent, Google considère les deux URLs de manière distincte.
Grace à de règles spécifiques dans votre fichier de configuration Apache par exemple, vous pourrez aisément vous protéger du contenu dupliqué généré par un site disponible en HTTP et HTTPS.
Le danger peut venir d’ailleurs
Je voulais au travers de cet article attirer votre attention sur un point: avez-vous déjà essayé d’accéder à votre site ou blog en HTTPS ? Vous serez surpris de voir que cela fonctionne pour un certain nombre de sites (même pleins de copains SEO!).
Quelqu’un de mal intentionné pourrait donc facilement faire indexer l’ensemble de votre site en https afin de générer du contenu dupliqué. Il pourra même le faire via un seul lien si la structure de vos liens ne reprend pas le nom de domaine de votre site avec le http (sinon il devra faire indexer toutes les pages en HTTPS une à une, moins intéressant).
Exemple:
<a href="/rubrique/mapage.html">Ma page super intéressante</a>
Il me suffira de créer un lien vers https://www.domaine-ennemi.fr/rubrique/mapage.html et l’ensemble de son site pourra répondre à Googlebot en HTTPS. ça n’est jamais bon…
Les parades
Le fait que votre site soit accessible en HTTPS vient de la configuration Apache. Mais sur un serveur mutualisé (pauvre de vous), vous n’avez pas forcément la main…! Il vous suffit de bloquer l’accès à votre site si il est appelé via le protocole HTTPS ou d’en empêcher son indexation. Voilà quelques pistes afin de vous prémunir d’un éventuel contenu dupliqué lié à ce protocole sécurisé.
Avec un robots.txt spécial HTTPS
Via une règle de récriture, on va appeler un fichier robots_https.txt qui contiendra un Disallow pour l’ensemble du site
# va voir là bas si j'y suis! User-agent: * Disallow: /
Voici la règle de réécriture pour afficher le contenu du fichier robots_https.txt (que vous aurez préalablement pris le soin de placer à la racine de votre site) dans le cas où le protocole HTTPS est appelé:
RewriteCond %{SERVER_PORT} 443 [NC]
RewriteRule ^robots.txt$ robots_https.txt [L]
Mais comme je n’ai qu’une confiance limitée dans le fichier robots.txt, je vous propose une 2ème solution
Via un no-index
Vous pouvez effectivement injecter dans vos pages HTML générés par votre serveur un meta no-index pour toutes les URL en HTTPS. Il vous suffira de placer cette ligne au niveau de la section <head> de vos templates:
<? if ($_SERVER["SERVER_PORT"] == 443) print '< meta name="robots" content="noindex,nofollow">'; ?>
Encore plus radical grâce à l’en-tête X-Robots-Tag:
<? if ($_SERVER["SERVER_PORT"] == 443) header("X-Robots-Tag: noindex, nofollow", true); ?>
Bloquer l’accès via ce protocole
Dans le cas où aucune partie de votre site ne nécessite l’utilisation du protocole HTTPS (attention aux sites de e-commerce/panier/paiement), vous pouvez directement empêcher l’accès SSL pour l’intégralité du site:
RewriteCond %{SERVER_PORT} 443 [NC]
RewriteRule ^.*$ - [F]
Si jamais vous avez déjà des URL dupliquées qui sont indexées en HTTPS, nous pouvons effectuer des redirections 301 pour rediriger toutes les URL en HTTPS:
RewriteCond %{SERVER_PORT} 443 [NC]
RewriteRule ^(.*)$ http://%{HTTP_HOST}/$1 [R=301,L]
Bref…
N’hésitez pas à consulter ce topic d’SEOMoz à propos du Duplicate Content entre HTTP vs HTTPS http://www.seomoz.org/q/duplicate-content-and-http-and-https.
J’ai écris cet article pour faire petit rappel auquel on ne pense pas forcément concernant le protocole HTTP sécurisé mais aussi pour présenter quelques règles Apache pour les débutants. Promis, je ferais mieux la prochaine fois 😉
Aym.
Tu oublies aussi tout simplement la balise rel=canonical qui peut réduire de manière plus ou moins importante cette problématique (même si la balise ne la supprime pas complètement).
Pour l’avoir testé sur un site fortement dupliqué en interne, cela avait grandement améliorer le positionnement (et surtout, c’est rapide à mettre en place en attendant une solution plus complète).
Je plussoie la version de Daniel mais je me demande réellement les impacts d’une telle indexation.
Et donc, je vais de ce pas me mettre ça en todolist de test.
ça serait intéressant de voir la pénalité que pourrait ce prendre un site victime d’indexation sur les http et https, si c’est similaire au www. ou sans ou bien pondéré par le robot du moteur…
Un grand classique le https !
La solution que nous avons appliqués :
* Interdiction dans le robots.txt
* Noindex & no follow
Mais surtout une redirection 301 vers la version http à l’exception des pages nécessitant le https
Le NSEO a de beaux jours devant lui…
Intéressant. En effet c’est typiquement le genre de chose auquel on ne pense pas forcément.
Voilà un article qui tombe à pic : j’ai justement du https indéxé en masse sur mon CP pénalisé et je me suis pas encore approfondi sur la question mais ta solution semble efficace : je teste dès que je peux 😉 Thx !
Encore un billet qui aborde des sujets concrets, avec des réponses concrètes 🙂
J’ai eu ce cas de figure sur un site client et forcé la redirection vers un seul schéma d’URL. Ce client voulant un site entièrement sécurisé, j’ai du opter pour https en version canonique. Pour le moment, les performances sont au rendez-vous.
En revanche, la Toolbar ne m’affiche pas de pagerank sur quelconque page du site, une idée ?
Voici des idées pour se servir du même principe :
– les serveurs mutualisés qui proposent des sous domaines avec répertoire pour les webmasters.
– les gros sites utilisent des serveurs d’images, il y a donc duplication massive des images sur tous les serveurs.
– les ips. Chercher, et il y a parfois des sites accessibles directement via leur ip. Pinger un site. Récupérer l’ip et après, il suffit de trouver le répertoire 🙂
Il existe plusieurs methodes. La balise rel canonical peut etre interessante, les redirections,
Mais avoir le choix est toujours mieux.
le genre de chose auquel on ne pense pas du tout Oo j’aurais pensé que Google reconnaissait la connexion sécurisé et ne la considérait pas comme duplicate content ! Je vais faire les modifications de suite sur mes sites utilisant cette méthode merci !
« avez-vous déjà essayé d’accéder à votre site ou blog en HTTPS ? »
Je viens de tester sur mon blog qui est fait avec WordPress et je ne pense pas qu’un site fait avec WordPress puisse être sujet à ce genre de problème.
Et sinon, pourquoi ne pas faire une simple RewriteRule avec un flag 301 des adresses https vers http ?
C’est ce que j’ai précisé à la fin de mon article, tu n’as pas tout lu?
Si si, mais justement, je ne vois aucune règle qui correspond à une redirection de https vers http en 301.
Si cela correspond au code ci-dessous, alors je n’ai pas tout compris :
RewriteCond %{SERVER_PORT} 443 [NC]
RewriteRule ^(.*)$ http://%{HTTP_HOST}/$1 [R=301,L]
Le port 443 est retourné par une adresse HTTPS ?
Si cette bien cette règle! Le port HTTPS est par défaut sur le port 443. « Un serveur HTTP utilise alors par défaut le port 80 (443 pour HTTPS) » http://fr.wikipedia.org/wiki/Hypertext_Transfer_Protocol