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:
[sourcecode language= »html »]
<a href="/rubrique/mapage.html">Ma page super intéressante</a>
[/sourcecode]
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
[sourcecode language= »bash »]
# va voir là bas si j’y suis!
User-agent: *
Disallow: /
[/sourcecode]
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é:
[sourcecode language= »bash »]
RewriteCond %{SERVER_PORT} 443 [NC]
RewriteRule ^robots.txt$ robots_https.txt [L]
[/sourcecode]
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:
[sourcecode language= »php »]
<? if ($_SERVER["SERVER_PORT"] == 443) print ‘< meta name="robots" content="noindex,nofollow">’; ?>
[/sourcecode]
Encore plus radical grâce à l’en-tête X-Robots-Tag:
[sourcecode language= »php »]
<? if ($_SERVER["SERVER_PORT"] == 443) header("X-Robots-Tag: noindex, nofollow", true); ?>
[/sourcecode]
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:
[sourcecode language= »bash »]
RewriteCond %{SERVER_PORT} 443 [NC]
RewriteRule ^.*$ – [F]
[/sourcecode]
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:
[sourcecode language= »bash »]
RewriteCond %{SERVER_PORT} 443 [NC]
RewriteRule ^(.*)$ http://%{HTTP_HOST}/$1 [R=301,L]
[/sourcecode]
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.